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

[Ivanhoe]

Цитата:

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

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

Конкретных два примера:
1. импорт прайс-листа поставщика на 100К+ позиций - типовая задача у дистрибутора. С созданием номенклатур, если их еще нет, обновлением цен.
2. импорт заказов на продажу с интернет-сайта. С он-лайн проверкой остатков, резервированием и т.п.

Как это сделать в AIF? Стандартном.

Цитата:

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

"Не верю!" © Именно делали или просто переносили XPO-шку с другого проекта?
Да-да, тоже очень интересно, как вы за полдня делали готовую реализацию, удобную для конечного пользователя и администраторов системы

Да, есть наработки, есть типовые шаблоны. На том же форуме сколько импортов из Excel, например? И это нормально. И поддерживать легко - о чем пишет Fed.

Цитата:

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

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

Во многих сценариях это большой минус.

Цитата:

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

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

Плюс минус. Согласен с Fed, что сложновато клиенту.

Цитата:

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

- из коробки не видно стека вызовов, но это легко лечится.

Как же так? Это же коробка время на это входит в полдня на PoC?

Цитата:

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

- довольно трудоемко, к примеру, добавлять новые поля в документы: для этого надо подчас переделать пару Query, View, перегенерить какие-нить AxBC-классы, etc.

Нельзя же трогать! а вдруг новый SP выйдет, это ж сколько времени потом на каждое обновление подымать? Я не передергиваю, есть клиенты западные которые помешаны на "стандарте" и это потом проблема ИТшников. Нормальный подход, но на это деньги нужны.

Цитата:

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

- не подходит для массовых тупых переливок данных 1-в-1, хотя это не минус, а скорее из области ограничений и допущений

Часто важно. Часто импорт на коленке в т.ч. оптимален с т.з. транспорта, например, обработка xls файла, промежуточной БД и веб-сервиса имеет разную реализацию и с точки зрения быстродействия. Из моего любимого последнего - огромный xml файл, который аксапта генерит часами, а простейшая выгрузка в SQL и формирование xml средствами SQL - минуты. И да, в этом сценарии отказались от BizTalk, потому что и он был не способен. А можно было потратить еще сколько-то человеко-месяцев на попытку использовать "стандарт".

Цитата:

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

- полный трэш, если, скажем, увеличилась длина строкового поля в таблице для уже опубликованного и используемого сервиса документов: нужно руками чистить кэш AXD-схем, которые AIF использует для валидации входящих сообщений. Ну т.е. если об этом знать, то нормально, а если не знать, то полный трэш

Бизнеса это не касается. Но после такого бизнес начинает считать ИТ лоботрясами, которым изменить длину поля (одного поля, Карл!) занимает часы, а то и дни на продакшене с десятком AOSов.

Цитата:

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

+ меня больше всего радует в AIF defaulting значений полей, а также возможность его повторного использования внутри аксаптовой бизнес-логики, никак не связанной с интеграциями. По-моему, это просто шедевр

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

Цитата:

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

По-моему, ситуация сильно зависит от ставок: если клиенту озвучат, что нарисуют в Аксапте любую интеграцию по его желанию, но это будет от 100 часов по ставке €120/час (думаю, обычная ставка у буржуйских консалтеров), то он может согласиться и на AIF PoC за полдня

Есть такое. Плюс архитектора накиньте, технического конса, МП, технического писателя и т.п. Только на русском форуме ожидается по умолчанию обсуждение наших реалий. Я верю и знаю про использование практически стандартных AX на Западе.

[gl00mie]

Цитата:

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

Конкретных два примера:
1. импорт прайс-листа поставщика на 100К+ позиций - типовая задача у дистрибутора. С созданием номенклатур, если их еще нет, обновлением цен.

Заведение номенклатур импортом в той же 12-ке - это очень, по-моему, нетривиальная задача (если брать шаблоны и варианты продуктов). Неужели вы и такое за полдня на коленке делаете?

Цитата:

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

2. импорт заказов на продажу с интернет-сайта. С он-лайн проверкой остатков, резервированием и т.п. Как это сделать в AIF? Стандартном.

Вот как раз импорт заказов на продажу с интернет-сайта с резервированием и т.п. делается в стандартном AIF очень замечательно - при условии, что сайт научится заворачивать свой заказ на продажу в правильный SOAP. Не знаю, правда, что вы подразумеваете под проверкой остатков - отлуп, если заказ нельзя полностью зарезервировать? Но такого в стандартной Аксапте нет, поэтому нет и в AIF.

Цитата:

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

Да, есть наработки, есть типовые шаблоны.

И почем вы продаете свои наработки клиенту, 4 часа разработки на импорт прайс-листа поставщика ?

Цитата:

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

Нельзя же трогать! а вдруг новый SP выйдет, это ж сколько времени потом на каждое обновление подымать?

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

Цитата:

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

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

Мне исторически как раз очень много приходилось заниматься поддержкой и развитием уже внедренной Аксапты, а не только запуском импорта прайс-листов поставщика за 4 часа с последующим соскоком на другой проект. Поэтому для меня очень большую ценность приобрели возможности расширять бизнес-логику (тот же defaulting полей), не перелопачивая при этом стопятсот связанных явно и неявно импортов, интеграций, обработок, созданий заказов/журналов из кода и прочей требухи. Согласен, что на внедрениях зачастую приоритеты совсем другие, отсюда типовые импорты вида clear/initValue/понапихили полей абы как/insert - спасибо, если validateWrite вызовут перед этим. А там хоть трава не расти...

[Ivanhoe]

Цитата:

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

Заведение номенклатур импортом в той же 12-ке - это очень, по-моему, нетривиальная задача (если брать шаблоны и варианты продуктов). Неужели вы и такое за полдня на коленке делаете?

Ага, можно еще стопяцот таблиц связанных заполнить с номенклатурой и делать импорт месяц. Оценка в полдня была не про это, а про пример Vadik с готовым AIF. Простые справочники, базовые журналы.

Цитата:

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

Вот как раз импорт заказов на продажу с интернет-сайта с резервированием и т.п. делается в стандартном AIF очень замечательно - при условии, что сайт научится заворачивать свой заказ на продажу в правильный SOAP. Не знаю, правда, что вы подразумеваете под проверкой остатков - отлуп, если заказ нельзя полностью зарезервировать? Но такого в стандартной Аксапте нет, поэтому нет и в AIF.

Просьба прислать пример SOAP запроса, который создает заказ из трех строк, просит зарезерировать товар (не всегда авторезервирование, а именно явное требование оного), просит проверить баланс клиента. AIF должен вернуть статус в виде создан заказ или нет, если нет - то почему, если да - то номер заказа, статус резерва, статус по оплате.
Fed про то и пишет, что просто втянуть в Акс через AIF - даже не пол беды. А вот все остальное все равно если программировать, то через AIF это делать намного накладнее.

Цитата:

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

И почем вы продаете свои наработки клиенту, 4 часа разработки на импорт прайс-листа поставщика ?

Становитесь клиентом, расскажем

Цитата:

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

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

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

Цитата:

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

Мне исторически как раз очень много приходилось заниматься поддержкой и развитием уже внедренной Аксапты, а не только запуском импорта прайс-листов поставщика за 4 часа с последующим соскоком на другой проект. Поэтому для меня очень большую ценность приобрели возможности расширять бизнес-логику (тот же defaulting полей), не перелопачивая при этом стопятсот связанных явно и неявно импортов, интеграций, обработок, созданий заказов/журналов из кода и прочей требухи. Согласен, что на внедрениях зачастую приоритеты совсем другие, отсюда типовые импорты вида clear/initValue/понапихили полей абы как/insert - спасибо, если validateWrite вызовут перед этим. А там хоть трава не расти...

Не знаю на кого намек в первой части Если говорить про мой опыт, отсутствие validateWrite - это плохой код. Приоритеты на проекте - да, они есть и их диктует Заказчик, а не Программист, как не странно И тут вообще широкое поле для философии. Можно извернуться на проекте и использовать типовую функциональность не по назначению вместо программирования - а что, очень находчиво. А потом столкнутся с тем, что понадобился этот стандарт на развитии, а он уже "занят". Как можно было это предвидеть?

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

[macklakov]

Цитата:

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

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

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

[Vadik]

Цитата:

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

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

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

Цитата:

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

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

[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]

Цитата:

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

Конкретных два примера:
1. импорт прайс-листа поставщика на 100К+ позиций - типовая задача у дистрибутора. С созданием номенклатур, если их еще нет, обновлением цен

EcoResProductService, InventItemService и, полагаю, PriceDiscAdmTransDocService (этот не использовал) ? 100K+ позиций - это да, челлендж. Надо смотреть, как часто вам такие финты ушами проделывать надо. Хотя опять же, между появлением продукта в выгрузке от поставщика и до момента когда все необходимые настройки в AX сделаны и можно реально с ним что-то делать - основные челленджи скорее нетехнического характера

Цитата:

2. импорт заказов на продажу с интернет-сайта. С он-лайн проверкой остатков, резервированием и т.п.

SalesSalesOrderService и настроенное авторезервирование? Вот тут чтобы "не смочь" уже постараться надо

Цитата:

довольно трудоемко, к примеру, добавлять новые поля в документы: для этого надо подчас переделать пару Query, View, перегенерить какие-нить AxBC-классы, etc

Да ладно. Новые parm методы проще руками досоздать, если их не десяток. После это правой кнопкой на сервисе тынц - addins - register service и перезапускаем порт

Цитата:

Бизнеса это не касается. Но после такого бизнес начинает считать ИТ лоботрясами, которым изменить длину поля (одного поля, Карл!) занимает часы, а то и дни на продакшене с десятком AOSов

Ну во первых не часы, а столько сколько у вас обычно накатывание изменений на продуктив занимает. Если вы изменения на размерность, тип поля в staging и target таблицах в AX и изменения в кастомном коде интеграции умеете в продуктив AX 2012 на лету деплоить без остановки приложения - расскажите, пожалуйста, КАК Вы это делаете. Думаю, многим эта информация будет полезна

Цитата:

Просьба прислать пример SOAP запроса, который создает заказ из трех строк, просит зарезерировать товар (не всегда авторезервирование, а именно явное требование оного), просит проверить баланс клиента.

Вы сомневаетесь в том, что через AIF можно SalesLine.Reservation управлять? Или в том, что если значение передать, резервирование выполнится? И про то что проверка кредитного лимита на уровне конкретного заказа не настраивается в стандарте, т.е. по-любому это кастомный флаг и кастомный код - Вы же в курсе?

Цитата:

AIF должен вернуть статус в виде создан заказ или нет, если нет - то почему, если да - то номер заказа, статус резерва, статус по оплате

Это все или есть еще что-то что AIF из коробки должен сделать? Ну там, поздравить клиента с днем рождения или шаббатом? Или если он вдруг это сумеет, мы еще по-быстрому хотелок накидаем, чтобы доказать что он в "реальных интеграционных сценариях" неприменим? Это мелко, Хоботов (с)