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

[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. Ох глюкавая... Но вроде завелась.