Проблема «мобилизации» корпоративных SAP приложений

Мир IT всё время меняется, сейчас в нашу жизнь прочно вошли мобильные устройства. Многие из нас уже не представляют, как можно обходится без планшета и смартфона на работе и в быту. Появились магазины App Store и Google Play, где разработчики всего мира предлагают нам приложения на все случаи жизни. Пользоватьcя этими приложениями действительно удобно. Современным web сайты (например, Facebook, Google, GitHub) сейчас больше похожи на полноценные приложения и способны обрабатывать тонны информации, оставаясь простыми и понятными. Множество разработчиков трудятся на тем, чтобы сделать эти приложения ещё более качественными и удобными.

Но корпоративные приложения (Рис. 1) и сервисы до сих пор остаются сложными, медленными, перегруженными информаций, а доступ к ним в большинстве случаев можно получить только с лэптопа, находясь на рабочем месте. Web-интерфейсы удовлетворительно работают только в браузере от компании Microsoft.

Рис. 1 SAP ERP типовой интерфейс

Почему же так мало мобильных и веб-приложений, работающих с корпоративными данными, но имеющих удобный и «легкий» интерфейс?

Какие сложности возникают при разработке такого рода приложений?

Постараемся ответить на эти вопросы:

Во-первых, конечно не все бизнес-операции могут быть «вынесены» из ERP систем для инкорпорирования в  простые мобильные  и веб-приложения. Но операций, с которыми можно это сделать, достаточно; таковыми являются: согласование документов, сбор показаний приборов, отчеты о выполненной работе, ввод сбытовых заказов и т.п.

Во-вторых, корпоративные системы, как правило, достаточно сложны, включают множество различных компонентов, которые предоставляют бизнес-данные в специфичных форматах и по «своим» протоколам. Разработчики этих систем, в первую очередь, решают задачи консистентности, полноты и безопасности обработки данных и, только потом, вопросы дизайна. Автоматизируемые бизнес-процессы объёмом и сложностью способны поставить в тупик даже специалиста.

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

Итак, для того чтобы создать мобильное приложение, специалисту необходимо достаточно хорошо разбираться в хитросплетениях корпоративных сервисов, бизнес-процессах и мобильных платформах (минимум Android и iOS), не лишними будут и навыки дизайна. Это сложно.

Пути решения проблемы

Для решения этих проблем необходим  инструмент, предоставляющий собой мост или шлюз между мирами back-end и front-end разработки, с помощью которого любой корпоративной сервис предоставлял бы данные единообразно, по одному и тому же протоколу (хорошо бы, чтобы этот протокол был максимально простым и широко распространённым), а любая мобильная или веб-платформа умела бы работать с данным протоколом. В этом случае возможно разделение труда разработчиков, а необходимость в «супер-разработчике» отпадает.  Разработчик корпоративных информационных систем занимается своим делам: сохраняет заказы в БД, следит за консистентностью данных, запускает по событиям последующие операции, не беспокоясь о тонкостях клиентской платформы и, тем более, о дизайне. Фронтенд-разработчик также занимается тем, что хорошо умеет делать: рисует красивые виджеты, обеспечивающие удобный ввод данных, разрабатывает удобные графические интерфейсы, а не разбирается в тонкостях работы корпоративных систем в «коммитах» и «ролбэках».

Для систем, построенных на решениях SAP (да и не только), таким инструментом является SAP NetWeaver Gateway, а протоколом – протокол OData (Рис.  2).

Рис.  2 SAP NetWeaver Gateway

Давайте на примере, стараясь особо не вдаваться в технические подробности, посмотрим, как работает этот компонент, для чего он нужен, и какие возможности он предоставляет, да и вообще в чем «profit» от его использования.

В первую очередь нам необходимо разобраться, что же это за протокол OData. Конечно же смотрим Wiki. OData (Open Data Protocol) - это открытый веб-протокол для запроса и обновления данных. Протокол позволяет выполнять операции с ресурсами, используя в качестве запросов HTTP-команды, и получать ответы в форматах XML или JSON.

Русскоязычная вики предоставляет «исчерпывающую» информацию о сабже, меняем язык на английский. Итак, протокол был разработан компанией Microsoft и с версии 4.0 стандартизован OASIS, то есть является промышленным стандартом (кстати SAP Gateway использует версию 2.0). Протокол определяет ресурсы, методы и операции, которые можно выполнять применительно к этим ресурсам. Ресурсы представляются протоколом в виде сущностей, которые имеют свойства, как минимум одно из которых является ключевым. Множество сущностей образуют коллекции. Между сущностями установлены реляционные связи (похоже на реляционную БД?). Связи между сущностями позволяют определить специальные свойства, используемые для навигации между коллекциями.

Например, на рисунке ниже (Рис.  3): сущность Order содержит два свойства OrderID (ключевое) и CustomerID, множество сущностей образуют коллекцию OrderSet. Вторая сущность Customer имеет реляционную связь с Order с кардинальностью один к многим, благодаря чему для Order возможно существование навигационного свойства Customer, которое позволят переходить от заказа к клиенту. А у сущности Custome появляется навигационное свойство OrderSet, позволяющее переходить от клиента к его заказам.

Рис.  3 Простая модель данных

OData является RESTful-протоколом. Что это значит? А то что, ресурсы можно просматривать, создавать, изменять, удалять (для краткости эти операция обозначают аббревиатурой CRUD), используя для этого HTTP-методы.

GET	Получить одну или более записи
POST	Создать новую запись
PUT	Полное обновление существующей записи
PATCH	Частичное обновление существующей записи
DELET	Удаление записи

То есть, для того, чтобы выполнить какое-то действие над ресурсом, достаточно по соответствующему URL послать HTTP-запрос необходимого вида с телом в формате XML или JSON (а если используется метод GET, так и вообще без тела). Например, для того чтобы получить список клиентов из ODatа- версии широко известной, в узких кругах, базы данных Northwind, достаточно отправить GET-запрос по вот этому адресу: http://services.odata.org/V4/Northwind/Northwind.svc/Customers (просто введите путь в адресную строку браузера). Этот запрос выбирает всех клиентов, ограничить выбор можно с помощью дополнения $filter= (прямо как WHERE в SELECT). Для выполнения запросов другого типа просто браузером уже не обойтись, нужно установить какое-нибудь расширение для работы с REST, их много, я , использую Postman.

Ещё одной очень важной особенностью протокола OData является доступность по одному и тому же URL к самим данным и к описаниям этих данных ‑ метаданных. Посмотрим, как это выглядит. Перейдем по следующему URL  http://services.odata.org/V4/OData/OData.svc/, видим список ресурсов, предоставляемых сервисом (Products, Suppliers, Persons и т.д.), добавляем в конец URL $metadata, и вот мы уже имеем полное описание ресурсов, их свойств и отношений между ними. Зная структуру данных и операции, которые применимы к этим данным, можно «на лету» сгенерировать клиент для сервиса.

Все, что нужно знать о протоколе OData (полную спецификацию протокола, примеры сервисов, инструменты и многое другое), можно найти на http://www.odata.org/.

Надеюсь, что с OData примерно понятно, и можно перейти к SAP NW Gateway.

Предполагается, что SAP NetWeaver Gateway установлен, настроен и готов к использованию, как часть SAP Business Suite. Это-так называемая Embedded architecture, существует еще Central Hub architecture , когда  Gateway является отдельной системой. У каждого метода развертывания есть как преимущества, так и недостатки. Также, не используются адаптеры контента для SAP HANA, BPM, GenIL и т.п.

Для того, чтобы реализовать OData сервис (часто говорят OData Channel) с помощью Gateway, необходимо выполнить следующие шаги:

1. Создать и реализовать класс модели (Model class), который будет определять метаданные для нашего OData канала (наследуется класс /IWBEP/CL_MGW_ABS_MODEL).
2. Создать основной класс данных (Main Data Runtime Class), который будет предоставлять данные для нашего OData канала (наследуется класс /IWBEP/CL_MGW_ABS_DATA).
3. Создать для каждой сущности (ресурса) класс данных, зависящий от сущности (Entity Specific Data Classes), реализующий операции, которые можно производить над ресурсом (реализация интерфейса /IWBEP/IF_MGW_APPL_SRV_RUNTIME). Эти классы создавать необязательно, всю логику по обработке данных можно поместить в основной класс дынных, что часто разработчики и делают, так как этот класс «обязан» реализовывать интерфейс /IWBEP/IF_MGW_APPL_SRV_RUNTIME, однако такой подход очень перегружает основной класс данных бизнес-логикой.
4. Создать Техническую модель (Technical Model Name) c помощью транзакции /IWBEP/REG_MODEL. На этом шаге мы говорим системе, что назначение нашего класса, созданного  на первом шаге, я предоставлять метаданные для OData-канала.
5. Создать технический сервис (Technical Service Name) с помощью транзакции. /IWBEP/REG_SERVICE. На этом шаге мы связываем техническую модель (шаг 4) и основной класс данных (шаг 2).
6. На этом шаге мы делаем доступным сервис внешнему миру, для этого используем транзакцию /IWFND/MAINT_SERVICE.
7. Тестируем работоспособность OData-канала с помощью транзакции /IWFND/GW_CLIENT или веб-браузера.

Всё, сервис готов. Сложно? Немного. Ещё достаточно однообразно, особенно первый шаг. Если модель данных проработана, связи между сущностями установлены, реализация класса модели превращается в рутину, да и создание других артефактов - не творческая работа. А для следующего сервиса все эти операции придётся повторить. Есть основание задумается на тем, чтобы автоматизировать эти операции и реализовать удобный интерфейс как в современных средствах разработки ‑ набросали кубиков, начали генерировать и «Вуаля!» - все низкоуровневые операции выполнены программой за нас.

SAP предоставляет такой инструмент, он называется Gateway Service Builder (транзакция SEGW).Это ещё, конечно, не кубики, но уже реальное упрощение и ускорение разработки. Различные «мастеры» позволяют легко создать сущности, как вручную, так и на основании существующих объектов системы, указать связи между ними. Затем нажимаем кнопку «Генерировать» и получаем готовый класс модели (ненароком можно даже забыть о его существовании) и заготовку для основного класса данных, технические модель и сервис.

Можно поступить ещё проще - разработать модель с помощью более удобного средства, например, MS Visual Studio или Eclipse, сохранить модель в EMDX-файле и импортировать его с помощью Gateway Service Builder, получив при этом готовую модель в SAP.

После этого остаётся реализовать методы сущностей модели, протестировать и передать её URL-адрес фронтенд-разработчику. Созданная модель может быть использована для построения приложений, работающих на различных устройствах, мобильных платформах, веб-приложениях, а также использована как источник данных в офисных пакетах, причём всеми  клиентами, которые поддерживают работу с.

Например, модель для работы с заказом клиента может быть использована для мобильного приложения менеджера по продажам, создающего заказ, мобильного приложения руководителя, согласующего эти заказы, веб-сайта компании, предоставляющей средство мониторинга заказов клиенту, для программы на терминале кладовщика, производящего отпуск заказанных товаров, для аналитика, который работает с BI-системой. И не один из разработчиков этих решений не будет знать ничего о таблице VBAK и её связи с таблицей ZSD_VBAK и трудностях их совместного обновления.

Пример работы с OData

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

В SAP структура таблиц выглядит как на Рис. 4

Рис. 4 ER-модель для QM каталогов

Начнем с моделирования сервиса. Для этого воспользуемся средой разработки Eclipse http://eclipse.org/kepler/, у данной IDE очень много возможностей, большая часть из них обеспечивается плагинами. Вот такой plug-in для работы с OData предоставляется SAP и называется Odata Modeler. Взять его можно по этому адресу https://tools.hana.ondemand.com/#gateway. Скачиваем, разархивируем (обычной процедуры установки не требуется), подключаем plug-in.

Создаем