AX7 - data entities - sales order

[Vadik]

Коллеги, кто-то уже использовал data entities для создания заказов на продажу с синхронным вызовом ? То что есть сейчас не сильно нравится. Я в курсе существования KB3171892, но composite data entities не могут использоваться с синхронными вызовами. То, как используется OData здесь - это просто Содом и Гоморра какие-то по сравнению с тем что можно было делать в AIF, одна генерация номера заказа на клиенте чего стоит. Смотрю в сторону recurring integrations, но там тоже чувствую все не однозначно
Если кто-то может поделиться обезличенным проектом или просто поделится опытом, буду премного благодарен

[trud]

Вот здесь же Иван 20 минутное видео сделал как раз посвященное этому
выглядит правда тоже странновато, поделитесь потом, насколько это рабочий вариант

Цитата:

In the process, you will get an understanding of the following concepts:
•Data entities
•Composite data entities
•XML structure of the ASN files
•Data management workspace
•Service endpoint authentication
•Azure Active Directory app registration
•REST enqueue API, GitHub app
•etc.

http://kashperuk.blogspot.com.au/201...ound-asns.html

[Vadik]

Спасибо

[Vadik]

Цитата:

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

выглядит правда тоже странновато, поделитесь потом, насколько это рабочий вариант

Это DMF-подобный импорт из говна и палок, названный по какому-то недоразумению интеграцией. Запустить это в принципе возможно, поддерживать - на мой взгляд, нет

[mazzy]

Цитата:

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

data entities для ... заказов на продажу

в 7.0 microsoft использует data entities только для работы с setup-данными.
думаю, что пока не стоит использовать их для работы с worksheet-данными. и уж точно не стоит использовать в транзакционными данными. пока по крайней мере.

[Vadik]

Цитата:

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

в 7.0 microsoft использует data entities только для работы с setup-данными

ну, не совсем так

Цитата:

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

Ну тогда AIF верните что ли, изверги - ничего другого-то нет. А то про расширения, минимум over-layering-а, облака и OData (настолько кстати продвинутая технология, что даже в Visual Studio не поддерживается штатно) - я уже наслушался, они прекрасны и я их всецело одобряю и поддерживаю. Но клиенту нужно тупо работать и гонять заказы из самописной учетной системы в AX, а нормального штатного механизма как оказывается и нету. Приехали, как говорится

[EVGL]

Цитата:

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

в 7.0 microsoft использует data entities только для работы с setup-данными.

Еще как использует. Только их и использует: импорт банковской выписки. Импорт выписки кредитной карты. Обмен данными о номенклатуре, клиентах и поставщиках.

[mazzy]

Цитата:

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

Еще как использует. Только их и использует: импорт банковской выписки. Импорт выписки кредитной карты. Обмен данными о номенклатуре, клиентах и поставщиках.

чёрт, я опять что-то из закрытого ляпнул, что ли?

а могу попросить ссылки на классы, которые занимаются импортом выписки?
просто мне самому интересно что за фигня с этими data entity происходит.

[Vadik]

Цитата:

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

а могу попросить ссылки на классы, которые занимаются импортом выписки?

Я скриншот с data entity выше постил вроде

[trud]

А чем не подходит ваш пример в первом посте про OData?
номер заказа можно получать через предварительный вызов web сервиса к примеру

[Vadik]

Цитата:

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

А чем не подходит ваш пример в первом посте про OData?
номер заказа можно получать через предварительный вызов web сервиса к примеру

За неимением лучшего, он подходит. Осталось только

Цитата:

insert not allowed for field 'FormattedDeliveryAddress'

починить

[macklakov]

Цитата:

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

это просто Содом и Гоморра какие-то по сравнению с тем что можно было делать в AIF

Это AIF был содомом и гоморрой, т.к. нарушал инкапсуляцию. Сейчас есть кошерный json. А odata, насколько понимаю, оставили чисто для своих целей (если поискать, ее и в 12-й можно найти), но из маркетинговых соображений выставляют как дополнительную опцию.

[Vadik]

Цитата:

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

Это AIF был содомом и гоморрой, т.к. нарушал инкапсуляцию. Сейчас есть кошерный json. А odata, насколько понимаю, оставили чисто для своих целей

У вас там уже пятница ? Затрудняюсь установить логическую связь инкапсуляции и JSON, про противопоставление JSON и OData тоже хотелось бы услышать чуть более развернуто. Ну и, само собой, о том как идеологически, расово правильно и политкорректно делать интеграцию заказов в AX7

[macklakov]

Цитата:

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

Ну и, само собой, о том как идеологически, расово правильно и политкорректно делать интеграцию заказов в AX7

Да как в нормальном программировнии. У тебя есть интерфейс, состоящий из методов, ты в них передаешь параметры, а что там сервер с этими параметрами делает, для тебя скрыто. Черный ящик. Те проблемы которые ты испытываешь, связаны не веб-сервисами, а с тем, что ваше решение было написано через AIF, причем, судя по всему, не через кастомные веб-сервисы. Были бы они кстомные, это был бы кошерный SOAP, который и в 7 вполне себе поддерживается.

[gl00mie]

Цитата:

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

Это AIF был содомом и гоморрой, т.к. нарушал инкапсуляцию.

Как интересно: в MS разработали этот framework, несколько версий его продвигали и развивали, и вот когда для публикации портов отпала уже необходимость танцев с бубнами, ручной настройкой точек входа и проч., оказалось, что AIF-таки нарушает инкапсуляцию и потому более неприменим! Т.е. то, что он не "вписался" в облака, тут совершенно ни при чем, все дело в инкапсуляции, из-за нарушения которой клиенты, видимо, мучились все эти годы. Вы - астронавт архитектуры?

Цитата:

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

Сейчас есть кошерный json.

Напоминает Огонь и движение:

Цитата:

Подумайте об истории всевозможных стратегий доступа к данным, разработанным Microsoft. ODBC, RDO, DAO, ADO, OLEDB, теперь вот ADO.NET - И все абсолютно новые! Может это было вызвано технологической необходимостью? Может это результат некомпетентной группы проектирования, которой необходимо придумывать по-новой доступ к данным каждый чертов год? (Возможно, это в самом деле так.)

Цитата:

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

Да как в нормальном программировнии. У тебя есть интерфейс, состоящий из методов, ты в них передаешь параметры, а что там сервер с этими параметрами делает, для тебя скрыто. Черный ящик.

В переводе с австралийского на русский: выкиньте наши фреймворки и пишите интеграции сбоку на коленке, так что ли?

Цитата:

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

Те проблемы которые ты испытываешь, связаны не веб-сервисами, а с тем, что ваше решение было написано через AIF, причем, судя по всему, не через кастомные веб-сервисы.

Т.е. возникшие проблемы никак не связаны с отказом от AIF в 7-ке, правильно?

Цитата:

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

Были бы они кстомные, это был бы кошерный SOAP, который и в 7 вполне себе поддерживается.

Действительно, зачем было использовать доступный из коробки AIF, если можно писать всё сбоку на коленке, тут и дураку понятно, что это было просто неправильное архитектурное решение! Вот решение использовать новый OData или composite data entities - правильное, честна-честна, ага...

[macklakov]

Цитата:

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

Как интересно: в MS разработали этот framework

ходят слухи что это шедевр некоего бангалорского стартапа

Цитата:

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

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

Ну, такова традиция.

Цитата:

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

Не_дайте_Астронавтам_Архитектуры_вас_запугать

Ну вот универсальность AIF с его "seemless integration" это как раз и был попыткой выйти в астрал.

Цитата:

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

В переводе с австралийского на русский: выкиньте наши фреймворки и пишите интеграции сбоку на коленке, так что ли?

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

Цитата:

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

зачем было использовать доступный из коробки AIF, если можно писать всё сбоку на коленке, тут и дураку понятно, что это было просто неправильное архитектурное решение!

Как первый день в этом бизнесе, честно слово. Забыли с кем дело имеете? Я уже 3 года только так и делаю. На коленке и сбоку. Кастомный веб-сервис пишется в разы быстрее, работает надежнее и в сопровождении прост.

Цитата:

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

Вот решение использовать новый OData или composite data entities - правильное, честна-честна, ага...

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

[fed]

Вообще многие годы работы с Ax, привели меня к выводу что лучший способ интеграции - это как раз таки написание наколенного кода на X++. Как он с внешним миром обменивается - через текстовые файлы, ODBC-соединение в соседнюю БД - второстепенно. Главное что в конечном итоге, трудозатраты на интеграцию намного ниже чем при использовании любых предлагаемых в настоящее время Microsoft|Navision|Damgaard тулзов. Контроль над данными - полный, а вопросы собственно технических коммуникаций между Ax и внешней системой - это максимум 15% от проблем организации обмена. Все равно без программирования две системы не синтегрировать. И проще этот код написать в Ax на X++, чем пытаться какие-то настроки в biztalk приделать или расширения Integration Services писать или какие-нить приблуды на Perl для модификации текстовых файлов лабать. Сразу у тебя в одном месте и логика преобразования чужих данных и логика модификации аксаптовских данных. В конечном итоге - удобнее и дешевле получается.

[Vadik]

Цитата:

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

Вообще многие годы работы с Ax, привели меня к выводу что лучший способ интеграции - это как раз таки написание наколенного кода на X++

Тут каждый для себя решает самостоятельно, спорить не буду. Но ты упускаешь тот факт что "многие годы работы с AX" - это было на on premise, а в чужом облаке у тебя возможности для маневра в выборе технологии немного ограничены хостером (вендором). Поэтому подстраиваться, понимать и договариваться все же придется

P.S. Что касается ошибки с

Цитата:

insert not allowed for field 'FormattedDelveryAddress

, менее чем через час после создания инцидента в LCS позвонили, расспросили, начали разбираться. Приятно, по сравнению с саппортом MS году эдак в 2005

[Vadik]

Да, забыл - приглашаю любителей наколеночных решений поделиться в этой ветке своими success stories с интеграциями построеными на файловых обменах, ODBC и прочем и их миграции в Azure. Для полноты спектра - особенно приветствуются сценарии с AX в Azure и миксом из внешних приложений в Azure и on-premise. Ничего ведь переписывать не пришлось, все само смигрировало и работает ?

[fed]

Цитата:

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

Да, забыл - приглашаю любителей наколеночных решений поделиться в этой ветке своими success stories с интеграциями построеными на файловых обменах, ODBC и прочем и их миграции в Azure. Для полноты спектра - особенно приветствуются сценарии с AX в Azure и миксом из внешних приложений в Azure и on-premise. Ничего ведь переписывать не пришлось, все само смигрировало и работает ?

Это из серии "Сами себе создаем трудности - сами преодолеваем". У нас в фирме действует официальная установка - постараться не продавать 7ку до момента выхода on-premise версии. И знаешь - как-то у большинства клиентов упоминание того что надо бы обождать с этим Ажуром и пожить на версии 2012 находит горячую поддержку. Мало кто рвется свои данные индусам в облако отдать.

Говоря о миграции - так ситуация не такая сложная как тебе кажется. Просто раньше у меня приблуда лезла через ODBC в соседнюю базу, а сейчас мне ее придется переписать на использование локальных буферных таблиц (которые я уж как-нить опубликую в веб с использованием любого из поддерживаемых 7кой механизмов - независимо от их кривизны и глюкавости).
Я уже написал что в интеграции - 85% проблем из за преобразования ЛОГКИКИ данных, а не из за технических сложностей с вызовом web-service/JSON/ODATA/etc или замены EBCDIC на UNICODE. Если логика преобрахования написана на X++, то сложностей с миграцией явно будет меньше независимо от того как и зачем Микрософт поменял AIF на более модный Three Letter Acronym...