Интеграция - использовать стандарт или писать на коленке ?

[Vadik]

Цитата:

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

Тут в Яммере Сунил задал вопрос "Какие Anti-patterns при работе с data entities вы знаете". В тему внесены 22 ответа за два дня. Перечислены все области функционала, кроме примитивного одноразового импорта ограниченного числа строк.

И есть реально что-то интересное кроме паттернов которые сам MS настоятельно просит не использовать во всех techtalks, вроде объемного data management и Power BI через OData? Что для упоротых эти рекомендации не указ, в общем и так было понятно

P.S. суд по количеству лайков под постом trud о том, что подбирать надо не лучшую технологию "вообще", а технологию под конкретную задачу - прочитали его многие, поняли и оценили не все. Ничего личного, просто мысли вслух

[ax_mct]

Цитата:

Импорт JSON текстовых файлов. А подойдет DMF для update? Все изменения (246 полях из 39 таблиц) должны приниматься AX.
И AIF тоже выглядит вкусно как готовый шаблон который можно местами расширить, местами сдублировать.

JSON не поддерживается, в вот почему: https://www.mssqltips.com/sqlservert...tion-services/
Для update подойдет. Там, где это можно, entity работают в режиме UPSERT, пользуемся этим каждый день.
Про AIF уже все было сказано.

Извините, в который раз отредактировал вместо того, чтобы ответить.

[ax_mct]

Цитата:

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

Но сейчас у меня задача выбора архитектуры и создания рабочего прототипа.
Есть AX2012R3 и есть отдельная система master data management в которую должно быть передано управление номенклатурой товаров со всеми этими 30 таблицами вокруг этого.
2 совещания сегодня, есть список из 200-300 полей в 20-30 таблицах в AX которые должны обновляться из этой другой системы.

DMF и web-service отвергнуто клиентом самостоятельно.

Задача создания предельно стандартной коленки чтения из JSON файлов.

Цитата:

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

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

Цитата:

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

Убедить клиента, что он не прав и надо использовать DMF. Может быть, даже создать свой набор упрощенных классов, а не заморачиваться со стандартными. Импортировать текстовые файлы.
...
JSON не поддерживается, в вот почему:
...
Для update подойдет. Там, где это можно, entity работают в режиме UPSERT, пользуемся этим каждый день.
Про AIF уже все было сказано.

Делюсь опытом. Честно покопался в DMF, поиграл с AIF, в результате сделал коленку. DMF это зависимость от DLL, а AIF это использование XML и AIF настроек. За то время за которое я сделал свой фреймворк я бы только разбирался с очередной ошибкой в DMF или AIF. То есть точно то что уже говорилось в теме.

Сложный фреймворк - простой/стандартный бизнес процесс. Настроить без программирования.
Простой фреймворк - сложный бизнес процесс. Только с простым можно программировать.

Использование DMF, AIF для программирования противоречит 3 закону кибернетики.
Только простой фреймворк может компенсировать Agile и нестандартные но при этом логичные требования клиента.

[trud]

Цитата:

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

За то время за которое я сделал свой фреймворк я бы только разбирался с очередной ошибкой в DMF или AIF.

Это положительный момент или отрицательный? (ну т.е. могли к примеру зачаржить 150часов, а зачаржили 40)

[ax_mct]

Цитата:

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

Это положительный момент или отрицательный? (ну т.е. могли к примеру зачаржить 150часов, а зачаржили 40)

Хороший вопрос. Одномоментно может быть но не в средней перспективе.
Один раз зачаржишь 150 часов на AIF, в следующий раз будет делать тот кто делает на коленке за 40 часов. Конечно если клиент может сравнивать. А они как правило могут.

Скорее всего сделав с AIF за 150 часов потом будешь отлавливать там чисто технические ошибки за свой счет вместо того чтобы чарджить дальше за реализацию новых бизнес-задач в своем собственном фреймворке.

Если он сам не упирается рогом что хочет именно AIF/DMF то вряд ли он поймет увеличение стоимости в разы. Есть некое количество дней в мозгах у всех на примерные задачи.
Оценив в 20 дней скорее всего работы просто бы не было или была но мозг бы сьели потом. Интерфейсные вещи это 5-10 дней начально по крайней мере.

При данном заказе для клиента важна прозрачность и понятность ошибок по отношению к каждому полю в JSON файле, что выяснилось кстати уже после демонстрации прототипа и основное отличие в охвате импорта, порядка 40 таблиц с 300 полями. Задача просто бы не взлетела с AIF/DMF. То есть в Agile, когда все нюансы требований в процессе уточнения, использовать танки вместо телеги просто опасно. Я пару раз облегченно вздохнул что на коленке.

[Vadik]

Цитата:

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

Скорее всего сделав с AIF за 150 часов потом будешь отлавливать там чисто технические ошибки за свой счет вместо того чтобы чарджить дальше за реализацию новых бизнес-задач в своем собственном фреймворке

https://youtu.be/-nJ8tXXLJNQ

Что, неужели так много ошибок нашли пока разбирались?

[ax_mct]

Цитата:

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

https://youtu.be/-nJ8tXXLJNQ

Что, неужели так много ошибок нашли пока разбирались?

Запустил AIF Service классы из джобика с целью продебажить конкретный нужный мне сервис на предмет его расширения, поймал ошибки конфигурации в схеме и понял что не хочу связываться.
Я честно посвятил AIF 10 минут своей жизни и понял что это не мое

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

Ладно там если веб-сервисы, но вот зачем мне XSD, XML чтобы прочитать из JSON файла? Какая мне польза как программисту от AIF как инструмента при импорте из файла?

Всю возможную пользу от AIF в случае импорта из текстового файла можно выборочно оттуда взять максимум за два дня. Что я и сделал. Есть полезный код, да. Поскольку с AIF уже работал то просто уже знал откуда брать.

Entity из DMF использую как структуру, тоже честно DMF посмотрел, примерно часик посмотрел и впечатлился глубиной извращений. Ну его в болото такое дергать. Оно не для программиста этот фреймворк.

Как ни странно полезное нашел в PBA и Retail классах как пример API для создания продуктов.
А все остальное что в DMF что в AIF приходит к validateField, modifiedField, validateWrite, write.
Ну и зачем мне обертки от которых одна боль?

[ax_mct]

Цитата:

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

И есть реально что-то интересное кроме паттернов которые сам MS настоятельно просит не использовать во всех techtalks, вроде объемного data management и Power BI через OData? Что для упоротых эти рекомендации не указ, в общем и так было понятно

P.S. суд по количеству лайков под постом trud о том, что подбирать надо не лучшую технологию "вообще", а технологию под конкретную задачу - прочитали его многие, поняли и оценили не все. Ничего личного, просто мысли вслух

Сначала размер задницы и только потом памперс. Просто брать тот же DMF и его пилить потому что он лучший выбор вообще, конечно же нет. Скорость разработки и надежность работы важнее правильности. Даже если это будет 246 копи-пастов c прямой работой с табличными буферами и вызовом .modifiedField(). Никто не осудит.
Но конечно этого хочется избежать. Продебажу стандартный AIF сервис и копну DMF. А там задница подскажет без оглядки на рекомендации MS.

P.S. Прикольно я сам с собой разговариваю. Cпасибо!

[fed]

Цитата:

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

И есть реально что-то интересное кроме паттернов которые сам MS настоятельно просит не использовать во всех techtalks, вроде объемного data management и Power BI через OData? Что для упоротых эти рекомендации не указ, в общем и так было понятно

1. Глюки change tracking и interactive push (сам сталкивался при работе data integrator)
2. Очень медленная выгрузка больших объемов в BYOD
3. Отстутствие параллелизма для многих типов Entity. (Да - я знаю что некоторые из них на number sequence завязаны, но грузить-то их как-то надо).
Не из темы, а из собственного опыта:
1. Вчера внезапно у клиента перестал работать тупой экспорт из Customers в excel. Диагностики нету, есть только код ошибки от SSIS. Удалось победить заменив экспорт в excel на экспорт в CSV. Это Tier-2 окружение, в котором я точно никакого странного постороннего софта не ставил.
2. Несколько раз видел когда один и тот же набор данных грузился в обычном режиме и выдавал какую-то загадочную диагностику от SQL в Set Based update. (Хотя ok, Set Based update - это экстрим. Но с другой стороны - он заявлен и галочка не скрыта...)

Я собственно нигде не отрицаю, что надо инструмент сообразно задаче выбирать. Просто опыт работы с DMF показывает что все кроме простейшего функционала там неустойчиво, неоттестировано и не имеет средств диагностики.

[Stitch_MS]

Цитата:

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

Просто опыт работы с DMF показывает что все кроме простейшего функционала там неустойчиво, неоттестировано и не имеет средств диагностики.

Только что наткнулся