AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 24.08.2016, 10:01   #1  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,043 / 2092 (78) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Интеграция - использовать стандарт или писать на коленке ?
Vadik - продолжение ветки AX7 - data entities - sales order

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

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

Последний раз редактировалось Vadik; 24.08.2016 в 11:20.
Старый 24.08.2016, 10:08   #2  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,474 / 4690 (161) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Vadik Посмотреть сообщение
Да что ж у вас там за программисты такие-то ? С AIF я как правило просто выбирал подходящий сервис (из двух сотен "из коробки"), за полдня рисовал и отдавал клиенту proof of concept проект по его использованию, настраивал порт и data policy, и дальше он делал все сам.
Это означает что те самые 85% трудозатрат на трансляцию логики данных выполнялись у клиента где-то за пределами Аксапты и тебе были попросту невидны.
За это сообщение автора поблагодарили: OhMyBrain (1).
Старый 24.08.2016, 10:37   #3  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,429 / 1554 (58) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Давайте в отдельную ветку вынесем, чтобы продолжить в более широком поле.
Сделал
Цитата:
Ключевое в вашей истории - "отдавал клиенту и дальше он сам"
Да, интерфейс к AX открываем и настраиваем мы, программирует его подключение и использование в своих кастомных приложениях клиент самостоятельно. Вроде все логично
Цитата:
Также просьба рассказать про стандартные Локализованные сервисы
Я к сожалению не знаю что такое Локализованные сервисы. Если речь о неполной поддержке российской локализации (с ней работаю мало, могу быть не в курсе) - Вам как представителю партнера наверное продуктивнее было бы общаться с российским офисом MS и выбивать из них нужное
Цитата:
А мы за полдня делали готовую реализацию
Я не уверен что понимаю смысл заложенный в "реализацию за полдня", так как она вроде на обеих сторонах делаться должна. Но, в любом случае - поздравляю
Цитата:
Это означает что те самые 85% трудозатрат на трансляцию логики данных выполнялись у клиента где-то за пределами Аксапты и тебе были попросту невидны
Мне - видно все . Я с твоей оценкой распределения трудозатрат на согласование бизнес-логики и данных между приложениями вроде не спорил. Но я в упор не понимаю как оно относится к выбору между использованием стандартных фреймфорков (к слову, в семерке готовых "из коробки" entity и потенциально готовых к употреблению сервисов - более 1600) и самопиской. Ты же с завидным упорством приводишь этот аргумент снова и снова. Так мы не договоримся
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 24.08.2016 в 10:47.
Старый 24.08.2016, 11:19   #4  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,474 / 4690 (161) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Vadik Посмотреть сообщение

Мне - видно все . Я с твоей оценкой распределения трудозатрат на согласование бизнес-логики и данных между приложениями вроде не спорил. Но я в упор не понимаю как оно относится к выбору между использованием стандартных фреймфорков (к слову, в семерке готовых "из коробки" entity и потенциально готовых к употреблению сервисов - более 1600) и самопиской. Ты же с завидным упорством приводишь этот аргумент снова и снова. Так мы не договоримся
Ну вот представь себе: Есть аксапта, которая используется для логистики и производства. Есть закупки и продажи где-то во внешней системе. (пусть даже 1с для ясности). тебе надо регулярно импортировать информацию о входящих и выходящих накладных и платежах, а также сопоставлять накладные с платежами в Аксапте.
В целом - могу представить что ты где-то в промежуточной системе хранишь мэппинг номенклатур, кодов клиентов и поставщиков и аналитик. Но проблема в том что тебе при импорте надо создать заказ/закупку (или не создавать - может есть уже подходящий), потом разнести накладную (и помнится в AIF такой функции просто нету), потом разнести журнал платежей (для всех дневных платежей чохом) и, наконец, сопоставить каждый из этих самых платежей с входящей или исходящей накладной (скорее всего - разнесенной ранее). Из этого процесса, я только импорт заказов/закупок/журналов с помощью AIF могу представить. Все остальное - как-то не очень. При этом ситуация достаточно типична - это не только исключительно с 1с такая засада, а с любой локальной системой. (Видел ситуацию где сейлы создавали все документы в сильно допиленной MS CRM и надо было их в системе как-то отражать. Включая резервирование товара на ранних стадиях жизни заказа в CRM, и разноску picking list когда сейл отдает складскому задание на отгрузку, потом packing slip, invoice и так далее).
Старый 24.08.2016, 11:36   #5  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,429 / 1554 (58) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от fed Посмотреть сообщение
Но проблема в том что тебе при импорте надо создать заказ/закупку (или не создавать - может есть уже подходящий), потом разнести накладную (и помнится в AIF такой функции просто нету), потом разнести журнал платежей (для всех дневных платежей чохом) и, наконец, сопоставить каждый из этих самых платежей с входящей или исходящей накладной (скорее всего - разнесенной ранее). Из этого процесса, я только импорт заказов/закупок/журналов с помощью AIF могу представить. Все остальное - как-то не очень
Так, давайте попробуем разделить собственно интеграцию бизнес-документов (заказов) и кастомную бизнес-логику которую хочет клиент помимо интеграции. С первым AIF справлялся на "отлично", второе (естественно) должно кастомизироваться. В AIF кстати для этого AxdBase.updateNow() перекрывается. Как из этого делается вывод о том что создание заказов должно делаться с нуля и на коленке, чем это быстрее, надежнее, дешевле и лучше в конечном итоге чем использование стандартного сервиса - для меня загадка
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 24.08.2016 в 11:45.
Старый 24.08.2016, 11:59   #6  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,474 / 4690 (161) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Vadik Посмотреть сообщение
Так, давайте попробуем разделить собственно интеграцию бизнес-документов (заказов) и кастомную бизнес-логику которую хочет клиент помимо собственно интеграции. С первым AIF справлялся на "отлично", второе (естественно) должно кастомизироваться. В AIF кстати для этого AxdBase.updateNow() перекрывается. Как из этого делается вывод о том что создание заказов должно делаться с нуля и на коленке, чем это быстрее, надежнее, дешевле и лучше в конечном итоге чем использование стандартного сервиса - для меня загадка
Ну ты конечно можешь разделить, но проблема в том, что импорт документов не отделим от импорта операций. И если с точки зрения Аксапты - накладная это операция над заказом, то с точки зрения другой системы (1c) - это документ. И если мне все равно придется дофига времени потратить на разработку импорта операций, то мне совсем не тяжело в тот же кусок кода добавить маленький кусочек, который и документы создает. При этом мне не придется тратить время на разбирательство с настройками AIF и тамошними глюками, которых в версиях 4 и 2009 было более чем достаточно. Соответственно - избегая использовать AIF, я заметно упрощаю внедрение и поддержку системы.
В том то и дело - что понятия бизнес-документов в одной системе в принципе не меппятся в понятия бизнес-документов в другой. Бизнес-документ в одной системе - это операция в другой или наоборот.
За это сообщение автора поблагодарили: gl00mie (1).
Старый 24.08.2016, 12:20   #7  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,043 / 2092 (78) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Fed - люто плюсую. AIF для стандартных операций Аксы - нормальная тема, но мир намного богаче

Про локализацию и MS все просто - "это не планируется". Так же как и локализация OLAP отчетности, портала и т.п. Поддерживать локализацию силами партнера - не вариант.
__________________
Ivanhoe as is..
Старый 24.08.2016, 12:43   #8  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,429 / 1554 (58) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от fed Посмотреть сообщение
При этом мне не придется тратить время на разбирательство с настройками AIF и тамошними глюками, которых в версиях 4 и 2009 было более чем достаточно
Ну вот почему практически всегда ссылки на нежелание "разбираться" с AIF и утверждения о многочисленных его глюках идут вместе, а ? Или это о "в вашей аксапте ничего не работает" вообще, не применительно к AIF? А что внедрять тогда?
Как гарантируется отсутствие глюков и багов в 100% кастомном интерфейсе ?
Цитата:
В том то и дело - что понятия бизнес-документов в одной системе в принципе не меппятся в понятия бизнес-документов в другой. Бизнес-документ в одной системе - это операция в другой или наоборот
Ну так давайте не плодить сущности без явной на то необходимости, эти проблемы вообще не связаны с выбором между стандартными / нестандартными интерфейсами
Цитата:
но мир намного богаче
Это универсальный аргумент, им при желании что угодно можно обосновать. Дальше уже либо требовать конкретики, разбираться и спорить с пеной у рта до победного конца, либо потихоньку выходить из дискуссии. В данный момент, я выбираю второе
__________________
-ТСЯ или -ТЬСЯ ?
Старый 24.08.2016, 13:00   #9  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,583 / 5174 (180) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
А мы за полдня делали готовую реализацию
"Не верю!" © Именно делали или просто переносили XPO-шку с другого проекта?
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Также просьба рассказать про стандартные Локализованные сервисы. Про удобство работы конечного пользователя, про удобство отслеживания интеграции администратом и т.п.
Да-да, тоже очень интересно, как вы за полдня делали готовую реализацию, удобную для конечного пользователя и администраторов системы Про AIF:
- для пользователя, пожалуй, неудобно то, что нельзя из коробки отследить историю обработки интеграции, скажем, по отдельно взятому заказу на продажу
+ тем же администраторам отслеживать инциденты, на мой взгляд, весьма удобно: для любого, скажем, входящего порта можно увидеть историю исключений и посмотреть, на каком сообщении возникла ошибка, а можно включить отладочные механизмы и видеть вообще все сообщения подряд.
- из коробки не видно стека вызовов, но это легко лечится.
- довольно трудоемко, к примеру, добавлять новые поля в документы: для этого надо подчас переделать пару Query, View, перегенерить какие-нить AxBC-классы, etc.
- не подходит для массовых тупых переливок данных 1-в-1, хотя это не минус, а скорее из области ограничений и допущений
- полный трэш, если, скажем, увеличилась длина строкового поля в таблице для уже опубликованного и используемого сервиса документов: нужно руками чистить кэш AXD-схем, которые AIF использует для валидации входящих сообщений. Ну т.е. если об этом знать, то нормально, а если не знать, то полный трэш
+ меня больше всего радует в AIF defaulting значений полей, а также возможность его повторного использования внутри аксаптовой бизнес-логики, никак не связанной с интеграциями. По-моему, это просто шедевр
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
а если клиент считает деньги, имеет большой опыт работы с бизнес-приложениями (которые сделаны для бизнеса, а не для вендора приложения), а уже потом декларирует "мы внедряем стандарт" - ситуация иная.
По-моему, ситуация сильно зависит от ставок: если клиенту озвучат, что нарисуют в Аксапте любую интеграцию по его желанию, но это будет от 100 часов по ставке €120/час (думаю, обычная ставка у буржуйских консалтеров), то он может согласиться и на AIF PoC за полдня
За это сообщение автора поблагодарили: alex55 (1).
Старый 24.08.2016, 13:28   #10  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,474 / 4690 (161) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Vadik Посмотреть сообщение
Ну вот почему практически всегда ссылки на нежелание "разбираться" с AIF и утверждения о многочисленных его глюках идут вместе, а ? Или это о "в вашей аксапте ничего не работает" вообще, не применительно к AIF? А что внедрять тогда?
Свои глюки искать и править быстрее чем микрософтовские.
А еще я видел два примера использования AIF для интеграции. В одном случае для текстильной MES, во втором - для универсальной MES. В обоих случаях - модуль интеграции был самым популярной причиной проблем с системой. То есть - вот буквально проблемы на обоих проектах классифицировались как "Проблемы AIF" и "Все остальные проблемы". Причем соотношение колебалось между 40:60 и 60:40
Во вторых - ладно - я AIF как-нить выучу (и выучил в конечном итоге, хотя в 2012ой не довелось попользоваться). Проблема в том что реальные сотрудники клиента на реальных внедрениях не вполне в состоянии изучить все эти тонкие интеграционные технологии и разбираться в том как с проблемами бороться. У них там и так запара и зоопарк систем. Как-то разобраться в X++ они могут, соответственно самопальное решение тупо и влоб написанное, они поддерживать смогут (потому что в нем трассироваться просто и не надо лишние сущности изучать). А необходимость трассировать AIFовские классы даже у меня краткий приступ депрессии вызывает.
Старый 24.08.2016, 13:41   #11  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,474 / 4690 (161) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Вообще получается что для реальных интеграционных сценариев (где надо и документы и операции импортировать), AIF просто не пригоден. Пригоден он для прямолинейного переливания справочников 1:1 или каких-нить простейших структур master-detail. Проблема в том что в таких вырожденных ситуациях, время на разработку самописного класса сопоставимо со временем настройки AIF. А поддерживать самописный класс невпример легче...
Старый 24.08.2016, 14:19   #12  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,043 / 2092 (78) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от 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 на Западе.
__________________
Ivanhoe as is..
Старый 24.08.2016, 14:47   #13  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,583 / 5174 (180) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Конкретных два примера:
1. импорт прайс-листа поставщика на 100К+ позиций - типовая задача у дистрибутора. С созданием номенклатур, если их еще нет, обновлением цен.
Заведение номенклатур импортом в той же 12-ке - это очень, по-моему, нетривиальная задача (если брать шаблоны и варианты продуктов). Неужели вы и такое за полдня на коленке делаете?
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
2. импорт заказов на продажу с интернет-сайта. С он-лайн проверкой остатков, резервированием и т.п. Как это сделать в AIF? Стандартном.
Вот как раз импорт заказов на продажу с интернет-сайта с резервированием и т.п. делается в стандартном AIF очень замечательно - при условии, что сайт научится заворачивать свой заказ на продажу в правильный SOAP. Не знаю, правда, что вы подразумеваете под проверкой остатков - отлуп, если заказ нельзя полностью зарезервировать? Но такого в стандартной Аксапте нет, поэтому нет и в AIF.
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Да, есть наработки, есть типовые шаблоны.
И почем вы продаете свои наработки клиенту, 4 часа разработки на импорт прайс-листа поставщика ?
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Нельзя же трогать! а вдруг новый SP выйдет, это ж сколько времени потом на каждое обновление подымать?
Если нельзя трогать, то остается стандартный набор полей - вот и нет проблем Нельзя, как говорится, сделать яичницу, не разбив при этом чего-нибудь...
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Если вы активно используете эти классы и для других задач, то да, согласен что удобно. Но если их придется пилить под требования локализации только ради AIF - увольте
Мне исторически как раз очень много приходилось заниматься поддержкой и развитием уже внедренной Аксапты, а не только запуском импорта прайс-листов поставщика за 4 часа с последующим соскоком на другой проект. Поэтому для меня очень большую ценность приобрели возможности расширять бизнес-логику (тот же defaulting полей), не перелопачивая при этом стопятсот связанных явно и неявно импортов, интеграций, обработок, созданий заказов/журналов из кода и прочей требухи. Согласен, что на внедрениях зачастую приоритеты совсем другие, отсюда типовые импорты вида clear/initValue/понапихили полей абы как/insert - спасибо, если validateWrite вызовут перед этим. А там хоть трава не расти...

Последний раз редактировалось gl00mie; 24.08.2016 в 14:55.
Старый 24.08.2016, 16:06   #14  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,043 / 2092 (78) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от 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 - это плохой код. Приоритеты на проекте - да, они есть и их диктует Заказчик, а не Программист, как не странно И тут вообще широкое поле для философии. Можно извернуться на проекте и использовать типовую функциональность не по назначению вместо программирования - а что, очень находчиво. А потом столкнутся с тем, что понадобился этот стандарт на развитии, а он уже "занят". Как можно было это предвидеть?

Баланс должен быть, идеальный баланс - искусство. При этом я понимаю, что ситуации бывают разные и мой опыт - это мой опыт и не более того всем хороших проектов!
__________________
Ivanhoe as is..
Старый 24.08.2016, 16:36   #15  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,429 / 1554 (58) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от 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 из коробки должен сделать? Ну там, поздравить клиента с днем рождения или шаббатом? Или если он вдруг это сумеет, мы еще по-быстрому хотелок накидаем, чтобы доказать что он в "реальных интеграционных сценариях" неприменим? Это мелко, Хоботов (с)
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 24.08.2016 в 17:05.
Старый 24.08.2016, 16:42   #16  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,043 / 2092 (78) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
О том и речь, есть кучка кирпичиков в AIF. А есть одна доработка, которая делает типовую задачу. Про импорт номенклатур - каждую неделю производитель присылает прайс-лист. Пользователь нажимает кнопку, указывает файл, получает результат. Опишите, как это сделать с AIF?

Опишите, пожалуйста, ваши типовые примеры интеграции через AIF. Чтобы не с одного проекта, а хотя бы 4-5. Будет для всех больше пищи для ума
__________________
Ivanhoe as is..
Старый 24.08.2016, 17:27   #17  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,429 / 1554 (58) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от 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
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 24.08.2016 в 18:25.
За это сообщение автора поблагодарили: trud (1), Zick-Zibn (1).
Старый 24.08.2016, 17:53   #18  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
2,367 / 896 (34) +++++++
Регистрация: 10.10.2005
Адрес: Westlands
В принципе необязательно менять существующий AIF сервис, можно тупо сдублировать все связанные обьекты и потом их расширять в рамках нового сервиса. Я так и делал. Выглядит красиво типа новый AIF сервис.

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

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

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

Последний раз редактировалось ax_mct; 24.08.2016 в 17:59. Причина: ЗЫ
Старый 24.08.2016, 18:04   #19  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,429 / 1554 (58) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Но только если возможно то предпочту не использовать AIF, всегда предлагаю тупо и просто secure-ftp сетевые папки для обмена файлами
Ну а мне как человеку которому все и разрабатывать и поддерживать - асинхронные вызовы не айс как-то. На той стороне какую-то дрянь отправили и расслабились, а мне с ней что делать? Отдельные папки для необработанного ? Парсить мегабайты логов ? Нет уж - только хардкор, только синхронные вызовы, и пока мне эти данные в AX не понравятся настолько чтобы я смог их обработать, я своего OK на них не дам
Цитата:
И часто бизнес-партнерам или провайдерам услуг это совсем не нужно
Это неправильным провайдерам услуг не нужно. А вот некоторым правильным типа провайдеров EDI интересно чтобы у нас было относительно стандартное решение для стандартного продукта, чтобы его можно было легко внедрить на другом клиенте и жить на ренту. С такими и файлами пообмениваться не грех
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 24.08.2016 в 18:20.
Старый 24.08.2016, 19:40   #20  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
2,367 / 896 (34) +++++++
Регистрация: 10.10.2005
Адрес: Westlands
!
Цитата:
Сообщение от Vadik Посмотреть сообщение
Ну а мне как человеку которому все и разрабатывать и поддерживать - асинхронные вызовы не айс как-то. На той стороне какую-то дрянь отправили и расслабились, а мне с ней что делать? Отдельные папки для необработанного ? Парсить мегабайты логов ? Нет уж - только хардкор, только синхронные вызовы, и пока мне эти данные в AX не понравятся настолько чтобы я смог их обработать, я своего OK на них не дам

Это неправильным провайдерам услуг не нужно. А вот некоторым правильным типа провайдеров EDI интересно чтобы у нас было относительно стандартное решение для стандартного продукта, чтобы его можно было легко внедрить на другом клиенте и жить на ренту. С такими и файлами пообмениваться не грех
Файл переносится в архивную папку. Простое решение интеграции которое живет всю историю AX и жить будет пока та еще шевелится.

А вот насчет синхронности/асинхронности - да, интересный пойнт. Но чаще асинхронность на проектах. И к ней надо стремится если есть выбор.

Одно дело популярность AIF у поставщиков решений которые хотят на гламурной волне маркетинга подняться, и совсем другое дело у прагматичных клиентов которые не в информационном вакууме, а так или иначе имеют проектный опыт и оценивают риски.

Жить на ренту - это не на основе AIF. Вот как раз файловая система будет надежнее. Или SSIS etc. То есть технологически должно быть тупо и просто. Иначе никакой ренты.

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

Последний раз редактировалось ax_mct; 24.08.2016 в 19:48.
Теги
#msftadvocate, aif, абстракции, закопаем стюардессу, индийская кухня, интеграция, как правильно, холивар

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Должностные лица - использовать или нет? olesh DAX: Программирование 5 04.03.2019 16:22
Модуль Проекты можно ли использовать Aquarius DAX: Функционал 1 27.02.2015 18:35
AX.NET: интеграция .NET-приложений с Аксаптой и (будущие) возможности облачных вычислений gl00mie DAX: Программирование 2 23.04.2010 00:47
Андре: Интеграция Ax с системами контроля версий Андре DAX Blogs 7 03.03.2008 14:47
Управление команой разработчиков - что лучше использовать ShadowFromXZone DAX: Прочие вопросы 66 05.02.2007 19:58
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 19:44.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.