1. Вводная задача от заказчика, проблематика, цели

На старте была поставлена задача: разработать систему, обрабатывающую заявки от пользователей ЕПГУ (единый портал государственных услуг), и интегрировать её с информационной системой ЕОГ (единый портал газификации).

Заявка должна пройти определенный путь до информационной системы.

Этапы заявки:

• Форма на ЕПГУ (заявитель заполняет форму и отправляет).
• Заявка попадает в СМЭВ (Система Межведомственного Электронного Взаимодействия).
• Из СМЭВ данные получает и обрабатывает Агредатор (сервис, гарантирующий доставку данных из СМЭВ).
• Обработанные данные получает интеграционный сервис, задача которого обеспечить интерфейс между "Агредатором" и системой заказчика с учетом бизнес-логики.
• Заявка попадает в информационную систему заказчика в Единый портал газификации.

Проект был сложным. На стороне заказчика не хватало:

• Экспертизы в части интеграции с ЕПГУ
• Бюджета на приобретение интеграционной шины необходимого уровня надежности
• Времени, организационных и технических ресурсов на внедрение интеграционного шлюза

Мы сразу оценивали риски. Могли быть сорваны сроки запуска, и наш заказчик потерял бы лояльность первых лиц государства. Важно понимать, что работы проводились по поручению Президента РФ под контролем заместителя председателя правительства РФ Александра Новака и заместителя председателя Совета Федерации Андрея Турчака. Был риск финансовых потерь из-за недополучения государственных субсидий на реализацию нацпроекта по газификации.

Уровень ответственности за проект требовал гарантированной работоспособности и производительности решения.

2. Описание реализации кейса и творческого пути по поиску оптимального решения

Для решения задачи у клиента была развернута платформа "Агредатор", на базе которой силами команды RNDSOFT организован интеграционный шлюз между информационной системой "Газпром газификации" и Единым порталом государственных услуг.

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

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

Агредатор и сервис должны были стать главным транспортом заявки.

Нужный уровень стабильности и производительности итогового решения обеспечили свойства Агредатора, как сервисной шины:

• событийно-ориентированная архитектура (англ. event-driven architecture);
• AMQP-протокол;
• асинхронность;
• согласованность в конечном счёте (англ. eventual consistency);
• гарантия ответа (запрашивающей стороне будет возвращен ответ в случае успеха либо ошибка);
• терпимость к временным отказам частей и сервисов надежная доставка (англ. reliable delivery);
• модульность
• другие особенности реализуются дополнительными модулями (HTTP-транспорт, HTTP-push уведомления об ответах, пакетная обработка запросов).

Экспертиза команды позволила заблаговременно выявить основные риски, избежать срыва сроков и реализовать первый коммерческий проект на ЕПГУ.

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

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

В нашем случае, хорошим примером такой сущности стали различные виды адресов. Они были разными только по смыслу, но имели одинаковую структуру в API клиента и описывались одной моделью в swagger.json. Можно было бы реализовать только эту модель и обходится ей, но мы предпочли выделить абстракцию для каждого из адресов.

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

3. Результаты сотрудничества

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

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

Данный процесс начинает свой путь с оставленной заявки о заключении договора на портале ЕПГУ затем при помощи сервиса “Агредатор” попадает на портал Единого оператора газификации (ЕОГ). Связным звеном между "Агредатором" и ЕОГ является отдельное интеграционное приложение для обработки заявок, поданных через Госуслуги.

4. Заключение

Заказчик успешно запустил проект в срок. Масштабная презентация состоялась в пресс-центре администрации Президента РФ с прямым включением по центральным каналам. Все системы сработали штатно и выдержали огромный наплыв пользователей после ТВ-трансляции и публикации новости о запуске в СМИ.

C момента запуска проекта от граждан получено свыше 131 тысячи сообщений. В среднем за день обработку проходят более 700 сообщений.