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

[fed]

Цитата:

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

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

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

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

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

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

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

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

[fed]

Цитата:

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

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

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

[Maxim Gorbunov]

Цитата:

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

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

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

[ax_mct]

Цитата:

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

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

Цитата:

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

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

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

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