AX7 - data entities - sales order

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

[macklakov]

Цитата:

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

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

Извините! Попрошу не путать! То что мы на коленке делаем, еще не значит что мы делаем это через задний проход! И даже, когда приходится большие объемы данных быстро гонять, мы предохраняемся через views.

Цитата:

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

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

Дык если у тебя кастомный AIF опубликован на IIS или самописный WS, который дергает аксу через BC, с точки зрения интегрируемого приложения ничего не меняется, кроме адреса веб-сервиса. Даже если в облако все запихать. Даже если LedgerTrans больше не существует, а аналитки стали ну очень гибкими, веб-сервис выглядит точно так же как и раньше.

[Maxim Gorbunov]

Цитата:

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

Извините! Попрошу не путать! То что мы на коленке делаем, еще не значит что мы делаем это через задний проход! И даже, когда приходится большие объемы данных быстро гонять, мы предохраняемся через views.

Не так давно, волею судеб, пришлось поработать с клиентом, которому проект делал Юрий. Не один делал, конечно, с командой. Подтверждаю, интеграции (по крайней мере, большинство из них) были сделаны на коленке и скреплены скотчем. Проблемы в основном решались путём наматывания большего количества скотча. В результате получилась конструкция, рядом с которой было боязно не то что ходить, но и дышать - как бы не рухнуло всё

Цитата:

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

Поддержу macklakov и fed. Использование того же AIF всегда несло кучу рисков и затрат. В моем опыте на всех проектах, где делали "на коленке", ни разу не пожалели. А ради гипотетического шанса, что проект когда то перейдет на новую версию и там MS позаботится о техническом переходе без проблем, городить огород здесь и сейчас - ну не знаю.

Вот умиляют меня заявления типа "самописное решение легче и дешевле поддерживать". Ребята, никто же и не спорит, что самописное решение лично вам поддерживать проще. И любое расширение этого решения лично вы можете сделать не больше, чем за полдня. Проблемы начинаются, когда вы перестаёте работать в проекте, и поддерживать ваше решение приходится другим людям. Только изучение всех трудов предыдущего автора может занять месяцы (на проекте, о котором я писал выше, только анализ уже третий месяц идёт; когда начнётся дизайн - и начнётся ли он вообще - никто сказать не может). Разумеется, в конечном итоге за это платят клиенты, но готовы ли они были к таким расходам, когда вы им продавали своё недорогое решение, написанное на коленке?

[Maxim Gorbunov]

Цитата:

Сообщение от Maxim Gorbunov

Не так давно, волею судеб, пришлось поработать с клиентом, которому проект делал Юрий. Не один делал, конечно, с командой. Подтверждаю, интеграции (по крайней мере, большинство из них) были сделаны на коленке и скреплены скотчем. Проблемы в основном решались путём наматывания большего количества скотча. В результате получилась конструкция, рядом с которой было боязно не то что ходить, но и дышать - как бы не рухнуло всё

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