Показать сообщение отдельно
Старый 25.03.2021, 05:08   #83  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Спасибо, для D365 тоже было бы интерестно обсудить
Цитата:
Сообщение от vmoskalenko Посмотреть сообщение
1. написать свою Data Entity. Кстати, для performance - это best practice. Помним, что CustomersV3 - одна из самых тяжелых data entity.
Да, по поводу написать свою, поддерживаю. Но зачем. Что делать если данные не укладываются в ентити? из недавнего - нужно передавать e-mail клиента из настроек принт менеджмента, который хранится в контейнере
CustomersV3 содержит около 900 строчек кода. Чем это лучше методов логирования из 1 строчки(insert, updated, delete) на таблицах входящих в нее
Есть мнение что методы логирования это не бест практис, то как бы MS их тоже активно использует
Нажмите на изображение для увеличения
Название: 2021-03-25_12-20-31.png
Просмотров: 33
Размер:	58.6 Кб
ID:	13152

Цитата:
Сообщение от 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, другой оттуда забирает)
Требования которые надо будет реализовать могут быть к примеру один файл на клиента, файл должен быть определенной структуры с определенным названием. Зачем это все кодить во внешнем приложении?

Последний раз редактировалось trud; 25.03.2021 в 05:23.
За это сообщение автора поблагодарили: vmoskalenko (4).