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

[Ivanhoe]

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

[Vadik]

Цитата:

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

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

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

Цитата:

Или SSIS etc

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

Цитата:

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

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

Цитата:

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

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

[macklakov]

Цитата:

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

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

Мне кажется, тут столкнулись 2 разные точки зрения, консультантская и программистская. Программист хочет кнтролировать код, консультант хочет сделать все с помощью стандарта.
Мне раньше был ближе консультантский подход красиво сформулированный mazzy как "все уже написано до нас". Но MS с тех пор изменил политику. И теперь я склоняюсь к тому, чтобы писать код "сбоку". Ибо опираться на стандарт нынче это складывать все свои яйца в одну львинную пасть.

[Maxim Gorbunov]

Цитата:

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

Соответственно - избегая использовать AIF, я заметно упрощаю внедрение и поддержку системы.

Ох, не в ту тему я ответ свой запостил

Денис, ты упрощаешь и, возможно, удешевляешь, внедрение своего проекта, но не поддержку этого проекта в долгосрочной перспективе. Если твоё решение не использует стандартные паттерны вроде AIF, его в любом случае будет сложнее поддерживать и расширять другим консультантам.

[Vadik]

Цитата:

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

И теперь я склоняюсь к тому, чтобы писать код "сбоку"

Ну, в любом случае решения с заранее искусственно наложенными ограничениями, будь они в виде "все сбоку" или "все на стандарте" заведомо проигрышные, как мне кажется. Почему бы не воспользоваться стандартом в той части, где он есть и нормально работает? (тут правда надо наступить на горло собственной гордости "все ###ы я Дартяньян", сесть и разобраться). Или уж тогда давайте не будем ограничиваться своми интеграционными фреймфорками, напишем свой собственный InventTrans, InventSum и LedgerTrans, а потом свой интерпретатор X++ и компилятор CIL. Мы же вендору ни в чем не доверяем, параноить - так по полной, на все деньги

Цитата:

Ибо опираться на стандарт нынче это складывать все свои яйца в одну львинную пасть

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

[fed]

Цитата:

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

Ох, не в ту тему я ответ свой запостил

Денис, ты упрощаешь и, возможно, удешевляешь, внедрение своего проекта, но не поддержку этого проекта в долгосрочной перспективе. Если твоё решение не использует стандартные паттерны вроде AIF, его в любом случае будет сложнее поддерживать и расширять другим консультантам.

Ну знаешь - я ни на немецком, ни на турецком, ни на российских рынках не видел консультантов со знанием AIF. Может у вас в Заливе они и попадаются часто, но мне кажется это от избытка трудолюбивых, но дешевых индусов, которые за 20 долларов в час и три плошки кичри в день будут неделями сидеть и изучать галочки в той новой фигне которую сегодня микрософт в текущем маркетинге использует. Отсюда избыток дешевых консов со знанием AIF или workflow.
Вообще - по легенде, AIF разрабатывался с упором на его использование в адаптере к Biztalk. И я охотно верю что именно там он смотриться вполне логично. Если у вас лавка достаточно богата чтобы содержать конса по сложнейшему и мощнейшему Biztalk, то вероятно деньги на обучение кого-то настройкам AIF у нее найдутся. Если Biztalk не используется, то и AIF идет в топку.

Кроме того - клиентам не очень-то легко продать идеи стоимости поддержки проекта в долгосрочной перспективе. Идея потратить лишние человеко-недели на добавление поддержки AIF для новых полей в ключевых таблицах, настройку AIF, обучение админови тп - и все ради каких-то сниженных затрат в пятилетней перспективе - она не всегда найдет особую поддержку клиента. Клиентский ПМ обычно мыслит границами проекта (его все равно после завершения проекта переведут куда-то, а то и повысят). За бюджет проекта он отвечает, за бюджет последющей поддержки - нет.
К слову сказать - характер исходного сообщения Вадима, несколько подрывают веру в большие перспективы стандартных механизмов.
P.S. Прочитал твое сообщение в 'не той' ветке.Так вот - мне тоже приходится поддерживать и переделывать проекты внедренные не моей фирмой. Так вот - разбираться в криво внедренном AIF на порядок сложнее чем в криво написаной самописной интеграции. Просто потому что AIF изначально over-engineered и попытки его расширить грязными руками разработчика типичного уровня безграмотности приводят к чудовищным результатам. В то же время тот же разработчик в состоянии написать примитивный импорт примитивных производственных заказов через ODBC и в его коде можно разобраться за пару часов времени. Этот код тоже не фонтан, но в связи с его примитивностью его вполне можно починить.

Наконец еще раз напоминаю - не всегда настройка дешевле программирования. После достижения некоторой степени сложности настройки, дешевле (и в краткосрочной и в долгосрочной перспективе) не настраивать, а тупо кодить.

[fed]

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

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

[Fillin]

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

[fed]

Цитата:

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

Или уж тогда давайте не будем ограничиваться своми интеграционными фреймфорками, напишем свой собственный InventTrans, InventSum и LedgerTrans, а потом свой интерпретатор X++ и компилятор CIL. Мы же вендору ни в чем не доверяем, параноить - так по полной, на все деньги

Еще раз напоминаю - вопрос не в том что мне лень разбираться. Вопрос чисто комммерческий. Я не вижу на моих рынках особого спроса на знание AIF. Я не вижу на тех же рынках большого количества консультантов со знанием AIF. Все это приводит к тому что изучение и использование стандарта в этой области - экономически не целесообразно.
В то же время специалистов по логистике и сводному (и с точки зрения консалтинга и с точки зрения разработки) на рынке много и спрос на этих специалистов присутствует. Поэтому вполне целесообразно изучать и использовать стандарт. (не говоря уже о том что глюков там на порядок меньше чем в AIF).
Почему так случилось ? Потому что идиоты-маркетологи ухитрились продвинуть AIF (разработанный как адаптер к Biztalk), как универсальное интеграционное средство. Из за этого случилась куча провальных проектов, с кучей проблем порожденных именно AIF. Часть проблем была из за сырости AIF, часть проблем из за того что сама технология была перепродана и клиенты пытались ее использовать не по назначению (не как частный и ограниченный механизм обмена документами, а как универсальный механизм интеграции всего и вся), часть проблем была порождена отсутствием внятной документации с концептуальным описанием идеи (а не просто рассказом о галочках).
Собственно - результат на лицо.

[macklakov]

Цитата:

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

напишем свой собственный InventTrans, InventSum и LedgerTrans

В следующей версии этих сущностей может не оказаться. И когда есть "самописный" веб-сервис который всю эту кухню разруливает, то изменения локализованы именно в этом веб-сервисе. Не надо ничего менять в интегрируемом приложении. Не надо ничего менять в AX. Все ограничивается переписыванием логики веб-сервиса.
Если же клиентское приложение знает о существовании LedgerTrans, то переход на новую версию может оказаться полон сюрпризов.
В сущности, этот подход лишь попытка приспособиться к быстрому эволюционированию продукта.
P.S. Эти кастомные веб-сервисы я обычно пишу на x++ и через AIF выставляю. Но клиентскому приложению об этом знать не обязательно.

[Vadik]

Цитата:

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

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

Ну вот опять - консультантов со знанием продукта нет, а мифы о нем - есть Адаптер для BizTalk был только в 4.0 и не то чтобы сильно пиарился. Ни с 2009, ни с 2012 он не используется. Несерьезно это - делать такого уровня выводы основываясь на слухах

Цитата:

Так вот - разбираться в криво внедренном AIF на порядок сложнее чем в криво написаной самописной интеграции. Просто потому что AIF изначально over-engineered и попытки его расширить грязными руками разработчика типичного уровня безграмотности приводят к чудовищным результатам

Ты разбирался или ты предполагаешь, как это будет ? Нечему там расширяться особо - parm методы, prepareForSave и updateNow (pre- и post- обработка)

Цитата:

К слову сказать - характер исходного сообщения Вадима, несколько подрывают веру в большие перспективы стандартных механизмов

Ты наверное как-то выборочно читаешь. Я писал что
- простые data entity подключаются на раз. с ними работаешь примерно как c AIF в прошлых версиях. Готовых - примерно 1600 штук из коробки (не все оформлены как Public, ну и не без багов, как же без них). То, что в data management активно используется для импорта-экспорта на проектах (мастер-данные), уже более-менее вылизано (по крайней мере, 9 интерфейсов на стандартных entities запустились на раз). С заказами вот неувязочка вышла, это мы сейчас вместе с MS исправляем
- composite enities - только для импорта (не для интеграций), к сожалению
- recurring intergartions - кака, этим пользоваться нельзя

[fed]

Цитата:

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

Ты разбирался или ты предполагаешь, как это будет ? Нечему там расширяться особо - parm методы, prepareForSave и updateNow (pre- и post- обработка)

Это просто если ты его по назначению используешь. А я видел (и вынужден был поддерживать) решения где разработчики из AIF в тихаря журналы разносили или писали в какие-то отдельные файлы протоколами обмена или делали другие очень интересные, но неоднозначные вещи
Ты мне рассказываешь о том как все хорошо, если AIF используется квалифицированными специалистами и по назначению. А я тебе рассказываю как он реально использовался в тех проектах, которые мне чинить пришлось.
Причем когда я спрашивал - а НАХЕРА вы вообще засунули в AIF разноску picking journal по производственным заказам, клиент мне честно смотрел в глаза и говорил: А нам Микрософт порекомендовал AIF как универсальное интеграционное решение.И мы всю интеграцию сделали путем легкого расширения AIF. (То есть - в стандартные AIFовские классы засунули кучу дополнительной бизнес логики, которая в зависимости от типа документа тихонько пыталась чего-нить где-нить разнести, регулярно отваливаясь на ходу и оставляя poison pills в очереди сообщений).

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

[Vadik]

Цитата:

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

Ты мне рассказываешь о том как все хорошо, если AIF используется квалифицированными специалистами и по назначению. А я тебе рассказываю как он реально использовался в тех проектах, которые мне чинить пришлось

Ну а откуда тогда уверенность что эти нехорошие люди (тьфу на них) на коленке сделали бы лучше ? Может, не в продукте все же дело ?

[Maxim Gorbunov]

Цитата:

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

Если Biztalk не используется, то и AIF идет в топку.

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

Да, я соглашусь, бывает, что AIF используют неправильно и совсем не для того, для чего он предназначен. Соглашусь и с тем, что документации катастрофически мало. Но, как и любой фреймворк, он хотя бы делает попытку дисциплинировать и ограничить полёт фантазии программиста.

Цитата:

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

Кроме того - клиентам не очень-то легко продать идеи стоимости поддержки проекта в долгосрочной перспективе. Идея потратить лишние человеко-недели на добавление поддержки AIF для новых полей в ключевых таблицах, настройку AIF, обучение админови тп - и все ради каких-то сниженных затрат в пятилетней перспективе - она не всегда найдет особую поддержку клиента. Клиентский ПМ обычно мыслит границами проекта (его все равно после завершения проекта переведут куда-то, а то и повысят). За бюджет проекта он отвечает, за бюджет последющей поддержки - нет.

Клиентские ПМ, в большинстве своём, вполне адекватные люди. Просто надо разговаривать с ними и объяснять такие вещи на доступном языке, без лишних технических или маркетинговых подробностей. Мне встречалось немало ПМ, для которых одно упоминание о том, что мы используем стандартный функционал по максимуму, являлось достаточных обоснованием дополнительных административных затрат на настройку и обучение. Просто они уже понабивали себе шишек, поддерживая другие (совсем необязательно это должна быть Аксапта) кастомные решения. Больше того, многие проекты внедрения Аксапты как раз и начинались для того, чтобы такие решения заменить и стандартизировать процесс.

Цитата:

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

Просто потому что AIF изначально over-engineered и попытки его расширить грязными руками разработчика типичного уровня безграмотности приводят к чудовищным результатам. В то же время тот же разработчик в состоянии написать примитивный импорт примитивных производственных заказов через ODBC и в его коде можно разобраться за пару часов времени. Этот код тоже не фонтан, но в связи с его примитивностью его вполне можно починить.

То есть, из-за безграмотности типичного разработчика ты предлагаешь выкинуть фреймворк? Ну, так мы можем далеко уйти. Типичному безграмотному разработчику, возможно, будет тяжело разобраться с разноской инвойсов по продажам, но уж с записью данных напрямую в таблицы он как-нибудь разберётся. Разрешим ему писать в таблицы?

[Morpheus]

Цитата:

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

То есть, из-за безграмотности типичного разработчика ты предлагаешь выкинуть фреймворк? Ну, так мы можем далеко уйти. Типичному безграмотному разработчику, возможно, будет тяжело разобраться с разноской инвойсов по продажам, но уж с записью данных напрямую в таблицы он как-нибудь разберётся. Разрешим ему писать в таблицы?

Седьмая версия Аксапты была спроектирована как раз для таких разработчиков.

[Vadik]

Цитата:

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

Седьмая версия Аксапты была спроектирована как раз для таких разработчиков.

А Вас не затруднит чуть-чуть более развернуто и аргументированно рассказать, на основании какого опыта с AX7 Вы пришли к этому выводу? А то я немного комплексую уже. Заранее спасибо

[Maxim Gorbunov]

Цитата:

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

Седьмая версия Аксапты была спроектирована как раз для таких разработчиков.

Э-э-э... не понял... для того, чтобы таких разработчиков стало меньше или наоборот? AX7 накладывает некоторые дополнительные ограничения на разработку модификаций, и - понимаю, что в меня сейчас полетят помидоры - это правильно и это хорошо для качества продукта в целом.

[fed]

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

[fed]

Цитата:

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

Ну а откуда тогда уверенность что эти нехорошие люди (тьфу на них) на коленке сделали бы лучше ? Может, не в продукте все же дело ?

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

[ax_mct]

Цитата:

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

Просто потому что AIF изначально over-engineered и попытки его расширить грязными руками разработчика типичного уровня безграмотности приводят к чудовищным результатам. В то же время тот же разработчик в состоянии написать примитивный импорт примитивных производственных заказов через ODBC и в его коде можно разобраться за пару часов времени. Этот код тоже не фонтан, но в связи с его примитивностью его вполне можно починить.
Наконец еще раз напоминаю - не всегда настройка дешевле программирования. После достижения некоторой степени сложности настройки, дешевле (и в краткосрочной и в долгосрочной перспективе) не настраивать, а тупо кодить.

Цитата:

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

Грань между личными и профессиональными отношениями с вендором надо проводить и поддерживать очень четко

Мне кажется что разница в двух лагерях лишь в отношении к клиенту, в бизнес-подходе. А не в отношении к AIF так таковому.

Для одних вендор это неизбежное зло и для других вендор это партнер в игре как выдоить побольше молока.