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()

[Ivanhoe]

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

[macklakov]

Цитата:

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

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

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

[macklakov]

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

[Ivanhoe]

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

[makbeth]

Цитата:

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

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

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

[Vadik]

Цитата:

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

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

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

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

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

[Vadik]

Цитата:

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

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

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

[makbeth]

Цитата:

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

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

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

[skuull]

Можно еще посмотреть класс RetailCDXDataSync он тоже использует Change Tracking для синхронизации AX базы с POS базой. Пришел как раз на смену кода в insert(), update(), delete().
О чем уже писал выше Ivanhoe

[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 и сделано)?

[macklakov]

Цитата:

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

Можно узнать - зачем (в сценариях интеграции) ?

Пытаюсь понять применимость нового, для меня, инструмента.

Цитата:

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

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

Замечательно. Я в Dev настроил change tracking на 2 разные Query, обе содержат MainAccounts. Написал инструкции по деплойменту в других приложениях. В UAT, юзера сообразили, что одна из query надо убрать, т.к. эти данные расстраивают смежную систему и их надо как-то по другому выдавать. Мне теперь надо убрать изменения произведенные скриптом для этой query на sql сервере. И потом накатить эти изменения на sysTest, SIT и UAT. Есть для этого другой специально обученный скрипт? И что произойдет с настройками для другой Query, которая тоже включает MainAccounts?

Цитата:

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

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

Ну т.е. аксовские права, особенно RLS не работают?

Цитата:

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

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

Они ведь ресурсы жрут, если правильно понимаю?

[macklakov]

Цитата:

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

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

А как посомотреть старые и новые значения поля в таблице?

Цитата:

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

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

Управление модификациями. Как мне перенести то, что этот скрипт нагенерил? Как откатить? Как контролировать версии?

[makbeth]

Цитата:

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

А как посомотреть старые и новые значения поля в таблице?

Это как раз умеет Change Data Capture. В как я уже писал, в Aif реализованы зачатки его поддержки. Видимо еще нигде не пригодился.

Цитата:

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

Управление модификациями. Как мне перенести то, что этот скрипт нагенерил? Как откатить? Как контролировать версии?

Зачем переносить то, что нагенерил скрипт? Правильнее перенести скрипт в новую среду и дать ему нагенерить то что нужно.
Откат делается парным скриптом. По моему, это очевидно, когда функционал позволяет включать/отключать свои возможности для определенных объектов системы.

[Vadik]

Цитата:

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

А как посомотреть старые и новые значения поля в таблице?

Ну зачем в сценариях интеграции передавать "старое значение поля" ? А что внешняя система будет делать с моим "старым" значением из AX если ее (системы) "старое" (текущее) отличается ? А какое именно "старое" значение поля передавать (и откуда его брать) в случае если у меня внешних систем несколько - отслеживать еще и версию для каждой внешней системы отдельно в AX ? Нет, я понимаю, это круто, но - ЗАЧЕМ ?

Цитата:

Управление модификациями. Как мне перенести то, что этот скрипт нагенерил? Как откатить?

Эти модификации не нужно переносить потому что это не модификации как таковые а вспомогательные объекты \ настройки которые AIF сам создаст при разворачивании \ настройке сервиса в новой среде

Цитата:

Как контролировать версии?

У этих вспомогательных объектов сгенерированных автоматически версионность как таковая отсутствует, потому что генерятся они одинаковыми
Из того, что реально не хватает - это хоть какой-то инструментарий в виде пары-тройки форм для управления \ просмотра того что уже настроено (хотя репозитарий со списком таблиц со всключенным Change tracking и созданных триггеров присутствует)

[makbeth]

Цитата:

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

Из того, что реально не хватает - это хоть какой-то инструментарий в виде пары-тройки форм для управления \ просмотра того что уже настроено (хотя репозитарий со списком таблиц со всключенным Change tracking и созданных триггеров присутствует)

Так там, собственно, кроме указанных табличек создается только одна хп, которая при вызове включает CT для указанных в репозитарии табличек, и отключает для тех, которых в списке нет. И... все. Остальное делается прямыми запросами, формируемыми в коде классов AifChangeTracking*.