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

[gl00mie]

Цитата:

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

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

Нужно уточнить, что значит "достучаться", достаточно ли асинхронного обмена или нужен непременно синхронный. От ответа на этот и другие вопросы сильно зависит реализация.

Цитата:

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

для акс7 понятно - там OData поставляется "из коробки". А вот для предыдущих версий?

Возможно, в вопросе есть часть ответа Может, спустить OData из коробки AX7 в ту же 2012-ю? На счет 2009-й не уверен, что получится легко и просто, но с .net-обертками тоже всё реализуемо.

Цитата:

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

"custom" вэб-сервисы - это специализированные веб-сервисы, написанные на Аксапте?
Другими словами, вести параллельную кастомизацию и в веб-приложении, и в Аксапте?

Если "достучаться" значит "читать данные их AX", то можно сделать что-то универсальное, если же нужно писать данные в AX, то необходимо задействовать бизнес-логику приложения, и тогда, весьма вероятно, без доработки AX не обойтись.
Еще по поводу написания веб-сервисов в AX - я видел, к примеру, To-Increase Web Service Studio, там веб-сервисы не столько пишутся, сколько настраиваются - в простейших случаях буквально за считанные минуты: выбрали публикуемый справочник или "документ", выбрали поля, deploy, profit!

Цитата:

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

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

Ни фига себе типичный пример! Это не "достучаться до AX", это - смостоятельный полноценный модуль из AX с мордой веб-клиента, в котором:

1. используется синхронный обмен данными с AX (важна актуальность данных)
2. непосредственно дергается бизнес-логика AX

Для меня типичный пример - это скорее какая-нибудь интеграция с интернет-магазином:

• обмен данными асинхронный
• стороннее веб-приложение может какое-то время работать автономно
• бизнес-логика AX дергается опосредованно в момент обработки документов

Цитата:

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

Другими словами, на каждый случай свой отдельный сервис? стоит ли заморачиватся универсальными сервисами?

По-моему, можно выделить следующие основные требования к интеграции:

• направление потоков данных (из AX либо в AX)
• синхронность/асинхронность обмена
• необходимость обратной связи
• необходимость дергать бизнес-логику AX (в т.ч. для контроля доступа и применения политик RLS/XDS)
• допустимые виды транспорта данных

Синхронность/асинхронность обмена я выделил как требование, а не как вариант реализации, потому что считаю, что интеграции нужно всегда по возможности делать асинхронными. Отсюда - отсутствие в списке такого параметра как нагрузка. Комбинации приведенных условий формируют ограничения, в рамках которых можно уже искать свой оптимальный вариант реализации:

• Если данные читаются из AX без обратной связи, и бизнес-логику дергать не надо, то возможен вариант наподобие DWH, когда данные читаются напрямую из базы AX либо ее копии. Это - самый лайтовый, самый простой в реализации вариант "достучаться"
• Если всё то же, что с DWH, но прямой доступ к базе AX невозможен, то нужно использовать отдельное решение для интеграции, которое обеспечит доступный транспорт
• Если данные читаются, но нужно контролировать доступ (в т.ч. RLS/XDS), то нужно писать/использовать коробочный сервис в AX - универсальный или нет, дело десятое.
• Если данные читаются, но нужно обеспечить асинхронность (независимость от доступности AX), то нужно писать периодические выгрузки, либо использовать некий фреймворк/горизонтальное решение для интеграции, либо использовать отдельный движок для синхронизации баз (как в модуле Retail)
• Если данные читаются, но нужно обеспечить обратную связь (дошли/не дошли, загрузились или нет), то это уже - вариант с записью данных, см. ниже
• Если данные пишутся синхронно, то нужно в любом случае писать/использовать коробочный сервис в AX, который будет дергать бизнес-логику валидации/defaulting'а/обработки данных
• Если данные пишутся асинхронно, то нужно опять же иметь в AX нечто, что будет дергать бизнес-логику валидации/defaulting'а/обработки данных в AX, при этом для "перекладывания" данных можно использовать DIXF или иное решение для интеграции.
• etc