Как достучаться из веб-приложения к акс2012, акс2009? Сервер OData?

[mazzy]

Цитата:

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

RetailCommonWebAPI - это как бы "правильно" с точки зрения вендора, но не не обязательно "верно" для конкретного использования. Никоим образом не рекомендовал. Но оно все же"стандартное" (в новом значении этого слова) и перечислять такое в качестве примера необходимо.

ага. понял.
предлагаю считать долг вендору и Retail-компонентам отданым и перейти к правильному с точки зрения пользователей и ИТ-команды заказчика. Кстати, не исключено, что Retail-компоненты вполне правильные с точки зрения пользователей и ИТ-команды заказчика, просто я их неправильно готовлю.

Цитата:

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

Кстати постановка вопроса "достучаться из веб-приложения к AX" - спорная. Возможно это AX надо обновлять веб-приложение. То есть само веб-приложение не имеет доступа к AX. В идеале - так лучше.

я согласен, что спорная.

изначально писал про то, что современные веб-приложения - это комплекс ПО и на сервере, и на клиенте. Встретить современного клиента без JS... это поискать надо. (или какой-нибудь Dynamics AX WMS. Будем считать, что и ему долг отдали. )))

Причем современные - это не только браузерные приложения, но и Android/iOS приложения.

Скорее у заказчика будет уже существующее веб-приложение типа WMS, типа какой-нибудь внутренней заказывалки или еще что-нибудь. Скорее всего, это приложение будет реализовано на LAMP в виде серверной и клиентской части. Скорее всего, используются какие-нибудь стандартные для веб-мира библиотеки типа node.js, knockout и подобные

Собственно, вопрос как организовать взаимодействие этого приложения с акс2012, акс2009?

[ax_mct]

Цитата:

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

современные веб-приложения - это комплекс ПО и на сервере, и на клиенте. Встретить современного клиента без JS... это поискать надо.
...
Скорее у заказчика будет уже существующее веб-приложение типа WMS, типа какой-нибудь внутренней заказывалки или еще что-нибудь. Скорее всего, это приложение будет реализовано на LAMP в виде серверной и клиентской части
....
Собственно, вопрос как организовать взаимодействие этого приложения с акс2012, акс2009?

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

Что мешает AX самой подключиться к удаленной базе третьего приложения и положить, взять то что нужно? А если в одной сети то вообще - однозначно так.
Есть база MySQL в локальной сети, так что мудить с REST? Для CV?Периодический джобик AX работает с этой базой. У самого этого внутреннего приложения нет доступа к AX - ибо нефиг.

Но вот скорее веб-приложение хостится на AWS, а AX - во внутренней сети. Тут варианты но все равно лучше когда не к AX обращаются, а она сама синхронизирует данные третьего приложения. Так многое упрощается и становится надежнее.

Транспорт? Если это не красивый адаптер для продажи, а как для себя, то я бы передавал файлы через SFTP или HTTP POST.

[ax_mct]

Цитата:

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

Что мешает AX самой подключиться к удаленной базе третьего приложения и положить, взять то что нужно?

В принципе может мешать многое. Но мы же берем ситуацию когда одна и та же команда в одной и той же компании, то есть внутрикорпоративно. Хороший интернет и хорошие программисты

Делать так ISV адаптеры - уже не поймут. Тут конечно же REST/JSON и все такое. Красивое