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

[Maxim Gorbunov]

Цитата:

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

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

Денис, ну вот опять. Ты же понимаешь, что если правильно делать интеграцию через AIF, она тоже не только не будет перекрывать стандарт, но и будет его с выгодой для себя использовать. А ты сравниваешь полностью неправильную интеграцию в AIF, с чуть менее неправильной интеграцией, сделанной без AIF, и, сюрприз-сюрприз, чуть менее неправильная интеграция у тебя выигрывает. Почему из того, что у криворуких программистов не хватило желания разобраться с 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 будет такое, что говорить о разнице в миллисекундах на вызов - просто смешно

[Maxim Gorbunov]

Цитата:

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

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

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

[macklakov]

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

Цитата:

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

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

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

[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 разумней таки на коленке за день написать. Зачем делать сложно там где можно просто?

[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. Ты, наверное, удивишься, но далеко не все новые технологии бесполезны.

[Maxim Gorbunov]

Цитата:

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

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

И ещё раз повторю: какой вы транспорт будете использовать, FTP или вебсервис, не влияет на применимость/неприменимость AIF. AIF может прекрасно и с файлами работать и быть при этом полезным.

[Maxim Gorbunov]

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

[ax_mct]

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

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

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

[Fillin]

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

[Maxim Gorbunov]

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

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

[Maxim Gorbunov]

Цитата:

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

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

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