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

[Vadik]

Цитата:

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

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

Так, давайте попробуем разделить собственно интеграцию бизнес-документов (заказов) и кастомную бизнес-логику которую хочет клиент помимо интеграции. С первым AIF справлялся на "отлично", второе (естественно) должно кастомизироваться. В AIF кстати для этого AxdBase.updateNow() перекрывается. Как из этого делается вывод о том что создание заказов должно делаться с нуля и на коленке, чем это быстрее, надежнее, дешевле и лучше в конечном итоге чем использование стандартного сервиса - для меня загадка

[fed]

Цитата:

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

Так, давайте попробуем разделить собственно интеграцию бизнес-документов (заказов) и кастомную бизнес-логику которую хочет клиент помимо собственно интеграции. С первым AIF справлялся на "отлично", второе (естественно) должно кастомизироваться. В AIF кстати для этого AxdBase.updateNow() перекрывается. Как из этого делается вывод о том что создание заказов должно делаться с нуля и на коленке, чем это быстрее, надежнее, дешевле и лучше в конечном итоге чем использование стандартного сервиса - для меня загадка

Ну ты конечно можешь разделить, но проблема в том, что импорт документов не отделим от импорта операций. И если с точки зрения Аксапты - накладная это операция над заказом, то с точки зрения другой системы (1c) - это документ. И если мне все равно придется дофига времени потратить на разработку импорта операций, то мне совсем не тяжело в тот же кусок кода добавить маленький кусочек, который и документы создает. При этом мне не придется тратить время на разбирательство с настройками AIF и тамошними глюками, которых в версиях 4 и 2009 было более чем достаточно. Соответственно - избегая использовать AIF, я заметно упрощаю внедрение и поддержку системы.
В том то и дело - что понятия бизнес-документов в одной системе в принципе не меппятся в понятия бизнес-документов в другой. Бизнес-документ в одной системе - это операция в другой или наоборот.

[Vadik]

Цитата:

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

При этом мне не придется тратить время на разбирательство с настройками AIF и тамошними глюками, которых в версиях 4 и 2009 было более чем достаточно

Ну вот почему практически всегда ссылки на нежелание "разбираться" с AIF и утверждения о многочисленных его глюках идут вместе, а ? Или это о "в вашей аксапте ничего не работает" вообще, не применительно к AIF? А что внедрять тогда?
Как гарантируется отсутствие глюков и багов в 100% кастомном интерфейсе ?

Цитата:

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

Ну так давайте не плодить сущности без явной на то необходимости, эти проблемы вообще не связаны с выбором между стандартными / нестандартными интерфейсами

Цитата:

но мир намного богаче

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

[fed]

Цитата:

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

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

Свои глюки искать и править быстрее чем микрософтовские.
А еще я видел два примера использования AIF для интеграции. В одном случае для текстильной MES, во втором - для универсальной MES. В обоих случаях - модуль интеграции был самым популярной причиной проблем с системой. То есть - вот буквально проблемы на обоих проектах классифицировались как "Проблемы AIF" и "Все остальные проблемы". Причем соотношение колебалось между 40:60 и 60:40
Во вторых - ладно - я AIF как-нить выучу (и выучил в конечном итоге, хотя в 2012ой не довелось попользоваться). Проблема в том что реальные сотрудники клиента на реальных внедрениях не вполне в состоянии изучить все эти тонкие интеграционные технологии и разбираться в том как с проблемами бороться. У них там и так запара и зоопарк систем. Как-то разобраться в X++ они могут, соответственно самопальное решение тупо и влоб написанное, они поддерживать смогут (потому что в нем трассироваться просто и не надо лишние сущности изучать). А необходимость трассировать AIFовские классы даже у меня краткий приступ депрессии вызывает.

[Maxim Gorbunov]

Цитата:

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

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

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

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

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

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

[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 так таковому.

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