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

[Maxim Gorbunov]

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

Есть Аксапта и есть целый выводок самописных систем. Для оценки, скажем, десять систем. Каждая из этих систем создаёт в Аксапте заказы на продажу и платежи клиентов. Каждая система шлёт данные в своём формате. Кто-то выдаёт CSV, кто-то готов вызывать веб-сервисы. Некоторым системам хочется получить подтверждение из Аксапты, с номером созданного заказа/журнала, а некоторым наплевать. Сколько времени вы будете делать такую интеграцию?

[ax_mct]

Цитата:

Сообщение от Maxim Gorbunov

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

Есть Аксапта и есть целый выводок самописных систем. Для оценки, скажем, десять систем. Каждая из этих систем создаёт в Аксапте заказы на продажу и платежи клиентов. Каждая система шлёт данные в своём формате. Кто-то выдаёт CSV, кто-то готов вызывать веб-сервисы. Некоторым системам хочется получить подтверждение из Аксапты, с номером созданного заказа/журнала, а некоторым наплевать. Сколько времени вы будете делать такую интеграцию?

В ситуации когда всем 10 можно использовать Secure FTP то по три дня на интерфейс.

В ситуации когда решено что нужно AIF или да, в силу синхронности, те же три дня на каждый интерфейс.

Естественно не как финальный продукт а как betа-версия для тестирования.

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

Более того постараюсь максимально сдублировать и сделать каждый интерфейс максимально независимым как от других так и от стандарта. Не правильно так делать да, но практично.

[Vadik]

Цитата:

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

Более того постараюсь максимально сдублировать и сделать каждый интерфейс максимально независимым как от других так и от стандарта. Не правильно так делать да, но практично

Добавили поле в шапке заказа / хотим немного модифицировать поведение (то же резервирование, проверка баланса) - правим 10 независимых интерфейсов в AX ? Неаккуратно как-то

[ax_mct]

Цитата:

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

Добавили поле в шапке заказа / хотим немного модифицировать поведение (то же резервирование, проверка баланса) - правим 10 независимых интерфейсов в AX ? Неаккуратно как-то

Да к бесу ООП там где оно вредит. Чем независимее тем лучше. C точки зрения исскуства программирования да "неаккуратно", а с точки зрения программиста AX как поставщика решения - очень мудро. Можно даже и теорию под это подобрать, много их этих теорий

[Maxim Gorbunov]

Цитата:

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

В ситуации когда всем 10 можно использовать Secure FTP то по три дня на интерфейс.

Ок. А теперь допустим, что у клиента есть требование организовать журнал обработки сообщений. Сколько времени займёт организовать такой для каждой из 10 интеграций?

Цитата:

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

Более того постараюсь максимально сдублировать и сделать каждый интерфейс максимально независимым как от других так и от стандарта. Не правильно так делать да, но практично.

Бедные ваши клиенты

[ax_mct]

Цитата:

Сообщение от Maxim Gorbunov

Ок. А теперь допустим, что у клиента есть требование организовать журнал обработки сообщений. Сколько времени займёт организовать такой для каждой из 10 интеграций?

Бедные ваши клиенты

журнал обработки сообщений - 2 дня на все 10 интеграций. Просто копируем готовое из AIF.

Когда я упоминал о независимости то на самом деле подразумевал что не один делаю эти 10 интеграций. Чаще всего ситуации когда два-три подрядчика/партнера/программиста и до кучи еще что-то вертикальное купленное. Поэтому с практической стороны максимальная независимость она много нервов бережет. Так как по сути разные команды участвуют. Чисто практическая вещь связанная с деплойментом и тестированием.

[Maxim Gorbunov]

Цитата:

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

журнал обработки сообщений - 2 дня на все 10 интеграций. Просто копируем готовое из AIF.

У меня был заготовлен следующий вопрос про value mapping при интеграции, но ответ я уже заранее могу предположить. Любую новую функцию будем копировать из AIF (и выставлять клиенту новый счёт на разработку) по мере необходимости. В итоге получим урезанную копию AIF, без функций, которые пока не понадобились. Опять же, могу только посочувствовать вашим клиентам.

[ax_mct]

Цитата:

Сообщение от Maxim Gorbunov

У меня был заготовлен следующий вопрос про value mapping при интеграции, но ответ я уже заранее могу предположить. Любую новую функцию будем копировать из AIF (и выставлять клиенту новый счёт на разработку) по мере необходимости. В итоге получим урезанную копию AIF, без функций, которые пока не понадобились. Опять же, могу только посочувствовать вашим клиентам.

Если надо маппить XSD-XSD то конечно я не буду копировать и делать это с нуля. Если клиент хочет так любиться то AIF для него подходит.

А если вопрос во внешнем названии продукта или похожее то использовать из-за этого AIF несколько излишне. Точнее просто не нужно.

AIF появился в Dynamics AX 4.0.
В Axapta 2.5 и 3.0 тоже решались вопросы асинхронной интеграции.
Что-то изменилось в бизнес-мире c тех пор что без value mapping через AIF никак?

Я вот в магазине кофеварку-комбайн за £900 узрел. Жену позвал, мы пытались поскоблить думали что платина. Ан нет, просто функций дофига.

Высокая цена сверху
https://www.google.co.uk/#q=coffee+m...rd:pd&tbm=shop

Низкая цена сверху
https://www.google.co.uk/#q=coffee+m...ord:p&tbm=shop

Это по поводу богатства функций.

[macklakov]

Цитата:

Сообщение от Maxim Gorbunov

Есть Аксапта и есть целый выводок самописных систем. Для оценки, скажем, десять систем. Каждая из этих систем создаёт в Аксапте заказы на продажу и платежи клиентов.

Мне кажется наша "битва при AIF" зацикливается, т.к. произошло смешение понятий. Есть AIF как инфраструктура для публикации веб-сервисов. В нем я не вижу ничего особо плохого. А есть набор стандартных entities выставленных через AIF и еще более экстремальная OData. Вот именно их использование спорно, т.к. они подразумевают что клиентское приложение должно иметь понятие о устройтве AX.
В приведенном примере, клиентское приложение вообще может не понимать концепции заказа на продажу. И не факт что в аксе это нужно отражать именно как заказ. Может это quotation, а может invoice, а может и проект или просто проводки в ГК. Более того, понимание того, как надо проводить, может прийти в процессе внедрежа или даже после. И чем более абстрогирован будет веб-сервис от деталей реализации, тем гибче будет решение.

[Raven Melancholic]

Цитата:

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

Есть AIF как инфраструктура для публикации веб-сервисов.

Не только это, но еще и готовый набор механизмов для согласования тех же кодов НСИ (ну или технологично сказать Мастер-данных).

Цитата:

клиентское приложение должно иметь понятие о устройстве AX.
...
И не факт что в аксе это нужно отражать именно как заказ.

Оно самое. Абстракции одной системы совсем не обязательно совпадают с абстракциями другой системы. И что-то суперуниверсальное может не справиться с такими отличиями. Вообще простейший пример: даже при похожих подходах, в разных системах то же определение того, что считать датой операции может различаться.
Хотя я вполне допускаю, что можно воткнуть несколько XSLT преобразований между входом и выходом (или наоборот).
А вообще, данный спор, можно сказать, ни о чем. Нет какого-то универсального подхода - используем AIF, не используем AIF, а ваяем что-то сами.

• Один вариант - когда уже есть куча механизмов обмена и нужно добавить еще одну систему. Тут подход должен учитывать как все остальное работает.
• Другой - начинаем с нуля. Тут самое интересное выяснить это единичный случай обмена или планируется и дальше делать интеграцию с другими системами (если найдете заказчика, который заранее знает ответ на такой вопрос, просьба сообщить его координаты - с удовольствием поучаствую в конкурсе на вакантное место у такого заказчика).

Ну и еще, если решить начать использование AIF, то вопрос по лицензиям. Если используется DAX2009, лицензий на AIF и NET.Connector нет, то как их можно легально получить?

[Maxim Gorbunov]

Цитата:

Сообщение от Raven Melancholic

Ну и еще, если решить начать использование AIF, то вопрос по лицензиям. Если используется DAX2009, лицензий на AIF и NET.Connector нет, то как их можно легально получить?

Специально сейчас проверил: AIF входит в Business Essentials. Какое отношение к AIF имеют лицензии Business Connector Users, я не понял. Поясните, пожалуйста.

[Raven Melancholic]

Цитата:

Сообщение от Maxim Gorbunov

Какое отношение к AIF имеют лицензии Business Connector Users, я не понял. Поясните, пожалуйста.

Если использовать асинхронные порты, но никакого. А если хочется синхронности? Как в DAX2009 можно опубликовать синхронную службу кроме как развернуть WEB службу на IIS?

Цитата:

AIF входит в Business Essentials.

Я работал всегда на клиенте, поэтому мне сложно сказать про тонкости лицензирования. Но вот для проверки зашел на приложении одного из моих клиентов, про которого я точно знаю, что AIF там нет. Базовая лицензия - Enterprise. Из того, что относится к AIF доступны только конечные точки в той части, которая используется в InterCompany.

[ax_mct]

Цитата:

Сообщение от Raven Melancholic

Нет какого-то универсального подхода - используем AIF, не используем AIF, а ваяем что-то сами.

• Один вариант - когда уже есть куча механизмов обмена и нужно добавить еще одну систему. Тут подход должен учитывать как все остальное работает.
• Другой - начинаем с нуля. Тут самое интересное выяснить это единичный случай обмена или планируется и дальше делать интеграцию с другими системами (если найдете заказчика, который заранее знает ответ на такой вопрос, просьба сообщить его координаты - с удовольствием поучаствую в конкурсе на вакантное место у такого заказчика).

Вот это. Использовать стандарт или писать на коленке - по ситуации но не всегда и везде просто потому что это круть

[Maxim Gorbunov]

Цитата:

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

Есть AIF как инфраструктура для публикации веб-сервисов

Юрий, ты в корне неправильно понимаешь предназначение AIF. Веб-сервисы - это лишь один из транспортов, которые можно использовать для передачи данных. AIF работает и с другими. Именно за то, чтобы стороннему приложению не нужно было знать устройство Аксапты, AIF и отвечает.

[macklakov]

Цитата:

Сообщение от Maxim Gorbunov

Юрий, ты в корне неправильно понимаешь предназначение AIF.

По мне так AIF это, по сути дела, кустарный BizTalk. Скромненький и не очень удобный, зато отдельно покупать не надо. По этой причине BizTalk или ESB c AX я не слышал чтоб кто-то использовал. Но стандартные сущности в AIF написаны именно для стыковки с BizTalk. А т.к. стыковаться не с чем, а они есть, но народ их начинает использовать для того, для чего они не предназначены. Т.е. хакерствовать. А Microsoft, ясно дело, хакерские выходки поддерживать не обязан и не намерен, что разумно. Поэтому я считаю что лучше их не использовать.

[Raven Melancholic]

Цитата:

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

По этой причине BizTalk или ESB c AX я не слышал чтоб кто-то использовал

На самом деле BizTalk используется (точнее точно использовался несколько лет назад - дальше у меня информации нет) в России на одном из очень заметных игроков на рынке кондитерских изделий.
Там 1С, Акса, портал корпоративной отчетности очень плотно использовали обмен данными между собой используя BizTalk. Использовались и MSMQ и файлы и почта, сам лично дописывал некоторые оркестровки. Не скажу что все идеально - были моменты когда вдруг какой-то порт абсолютно на пустом месте переставал работать, но в целом все как-то крутилось, шуршало.

[macklakov]

Цитата:

Сообщение от Raven Melancholic

На самом деле BizTalk используется (точнее точно использовался несколько лет назад - дальше у меня информации нет) в России на одном из очень заметных игроков на рынке кондитерских изделий.

Интересно. Но согласись что это случается очень редко. И причина, мне кажется, в том, что ERP и enterprise application integration это конкурирующие концепции интеграции, пытающиеся решить одну и ту же задачу разными способами.
К примеру, если у тебя есть специализированная складская система, интернет-магазин, data warehouse для BI, 1С, payroll приложение и т.д. и все это увязано через BizTalk, зачем тебе ERP? С другой стороны, если у тебя хорошо внедренная ERP, тебе весь этот зоопарк не нужен, в ней и так все есть. Ну да, всегда остается какая-то мелочевка, но вся эта мелочь стыкуется именно с ERP.
Еще стоит учесть, что вне СНГ интеграция с аналогом 1С это крайне редкая задача. Чаще именно AX используется как аналог 1С.

[gl00mie]

Цитата:

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

К примеру, если у тебя есть специализированная складская система, интернет-магазин, data warehouse для BI, 1С, payroll приложение и т.д. и все это увязано через BizTalk, зачем тебе ERP?

• специализированная складская система может быть у 3PL-оператора, или нескольких, где хранится наш товар, либо может быть свой склад с автономной (а не в общем ЦОДе) специализированной складской системой
• интернет-магазин и так практически всегда - отдельно стоящий, со своей базой, и это правильно: так он может развиваться отдельно и быть, опять же, автономным
• наличие data warehouse для BI вроде бы не конфликтует с транзакционной ERP-системой
• 1С традиционно хорошо умеет рисовать регламентированную отчетность
• payroll тоже, вполне допускаю, может быть отдельно стоящий - скажем, из параноидальных соображений или потому, что там оперативнее учитываются последние изменения законодательства

а ERP может использоваться по своему прямому назначению: для планирования и управления финансовыми и материальными ресурсами, а также человеческим капиталом. Потому что интернет-магазин, payroll и складская система обычно не умеют планировать ресурсы, ну кроме, может, мест хранения на складе.

Цитата:

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

С другой стороны, если у тебя хорошо внедренная ERP, тебе весь этот зоопарк не нужен, в ней и так все есть. Ну да, всегда остается какая-то мелочевка, но вся эта мелочь стыкуется именно с ERP.

Ну как это не нужен? Интернет-магазин - отдельная система в любом случае, BI - отдельная система, которой негоже строить отчеты по транзакционной базе, управление складом - очень часто делается отдельной системой, payroll - зависит от внедрения, отнюдь не всегда, насколько я знаю, расчет зарплаты и вознаграждений, отпуска и больничные ведут в ERP.

Цитата:

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

Еще стоит учесть, что вне СНГ интеграция с аналогом 1С это крайне редкая задача. Чаще именно AX используется как аналог 1С.

Везет...

[Maxim Gorbunov]

Цитата:

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

Еще стоит учесть, что вне СНГ интеграция с аналогом 1С это крайне редкая задача. Чаще именно AX используется как аналог 1С.

Уже как минимум у двух клиентов наблюдал Oracle Financials в качестве хранилища всей финансовой информации. То есть, по сути, в качестве аналога 1С, в который AX выгружает свои данные.

[George Nordic]

Цитата:

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

По мне так AIF это, по сути дела, кустарный BizTalk. Скромненький и не очень удобный, зато отдельно покупать не надо.

Точно! Теперь вспомнил, что это мне напоминает. В SAP несколько лет назад, при расширении функциональности и переход на Sap NetWeaver архитекторы осознали, что добавлять еще кучу таблиц в стандарт, где их так пара сотен тысяч (PS: активных - меньше), причем они не всегда будут использоваться, ну уж совсем не комильфо.

Сделали так - построили интеграционную шину - CIF (Core Infrastructure Framework) - что-то навроде Oracle Fusion, и используют ее для интеграции с доп. модулями, как минимум линейки APO (Advanced Planner and Optimizer), куда входят:
* Центр управления логистическими цепочками (Supply Chain Cockpit)
* Планирование спроса (Demand Planning)
* Планирование и развертывание сетей логистических цепочек (Supply Network Planning & Deployment)
* Планирование производства (Production Planning)
* Точное календарное планирование (Detailed Scheduling)
* Глобальная система контроля доступности (Global Available-to-Promise)
Кстати, туда же входит и их WMS - SAP EWM - Extended Warehouse Management

Так вот, как это работает: основные таблицы остались в самом SAP - номенклатура там и т.п., а специфичные таблицы, необходимые только для APO - стоят отдельно в апо, например для EWM - это карта склада, палеты, габариты ячеек и палет, маршруты комплектации и т.д. CIF обеспечивает двухстороннюю интеграцию - в APO заливаются изменения в номенклатуре, клиентах, заказах, а обратно - результаты операций, комплектация, отгрузка и прочее.

Может в эту сторону идет развитие AIF?

С Уважением,
Георгий