AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 24.03.2021, 11:55   #81  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
120 / 284 (10) ++++++
Регистрация: 25.01.2007
Адрес: Kyiv
Цитата:
Сообщение от 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
За это сообщение автора поблагодарили: EVGL (2), gl00mie (5), trud (5).
Старый 24.03.2021, 12:41   #82  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,581 / 1750 (66) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Речь шла о выгрузке из AX2012
__________________
-ТСЯ или -ТЬСЯ ?
Старый 25.03.2021, 05:08   #83  
trud is offline
trud
Участник
Лучший по профессии 2017
 
982 / 1370 (47) ++++++++
Регистрация: 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
Просмотров: 11
Размер:	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).
Старый 01.04.2021, 09:11   #84  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
120 / 284 (10) ++++++
Регистрация: 25.01.2007
Адрес: Kyiv
Цитата:
Сообщение от 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. Ох глюкавая... Но вроде завелась.
За это сообщение автора поблагодарили: Vadik (1).
Теги
aif, ax2012, change tracking, интеграция, как правильно

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
AX2012 Общие справочники поставщиков и клиентов PTG DAX: Функционал 2 11.06.2015 15:39
Импорт адресов для существующих клиентов и поставщиков IKA DAX: Программирование 0 10.12.2013 21:04
ax 3.0 Экспорт справочников во внешнюю систему, по какому ключу связаться? Shakr DAX: Программирование 2 11.11.2008 11:34
Сергей Герасимов: О технической поддержке клиентов по продуктам Microsoft Dynamics Blog bot DAX Blogs 4 13.02.2007 14:58
Коды клиентов в CRM - проблема Zabr DAX: Функционал 5 01.12.2003 12:41
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 12:59.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.