Интеграция между системой оформления договоров ОСОПО (АПО) и учетной системой (АРМ)
Предисловие
Ранее (более десяти лет) в «РосГосСтрахе» (РГС) для договоров ОСОПО (обязательного страхования опасных производственных объектов) не было интеграции между системами оформления договоров (АПО) и учётной системой (АРМ).
Информация о договорах ОСОПО подлежит обязательной передаче в регулирующий орган, которым является НССО (Национальный Союз Страховщиков Ответственности), в 3-х месячный срок с даты получения номера договора.
Договора ОСОПО – являются сложными договорами страхования. При их оформлении и учёте возникает множество проблем, в связи с чем информация не обо всех договорах передаётся регулятору вовремя.
Если непереданных договоров много (для них существует специальный норматив), регулятор выставляет штраф.
Долгое время в РГС существовала практика ручного ввода договоров ОСОПО в учётную систему, что увеличивало время на передачу информации между системами в РГС и последующей передачей в НССО.
Передо мной была поставлена задача доработки модуля оформления договоров ОСОПО для автоматической передачи информации в учётную систему (АРМ).
Система АПО была успешно доработана. После ввода в эксплуатацию, информация о договорах ОСОПО стала попадать в систему АРМ автоматически. Количество проблемных договоров уменьшилось до приемлемого показателя. «РосГосСтрах» перестал выплачивать штрафы.
Веб-Сервисы АРМ.
Технически, интеграция с системой АРМ реализована на основании Веб-Сервисов, которые предоставляет система АРМ.
Упрощённо, система АРМ предоставляет следующие End-Point-ы:
- AgentStatement (работа с отчётом агента)
- Ancillary (вспомогательные операции)
- Contract (работа с договором)
- Search (поиск)
Методов Веб-Сервисов чуть больше.
Более подробную информацию можно посмотреть в файле-Спецификации веб-сервисов
Этапы проекта интеграции.
Проект интеграции состоял из нескольких этапов:
- Интеграция по передаче иноформации о первоначальных договорах.
- Интеграция по передаче иноформации о доп.соглашениях (об изменениях к договору).
- Интеграция по передаче иноформации о расторжениях договоров.
Сложности проекта интеграции.
Со стороны системы АПО, доработка системы по интеграции с системой АРМ не выглядела слишком сложной: нужно было сформировать xml-запрос, обратиться к соответствующему Веб-Сервису со сформированным запросом и обработать ответ от Веб-сервиса.
Однако, особенности реализации Веб-Сервисов АРМ таковы, что:
- во-первых, договор ОСОПО слишком сложный, а xml-запрос, которым передаётся договор, состоит из множества тегов (более 500) и большой, объёмом в несколько Мегабайт.
- во-вторых, АРМ обрабатывает один запрос слишком долго (примерно 30-40 минут и дольше), следовательно, возникает необходимость реализации в системе АПО механизма взаимодействия с системой АРМ в фоновом режиме и оповещения пользователей о результатах загрузки договора.
- в-третьих, обнаружилась многочисленные расхождения в справочных данных, которыми оперируют взаимодействующие системы (АПО и АРМ), было потрачено большое количество времени и сил на синхронизацию справочных данных и на отладку механизма передачи данных для Веб-Сервиса АРМ.
- во-четвёртых, система АРМ требует передачи Веб-Сервису договора целиком (пореквизитная передача не была реализована), в результате чего договор не загружался, если (из-за рассинхронизации данных) происходила ошибка в передаче реквизита, который, по идее, можно было бы передать позднее, отдельным образом.
Интеграция с НССО.
Проект интеграции с АРМ предусматривал прохождение формально-логического контроля (ФЛК) договора с помощью Веб-Сервисов НССО. Для этого, система АПО решала задачу, схожую с задачей передачи информации по договору в АРМ.
А именно: формировался xml-запрос с описанием договора для Веб-сервиса НССО.
Хотя оба Веб-сервиса (НССО и АРМ) требуют передачи информации по договору, однако Веб-Сервис НССО реализован проще на несколько порядков, с обращением к сервису НССО не возникало никаких сложностей.
Процесс взаимодействия с АРМ.
Для реализации задач по интеграции, в системе АПО был реализован отдельный механизм по автоматической передаче информации по договорам, механизм, функционирующий в фоновом режиме, незаметно для пользователя, – процесс взаимодействия с АРМ.
Диаграмма последовательностей отправки договора в АРМ через Веб-Сервис
Для передачи информации о договорах в АРМ, процесс взаимодействия обращается к нескольким Веб-Сервисам АРМ.
Во-первых, формируется xml-запрос к Веб-Сервису createAgentStatement для передачи в АРМ отчета агента (ОА) с договором ОСОПО. Веб-сервис присылает ответ createAgentStatementResponse со статусом, принят или не принят договор в обработку.
Во-вторых, если запрос принят в обработку, нужно периодически обращаться к Веб-Сервису getResultProcessing, ожидая статуса того, завершена ли обработка договора в АРМе, успешно или не успешно, либо продолжается.
Пример запроса createAgentStatement
<s:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<createAgentStatement xmlns="http://rgs.ru/arm4/integration">
<createRequest>
<requestAttributes>
<requestId>4621a3a0-3148-4342-8ca2-0aa20cc1ddfd</requestId>
<version>3.3.53</version>
</requestAttributes>
<agentStatement>
<sysCreateUser>WebSU</sysCreateUser>
<sysCreateDate>2019-08-20T12:34:40</sysCreateDate>
<!-- Параметры отчета агента пропущены -->
<contract>
<!-- Параметры блока contract пропущены -->
</contract>
</agentStatement>
</createRequest>
</createAgentStatement>
</s:Body>
</s:Envelope>
Пример ответа createAgentStatementResponse
Важная информация в ответе:
- status – 18 означает, что запрос на создание отчета агента (вместе с договором) принят в обработку, другое число указывает об ошибке.
- responseId – идентификатор ответа, с которым следует обращаться к сервису getResultProcessing, чтобы узнать, продолжается ли обработка или завершена (успешно или с ошибкой).
<S:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header>
<work:WorkContext xmlns:work="http://oracle.com/weblogic/soap/workarea/">rO0ABXdbABp3ZWJsb2dpYy5hcHAuYXJtNC1zZXJ2aWNlcwAAANYAAAAjd2VibG9naWMud29ya2FyZWEuU3RyaW5nV29ya0NvbnRleHQAEHJlbGVhc2UtNC4zNy4wMTEAAA==
</work:WorkContext>
</env:Header>
<S:Body>
<ns0:createAgentStatementResponse xmlns:ns0="http://rgs.ru/arm4/integration">
<ns0:createResponse>
<ns0:responseAttributes>
<ns0:responseId>d37e1c00c32e11e99a1d00505</ns0:responseId>
<ns0:status>18</ns0:status>
<ns0:version>3.3.55</ns0:version>
</ns0:responseAttributes>
</ns0:createResponse>
</ns0:createAgentStatementResponse>
</S:Body>
</S:Envelope>
Пример запроса getResultProcessing
В запросе указывается идентификатор, который возвратился в ответе createAgentStatementResponse
<s:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<s:Body>
<getResultProcessing xmlns="http://rgs.ru/arm4/integration">
<processRequest>
<requestAttributes>
<requestId>8301b733-c56d-4bc4-88cc-87d12ce16dda</requestId>
<version>3.3.53</version>
</requestAttributes>
<identifierType>Arm4CorrelationId</identifierType>
<identifierList>
<id>d37e1c00c32e11e99a1d00505</id>
</identifierList>
</processRequest>
</getResultProcessing>
</s:Body>
</s:Envelope>
Пример ответа getResultProcessingResponse
Важная информация в ответе:
- status – F0 означает, что запрос на создание отчета агента (вместе с договором) обработан успешно, иначе префикс F означает, что обработка завершена и получены ошибки обработки, другой статус означает, что обработка продолжается.
- violationList – представляет собой блок ошибок.
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<WorkContext xmlns="http://oracle.com/weblogic/soap/workarea/">rO0ABXdbABp3ZWJsb2dpYy5hcHAuYXJtNC1zZXJ2aWNlcwAAANYAAAAjd2VibG9naWMud29ya2FyZWEuU3RyaW5nV29ya0NvbnRleHQAEHJlbGVhc2UtNC4zNy4wMTEAAA==
</WorkContext>
</S:Header>
<S:Body>
<getResultProcessingResponse xmlns="http://rgs.ru/arm4/integration">
<resultProcessingResponse>
<responseAttributes>
<status>6</status>
<version>3.3.55</version>
</responseAttributes>
<resultList>
<result>
<id>30650010-4206025687-140819</id>
<status>FE1</status>
<violationList>
<violation>
<type>ERROR</type>
<code>0012600</code>
<fieldName>Краткое наименование</fieldName>
<message>У ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ "ПОДОРОЖНИК-КЕМЕРОВО" не заполнено поле Краткое наименование.</message>
</violation>
<!-- может быть несколько причин неудачной загрузки договора -->
</violationList>
</result>
</resultList>
</resultProcessingResponse>
</getResultProcessingResponse>
</S:Body>
</S:Envelope>
Статусы договоров ОСОПО.
Работа механизма взаимодействия с АРМ основывается на статусной модели для договоров ОСОПО. Как отмечалось выше, передача информации по договору в АРМ занимает продолжительное время (более 40 минут), поэтому осуществляется в фоновом режиме, асинхронно, не мешая действиям пользователя.
После того, как договор создан, правильно заполнен и ошибок в договоре нет, договор переводится в статус «Согласован». При переходе в этот статус возможна печать страхового полиса.
После печати полиса, договор переходит в статус «Действующий». Начинается отправка информации по договору в АРМ. В это время работает механизм взаимодействия с АРМ.
Спустя некоторое время, в зависимости от того, чем завершится процесс передаччи договора в АРМ, статус договора изменится на «Загружен в АРМ» (если передача будет успешной) либо на «Ручной ввод в АРМ» (если в ответах от Веб-Сервиса АРМ придут ошибки).
Менеджер задач.
Технически, работа механизма взаимодействия с АРМ реализована с помощью менеджера задач.
Менеджер задач – это глобальный объект.
Запуск менеджера задач.
Запуск менеджера задач осуществляется функцией StartTaskManager. Функция вызывается при старте модуля.
Объект менеджера задач запрашивается у фабрики по нужному имени. Могут быть различные реализации менеджера задач. У фабрики запрашивается та реализация, которая определена параметром OSOPO_TaskManager.
/*------------------------------------------------------------------------------
Создание глобальных структур.
------------------------------------------------------------------------------*/
void ConstructGlobals()
{
String TaskManagerName;
// пропущено
if(osopo::GV != NULL) {
TaskManagerName = osopo::GV->Get("OSOPO_TaskManager").Trim();
}
if(TaskManagerName.SubString(1, 11) != "TaskManager") {
TaskManagerName = "TaskManager";
}
osopo::StartTaskManager( TaskManagerName ); // менеджер задач
// пропущено
}
Останов менеджера задач.
Запуск менеджера задач осуществляется функцией StopTaskManager. Функция вызывается при завершении работы модуля.
/*------------------------------------------------------------------------------
Уничтожение глобальных структур.
------------------------------------------------------------------------------*/
void DestructGlobals()
{
// пропущено
osopo::StopTaskManager(); // менеджер задач
// пропущено
}
Диаграмма классов менеджера задач.
TaskManager – это абстрактный класс, предоставляющий интерфейс для запуска задач.
Задачи.
Задача представляет собой некую последовательность действий для выполнения законченной операции. Например, обращение к сервису createAgentStatement.
Цепочки задач.
Задачи могут объединяться в цепочку. Так, задача – это одно законченное действие (обращение к сервису), а цепочка – это несколько действий, представляющих собой общую операцию (например, отправку договора в АРМ).
Так, для того, чтобы выполнить отправку договора в АРМ необходимо совершить ряд шагов (обратиться к сервису поиска договоров, обратиться к сервису создания отчёта агента, несколько раз вызвать сервис проверки результата и т.д.)
Ниже приведён пример цепочки задач “Chain_01. Экспорт превоначального договора в АРМ”.
