В компании «Блэк Машрум» возникла идея проекта электронной коммерции — предоставления сервиса оплаты разнообразных услуг через мобильное устройство на платформе Android с привлечением сервисов агрегаторов платежей. К такому мобильному приложению нужен доступ по HTTP и JSON, а к платежной системе требуется обращаться через ее API — веб-сервисы с SOAP-содержимым (WSDL). Как интегрировать одно с другим без потери производительности при разработке приложений и обеспечить быструю реакцию на изменения, для того чтобы опередить конкурентов? Делать «на коленке» было нельзя — потенциальные инвесторы вряд ли бы это одобрили, однако и выделить много ресурсов на проект также не представлялось возможным.

Проанализировав несколько продуктов, позволяющих решить поставленную задачу (среди них Apache ESB, Talend Open Studio for ESB и Oracle Middleware Suite), в компании предпочли систему InterSystems Ensemble [1], полагая, что настройка процесса интеграционного взаимодействия и логики обработки в ней осуществляется быстрее и лучше. Однако у сотрудников «Блэк Машрум» был только опыт работы с Cache ObjectScript, а не с Ensemble — комплексным решением, сочетающим в себе СУБД, сервер приложений, интеграционную шину предприятия (ESB), систему BPM и технологию разработки аналитических приложений, что, с другой стороны, исключало необходимость изучения нескольких различных продуктов и их интеграции. Объектная модель хранения Cache позволяет напрямую сохранять объекты в базе данных: объект является экземпляром какого-либо класса, а класс — это своего рода шаблон, в соответствии с которым создаются его экземпляры. Каждый объект имеет уникальный идентификатор и характеризуется свойствами и поведением, определяемым набором методов класса. Объект в системе может существовать и в оперативной памяти, и в виде своей хранимой версии в базе данных. В Ensemble имеется способ интеграции с внешними и внутренними системами по различным протоколам за счет расширяемой библиотеки адаптеров.

Клиент (мобильное устройство) по протоколу HTTP отправляет запрос c JSON-содержимым на порт сервера, который проверяется «черным ящиком» Ensemble и после обработки получает ответ. Для реализации такой простой схемы в Ensemble была создана продукция (Production — интеграционное решение), состоящая из трех частей: бизнес-сервисов, бизнес-процессов и бизнес-операций. Сервис в Ensemble — это компонент, принимающий запросы по различным протоколам,процесс — логика работы приложения, операция — компонент, позволяющий посылать исходящие запросы во внешние системы. Внутри Ensemble все взаимодействие производится на основе очередей сообщений — объектов пользовательского класса. Класс должен содержать все необходимые пользователю свойства и для применения его объектов в качестве сообщений должен быть унаследован от одного из системных классов Ens.Request или Ens.Response. Такое наследование дает возможность передавать объекты класса между частями продукции, а также вести визуальный мониторинг этого взаимодействия встроенными средствами Ensemble.

В Ensemble реализовано несколько системных классов адаптеров, позволяющих осуществлять взаимодействие по наиболее распространенным протоколам, — например, созданная служба оплаты услуг использует HTTP-адаптер, реализуемый системным классом EnsLib.HTTP.InboundAdapter. С помощью этого адаптера можно задать конкретный порт и получать HTTP-запросы, отправленные на него клиентом. Далее служба преобразует полученный запрос в сообщение, а затем отправляет процессу, получая в ответ сообщение с результатами обработки, после чего преобразует его в форму ответа для клиента. Бизнес-процесс реализует логику приложения и содержит последовательность действий, которые необходимо выполнить для того, чтобы дать ответ клиенту, — например, сохранить/обновить данные клиента, добавить новую отслеживаемую услугу, запросить статус услуги, оплатить услугу. Ясно, что, не имея интеграционной платформы, пришлось бы писать много кода.

В Ensemble бизнес-процесс описывается на языке Business Process Language (BPL) и собирается в визуальном редакторе (рис.1) с использованием таких элементов, как присваивание, преобразование данных, вызов кода, синхронные и асинхронные вызовы и др. В итоге вместо большой программы получается визуальная блок-схема бизнес-процесса сервиса оплаты разнообразных услуг через мобильное устройство.

 

Рис. 1. Схема бизнес-процесса проведения платежной операции с мобильного устройства
Рис. 1. Схема бизнес-процесса проведения платежной операции с мобильного устройства

 

На рис. 1 приведен пример процесса для двух разных запросов пользователя — «Получить доступные данные об услуге» и «Оплатить услугу»:

  • сохранение клиентских данных — с помощью преобразования данных все данные клиента переписываются в отдельный объект, после чего вызывается код для их сохранения в базе;
  • получение актуальных данных от платежной системы — с помощью другого преобразования заполняются данные запроса к платежной системе, осуществляется запрос и полученные услуги сохраняются в базе данных (аналогичная операция выполняется и при оплате, чтобы удостовериться в том, что услуга еще актуальна);
  • запрос на оплату — проводится проверка, найдена ли услуга; если нет, производится возврат ошибки «Услуга не найдена / уже оплачена», иначе — осуществляется расчет комиссии и полной суммы платежа, а затем заполняется форма запроса и реализуется запрос на оплату к платежной системе;
  • ответ в формате клиента — полученный результат преобразуется в форму, принятую для ответа клиенту.

Любые преобразования осуществляются без написания кода. Например, как видно на рис. 2, поля объекта сообщения ставятся в соответствие аналогичным полям объекта запроса к платежной системе: создается новое преобразование, указывается класс, объектом которого является источник данных, и класс, объектом которого является приемник данных, далее нужные поля просто соединяются.

Разберем подробнее приведенный пример. Наш сервис получил HTTP-запрос от клиента, преобразовал его в сообщение (объект созданного класса invoice.Msg.Message) и передал это сообщение процессу. Затем процесс должен сделать запрос к платежной системе, а для этого необходимо заполнить поля запроса, используя данные, полученные от клиента. Как показано на рис. 2, данные из полей email, fee, amount и т. д. объекта сообщения сохраняются в соответствующих полях объекта запроса путем простого соединения полей.

Рис. 2. Пример фрагмента преобразования данных
Рис. 2. Пример фрагмента преобразования данных

 

Помимо сервисов и бизнес-процессов, в Ensemble есть компонент «бизнес-операции», и если сервис — это своего рода входной адаптер, то операции позволяют реализовать запрос по любому протоколу к произвольной внешней системе, например, с помощью встроенного в студию расширения, импортируемого из Cache Studio и документа WSDL от платежной системы. Для этого в Studio нужно выбрать команду Инструменты-Add-Ins-Расширения-Мастер создания SOAP-клиента, установить полученный от платежной системы документ WSDL на сервер, указать его расположение и отметить «Создать операцию». В таком случае, помимо генерации кода на основе WSDL, автоматически создаются необходимые операция и классы. В итоге получаем готовый код для запросов-ответов к платежной системе. После этого нужно добавить эту операцию в продукцию, указать в портале управления Ensemble-Настроить-Продукция и открыть нужную продукцию, а затем задать мнемоническое имя операции (например, «InfoOperation»).

Работа с платежной системой происходит по протоколу SSL, поэтому к операции необходимо прикрепить соответствующие сертификаты. Их можно создать через «Портал управления системой», для чего нужно указать «Администрирование системы — Безопасность — SSL/TLS — новая конфигурация» и описать сертификат клиента и закрытый ключ. После этого остается только вызвать операцию из бизнес-процесса. В нашем случае таких операций две: для информационной и для платежной составляющих.

Коме того, имеется еще отдельный процесс, реализующий встроенными средствами Ensemble PUSH-уведомления о новых услугах, на которые подписался клиент, и об истечении сроков скидок на услуги. Также реализован процесс получения по протоколу SFTP (SSH File Transfer Protocol) реестров от платежной системы. Реестры — это текстовые файлы в формате csv, содержащие полную информацию по проведенным платежам, которая используется для сверки данных клиента и платежной системы, а также для генерации чеков и их предоставления клиенту в формате PDF.

***

Таким образом, для организации обращения к платежной системе не понадобилось писать ни строчки кода, а на базе выбранной технологии за две недели было запущено мобильное приложение для оплаты штрафов ГИБДД через мобильные устройства на платформе Android. В перспективе такие приложения могут быть созданы и на платформах iOS и Web.

Литература

  1. Олег Оленин. Промышленная СУБД для Web 2.0 // Открытые системы. СУБД. — 2009. — № 2. — С. 35–37. URL: http://www.osp.ru/os/2009/02/7322762 (дата обращения: 18.05.2016).

Тамара Лебедева (tlebedeva@systems.moscow) — архитектор, компания «Блэк Машрум» (Москва).