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

[Maxim Gorbunov]

Ну и чтобы два раза не вставать: формат файлов/сообщений тоже не является определяющим критерием при выборе пользоваться или не пользоваться AIF. В стандартную AX2012 входит настраиваемый компонент для препроцессинга CSV-файлов. То есть, AIF вполне может читать и писать данные в CSV, и при этом использовать весь остальной фреймворк. Можно писать и свои компоненты для препроцессинга, таким образом расширяя набор форматов файлов, с которыми может работать AIF. На Dynamics Community лежит простенький пример такой трансформации для Excel-файлов. Собственно, вопреки той ереси, что была понаписана здесь изначально, прелесть AIF именно в инкапсуляции различных стадий процесса интеграции, которая позволяет добавлять свои реализации для каждой стадии без необходимости изменения всей интеграции.

[ax_mct]

Без проблем использую AIF классы и код оттуда для упрощения моей работы.

Но использовать AIF как Фреймворк там где можно без него обойтись, я считаю непрактичным.

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

[Fillin]

В Европе при ставке 150 евро в час я б тоже только стандартный Аиф рекомендовал

[Maxim Gorbunov]

Цитата:

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

В Европе при ставке 150 евро в час я б тоже только стандартный Аиф рекомендовал

150 евро/час - это ставка суте... то есть, консалтинговой компании. У нас ставки, поверьте, значительно ниже

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

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

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

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