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

[Maxim Gorbunov]

Цитата:

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

А какой бюджет и по какой ставке?

Оцените в часах. Бюджет заранее неизвестен. Предположим, что вы отвечаете на RFQ.

[ax_mct]

Цитата:

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

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

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

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

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

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

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

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

[Vadik]

Цитата:

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

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

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

[ax_mct]

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[Maxim Gorbunov]

Цитата:

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

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

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

[Maxim Gorbunov]

Цитата:

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

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

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

[ax_mct]

Цитата:

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

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

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

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

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

[ax_mct]

Цитата:

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

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

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

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

[Vadik]

Цитата:

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

В приведенном примере, клиентское приложение вообще может не понимать концепции заказа на продажу. И не факт что в аксе это нужно отражать именно как заказ. Может это quotation, а может invoice, а может и проект или просто проводки в ГК. Более того, понимание того, как надо проводить, может прийти в процессе внедрежа или даже после

Как по мне, так это катастрофа. Ведь придется переключиться с одной готовой реализации (SalesSalesOrderService) на другую (SalesSalesQuotationService / CustFreeTextInvoiceService / LedgerGeneralJournalService), а Вам - всего лишь запилить новую, абстрагированную

Цитата:

И чем более абстрогирован будет веб-сервис от деталей реализации, тем гибче будет решение

Цитата:

Просто копируем готовое из AIF

Коллеги, вот честно - завидую. Так долго жонглировать абстракциями - и не устать..

[fed]

Собственно тема ушла куда-то в обсуждение абстрактной технической реализации непонятно чего.А я хочу просто заметить, что:
1. Рассуждения о том что, мол, благодаря использованию стандартной функциональности облегчается поддержка другими консультантами - не работают. Кроме Vadik и Maxim Gorbunov - других консультантов не нашлось. Остальные либо не разбирались, либо разбирались, но теперь плюются и AIF не любят.
2. Рассуждения о легкости апгрейда тоже как-то не срабатывают, поскольку вся тема стартовала с того что Vadik жаловался на отсутствие правильной совместимости ax7 с более ранними версиями.

Рассуждать про стоимость интеграции какого-то абстрактного примера с помощью AIF vs самописки - достаточно бессмыслено.
Также бессмысленно рассуждать о большой мощности и преимуествах AIF. Вполне возможно что так оно и есть. Но по факту - индустрия эту технологию не приняла, какой бы правильной и мощной она не была.
Я на этом, пожалуй, участие в этой теме завершу. Если вы считаете что я ошибаюсь насчет принятия/непринятия AIF в консультантско/программистских кругах - откройте голосовалку.

[pitersky]

У меня на предыдущем проекте был небольшой кусочек работы с AIF - делали сопряжение с внешной самопиской. Правда, штатные сервисы не использовали, был собственный, бо данные были достаточно специфические. Всё работало стабильно и надёжно - данные приходили, фидбеки обработки уходили и принимались внешней системой. В обратную сторону тоже всё летало нормально. Поэтому, честно говоря, претензии fed к AIF мне непонятны. Мне кажется, что индустрия просто не успела толком распробовать AIF к тому моменту, как майкрософт от него отказался.

[skuull]

Хочеться сказать в защиту многострадального AIF, что довелось мне увидеть пару B2B интеграций которые были сделаны через VAN который использовал сервисы AIF из коробки с добавлением парочки кастомных полей. Все работает который год без проблем.

[macklakov]

Цитата:

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

Как по мне, так это катастрофа. Ведь придется переключиться с одной готовой реализации (SalesSalesOrderService) на другую (SalesSalesQuotationService / CustFreeTextInvoiceService / LedgerGeneralJournalService), а Вам - всего лишь запилить новую, абстрагированную

Не забывай, что по условиям задачи у тебя 10 клиентских приложений, а значит при каждой смене реализации нужно будет полностью переписывать 10 кусков клиентского кода. В то время как дополнительный уровень абстракции изолирует изменения исключительно рамками AX.
В идеальной архитектуре, этим занимается ESB или в BizTalk, и тогда стандартные сущности AIF действительно смотрятся логично. У тебя есть абстрактный сервис на ESB, который дергает все положенные сущности AIF. Но если бы у вас так было организовано, то этого обсуждения и не возникло бы. В реальных условиях, о ESB архитекторы мечтают, но обосновать ее внедрение вменяемо не могут (отчасти потому, что AIF большинство функций и так исполняет), поэтому низко-гранулированные сервисы пишутся в AX, и дергают классы разноски напрямую. Т.к. если ты уже ввел уровень изоляции, то зачем тогда весь этот overhead со стандартными сущностями?

[macklakov]

Цитата:

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

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

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

[ax_mct]

Цитата:

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

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

Индустрия таки попробовала в AX 2009. Не зря перелопатили AIF в AX 2012.
И послевкусие таки есть у всех.

Вот с каким глаголом у вас ассоциируется слово AIF
1-2 секунды на ассоциацию
Предположим что
- "интегрирует"
- "работает"
- "настраивать"
- "разбираться"
- "заработать"
- "трахаться"
...
Уверен в ответе в 95% случаев для людей с проектным опытом

[Raven Melancholic]

Цитата:

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

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

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

Цитата:

AIF входит в Business Essentials.

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

[Raven Melancholic]

Цитата:

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

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

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