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

[Ivanhoe]

Vadik - продолжение ветки AX7 - data entities - sales order

Цитата:

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

Да что ж у вас там за программисты такие-то ? С AIF я как правило просто выбирал подходящий сервис (из двух сотен "из коробки"), за полдня рисовал и отдавал клиенту proof of concept проект по его использованию, настраивал порт и data policy, и дальше он делал все сам.

А мы за полдня делали готовую реализацию Есть разница с PoC? Также просьба рассказать про стандартные Локализованные сервисы. Про удобство работы конечного пользователя, про удобство отслеживания интеграции администратом и т.п.

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

[fed]

Цитата:

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

Да что ж у вас там за программисты такие-то ? С AIF я как правило просто выбирал подходящий сервис (из двух сотен "из коробки"), за полдня рисовал и отдавал клиенту proof of concept проект по его использованию, настраивал порт и data policy, и дальше он делал все сам.

Это означает что те самые 85% трудозатрат на трансляцию логики данных выполнялись у клиента где-то за пределами Аксапты и тебе были попросту невидны.

[Vadik]

Цитата:

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

Давайте в отдельную ветку вынесем, чтобы продолжить в более широком поле.

Сделал

Цитата:

Ключевое в вашей истории - "отдавал клиенту и дальше он сам"

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

Цитата:

Также просьба рассказать про стандартные Локализованные сервисы

Я к сожалению не знаю что такое Локализованные сервисы. Если речь о неполной поддержке российской локализации (с ней работаю мало, могу быть не в курсе) - Вам как представителю партнера наверное продуктивнее было бы общаться с российским офисом MS и выбивать из них нужное

Цитата:

А мы за полдня делали готовую реализацию

Я не уверен что понимаю смысл заложенный в "реализацию за полдня", так как она вроде на обеих сторонах делаться должна. Но, в любом случае - поздравляю

Цитата:

Это означает что те самые 85% трудозатрат на трансляцию логики данных выполнялись у клиента где-то за пределами Аксапты и тебе были попросту невидны

Мне - видно все . Я с твоей оценкой распределения трудозатрат на согласование бизнес-логики и данных между приложениями вроде не спорил. Но я в упор не понимаю как оно относится к выбору между использованием стандартных фреймфорков (к слову, в семерке готовых "из коробки" entity и потенциально готовых к употреблению сервисов - более 1600) и самопиской. Ты же с завидным упорством приводишь этот аргумент снова и снова. Так мы не договоримся

[fed]

Цитата:

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

Мне - видно все . Я с твоей оценкой распределения трудозатрат на согласование бизнес-логики и данных между приложениями вроде не спорил. Но я в упор не понимаю как оно относится к выбору между использованием стандартных фреймфорков (к слову, в семерке готовых "из коробки" entity и потенциально готовых к употреблению сервисов - более 1600) и самопиской. Ты же с завидным упорством приводишь этот аргумент снова и снова. Так мы не договоримся

Ну вот представь себе: Есть аксапта, которая используется для логистики и производства. Есть закупки и продажи где-то во внешней системе. (пусть даже 1с для ясности). тебе надо регулярно импортировать информацию о входящих и выходящих накладных и платежах, а также сопоставлять накладные с платежами в Аксапте.
В целом - могу представить что ты где-то в промежуточной системе хранишь мэппинг номенклатур, кодов клиентов и поставщиков и аналитик. Но проблема в том что тебе при импорте надо создать заказ/закупку (или не создавать - может есть уже подходящий), потом разнести накладную (и помнится в AIF такой функции просто нету), потом разнести журнал платежей (для всех дневных платежей чохом) и, наконец, сопоставить каждый из этих самых платежей с входящей или исходящей накладной (скорее всего - разнесенной ранее). Из этого процесса, я только импорт заказов/закупок/журналов с помощью AIF могу представить. Все остальное - как-то не очень. При этом ситуация достаточно типична - это не только исключительно с 1с такая засада, а с любой локальной системой. (Видел ситуацию где сейлы создавали все документы в сильно допиленной MS CRM и надо было их в системе как-то отражать. Включая резервирование товара на ранних стадиях жизни заказа в CRM, и разноску picking list когда сейл отдает складскому задание на отгрузку, потом packing slip, invoice и так далее).

[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% кастомном интерфейсе ?

Цитата:

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

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

Цитата:

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

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

[Maxim Gorbunov]

Цитата:

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

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

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

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

[Ivanhoe]

Fed - люто плюсую. AIF для стандартных операций Аксы - нормальная тема, но мир намного богаче

Про локализацию и MS все просто - "это не планируется". Так же как и локализация OLAP отчетности, портала и т.п. Поддерживать локализацию силами партнера - не вариант.

[gl00mie]

Цитата:

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

А мы за полдня делали готовую реализацию

"Не верю!" © Именно делали или просто переносили XPO-шку с другого проекта?

Цитата:

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

Также просьба рассказать про стандартные Локализованные сервисы. Про удобство работы конечного пользователя, про удобство отслеживания интеграции администратом и т.п.

Да-да, тоже очень интересно, как вы за полдня делали готовую реализацию, удобную для конечного пользователя и администраторов системы Про AIF:
- для пользователя, пожалуй, неудобно то, что нельзя из коробки отследить историю обработки интеграции, скажем, по отдельно взятому заказу на продажу
+ тем же администраторам отслеживать инциденты, на мой взгляд, весьма удобно: для любого, скажем, входящего порта можно увидеть историю исключений и посмотреть, на каком сообщении возникла ошибка, а можно включить отладочные механизмы и видеть вообще все сообщения подряд.
- из коробки не видно стека вызовов, но это легко лечится.
- довольно трудоемко, к примеру, добавлять новые поля в документы: для этого надо подчас переделать пару Query, View, перегенерить какие-нить AxBC-классы, etc.
- не подходит для массовых тупых переливок данных 1-в-1, хотя это не минус, а скорее из области ограничений и допущений
- полный трэш, если, скажем, увеличилась длина строкового поля в таблице для уже опубликованного и используемого сервиса документов: нужно руками чистить кэш AXD-схем, которые AIF использует для валидации входящих сообщений. Ну т.е. если об этом знать, то нормально, а если не знать, то полный трэш
+ меня больше всего радует в AIF defaulting значений полей, а также возможность его повторного использования внутри аксаптовой бизнес-логики, никак не связанной с интеграциями. По-моему, это просто шедевр

Цитата:

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

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

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

[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. Мы же вендору ни в чем не доверяем, параноить - так по полной, на все деньги

Цитата:

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

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

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

[fed]

Вообще получается что для реальных интеграционных сценариев (где надо и документы и операции импортировать), AIF просто не пригоден. Пригоден он для прямолинейного переливания справочников 1:1 или каких-нить простейших структур master-detail. Проблема в том что в таких вырожденных ситуациях, время на разработку самописного класса сопоставимо со временем настройки AIF. А поддерживать самописный класс невпример легче...

[Ivanhoe]

О том и речь, есть кучка кирпичиков в AIF. А есть одна доработка, которая делает типовую задачу. Про импорт номенклатур - каждую неделю производитель присылает прайс-лист. Пользователь нажимает кнопку, указывает файл, получает результат. Опишите, как это сделать с AIF?

Опишите, пожалуйста, ваши типовые примеры интеграции через AIF. Чтобы не с одного проекта, а хотя бы 4-5. Будет для всех больше пищи для ума

[Vadik]

Цитата:

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

О том и речь, есть кучка кирпичиков в AIF. А есть одна доработка, которая делает типовую задачу. Про импорт номенклатур - каждую неделю производитель присылает прайс-лист. Пользователь нажимает кнопку, указывает файл, получает результат. Опишите, как это сделать с AIF?

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

Цитата:

Опишите, пожалуйста, ваши типовые примеры интеграции через AIF. Чтобы не с одного проекта, а хотя бы 4-5. Будет для всех больше пищи для ума

- Мастер-данные из AX в кастомное приложение, заказы на продажу из него - в AX
- Заказы на продажу, простые складские движения типа adjustment, transfer и counting из кастомного приложения - в AX
- Разнесенные проводки в payroll - между двумя инстансами AX общими журналами ГК (есть и такой, очень, гхм, оригинальный сетап)
- мастер данные, заказы на продажу и накладные с балансом по оплате - между AX и CRM через Dynamics Connector
- заказы на продажу, накладные - из AX на сайт (сайт и AX в одной сети)
- X12 EDI - там что-то мапится на стандарт, что-то (типа каталога 832) - уже не очень и документы нестандартные

P.S. Да, забыл - там где нужен доступ в AX только на чтение и важно время отклика - понемногу используем Dynamic query - они гораздо легче и "отзывчивее" традиционного AIF

[ax_mct]

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

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

AIF смотрится хорошо в резюме и маркетинге, но на проекте это тухлая вещь.

ЗЫ: Чаще всего интегрироваться приходится с системами где уже есть экспорт/импорт простых текстовых файлов, а интерфейса веб-служб просто нет и их надо писать и на той стороне. То есть разработка должна быть и на той стороне.
И часто бизнес-партнерам или провайдерам услуг это совсем не нужно.