Модуль промежуточной обработки данных в «1С:Предприятие» при использовании HTTP-сервисов

Система программ «1С:Предприятие» предназначена для автоматизации управления и учета на предприятиях различных отраслей, видов деятельности и типов финансирования.

Система «1С:Предприятие» состоит из передовой технологической платформы (ядра) и разработанных на ее основе прикладных решений ("конфигураций"). Такая архитектура системы принесла ей высокую популярность, поскольку обеспечивает открытость прикладных решений, высокую функциональность и гибкость, масштабируемость от однопользовательских до клиент-серверных и территориально распределенных решений, от самых малых до весьма крупных организаций и бизнес-структур [1].

В настоящее время гибкая и качественная интеграция с данным программным решением может позволить значительно улучшить функционал нашего приложения благодаря большим объемам данных, хранящихся в базах данных, находящихся под управлением 1С, и уже готовой, качественно реализованной бизнес логике.

Начиная с версии 8.3.5.1068 в «1С:Предприятие» [2] появился новый объект конфигурации под названием «HTTP­–сервисы». Этот функционал был добавлен в дополнение к автоматическому REST интерфейсу прикладного решения.

По сравнению с имеющимися в платформе SOAP (Simple Object Access Protocol – простой протокол доступа к объектам) WEB–сервисами [3], «HTTP–сервисы» имеют ряд преимуществ:

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

Подход, который используется для реализации «HTTP–сервисов» в «1С:Предприятие», является простым и понятным для разработчика программного обеспечения (далее-ПО). Каждый «HTTP–сервис» может содержать в себе один или несколько шаблонов. Для каждого шаблона можно создать один или несколько методов, выполняющих обработку данных (см. рисунок 1).

Рисунок 1. Настройка «HTTP-сервиса»

Шаблон задаёт путь, по которому может происходить обращение к «HTTP-сервису». В шаблоне можно использовать определённый набор символов, в том числе параметризованные сегменты вида «{параметр}». Для каждого метода указывается, во-первых, обрабатываемый HTTP метод, а также создается процедура на встроенном языке, которая и будет выполнять обработку данных. В качестве HTTP метода используются: GET, POST, PUT, DELETE, PATCH, MERGE, CONNECT, OPTIONS, TRACE, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, «Любой».

Предположим: заказчик 1С конфигурации сформировал техническое задание, в котором говорится о необходимости реализовать средства, позволяющие производить интеграцию с платформой посредствам HTTP протокола.  Кроме того, поставлена задача - реализовать дополнительный функционал авторизации, который будет использовать Barrier Token для доступа к корпоративным данным клиентов с повышенным уровнем привилегий, которые могут меняться во времени.

Прежде всего, актуальным является решение проблемы построения оптимальной архитектуры модулей бизнес-логики. Самым простым и тривиальным решением будет внедрение логики авторизации непосредственно в методы обработки HTTP запросов, доступных привилегированным клиентам (см. рисунок 2).

Рисунок 2. Архитектура приложения при использовании стандартных средств обработки запросов

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

Один из вариантов исключения недостатков, описанного ранее метода – это переход к архитектуре, позволяющей использовать механизмы работы с промежуточным ПО (middleware), которые используются в MVC веб-фреймворке Laravel [4]. Как известно, Laravel является одним из самых распространенных PHP фреймворков в мире. Используя данные принципы, можно добиться гибкого конфигурирования роутинга. Тем самым будет достаточно лишь один раз указать метод авторизации пользователя для группы роутов, используемых в конфигурации. Ниже на рисунке 3 приведена возможная архитектура модулей обработки запросов.

Рисунок 3. Архитектура приложения при использовании промежуточного программного обеспечения

При всех положительных моментах использования данного подхода для решения поставленных задач в системе «1С:Предприятие» можно столкнуться с рядом сложностей.

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

Рассматриваемый функционал будет в значительной степени уступать по объективным причинам в скорости обработки информации стандартным средствам платформы, что может привести к долгому отклику системы и как следствие не эффективной работе при большой нагрузке.

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

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