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

[Vadik]

Цитата:

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

Но только если возможно то предпочту не использовать AIF, всегда предлагаю тупо и просто secure-ftp сетевые папки для обмена файлами

Ну а мне как человеку которому все и разрабатывать и поддерживать - асинхронные вызовы не айс как-то. На той стороне какую-то дрянь отправили и расслабились, а мне с ней что делать? Отдельные папки для необработанного ? Парсить мегабайты логов ? Нет уж - только хардкор, только синхронные вызовы, и пока мне эти данные в AX не понравятся настолько чтобы я смог их обработать, я своего OK на них не дам

Цитата:

И часто бизнес-партнерам или провайдерам услуг это совсем не нужно

Это неправильным провайдерам услуг не нужно. А вот некоторым правильным типа провайдеров EDI интересно чтобы у нас было относительно стандартное решение для стандартного продукта, чтобы его можно было легко внедрить на другом клиенте и жить на ренту. С такими и файлами пообмениваться не грех

[ax_mct]

Цитата:

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

Ну а мне как человеку которому все и разрабатывать и поддерживать - асинхронные вызовы не айс как-то. На той стороне какую-то дрянь отправили и расслабились, а мне с ней что делать? Отдельные папки для необработанного ? Парсить мегабайты логов ? Нет уж - только хардкор, только синхронные вызовы, и пока мне эти данные в AX не понравятся настолько чтобы я смог их обработать, я своего OK на них не дам

Это неправильным провайдерам услуг не нужно. А вот некоторым правильным типа провайдеров EDI интересно чтобы у нас было относительно стандартное решение для стандартного продукта, чтобы его можно было легко внедрить на другом клиенте и жить на ренту. С такими и файлами пообмениваться не грех

Файл переносится в архивную папку. Простое решение интеграции которое живет всю историю AX и жить будет пока та еще шевелится.

А вот насчет синхронности/асинхронности - да, интересный пойнт. Но чаще асинхронность на проектах. И к ней надо стремится если есть выбор.

Одно дело популярность AIF у поставщиков решений которые хотят на гламурной волне маркетинга подняться, и совсем другое дело у прагматичных клиентов которые не в информационном вакууме, а так или иначе имеют проектный опыт и оценивают риски.

Жить на ренту - это не на основе AIF. Вот как раз файловая система будет надежнее. Или SSIS etc. То есть технологически должно быть тупо и просто. Иначе никакой ренты.

P.S. Вообще существует некий воображаемый мир где еще и Biztalk делает всем хорошо. И хде?

[Vadik]

Цитата:

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

Вот как раз файловая система будет надежнее

Это только если ее бэкапить синхронно с AX

Цитата:

Или SSIS etc

А я вот только что закончил (ну, я надеюсь) переделывать одну интеграцию сделанную какими-то бестолочами в SSIS на кастомную в X++. То есть технологически с точки зрения SSIS сделано было конечно качественно, но что какаха сделанная без малейшего понимания обоих интегрируемых продуктов и переделывать придется практически все - было ясно с самого начала. И времени на отладку перед запуском - пара недель. Ну, взяли и переделали на X++

Цитата:

Вообще существует некий воображаемый мир где еще и Biztalk делает всем хорошо. И хде?

Мы мой первый проект на AIF в 2008 сначала делали на файлах, а потом перевели на BizTalk. Разницы я как-то не почувствовал. Ну, то есть пару месяцев запускали на FTP и файлах, а через полгода взяли и перевели на Biztalk. Просто лицензии по SA уже были а начальство решило что без него недостаточно гламурно. Помимо черного ящика в центре решения в котором что-то иногда (редко, но метко и обычно невовремя) протухало и нужно было саммонить спецального человека, ничего не изменилось

Цитата:

Насчет EDI. Одни из крупнейших EDI провайдеров РФ (три штуки) настойчиво рекомендуют файловый обмен, а не веб-сервисы

И это нормально. Мы делали EDI проекты на файлах. С AIF. И я честно не знаю какого уровня крутости этот провайдер

[Ivanhoe]

Насчет EDI. Одни из крупнейших EDI провайдеров РФ (три штуки) настойчиво рекомендуют файловый обмен, а не веб-сервисы Не в рекламе, а на реальных проектах внедрения.

[fed]

Кстати - не смотря на мои большие симпатии к Biztalk, я его по своей инициативе использовать в своих проектах не буду.Просто за 10 лет существования Biztalk, я встретил только одного профессионального конса по Biztalk (в Румынии). Если выйти на 2nd grade connections, могу еще одного чувака из Канады вытянуть. Все. Это недешевые ребята в обоих случаях. Оплачивать изучение 4-5 месяцев изучения Biztalk нашим сотрудником, ни один клиент не будет.

Хотя таки да - в долгосрочной перспективе, использование Biztalk (также как и использование AIF) "Упрощает поддержку проекта в долгосрочной перспективе;Biztalk будет проще расширять и настраивать другим консультантам" (В том крайне маловероятном случае если этих самых "других консультантов" удастся найти по рейтам в пределах штуки долларов в день).

[Fillin]

Тоже как то начинал один проект по интеграции с AIF. Честно пытался его использовать. Но после двух недель плотных попыток запустить все-таки вернулся к старой доброй передаче данных через ftp. Согласен, что потратив месяц, возможно, и запустил бы через AIF. Но заказчику сложно объяснить почему он должен оплатить месяц занятости двух специалистов (консультант и разработчик) для интеграции пяти-десяти не самых сложных документов. И уж тем более не представляю кто бы на заказчике отлаживал работу AIF. Это надо отдельного специалиста не хило прокачать.

[fed]

А вы просто создайте голосовалку про AIF. Типа "Использовали и будете ли вы использовать AIF"
И варианты "Использовал и планирую использовать", "Использовал и не планирую использовать", "Не использовал, но планирую" и "Не использовал и не планирую".
Просто, как известно, практика - критерий истины. Вопрос не в том что правильнее, а в том что именно востребовано на рынке. Если окажется что фича правильная, но рынком не востребована - обратитесь в Микрософт, пусть они там у себя в маркетингово/документационной консерватории подправят...

[ax_mct]

AIF как машина на автопилоте. Никто не говорит что плохая вещь. Просто избыточно сложная для большинства практических задач. Дорогая и при этом недостаточно надежная.

Это как SharePoint использовать для веб-сайта и считать что это нормально. Гламурно, да.

Использовать можно но. Самописки дешевле выйдут там где без AIF можно обойтись. Солидарен с Fed. Обратное утверждают те кто любит много молока с одной коровы

Там где можно обойтись обменом через Secure FTP использовать AIF - саботаж интересов клиента.

[Maxim Gorbunov]

Цитата:

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

Самописки дешевле выйдут там где без AIF можно обойтись

А вы считали? А затраты на апгрейд/перевнедрение/добавление новых возможностей включали?

[ax_mct]

Цитата:

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

А вы считали? А затраты на апгрейд/перевнедрение/добавление новых возможностей включали?

C точки зрения программиста и технического консультанта по AX я за пару дней сделаю в самописке то на что c использованием AIF уйдут недели.

C точки зрения тестирования и внесения изменений обмен через S-FTP на порядок, то есть раз в 10 бьет AIF Web-services.

Использование любых web-services там где без них можно обойтись всегда неоправданно. А там где они таки интенсивно и постоянно используются не зря придумавают всякие JSON, REST вместо SOAP. А еще IIS сам по себе не самая быстрая штука.

P.S. Про скорость конечно и FTP не феррари, но не думаю что это релевантно в контексте инструментария. Скорее требования асинхронности/синхронности играют роль.
https://daniel.haxx.se/docs/ftp-vs-http.html
Ultimately the net outcome of course differ depending on specific details, but I would say that for single-shot static files, you won't be able to measure a difference. For a single shot small file, you might get it faster with FTP (unless the server is at a long round-trip distance). When getting multiple files, HTTP should be the faster one.

[Maxim Gorbunov]

Цитата:

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

C точки зрения программиста и технического консультанта по AX я за пару дней сделаю в самописке то на что c использованием AIF уйдут недели.

C точки зрения тестирования и внесения изменений обмен через S-FTP на порядок, то есть раз в 10 бьет AIF Web-services.

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

Цитата:

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

Использование любых web-services там где без них можно обойтись всегда неоправданно.

Какие у вас интересные критерии. Прямо-таки всегда?

Цитата:

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

А там где они таки интенсивно и постоянно используются не зря придумавают всякие JSON, REST вместо SOAP. А еще IIS сам по себе не самая быстрая штука.

Я так понимаю, в ход пошла тяжёлая артиллерия - аббревиатуры. Да только какое всё это отношение имеет к AIF и как это доказывает его ограниченность? Пару месяцев назад я делал интеграцию на AIF, которая обменивалась JSON-сообщениями. И даже не так сильно пришлось допиливать AIF. Если б проект был на AX2012, то и вообще бы не пришлось ничего пилить, но была AX2009, и потому пришлось перенести из AX2012 функционал, который занимается препроцессингом/постпроцессингом сообщений (на самом деле, он даже уже есть в стандартной AX2009, но не привязан к AIF).

Про IIS, по-моему, тоже вы куда-то мимо денег. Публикация сервисов на IIS - это лишь одна из фич AIF. Ну не нравится она вам, никто не заставляет её использовать. Для того, чтобы работал AIF, сервисы на IIS совершенно не обязательно публиковать.

Про скорость FTP vs HTTP комментириовать не буду. К AIF это вообще никакого отношения не имеет.

[Vadik]

Цитата:

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

C точки зрения программиста и технического консультанта по AX я за пару дней сделаю в самописке то на что c использованием AIF уйдут недели

За пару дней - с использованием "наработок" и недели - с изучением AIF ? Верю, но это изначально некорректное сравнение

Цитата:

C точки зрения тестирования и внесения изменений обмен через S-FTP на порядок, то есть раз в 10 бьет AIF Web-services

Тут сложно комментировать, так как критерии сравнения нечеткие

Цитата:

Использование любых web-services там где без них можно обойтись всегда неоправданно. А там где они таки интенсивно и постоянно используются не зря придумавают всякие JSON, REST вместо SOAP

Вы просто обязаны полюбить data entities в семерке, потому что они в кошерном JSON данные передают. Каких-либо кратных увеличений производительности по сравнению с AIF это не дает, как ни странно (я сравнивал). Наверное потому что data policies больше нет и данных передается тупо больше, хоть и упакованы они более компактно

Цитата:

А еще IIS сам по себе не самая быстрая штука

А еще сервисы AIF хостятся непосредственно в процессе AOS и никакого IIS не требуют. Правда, здорово ?

Цитата:

Про скорость конечно и FTP не феррари, но не думаю что это релевантно в контексте инструментария. Скорее требования асинхронности/синхронности играют роль

А что это вообще было ? FTP vs HTTP ? В чем смысл - перечислить кучу наукообразных терминов и в конце выдать "а хрен его знает"? В каких сценариях сравниваем? У Вас что, два приложения друг с другом вот так прямо по FTP разговоривают? Или одно по таймеру в папочку пишет, а другое по таймеру - из нее читает? Тогда какой смысл сравнивать протоколы с потенциальной разницей в миллисекунды на вызов, если асинхронность перекроет все? Потом, посмотрите на "реальные сценарии" на которые коллеги ссылаются. Там время обработки собственно бизнес логики в AX будет такое, что говорить о разнице в миллисекундах на вызов - просто смешно

[ax_mct]

Цитата:

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

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

Проблемы с кастомизациями если есть то не потому что они есть а потому что полный Agile когда вносятся и вносятся и вносятся изменения без реинженеринга кода. Но в случае интеграций такой беды как правило нет. Обычно все кастомные интеграции "в файл/из файла" прозрачнее некуда.

Цитата:

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

Я так понимаю, в ход пошла тяжёлая артиллерия - аббревиатуры...
Про IIS, по-моему, тоже вы куда-то мимо денег...
Про скорость FTP vs HTTP комментириовать не буду. К AIF это вообще никакого отношения не имеет.

Цитата:

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

FTP - это всего лишь транспорт. AIF тоже можно заставить работать через FTP. Но AIF - это не только про транспорт...Вы посмотрите в AIF хоть, потратьте пару часов. Он хороший

Согласен что со сравнением протоколов совсем я не в тему. И с IIS тоже. My bad.
Делал я AIF в AX 2009. Сервисов десяток в обе стороны. И JSON хитрый еще на другом проекте делал. Подзабыл просто. Да можно и так и эдак. И без IIS. Все так.

Цитата:

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

За пару дней - с использованием "наработок" и недели - с изучением AIF ? Верю, но это изначально некорректное сравнение

За 2-3 дня я любой новый сервис AIF сделаю для начального тестирования. И делал вообщем-то. Не проблема выдать на гора проект. Вопрос во всех необходимых админских усилиях и в принципе большей стоимости изменений и тестирования. Что выливается в совсем другие сроки.
C простотой изменений и тестирования (S)FTP простых текстовых файлов разница на тот самый порядок.

То есть если большой и жирный клиент/партнер мне скажет сделай нам AIF так как их местный архитектор решил сделать свое СV покрасивше, то я им сделаю все на высшем уровне стандартов Microsoft так что не придерешься ни к чему.

Но если меня спросят как IT consultancy что лучше для обмена информацией со скажем курьерской компанией где есть старый проверенный обмен через FTP но недавно еще те и web-services добавили. И если им можно по бизнес-логике таки обойтись обменом через FTP то я им настойчиво посоветую не страдать c web-services.

И в случае обмена через варианты FTP разумней таки на коленке за день написать. Зачем делать сложно там где можно просто?

[Maxim Gorbunov]

Цитата:

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

Там где можно обойтись обменом через Secure FTP использовать AIF - саботаж интересов клиента.

FTP - это всего лишь транспорт. AIF тоже можно заставить работать через FTP. Но AIF - это не только про транспорт. Это ещё и про конвертацию сообщений. И про ведение журналов обработки сообщений. И про интерфейсы настройки. И про механизмы сериализации данных. И про обработку исключений. Вы посмотрите в AIF хоть, потратьте пару часов. Он хороший

[macklakov]

Чтобы не флудить, перенес в эту ветку.

Цитата:

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

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

Спасибо за уточнения.
Но по результатам общения вскрылся еще один момент, требующий упоминания. По хорошему, отчеты тоже надо изолировать от прямого доступа к таблицам. Иначе в аксе ничего не улучшить и не починить без того, чтобы отчетность не поехала. Ибо в писатели отчетов берут generic SSRS, которые прямо из таблиц черпают данные. И норовят они брать данные из журналов, заказов и т.д.

[ax_mct]

Цитата:

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

Чтобы не флудить, перенес в эту ветку.

Спасибо за уточнения.
Но по результатам общения вскрылся еще один момент, требующий упоминания. По хорошему, отчеты тоже надо изолировать от прямого доступа к таблицам. Иначе в аксе ничего не улучшить и не починить без того, чтобы отчетность не поехала. Ибо в писатели отчетов берут generic SSRS, которые прямо из таблиц черпают данные. И норовят они брать данные из журналов, заказов и т.д.

Именно так. Я как-то думал смещаться в сторону отчетов (SSRS, BA) от чисто программирования но со временем таки передумап. С появлением SSRS в AX программисты AX перестали писать отчеты. Этим повсеместно занимаются generic SSRS и BA которые чихать хотели на интеграцию с AX, вызов фунций и просто тупо используют базу как коллекцию таблиц.

Это абсолютная ситуация на последнем десятке проектов. И всеми считается нормальной. Разве что постоянно просят добавлять время от времени явно избыточные поля в таблицы для удобства generic SSRS.

Ничего не изменится. Оно же для этого и делалось. Чтобы пучками этих generic рвать с грядки. Таких специалистов больше и они дешевле. "Правильного" (c интеграцией) специалиста по отчетам в этой толпе и не заметят. Вернее проигнорируют так как он будет по цене программиста (вернее он и будет программист) и будет не так специалирован на отчетах.

[macklakov]

Цитата:

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

Ничего не изменится.

В CRM есть замечательная best practice, не показывать базу внешним приложениям. Все только через вьюхи. А вьюха дает кой-какую изоляцию.

[trud]

Еще такой момент упустили - стандартный механизм который выполняет импорт дата entity в АХ7 - это бинарный компонент с отдельным сервисом.
т.е. это не X++ код, а какая то закрытая библиотека.
Сам этот факт - почему это нельзя было написать на X++ и зачем надо было писать dll за гранью моего понимания, но это факт

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

[fed]

Я заметил, что оба консультанта, поддерживающих AIF, работают в странах Персидского залива.
Я не думаю что это совпадение.
Вероятно парней заслали чтобы расшатать экономику арабских нефтедобывающих монархий с помощью внедрения бесполезных технологий. Типа - ассиметричный ответ на развязанную арабами ценовую войну на нефтяном рынке. Типа - будем внедрять AIF пока нефть не станет по 60 хотя бы. А защищают AIF они просто по необходимости, чтобы нечаянно не забыть свою легенду и не выдать себя.
Вы там держитесь парни! Если нефть будет плохо дорожать, вы еще workflow с Azure им повнедряйте! Пусть знают почем фунт лиха !

[Maxim Gorbunov]

Цитата:

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

Если нефть будет плохо дорожать, вы еще workflow с Azure им повнедряйте! Пусть знают почем фунт лиха !

Не переживай, Денис. Внедряем уже. И workflow, и AX7 на Azure. Ты, наверное, удивишься, но далеко не все новые технологии бесполезны.