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

[mazzy]

аксапта на react, cloudPOS на knockout... и никогда не быть им вместе...
поэт, уводящий в оффтопик. блин.


вернемся к теме?

Цитата:

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

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

Предположим, есть традиционное веб-приложение на традиционном для веба LAMP

Как лучше с архитектурной точки зрения организовать доступ к Аксапте для взаимодействие с Аксаптой этого приложения? делать прокси к бизнес-коннектору? делать сервер OData? Создавать специализироованные веб-сервисы средствами самой Аксапты? Еще как-то?
Поделитесь опытом, размышлениями.

Есть ли уже готовые решения?

были высказывания:

Цитата:

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

Я бы сделал так:
AX as a set of services - Queue - facade [LAMP + front (reactJS)]
Можно отказаться от очереди в этой схеме если пользователь готов ждать\терять запрос\ответ и весь роутинг зашить в LAMP

Цитата:

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

А я бы сделал старый-добрый Web сервис, ну или REST, но независимый от Аксапты - который бы реализовывал нужный функционал.
Как он будет это делать - через коннектор, Odata или просто читать напрямую из базы - уже дело вкуса. Внешнее приложение просто дергало бы в нужный момент сервис и не парилось как там чего реализовано.

Цитата:

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

Я не считаю работу в оффлайне обязательной, в некоторых сценариях без онлайна не обойтись. Но я считаю, что обмен данными стороннего приложения с Аксаптой должен быть по возможности асинхронным. Асинхронность уже дает некую автономность и предполагает хранение слепков данных отдельно от БД Аксапты, а дальше, если развивать тему, можно воспроизвести во внешнем приложении некую бизнес-логику, которая будет работать на доступных в оффлайне данных из Аксапты.
...
А если приложение и в оффлайне не работает, то чем оно лучше уже имеющейся в коробке портальной веб-морды, для которой уже реализован механизм "достучаться до Аксапты"?

еще?