Показать сообщение отдельно
Старый 22.05.2017, 19:42   #7  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от ax_mct Посмотреть сообщение
RetailCommonWebAPI - это как бы "правильно" с точки зрения вендора, но не не обязательно "верно" для конкретного использования. Никоим образом не рекомендовал. Но оно все же"стандартное" (в новом значении этого слова) и перечислять такое в качестве примера необходимо.
ага. понял.
предлагаю считать долг вендору и Retail-компонентам отданым и перейти к правильному с точки зрения пользователей и ИТ-команды заказчика. Кстати, не исключено, что Retail-компоненты вполне правильные с точки зрения пользователей и ИТ-команды заказчика, просто я их неправильно готовлю.

Цитата:
Сообщение от ax_mct Посмотреть сообщение
Кстати постановка вопроса "достучаться из веб-приложения к AX" - спорная. Возможно это AX надо обновлять веб-приложение. То есть само веб-приложение не имеет доступа к AX. В идеале - так лучше.
я согласен, что спорная.

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

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

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

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