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

[mazzy]

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

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

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

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

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


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

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

[Morpheus]

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

[mazzy]

Zitat:

Zitat von Morpheus

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

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

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

[ax_mct]

Zitat:

Zitat von mazzy

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

Zitat:

Zitat von Morpheus

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

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

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

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

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

Zitat:

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]

Zitat:

Zitat von ax_mct

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

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

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

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

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

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

[ax_mct]

Zitat:

Zitat von ax_mct

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

[/B]

Zitat:

Zitat von mazzy

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

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

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

Zitat:

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

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

[mazzy]

Zitat:

Zitat von ax_mct

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

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

Zitat:

Zitat von ax_mct

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

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

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

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

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

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

[Dumfag]

Zitat:

Zitat von Morpheus

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

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

[mazzy]

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

[ax_mct]

Zitat:

Zitat von mazzy

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

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

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

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

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

[ax_mct]

Zitat:

Zitat von ax_mct

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

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

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

[egorych]

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

[mazzy]

Zitat:

Zitat von ax_mct

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

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

Zitat:

Zitat von egorych

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

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

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

[Diman]

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

[egorych]

Zitat:

Zitat von mazzy

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

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

[mazzy]

Zitat:

Zitat von mazzy

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

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

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

Zitat:

Zitat von Diman

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

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

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

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

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

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

[mazzy]

пример доступа к DB со стороны серверной части
https://metanit.com/web/nodejs/6.2.php

[Diman]

Zitat:

Zitat von mazzy

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


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

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

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

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

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

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

[mazzy]

Zitat:

Zitat von Diman

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

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

[Diman]

Zitat:

Zitat von mazzy

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

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