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

[EVGL]

Цитата:

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

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

Убедить клиента, что он не прав и надо использовать DMF. Может быть, даже создать свой набор упрощенных классов, а не заморачиваться со стандартными. Импортировать текстовые файлы.

[fed]

Цитата:

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

Убедить клиента, что он не прав и надо использовать DMF. Может быть, даже создать свой набор упрощенных классов, а не заморачиваться со стандартными. Импортировать текстовые файлы.

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

[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]

Цитата:

Сообщение от 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 показывает что все кроме простейшего функционала там неустойчиво, неоттестировано и не имеет средств диагностики.

[fed]

Цитата:

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

Так сказать, day in life нашего клиента. Не совсем типичный, обычно процессим 1-5К строк журналов в 10 компаниях (странах) ежедневно. В общем, не так все страшно

Кстати, а как вы диагностируете проблемы, если что-то ломается на стадии загрузки в staging ? В таких ситуациях обычно только в event log полная информация об ошибке есть,а event log в prod не доступен. Вроде бы часть информации из event log в environment diagnostics тянется, но лога именно интеграции SSIS и D365FOE я там не нашел. (Возможно - плохо искал).

[Vadik]

Цитата:

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

Кстати, а как вы диагностируете проблемы, если что-то ломается на стадии загрузки в staging ?

У нас ломалось только на битых файлах "с той стороны". Тогда - View execution log \ Staging log details. Уже не помню когда в телеметрию последний раз заглядывал

Цитата:

Глюки change tracking и interactive push (сам сталкивался при работе data integrator)
Очень медленная выгрузка больших объемов в BYOD

Я за коммунизм агитировать не буду, просто напишу что у меня есть клиент который в BYOD проводки ГК (GeneralJournalAccountEntry) выгружает инкрементально несколько раз в час - отчеты из BYOD и TB сходятся

[ax_mct]

Есть такой интересный посыл от евангелиста (Martin Dráb)

Цитата:

D365FO doesn't come with it's own way for handling these things; simply take a .NET API of your choice and use it as in any other .NET application. It also means that you'll find a plenty of information on internet - tutorials, code samples and so on.

Just wrap the logic in a .NET class library, add a reference to your X++ project and call classes in the library when needed.

https://community.dynamics.com/365/f...f/765/t/300455

В связи с чем у меня вопрос. Если при вызове со стороны D365 все понятно что можно все, тот же TCP WCF (к сожалению .NET Remoting прибили для кросс-платформенности).

А вот как стучаться в D365 из .NET сборки на том же сервере? ODATA если вставка записей или custom service JSON/SOAP если обращение к коду? То есть только через Active Directory и IIS?

И чем им .NET/Business Connector помешал? При чем тут кросс-платформенность не понимаю.

[trud]

Цитата:

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

А вот как стучаться в D365 из .NET сборки на том же сервере? ODATA если вставка записей или custom service JSON/SOAP если обращение к коду? То есть только через Active Directory и IIS?

Это вроде описано в документации. есть даже пример с открытым кодом
https://github.com/Microsoft/Recurri...ions-Scheduler

[Stitch_MS]

Цитата:

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

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

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

[ax_mct]

Цитата:

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

А вот как стучаться в D365 из .NET сборки на том же сервере? ODATA если вставка записей или custom service JSON/SOAP если обращение к коду? То есть только через Active Directory и IIS?

Цитата:

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

Это вроде описано в документации. есть даже пример с открытым кодом
https://github.com/Microsoft/Recurri...ions-Scheduler

Пример классный спасибо. Интересно и очень в тему. Там сервис который перемещает файлы c данными и умеет это делать в частности в Azure BLOB.

Но это не совсем "то". Хотя я уже все понял. Martin Dráb сказал что можно все что можно в .NET и я призадумался. И обнаружил что в современном .NET можно сделать гораздо меньше чем в мое время.

То есть .NET Remoting (https://en.wikipedia.org/wiki/.NET_Remoting) в D365FO не применим. Это конечно вопрос к .NET.
То есть .NET Business Connector уже не часть D365FO и варианты вызова кода это только веб-сервисы. Через AAD и IIS и никак иначе. И тут я всплакнул за Business Connector.

[belugin]

Цитата:

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

То есть .NET Business Connector уже не часть D365FO и варианты вызова кода это только веб-сервисы..

Если сборка уже загружена в процесс dyn365fo и вызвана оттуда, то из нее можно вызывать X++ классы https://docs.microsoft.com/en-us/dyn...business-logic

[ax_mct]

Цитата:

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

Если сборка уже загружена в процесс dyn365fo и вызвана оттуда, то из нее можно вызывать X++ классы https://docs.microsoft.com/en-us/dyn...business-logic

Классный пример в копилку. Спасибо.
В приведенном примере AXQueryProvider (LINQ) и подписка на AX событие из C#.
Вызова X++ класса в примере нет.

Кстати жалуются что данный пример не рабочий из-за binding errors.
"12 Sep 2018 Bug 246523 has been logged to track this issue." и до сих пор.
https://github.com/MicrosoftDocs/dyn...lic/issues/326

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

И будет сакральное знание о том что так делать не стоит уделом экспертов которым платят за то что они знают чему верить, а чему нет. Я например из этого понял что AX из C# это плохой и проблемный дизайн в данном контексте. Так как то же самое можно сделать с C# из X++ и спокойнее спать.

Или таки есть опыт вызовов X++ классов из C#?

[ax_mct]

Цитата:

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

к сожалению .NET Remoting прибили для кросс-платформенности.
...
Martin Dráb сказал что можно все что можно в .NET и я призадумался. И обнаружил что в современном .NET можно сделать гораздо меньше чем в мое время.

Что интересно Java RMI так и осталось. Те же удаленные вызовы кода на уровне сокетов по внутреннему протоколу.
https://en.wikipedia.org/wiki/Java_r...hod_invocation
https://docs.oracle.com/javase/1.5.0...llo-world.html

При этом да, судя по всему Java RMI сейчас используют намного меньше чем раньше, все делают REST. Как бы общий тренд вообще.
P.S. По сути формально оставшись Java RMI тоже с рынка ушла.

Но добавляя (интеграционный) компонент на ту же машину (в виде DLL в случае .NET) и использовать
web-средства коммуникации, это странно.
Даже в on-premise это сборка (подписанная причем) должна быть зарегистрирована как приложение в Azure AD и ходить TCP через IIS (в AX).

[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.
Ну и зачем мне обертки от которых одна боль?