littleax: Change Tracking

[macklakov]

Цитата:

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

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

Еще раз, я хочу понять применимость этой штуки. Если это лишь самые прямолинийные сценарии интеграции, ну что ж, с microsoft спорить сложно. Но может оно еще хоть на что-то годится?

Цитата:

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

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

Эти настройки обратимы? Мы сперва накатили, а потом поняли что вот конкретно этот сервис мы больше не будем пользовать. Есть более-менее простой сопособ откатить результаты работы этого скрипта?

[Vadik]

Цитата:

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

Не понимаю как "Нормально (штатно) - на уровне настроек безопасности порта и привилегий на сервисные операции" трансформировалось в "не работают". AIF вполне нормально вписан в родную систему безопасности в 2012, понимайте это как "аксовские права - работают". Применяются ли RLS (!?) и XDS - не проверял, но могу

Цитата:

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

Цитата:

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

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

Цитата:

Эти настройки обратимы? Мы сперва накатили, а потом поняли что вот конкретно этот сервис мы больше не будем пользовать

Самое простое в данной ситуации - просто отключить ненужную сервисную операцию или порт целиком и оставить все остальное как есть. Если хочется отключить настроенный change tracking - это придется джобить. Хотя накладные расходы от включения change tracking - минимальные. Чтобы за примерами далеко не ходить, Management Reporter включает change tracking на транзакционных таблицах в GL (включая GeneralLedgerAccountingEntry) - и ничего, никто от этого пока не умер

Цитата:

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

Я знаю. Но все равно хочу нормального (ок, согласен на хоть какой-то) инструментария для управления а не джобов \ классов запускаемых из AOT

[macklakov]

Цитата:

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

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

Неправильно понял, какой порт имеется в виду. Если AIF порт, то да, вопрос снят.

Цитата:

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

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

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

Цитата:

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

Management Reporter включает change tracking на транзакционных таблицах в GL (включая GeneralLedgerAccountingEntry) - и ничего, никто от этого пока не умер

Так вот как эта хрень работает!? Спасибо. Не знал. Может теперь я смогу наконец-то заставить это красочное недоразумение синхронизировать итоговые счета.

[macklakov]

Цитата:

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

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

Интересно бы было эту штуку вместо DatabaseLog использовать. Т.к. DatabaseLog читать неудобно и медленно.

Цитата:

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

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

Я специально приводил сценарий двух query c одинаковой таблицей. Парный скрипт сброса параметров вытрет слишком много, т.к. не знает о существовании другого скрипта.
Т.е. нужен список нужных скриптов и один скрипт, который стирает вообще все.

[makbeth]

Цитата:

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

Я специально приводил сценарий двух query c одинаковой таблицей. Парный скрипт сброса параметров вытрет слишком много, т.к. не знает о существовании другого скрипта.

Эта проблема в Aif решается введением параметра scope, который для разных query разный. Что в итоге приведет к созданию для одной и той же таблицы двух записей в списке таблиц с включенным CT с разным scope. При отключении query от CT одного из query будет удалена только одна запись из списка, и это не приведет к вытиранию триггеров и отключению CT для таблицы в БД при обработке списка таблиц скриптом. Соответственно, при отключении другого query запись из списка будет удалена, и скрипт, не обнаружив таблицу в списке, отключит для нее CT и удалит все изменения, которые были добавлены при включении.

[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

[Vadik]

Перенес ветку в Базу знаний

[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 и использовали богопротивные табличные методы вместо таких привычных триггеров?

[fed]

Вообще интересно наблюдать эволюцию AIF в DAX. На мой взгляд, классический подход к интеграции, под который AIF и писался - выглядит примерно так:
1. В ключевых местах системы (типа классов разносок), вставляются вызовы Biztalk (тамошних интеграционных транзакций, которые, кажется, оркестровками называются). При этом в вызов передается некоторый набор ключевых полей, которые позволяют эту операцию идентифицировать (например - ваучер).
2. Biztalkовская оркестровка чего-то там думает, и спустя какое-то небольшое время, вызывает (через Axaptовский адаптер для biztalk) AIF-класс, который по ключевым полям (возможно как-то творчески проработанным и улучшенным самим biztalk) возвращает в виде XML документ (или документы - например оркестровка может решить запросить не только накладную но и перечитать отборочную накладную и закупку).
3. Дальше оркестровка как-то трансформирует документ, передает в посторонние приложения, возможно потом получив от них ответ обновляет какие-то документы в Аксапте (возможно снова через AIF).
Даже если Biztalk не использовался - парадигма была такая - по некоторым событиям Аксапта пинает стороннее приложение и стороннее приложение через AIF читает/пишет документы, как-то связанные с событием.

На практике партнеры Biztalk не знали, а клиенты из за астрономической цены его не покупали. В результате, партнеры начитавшиеся Микрософтовской рекламы, писали чудовщиные имплементации, при которых какие-то кривые батчи как-то вызывали AIF и чего-то там импортировали. При этом никакие события не отслеживались и эти батчики просто пытались сканировать таблицы по датам обновления или по номеру обновившей транзакции.

В итоге - Микрософт создал альтернативу существующему партнерскому подходу. С одной стороны - этот подход явно культурнее, чем то что я видел на реальных внедрениях. С другой - лучше бы они Biztalk популяризовали и продавали бы за менее сумасшедшие деньги. Все-таки идея событий и документов выглядит гораздо естественнее идеи просканировать изменения и дедуктивным методом понять что с данными происходило...

[mazzy]

угу.

Цитата:

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

лучше бы они Biztalk популяризовали и продавали бы за менее сумасшедшие деньги.

Biztalk закрыт и больше не развивается майкрософтом.

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

[mazzy]

Цитата:

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

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

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

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

[mazzy]

Цитата:

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

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

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

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

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

[fed]

Цитата:

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

угу.


Biztalk закрыт и больше не развивается майкрософтом.

Вот тут пишут что не закрыт, а даже пытается возродиться (хотя - как всегда после изрядной потери в умных головах...) Источник достаточно авторитетный в бизтолковских кругах.

[Vadik]

Цитата:

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

Даже если Biztalk не использовался - парадигма была такая - по некоторым событиям Аксапта пинает стороннее приложение и стороннее приложение через AIF читает/пишет документы, как-то связанные с событием

Скорее - маааленький шажок в облегчении продвижения продвижении AX как MDM системы "в центре", в которой ведутся все мастер-данные, с готовыми унифицированными интерфейсами для их "вытягивания", а вспомогательные системы к ней подстраиваются и синхронизуются, забирая изменения. Не царское это дело - из учетной системы одни и те же мастер-данные push-ить в десять приложений в пяти форматах по трем протоколам - от подсчета денег отвлекает

[mazzy]

Цитата:

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

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

Бггг!!!! блин, но ты то вроде давно...
представляешь какая каша в голове у молодежи?

Аксапта появилась ОЧЕНЬ давно.
http://axapta.mazzy.ru/lib/names/ (внизу историческая справка)

(ударил по гулсям и закатил глаза... затянул глухим глоосом)
в те времена:
1. SQL еще не был стандартом
2. не было одного-двух лидеров на рынке платформ баз данных
3. аксапта поддерживала несколько баз данных - я видел перечисление на 12 баз. в том числе DBF, mySQL, postgreSQL... был и собственный формат базы данных (он сейчас остался до 2009 в виде AOD файлов, c 2012 и его прибили)
4. "привычных" триггеров еще не было (если кто помнит времена MS SQL 6.5, oracle 7...) а в ранних mySQL триггеров вообще не было. не говоря уже о DBF

(нормальным голосом)
в связи с этим и были сделаны собственные унифицированные триггеры.
а потом пошла эволюция и коэволюция вместе с платформами баз данных. например, skip-методы появились относительно недавно, уже при MS вроде.

Upd: ну, а решение, что Аксапта не поддерживает Oracle, а работает только на одном MS SQL, вообще было принято очень кроваво и только начиная с ax2009

[mazzy]

Цитата:

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

Вот тут пишут что не закрыт, а даже пытается возродиться (хотя - как всегда после изрядной потери в умных головах...) Источник достаточно авторитетный в бизтолковских кругах.

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

конечно, может это я не умел его продавать.

[macklakov]

Цитата:

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

Бггг!!!! блин, но ты то вроде давно...

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