Выгрузка измененных клиентов во внешнюю систему

[trud]

Спасибо за комментарии.
По итогу оценил переделку в 3 дня, если согласуют, напишу чем закончилось. Это у них работает сейчас(с фильтром по "или" по дате модифиции по всем таблицам в запросе, я выше приводил пример), каждый вызов занимает минуту-полторы, подгружая в постоянном режиме где-то 6 ядер на 100% CPU, при этом большинство запросов возвращают пусто

[Vadik]

Пока разминался красненьким работал над небольшим POC, решил прогнать тест:

Дано: 5M клиентов более-менее равномерно (500К - 1.3М) распределены по 5 компаниям
В сутки обновляется (Insert/Update) 0.1% клиентов

Вопрос: что нам будет стоить идентицифировать обновленных клиентов с помощью Change tracking ?

Потрачено времени:

• Сгенерировать и импортировать данные через DMF - 4 дня
• Оттюнить AifSqlCtChangeTracking - 4 часа

Тестируем:

• Случайным образом обновляем данные по всем уровням AxdCustomer (это в некотором роде в сумме более 0.1% данных, ну и ладно)
• Запускаем незатейливый джобик в самой большой компании (1.3М клиентов)

Итого: на бюджетной VM в Azure (B4Ms, 4xvCPU, 16 GB RAM, standard HDD) список измененных клиентов (CustTable.RecId) мы получаем за 5 секунд (достаточно шустро). Без перекрытия прочего стандартного кода в .insert(), .update(), event handler-ов и shadow таблиц (просто). Для всех обновлений, в том числе и извне AX (надежно)

[trud]

Ну тест то как раз показывает что change tracking не всегда будет лучшим выбором. Т.е. никакие данные с точки зрения внешней системы вообще не изменились, а у вас выгрузились тысячи клиентов
Плюс все эти выгрузки полностью непрозрачны для пользователя, т.е. он не видит что и когда выгружалось
Плюс сам тест очень простой. Если удалить к примеру e-mail будет работать? Клиентов как правило требуется выгружать не всех, а принадлежащей определенной группе(при этом группу у клиента можно менять), это поддерживается?

[Vadik]

Цитата:

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

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

Change tracking честно говорит что менялось в AX в указанном отрезке времени. Какие из этих изменений актуальны для "внешней системы" (в общем случае - для "внешних систем"), в каком они сейчас состоянии - с этим пусть разбираются сами внешние системы

Цитата:

Плюс все эти выгрузки полностью непрозрачны для пользователя, т.е. он не видит что и когда выгружалось

Мы еще ничего никуда не выгружаем, мы просто спросили систему "что нового". Кто такие пользователи, что они видят, что им "непрозрачно" - пока непонятно

Цитата:

Плюс сам тест очень простой

Ну уж какой есть

Цитата:

Если удалить к примеру e-mail будет работать?

Конкретно для AxdCustomer и email - нет, потому что запрос использует не "физические" таблицы а DirPartyPostalAddressView и DirPartyContactInfoView. Для "физических" таблиц удаления отслеживаются (см. скриншот). Как интеграция отслеживает удаление данных (и должна ли) - это отдельная тема сама по себе

Цитата:

Клиентов как правило требуется выгружать не всех, а принадлежащей определенной группе(при этом группу у клиента можно менять), это поддерживается?

Да. AifChangeTracking::construct() принимает Query в качестве аргумента

Цитата:

Ну тест то как раз показывает что change tracking не всегда будет лучшим выбором

А кто-то утверждал что CT это "лучший" выбор, "всегда" ? Я например знаю сценарии где CT работает плохо и для них его предлагать не буду. Тест показывает решение поставленной задачи с неплохими (как мне кажется) трудозатратами, производительностью и надежностью. Кто захочет - попробует. Если будут альтернативные решения, с удовольствием на них посмотрю. Окажутся проще, быстрее, удобнее - буду иметь их в виду

[trud]

Цитата:

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

Да. AifChangeTracking::construct() принимает Query в качестве аргумента

Так а что туда передавать? Ну т.е. вчера клиент принадлежал группе выгрузки и выгружался, сегодня ему поменяли группу на невыгружаемую. Нужно же как уведомить внешнюю систему об этом
Ну пока "insert(), .update() delete()" мне видится единственным правильный подходом, т.е. это будет гарантированно работать в любом случае, плюс позволит покрыть все возможные "хотелки"
Хотя тут возможно ошибка выжившего, когда оно работает нормально, консалтинг не зовут, а мы видим только когда оно не работает

[Vadik]

Цитата:

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

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

Ну это наверное лучше с клиентскими постановщиками обсудить

Цитата:

Ну пока "insert(), .update() delete()" мне видится единственным правильный подходом, т.е. это будет гарантированно работать в любом случае, плюс позволит покрыть все возможные "хотелки"

Аминь

[vmoskalenko]

Цитата:

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

Ну тест то как раз показывает что change tracking не всегда будет лучшим выбором. Т.е. никакие данные с точки зрения внешней системы вообще не изменились, а у вас выгрузились тысячи клиентов
Плюс все эти выгрузки полностью непрозрачны для пользователя, т.е. он не видит что и когда выгружалось

Вам шашечки или ехать? Вам инкрементальную выгрузку данных или систему логирования данных?

Цитата:

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

Плюс сам тест очень простой. Если удалить к примеру e-mail будет работать?

Должно.

Цитата:

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

Клиентов как правило требуется выгружать не всех, а принадлежащей определенной группе(при этом группу у клиента можно менять), это поддерживается?

Ну кто мешает
1. написать свою Data Entity. Кстати, для performance - это best practice. Помним, что CustomersV3 - одна из самых тяжелых data entity.
2. Добавить defaultCTQuery метод как описано тут https://docs.microsoft.com/en-us/dyn...hange-tracking
3. Накладывать фильтр прямо в DMF на Data Entity. Кстати, там же, в определении Export Group, можно задать инкрементальную выгрузку данных.
4. Вызывать вот это вот всё извне через DMF API https://docs.microsoft.com/en-us/dyn...pi#import-apis и еще с картинками вот тут https://github.com/microsoft/Recurri...iki#export-job

[Vadik]

Речь шла о выгрузке из AX2012

[trud]

Спасибо, для D365 тоже было бы интерестно обсудить

Цитата:

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

1. написать свою Data Entity. Кстати, для performance - это best practice. Помним, что CustomersV3 - одна из самых тяжелых data entity.

Да, по поводу написать свою, поддерживаю. Но зачем. Что делать если данные не укладываются в ентити? из недавнего - нужно передавать e-mail клиента из настроек принт менеджмента, который хранится в контейнере
CustomersV3 содержит около 900 строчек кода. Чем это лучше методов логирования из 1 строчки(insert, updated, delete) на таблицах входящих в нее
Есть мнение что методы логирования это не бест практис, то как бы MS их тоже активно использует

Цитата:

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

2. Добавить defaultCTQuery метод как описано тут https://docs.microsoft.com/en-us/dyn...hange-tracking

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

Цитата:

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

3. Накладывать фильтр прямо в DMF на Data Entity. Кстати, там же, в определении Export Group, можно задать инкрементальную выгрузку данных.

С фильтром сложно, поле группа клиентов может меняться, как обрабатывать смену с той группы которая выгружалась, на ту которую уже не надо выгружать(фильтр же ее отсечет автоматом)?

Цитата:

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

4. Вызывать вот это вот всё извне через DMF API https://docs.microsoft.com/en-us/dyn...pi#import-apis и еще с картинками вот тут https://github.com/microsoft/Recurri...iki#export-job

Ну тут надо определить что мы хотим(потратить больше времени или меньше). Если меньше, то внедрение в работу системы внешнего приложения резко повысит трудоемкость ее поддержки. Т.е. вам надо будет поддерживать несколько репозиториев, разворачивать отдельные версии для разработки, теста и прочее. Нужно будет делать мониторинг этой программы, плюс останавливать ее когда останавливается АХ.
(DXC кстати продает аналогичную доработку, но в D365, 2 джоба, один из которых выгружает данные в DM, другой оттуда забирает)
Требования которые надо будет реализовать могут быть к примеру один файл на клиента, файл должен быть определенной структуры с определенным названием. Зачем это все кодить во внешнем приложении?

[vmoskalenko]

Цитата:

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

Спасибо, для D365 тоже было бы интерестно обсудить

Да, по поводу написать свою, поддерживаю. Но зачем. Что делать если данные не укладываются в ентити?

Вот тут Nathan Clouse выкладывает свои презентации. И вот как раз о быстродействии OData/Data Entity
https://github.com/NathanClouseAX/Co...-%20OData.pptx

Цитата:

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

Ну тут надо определить что мы хотим(потратить больше времени или меньше). Если меньше, то внедрение в работу системы внешнего приложения резко повысит трудоемкость ее поддержки. Т.е. вам надо будет поддерживать несколько репозиториев, разворачивать отдельные версии для разработки, теста и прочее. Нужно будет делать мониторинг этой программы, плюс останавливать ее когда останавливается АХ.
(DXC кстати продает аналогичную доработку, но в D365, 2 джоба, один из которых выгружает данные в DM, другой оттуда забирает)
Требования которые надо будет реализовать могут быть к примеру один файл на клиента, файл должен быть определенной структуры с определенным названием. Зачем это все кодить во внешнем приложении?

Да. Я тоже такое делал. Интеграция с CRM написанная полностью на X++ для D365FO. Применял дважды. В первый раз, потому что родного от Майкрософта еще не существовало. Второй раз, потому что логика была сложная. Надо было для каждой единицы товара создавать одну отдельную строку в ISV решении.

А вот сейчас бьюсь с Dual Write. Ох глюкавая... Но вроде завелась.