Реализация кейса
1. Вводная задача от заказчика, проблематика, цели
На старте была поставлена задача: разработать систему, обрабатывающую заявки от пользователей ЕПГУ (единый портал государственных услуг), и интегрировать её с информационной системой ЕОГ (единый портал газификации).
Заявка должна пройти определенный путь до информационной системы.
Этапы заявки:
Мы сразу оценивали риски. Могли быть сорваны сроки запуска, и наш заказчик потерял бы лояльность первых лиц государства. Важно понимать, что работы проводились по поручению Президента РФ под контролем заместителя председателя правительства РФ Александра Новака и заместителя председателя Совета Федерации Андрея Турчака. Был риск финансовых потерь из-за недополучения государственных субсидий на реализацию нацпроекта по газификации.
Уровень ответственности за проект требовал гарантированной работоспособности и производительности решения.
2. Описание реализации кейса и творческого пути по поиску оптимального решения
Для решения задачи у клиента была развернута платформа "Агредатор", на базе которой силами команды RNDSOFT организован интеграционный шлюз между информационной системой "Газпром газификации" и Единым порталом государственных услуг.
В процессе разработки и согласования было много участников с обеих сторон, а времени на отладку взаимодействия и согласования очень мало. У нас работало минимум 4 команды разработки, каждая со своим проектным менеджером.
Разрабатываемый сервис должен был служить неким адаптером между двумя информационными системами. Сроки были сжатые. Нам не хватало требований, к тому же они быстро менялись в процессе. Мы решили использовать абстракции и тем самым сделали сервис гибким.
Агредатор и сервис должны были стать главным транспортом заявки.
Нужный уровень стабильности и производительности итогового решения обеспечили свойства Агредатора, как сервисной шины:
Принятые архитектурные решения обеспечили возможность оперативно подстраивать систему под быстро меняющиеся и уточняемые требования.
Бывает, что с точки зрения бизнес-логики объект существует, но его не всегда отражают в коде, предпочитая реализовать через какой-то общий класс, функционально подходящий, но не отражающий смысл текущего объекта. Это делает код менее понятным, так как не описывает бизнес-логику "дословно".
В нашем случае, хорошим примером такой сущности стали различные виды адресов. Они были разными только по смыслу, но имели одинаковую структуру в API клиента и описывались одной моделью в swagger.json. Можно было бы реализовать только эту модель и обходится ей, но мы предпочли выделить абстракцию для каждого из адресов.
По началу это были пустые классы с наследованием от единого класса. Возможно, в начале это и было избыточным, но в дальнейшем адреса начали обрастать своей специфической логикой.
3. Результаты сотрудничества
Заказчик получил инфраструктурное решение, позволяющее легко развивать и масштабировать функционал на всей цепочке следования заявки с портала государственных услуг.
В результате на едином портале государственных услуг в сентябре 2021 г. появилась услуга на подведение газа до границ земельного участка в населённых пунктах без привлечения средств граждан.
Данный процесс начинает свой путь с оставленной заявки о заключении договора на портале ЕПГУ затем при помощи сервиса “Агредатор” попадает на портал Единого оператора газификации (ЕОГ). Связным звеном между "Агредатором" и ЕОГ является отдельное интеграционное приложение для обработки заявок, поданных через Госуслуги.
4. Заключение
Заказчик успешно запустил проект в срок. Масштабная презентация состоялась в пресс-центре администрации Президента РФ с прямым включением по центральным каналам. Все системы сработали штатно и выдержали огромный наплыв пользователей после ТВ-трансляции и публикации новости о запуске в СМИ.
C момента запуска проекта от граждан получено свыше 131 тысячи сообщений. В среднем за день обработку проходят более 700 сообщений.
На старте была поставлена задача: разработать систему, обрабатывающую заявки от пользователей ЕПГУ (единый портал государственных услуг), и интегрировать её с информационной системой ЕОГ (единый портал газификации).
Заявка должна пройти определенный путь до информационной системы.
Этапы заявки:
- Форма на ЕПГУ (заявитель заполняет форму и отправляет).
- Заявка попадает в СМЭВ (Система Межведомственного Электронного Взаимодействия).
- Из СМЭВ данные получает и обрабатывает Агредатор (сервис, гарантирующий доставку данных из СМЭВ).
- Обработанные данные получает интеграционный сервис, задача которого обеспечить интерфейс между "Агредатором" и системой заказчика с учетом бизнес-логики.
- Заявка попадает в информационную систему заказчика в Единый портал газификации.
- Экспертизы в части интеграции с ЕПГУ
- Бюджета на приобретение интеграционной шины необходимого уровня надежности
- Времени, организационных и технических ресурсов на внедрение интеграционного шлюза
Мы сразу оценивали риски. Могли быть сорваны сроки запуска, и наш заказчик потерял бы лояльность первых лиц государства. Важно понимать, что работы проводились по поручению Президента РФ под контролем заместителя председателя правительства РФ Александра Новака и заместителя председателя Совета Федерации Андрея Турчака. Был риск финансовых потерь из-за недополучения государственных субсидий на реализацию нацпроекта по газификации.
Уровень ответственности за проект требовал гарантированной работоспособности и производительности решения.
2. Описание реализации кейса и творческого пути по поиску оптимального решения
Для решения задачи у клиента была развернута платформа "Агредатор", на базе которой силами команды RNDSOFT организован интеграционный шлюз между информационной системой "Газпром газификации" и Единым порталом государственных услуг.
В процессе разработки и согласования было много участников с обеих сторон, а времени на отладку взаимодействия и согласования очень мало. У нас работало минимум 4 команды разработки, каждая со своим проектным менеджером.
Разрабатываемый сервис должен был служить неким адаптером между двумя информационными системами. Сроки были сжатые. Нам не хватало требований, к тому же они быстро менялись в процессе. Мы решили использовать абстракции и тем самым сделали сервис гибким.
Агредатор и сервис должны были стать главным транспортом заявки.
Нужный уровень стабильности и производительности итогового решения обеспечили свойства Агредатора, как сервисной шины:
- событийно-ориентированная архитектура (англ. event-driven architecture);
- AMQP-протокол;
- асинхронность;
- согласованность в конечном счёте (англ. eventual consistency);
- гарантия ответа (запрашивающей стороне будет возвращен ответ в случае успеха либо ошибка);
- терпимость к временным отказам частей и сервисов надежная доставка (англ. reliable delivery);
- модульность
- другие особенности реализуются дополнительными модулями (HTTP-транспорт, HTTP-push уведомления об ответах, пакетная обработка запросов).
Принятые архитектурные решения обеспечили возможность оперативно подстраивать систему под быстро меняющиеся и уточняемые требования.
Бывает, что с точки зрения бизнес-логики объект существует, но его не всегда отражают в коде, предпочитая реализовать через какой-то общий класс, функционально подходящий, но не отражающий смысл текущего объекта. Это делает код менее понятным, так как не описывает бизнес-логику "дословно".
В нашем случае, хорошим примером такой сущности стали различные виды адресов. Они были разными только по смыслу, но имели одинаковую структуру в API клиента и описывались одной моделью в swagger.json. Можно было бы реализовать только эту модель и обходится ей, но мы предпочли выделить абстракцию для каждого из адресов.
По началу это были пустые классы с наследованием от единого класса. Возможно, в начале это и было избыточным, но в дальнейшем адреса начали обрастать своей специфической логикой.
3. Результаты сотрудничества
Заказчик получил инфраструктурное решение, позволяющее легко развивать и масштабировать функционал на всей цепочке следования заявки с портала государственных услуг.
В результате на едином портале государственных услуг в сентябре 2021 г. появилась услуга на подведение газа до границ земельного участка в населённых пунктах без привлечения средств граждан.
Данный процесс начинает свой путь с оставленной заявки о заключении договора на портале ЕПГУ затем при помощи сервиса “Агредатор” попадает на портал Единого оператора газификации (ЕОГ). Связным звеном между "Агредатором" и ЕОГ является отдельное интеграционное приложение для обработки заявок, поданных через Госуслуги.
4. Заключение
Заказчик успешно запустил проект в срок. Масштабная презентация состоялась в пресс-центре администрации Президента РФ с прямым включением по центральным каналам. Все системы сработали штатно и выдержали огромный наплыв пользователей после ТВ-трансляции и публикации новости о запуске в СМИ.
C момента запуска проекта от граждан получено свыше 131 тысячи сообщений. В среднем за день обработку проходят более 700 сообщений.
Результат
На госуслугах в появилась услуга на подведение газа до границ земельного участка.
Внедренные API/Адаптеры
Похожие кейсы
Загрузка комментариев...