littleax: Change Tracking

[Blog bot]

Источник: http://littleax.blogspot.com/2015/06...-tracking.html
==============

SMART TALKS

Dynamics AX

Change Tracking в Dynamics AX 2012



Преллагаю небольшой видео блог по Change Tracking в Dynamics AX 2012. Основные принципы работы с отслеживанием изменений, возможности, рекомендации.

http://smart-talks.org/event/smart-talks-2/

Источник: http://littleax.blogspot.com/2015/06...-tracking.html

[Vadik]

Рекомендую посмотреть тем кто уже использует AIF в AX 2012, но не знаком с change tracking

[Vadik]

Если кто-то решит использовать change tracking на инстансе с несколькими partitions \ legal entities, сразу надо править
\Classes\AifChangeTracking\createJoinClausesAndPredicates
\Classes\AifSqlCtChangeTracking\createRootTableJoin
на предмет потерянных джойнов по Partition и DataAreaId полям. Иначе гарантированы тормоза и местами некорректные результаты выборки в getChangedKeys()

[Alex_KD]

Цитата:

Сообщение от Vadik

Если кто-то решит использовать change tracking на инстансе с несколькими ...

Пару дополнительных граблей на которые успел натолкнуться:

• Если используется R3 Retail, то стандартные AIFCT классы могу отключить CT на всех таблицах, которые синхронизируются с POS.
  
• АХ не умеет синхронизировать таблицу в случае изменения индекса PK (SQL требует отключения CT вручную).
  
• AX не умеет включать CT в случае если при синхронизации таблицу надо пересоздать по каким либо причинам в SQL (DROP Table + Create Table в SQL теряет CT). Наверное тригеры при этом тоже летят нафиг ...

Из позитива - быстро, надежно, не надо думать кто и где поменял, добавил или удалил данные, т.к. CT отслаживает все.
То что МС двигается (меееедленно) в сторону использования существующих технологий это очень даже хорошо. SQL должен такие дела отслеживать, а не AX. CT существует с 2008 года, почему не встроили его в AX раньше непонятно....

Насколька я знаю, на данный момент CT используется в -

• POS R3
• MDM
• AIF

[Vadik]

Цитата:

Сообщение от Alex_KD

Пару дополнительных граблей на которые успел натолкнуться

Спасибо

Цитата:

CT существует с 2008 года, почему не встроили его в AX раньше непонятно...

Как вариант - потому что для AX 2009 была заявлена совместимость с SQL Server 2005

[makbeth]

Цитата:

Сообщение от Alex_KD

ПЕсли используется R3 Retail, то стандартные AIFCT классы могу отключить CT на всех таблицах, которые синхронизируются с POS.

Здесь классическое "правая рука не знает что делает левая". Дело в том, что AIFCT не включает/выключает CT для какой-то отдельной нужной таблицы, а фактически перебирает все таблицы базы на предмет включен ли CT для каждой из них. И если эта таблица отсутствует в его, AIF, списке разрешенных таблиц CT, но CT для нее включен, то он его отключает. И наоборот.
Очевидно, для POS реализован отдельный механизм включения CT, поэтому AIF про таблицы для POS ничего не знает и в итоге происходит такой вот сюрприз.
Видимо, над AIF и POS работали разные команды, в итоге имеем то что имеем
А вообще, это повод запостить багу в MS, ибо на продакшене может вылезти неприятный такой "ой"...

[macklakov]

Цитата:

Сообщение от makbeth

Здесь классическое "правая рука не знает что делает левая"

Хм... Так для чего же тупые датчане в AX всю логику перенесли в AOT и использовали богопротивные табличные методы вместо таких привычных триггеров?

[mazzy]

Цитата:

Сообщение от makbeth

для POS реализован отдельный механизм включения CT, поэтому AIF про таблицы для POS ничего не знает и в итоге происходит такой вот сюрприз.

Видимо, над AIF и POS работали разные команды, в итоге имеем то что имеем
А вообще, это повод запостить багу в MS, ибо на продакшене может вылезти неприятный такой "ой"...

угу. они знают. но запосить все равно стоит.

разные команды... не то слово! блин...

[mazzy]

Цитата:

Сообщение от Alex_KD

CT существует с 2008 года, почему не встроили его в AX раньше непонятно....

решения, которые сейчас используют Change Tracking изначально появились раньше 2008 года. как партнерские решения.

пока их купили, пока встроили в аксапту, пока ужаснулись и пока таки решили что надо что-то делать... наоборот, очень быстро

[macklakov]

Цитата:

Сообщение от Vadik

Рекомендую посмотреть тем кто уже использует AIF в AX 2012, но не знаком с change tracking

Спасибо конечно, но я так и не понял зачем эта приблуда нужна. Такое ощущение, что все эти пляски с бубнами и жонглирование топорами ради того чтобы иммитировать changedDate.
Но очень полезно знать о ее существовании, чтобы знать где еще стоит рыть, когда SQL сервер неожиданно ляжет.

[Vadik]

Цитата:

Сообщение от macklakov

Спасибо конечно, но я так и не понял зачем эта приблуда нужна. Такое ощущение, что все эти пляски с бубнами и жонглирование топорами ради того чтобы иммитировать changedDate

Это ни разу не имитация, там плюшек, свистелок и перделок по сравнению с "решениями на коленке" - вагон и маленькая тележка если вдуматься

• все изменения отслеживаются на уровне SQL Server-а, т.е. железобетонно, никаких skipDatabaseLog и пр.
• если у нас сущность многоуровневая (см. к примеру клиентов\поставщиков с их адресами и контактами), не надо везде пропихивать код для отслеживания изменений на нижних уровнях или собирать эти изменения по всем уровням. Пример: клиенту добавился номер факса в GAB, и весь клиент теперь виден как измененная сущность. Удобно, нет ?
• очень удобно когда подписчиков на изменения много. Вернее, нам вообще фиолетово сколько их, этих подписчиков. Мы просто выставили наружу порт и объявляем в течение какого максимального периода в нем видны измененные данные (допусти, две недели). А подписчики уже сами решают как забирать эти изменения. Допустим, утягивать изменения за последний час каждый час или изменения за неделю каждый день. Нам - все равно. Мы не пропихиваем свои изменения каждому подписчику, мы не отслеживаем доставку каждого изменения отдельным сообщением, мы не должны заботиться о доставке каждого сообщения каждому подписчику и правильном порядке их доставки. Подключение нового подписчика происходит абсолютно прозрачно
• качественно реализована обработка массивных изменений через paging. При запросе к системе в которой может ждать до нескольких десятков тысяч измененных сущностей (реальный пример) я могу "попросить" getChangedKeys() выдавать результат порциями по 1000 записей, обрабатывать ее и запрашивать следующую. Всякого рода пляски с бубном вокруг настроек размеров буферов WCF на сервере\клиенте\прокси отсутствуют как класс
• при включении change tracking начинают работать Document filters (какая связь между ними - не спрашивайте, не знаю, скорее всего "так получилось"). Пример - отдавать внешней системе только определенные группы клиентов или отдавать курсы только определенного типа для USD. Возможности по настройке фильтров - те же что и у стандартного Query в AX.

Удобно, нет ? Да, документация и инструментарий по настройке к сожалению желают желать лучшего, но функционал сам по себе рулит

[macklakov]

Цитата:

Сообщение от Vadik

[*]все изменения отслеживаются на уровне SQL Server-а, т.е. железобетонно, никаких skipDatabaseLog и пр.

Если я пользую DatabaseLog, то я ожидаю версионирования полноценного. А CT этого не дает.

Цитата:

Сообщение от Vadik

[*]если у нас сущность многоуровневая (см. к примеру клиентов\поставщиков с их адресами и контактами), не надо везде пропихивать код для отслеживания изменений на нижних уровнях или собирать эти изменения по всем уровням. Пример: клиенту добавился номер факса в GAB, и весь клиент теперь виден как измененная сущность. Удобно, нет ?

Но я ведь правильно понимаю, что это происходит не само по себе, а специально обученный скрипт должен пройтись, проставить свойства на таблицах и прописать триггеры?

Цитата:

Сообщение от Vadik

[*]очень удобно когда подписчиков на изменения много. Вернее, нам вообще фиолетово сколько их, этих подписчиков. Мы просто выставили наружу порт и объявляем в течение какого максимального периода в нем видны измененные данные (допусти, две недели). А подписчики уже сами решают как забирать эти изменения. Допустим, утягивать изменения за последний час каждый час или изменения за неделю каждый день. Нам - все равно. Мы не пропихиваем свои изменения каждому подписчику, мы не отслеживаем доставку каждого изменения отдельным сообщением, мы не должны заботиться о доставке каждого сообщения каждому подписчику и правильном порядке их доставки. Подключение нового подписчика происходит абсолютно прозрачно

А как у нас с правами, компаниями, партициями?

Цитата:

Сообщение от Vadik

[*]при включении change tracking начинают работать Document filters (какая связь между ними - не спрашивайте, не знаю, скорее всего "так получилось"). Пример - отдавать внешней системе только определенные группы клиентов или отдавать курсы только определенного типа для USD. Возможности по настройке фильтров - те же что и у стандартного Query в AX.

Это хорошо или плохо?

[Vadik]

Цитата:

Сообщение от macklakov

Если я пользую DatabaseLog, то я ожидаю версионирования полноценного. А CT этого не дает

Можно узнать - зачем (в сценариях интеграции) ? CT выдает недавно измененные сущности по состоянию "на сейчас". Как мы к этому состоянию пришли, сколько было промежуточных версий, какова их хронология - а какая собственно разница ? При "правильном" накатывании всех изменений я в лучшем случае прихожу к состоянию "на сейчас", в неидеальном сценарии - к одному из промежуточных (не факт что правильных). Из change tracking я получаю измененную сущность в актуальном состоянии "на сейчас" в одну итерацию либо не получаю ее вовсе (например, "лежит" канал)

Цитата:

Но я ведь правильно понимаю, что это происходит не само по себе, а специально обученный скрипт должен пройтись, проставить свойства на таблицах и прописать триггеры?

Не само по себе. У меня на все про все один класс с 25 строками в main, из них примерно половина - вывод отладочной информации. Чтобы включить change tracking для нового документа AIF, надо в одной строке поменять имя используемого Query

Цитата:

А как у нас с правами, компаниями, партициями?

Нормально (штатно) - на уровне настроек безопасности порта и привилегий на сервисные операции

Цитата:

при включении change tracking начинают работать Document filters

Цитата:

Это хорошо или плохо?

Document filters можно не использовать, но любой новый работающий функционал это как минимум не плохо

[makbeth]

Цитата:

Сообщение от macklakov

Если я пользую DatabaseLog, то я ожидаю версионирования полноценного. А CT этого не дает.

Дает. Фиксируются все изменения, причем каждое изменение порождает новую версию в CT. Т.е. ровно те же возможности, что дает DatabaseLog. Особенность в том, что версии на SQL хранятся только ограниченное время (2 дня по умолчанию) и нужно периодически эти изменения считывать, чтобы они не потерялись.

Цитата:

Сообщение от macklakov

Но я ведь правильно понимаю, что это происходит не само по себе, а специально обученный скрипт должен пройтись, проставить свойства на таблицах и прописать триггеры?

В чем проблема написать специально обученный скрипт(ы) один раз и использовать его для любой таблицы (что собственно в 2012 и сделано)?

[mazzy]

Цитата:

Сообщение от macklakov

ради того чтобы иммитировать changedDate.

да, идея та же. реализация намного мощнее и лучше

Цитата:

Сообщение от Ivanhoe

Еще интеграция с POS начиная с R3 переведена на SQL change tracking...

угу. потому что...

Цитата:

Сообщение от Vadik

очень удобно когда подписчиков на изменения много.

помимо того, что Vadik сказал:
каждый подписчик получает свой набор изменений

предположим один подключается в изменениям раз в час, а другой подключается раз неделю. второй получит больший набор изменений как только подключится.

и да... это работает ОООООЧЕНЬ быстро по сравнению с аксаптовскими штатными вещами.
плюс масштабирование от SQL хорошее.

[Ivanhoe]

А кто-нить копал уже внутрь? Работа с SQL в ядре или доступна для просмотра в X++? Например, на 2009 или 4.0 можно портировать?

[Vadik]

Цитата:

Сообщение от Ivanhoe

А кто-нить копал уже внутрь? Работа с SQL в ядре или доступна для просмотра в X++? Например, на 2009 или 4.0 можно портировать?

Насколько я вижу - ничего ядро-специфичного не используется

[makbeth]

Цитата:

Сообщение от Vadik

Насколько я вижу - ничего ядро-специфичного не используется

Есть специфика 2012 - временная таблица TempDB используется для получения истории изменений для выбранной таблицы. Заполняется прямым запросом на SQL используя команды Change Tracking, а вот данные потом уже обрабатываются в AX.

[macklakov]

P.S. Пересмотрел, кажись понял. Т.е. из скрипта нафигачить триггеров, на все таблицы входящие в query рассматривается более кошерным подходом по сравнению со скриптом, который пройдется по той же query и пропишет строчки в insert/update методы.
Виталию спасибо за разъяснения. Хоть и считаю это бредовым нововедением, но теперь хотя бы знаю в чем оно заключается.

[makbeth]

Цитата:

Сообщение от macklakov

P.S. Пересмотрел, кажись понял. Т.е. из скрипта нафигачить триггеров, на все таблицы входящие в query рассматривается более кошерным подходом по сравнению со скриптом, который пройдется по той же query и пропишет строчки в insert/update методы.

На самом деле триггеры в AIFCT вешаются для того, чтобы при изменениях данных в приджойненных таблицах "потрогать" родительскую табличку. Например, если CT настроен на заголовок сложного документа, то при изменении его строк заголовок также поменяет свою версию в change tracking'е, попав таким образом в историю изменений, хотя по факту в самой таблице заголовка изменений не было. В остальном же - вполне годный функционал для отслеживания изменений, основанный на встроенном функционале SQL Server.
Кстати говоря, сейчас в 2012 реализована поддержка lite-версии функционала SQL - Change Tracking, который позволяет фиксировать сам факт того, что в таблице что-то изменилось. Есть еще более продвинутый (и более тяжеловесный) Change Data Capture, который позволяет также узнать какие произошли изменения с данными в таблицах. Задел под это в 2012 в некоторых местах есть в виде throw заглушек.