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

[mazzy]

Вопрос. Пока теоретический.

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

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

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

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


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

апд: И да, задача ставится не для "экономии" лицензий Аксапты. Задача "как сделать правильно"

[Morpheus]

С АХ 2012 необходимо интегрировать при помощи "custom" вэб-сервисов. Рабочеи места сотрудников, пользующихся web интерфейсом, лицензируется, как обычные, внешние пользователи - бесплатно.

[mazzy]

Цитата:

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

С АХ 2012 необходимо интегрировать при помощи "custom" вэб-сервисов.

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

А может есть что-нибудь более унверсальный способ?

[ax_mct]

Цитата:

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

• делать прокси к бизнес-коннектору
• делать сервер OData
• Создавать специализироованные веб-сервисы средствами самой Аксапты
• Еще как-то

Цитата:

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

С АХ 2012 необходимо интегрировать при помощи "custom" вэб-сервисов. Рабочеи места сотрудников, пользующихся web интерфейсом, лицензируется, как обычные, внешние пользователи - бесплатно.

"Правильно" но не обязательно "верно" - это JSON.
AX2012 это прежде всего класс RetailCommonWebAPI умеющий работать с JSON.

• Обмен файлами
• Обмен через общую базу данных
• Удаленный вызов функций
• Сервисная шина предприятия (MQ, ESB)
https://habrahabr.ru/post/326088/

А на веб-сервисы мы, хорошо подумав, забили. И вместо них решили реализовать обмен по старому доброму протоколу HTTP с применением обмена файлами
https://habrahabr.ru/company/bitrix/blog/129156/

Насчет всех внешних пользователей они должны быть не просто внешними но сторонними.

Цитата:

External (third party) users do not require licenses. Third party users are users that are not either (i) your or your affiliates’ employees, or (ii) your or your affiliates’ contractors or agents. In this sense, the definition of third party users does not extend to onsite contractors, vendors and users performing business processes on your behalf.

[mazzy]

Цитата:

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

AX2012 это прежде всего класс RetailCommonWebAPI умеющий работать с JSON.

Последние несколько месяцев работаю только с Retail.
Раньше в GMCS работал с этим модулем пару лет.
Удивлен, что объекты этого модуля кто-то в пример приводит.

а это ничего, что этот класс работает с JSON через System.Collections.Hashtable?
причем десериализует без проверок-стражей и даже без перехвата exception?

собственно мой вопрос возник из семейства классов Retail.
Да, вот это мы видим.

А как правильно?
А что делать приложению на LAMP? Переписывать приложение на c# под IIS?

апд: добавил скриншотов

[ax_mct]

Цитата:

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

(1)"Правильно" но не обязательно "верно" - это JSON.
(2 )AX2012 это прежде всего класс RetailCommonWebAPI умеющий работать с JSON.

[/B]

Цитата:

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

Удивлен, что объекты этого модуля кто-то в пример приводит.

а это ничего, что этот класс работает через System.Collections.Hashtable?
причем десериализует без проверок-стражей и даже без перехвата exception?

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

Цитата:

А как правильно?
А что делать приложению на LAMP? Переписывать приложение на c# под IIS?

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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

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

[Dumfag]

Цитата:

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

С АХ 2012 необходимо интегрировать при помощи "custom" вэб-сервисов. Рабочеи места сотрудников, пользующихся web интерфейсом, лицензируется, как обычные, внешние пользователи - бесплатно.

Я правильно понимаю, что это AIF?
Если да, то мне такой способ больше нравится, чем с бизнес-коннектором (создавать дополнительную прослойку для обмена между AX и LAMP, С# на IIS)
Почти все языки поддерживают формат обмена данными по WSDL.

[mazzy]

да, про AIF не сказал.
AIF требует доработки классов и настройки на стороне Аксапты.
AIF отсутствует в акс7. да, я спрашивал про акс2009, акс2012, но точно стоит завязываться на технологию, которой не будет в следующей версии? почему?

[egorych]

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

[mazzy]

Цитата:

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

Инициатором обмена данных может и должна выступать только AX.

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

Цитата:

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

А я бы сделал старый-добрый Web сервис, ну или REST, но независимый от Аксапты - который бы реализовывал нужный функционал

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

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

[egorych]

Цитата:

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

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

Я сторонник специализированных сервисов - и писать проще и работают быстрее.

[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

[mazzy]

Понятно. Спасибо. Надо подумать.

Основное отличие в наших картинах мира:

Цитата:

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

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

Я считаю, что middlware вполне можно создавать на Аксапте, если у нее будет удобный интерфейс к фронту и инструменты разработчика по интеграции с фронтом. На крайний случай где-то на каком-нибудь сервере должны быть развернуты прокси-объекты к Аксапте.

Вы считаете, что Аксапта должна взаимодействовать только с middware, ни в коем случае не с фронтом. В этом случае middlware должен быть достаточно интеллектуальным и достаточно самостоятельным.

Ок. Надо подумать.

[ax_mct]

Цитата:

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

Основное отличие в наших картинах мира:

Я считаю, что middlware вполне можно создавать на Аксапте, если у нее будет удобный интерфейс к фронту и инструменты разработчика по интеграции с фронтом. На крайний случай где-то на каком-нибудь сервере должны быть развернуты прокси-объекты к Аксапте.

Вы считаете, что Аксапта должна взаимодействовать только с middware, ни в коем случае не с фронтом. В этом случае middlware должен быть достаточно интеллектуальным и достаточно самостоятельным.

Настолько революционные идеи как PHP интерфейс к AX мне в голову не приходили. Думаю что ни разработчикам, ни бизнесу это не должно быть интересно.
Хотя в этом что-то есть

Практичнее брать популярный и независимый LAMP продукт и организовать обмен данными. Уверен что чем больше независимости и отдельности - тем лучше.
Причем обмен данными может быть и на уровне баз данных.

Если тема о построении альтернативного frond-end к AX, то я прошу прощения. Для меня веб-приложения на LAMP это уже известные и популярные продукты, а не самописки.

[Diman]

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

[mazzy]

Цитата:

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

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

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

остальное сознательно не конкретизировано.

Цитата:

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

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

Правильно = в долгосрочной перспективе максимизировать удовольствие пользователя от приложения при минимизации трудозатрат разработчиков.

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

скорее всего, при высокой нагрузке будет одно решение. какое?
а при низкой - другое. какое? или то же самое?

на первой итерации я бы с удовольствием послушал знающих людей как подобная задача решается в мире традиционной веб-разработки.

примеры:
https://angularjs.org/ (начиная со слов Data binding)
http://learn.knockoutjs.com/#/?tutorial=loadingsaving
https://facebook.github.io/react/tutorial/tutorial.html

[Diman]

Цитата:

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

остальное сознательно не конкретизировано.


Правильно = в долгосрочной перспективе максимизировать удовольствие пользователя от приложения при минимизации трудозатрат разработчиков.

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

скорее всего, при высокой нагрузке будет одно решение. какое?
а при низкой - другое. какое? или то же самое?

на первой итерации я бы с удовольствием послушал знающих людей как подобная задача решается в мире традиционной веб-разработки.

примеры:
https://angularjs.org/ (начиная со слов Data binding)
http://learn.knockoutjs.com/#/?tutorial=loadingsaving
https://facebook.github.io/react/tutorial/tutorial.html

сервис producer-очередь-сервис consumer обычно такие решения для больших проектов, которые предполагается масштабировать, паблишить наружу и т.п. Если решения для одного конкретного клиента, тот тут слово "правильно" и "приятно" имеют очень широкую трактовку.
Не понял причем тут JS фреймворки.

[mazzy]

Цитата:

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

Не понял причем тут JS фреймворки.

Что можете предложить посмотреть?

[Diman]

Цитата:

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

Что можете предложить посмотреть?

Из очередей: Rabbit, Redis, ActiveMQ
Для интеграции всего этого хозяйства с поддержкой BPM: Apache camel, Mule
Если сервисs не предполагают сложной логики, а так, чисто фасад к БД, то Go, NodeJS
Если сложное, то само собой C# / Java
НО сразу оговорюсь - этот зоопарк есть смысл разводить для больших проектов.
IMHO
Для акса 2012 и выше я бы выбрал сервисы на стороне аксы.