Сдам Сам

ПОЛЕЗНОЕ


КАТЕГОРИИ







Механизмы взаимодействия Пользователей с Системой





Программного обеспечения для реализации возможности заключения договора ОСАГО в виде электронного документа и обеспечения МВД России доступа к АИС РСА в части предоставления информации о действующих договорах ОСАГО

 

Листов 104

 

Москва, 2015

Содержание

Содержание. 2

Термины и сокращения. 4

Аннотация. 6

1. Назначение Системы.. 6

2. Механизмы взаимодействия Пользователей с Системой. 6

2.1. Подключение СК к Системе. 7

3. Работа с Адаптером WS Системы.. 8

3.1. Назначение Адаптера WS. 8

3.2. Подготовка к установке Адаптера WS. 9

3.3. Установка Адаптера WS. 9

3.3.1. Структура каталогов Адаптера WS.. 9

3.3.2. Настройки Адаптера WS.. 9

3.3.3. Проверка установки Адаптера WS.. 11

3.4. Логирование Адаптера WS. 11

3.5. Рекомендуемые значения параметров Адаптера WS. 13

3.6. Работа с использованием Адаптера WS. 13

3.6.1. Префиксы файлов-запросов. 15

3.7. Рекомендации по устранению возможных проблем подключения к веб-сервисам Системы 15

3.7.1. Проверка параметров при редактировании конфигурационного файла Адаптера WS 15

3.7.2. Проверка наличия связи с серверами веб-сервисов Системы.. 16

4. Взаимодействие СК с веб-сервисами системы.. 16

4.1. Адреса и методы веб-сервисов Системы.. 16

4.2. Формирование SOAP-заголовка. 18

4.2.1. Пример soap-заголовка. 18

4.2.2. Контрольные примеры хеширования паролей.. 18

4.2.3. Пример реализации хэширования пароля на Java. 19

4.3. Заполнение тега <Body>. 20

4.3.1. Пример заполнения тега <data> для передачи сообщения веб-сервисам с использованием МТОМ... 20

4.3.2. Пример заполнения тега <data> при передаче сообщения для веб-сервисов без использования МТОМ... 21

5. Правила формирования файлов-запросов. 21

5.1. Общие правила формирования файлов-запросов. 21

5.2. Общий порядок создания договора е-ОСАГО.. 21

5.3. Проверка субъектов/ТС.. 22

5.4. Получение статусов обработки запросов на проверку субъектов/ТС.. 23

5.5. Импорт проектов договоров е-ОСАГО.. 25

5.6. Получение статусов обработки запросов на загрузку проектов договоров е-ОСАГО.. 27

5.7. Загрузка статусов проектов договоров е-ОСАГО.. 28

5.8. Получение статусов обработки запросов на загрузку статусов проектов договоров е-ОСАГО 29

5.9. Запрос количества свободных номеров для проектов договоров е-ОСАГО.. 30

5.10. Запрос списка номеров проектов договоров е-ОСАГО.. 31

6. Идентификация объектов. 31

7. Выполняемые проверки. 33

8. Хеширование данных. 80

9. Перечень допустимых и недопустимых символов для передачи в Систему. 80

9.1. Данные документов субъектов. 80

9.2. Идентификаторы ТС (кроме государственного регистрационного знака) 81

9.3. Государственный регистрационный знак. 82

9.4. Нормализация данных. 82

10. Описание процесса перехода на следующую версию xsd-схем.. 82

Приложение 1 Ошибки валидации. 84

Приложение 2 Статусы запросов. 96

Приложение 3 Спецификация форматов взаимодействия. 103

Основные изменения. 104

 

 


Термины и сокращения

Термины, определения, сокращения
АИС РСА Автоматизированная информационная система Российского Союза Автостраховщиков, созданная в соответствии с Федеральным законом от 25 апреля 2002 года № 40-ФЗ «Об обязательном страховании гражданской ответственности владельцев транспортных средств»
БД База данных
Веб-сервис Идентифицируемая веб-адресом программная система со стандартизированными интерфейсами.
ВУ Водительское удостоверение
ДиКБМ Подсистемы Договоры и КБМ АИС РСА
Договор е-ОСАГО Договор ОСАГО в виде электронного документа
ДТП Дорожно-транспортное происшествие
ЕСИА Единая система идентификации и аутентификации
Заказчик Российский Союз Автостраховщиков
Идентифицирующие параметры Для субъектов идентифицирующими параметрами являются ХЭШ+документ (тип, серия и номер), для ТС – хотя бы один из идентификаторов (VIN, номер кузова, номер шасси, государственный регистрационный знак). Государственный регистрационный знак является идентификатором ТС только если он единственный идентификатор.
ИНН Идентификационный номер налогоплательщика
ИС Информационная система
КБМ Коэффициент бонус-малус
КИС Корпоративная информационная система
Клиент Компонент, который должен вызывать веб-сервис Системы, передавать сообщения в Систему, принимать ответы от Системы
ЛДУ Лицо, допущенное к управлению ТС
Лог Файл, в котором фиксируются события в программном обеспечении (например, данные о запросах от СК).
МВД Министерство внутренних дел Российской Федерации
НСД Несанкционированный доступ
Модуль СМЭВ Модуль регистрации запросов СМЭВ АИС РСА
ОСАГО Обязательное страхование гражданской ответственности владельцев транспортных средств
ПО Программное обеспечение
Промышленный стенд Программно-аппаратный комплекс РСА, предназначенный для функционирования Подсистем Договоры и КБМ и Модуля регистрации запросов СМЭВ
РСА Российский Союз Автостраховщиков
РФ Российская Федерация
СЗИ Средства защиты информации
Система Подсистема «Электронный полис» АИС РСА
СК Страховая организация – член РСА
СМЭВ Система межведомственного электронного взаимодействия
Сообщение Файл определенной согласованной структуры, содержащий запросы/ответы, данные
Страхователь Лицо, заключившее со страховщиком договор страхования
Страховщик Юридическое лицо, имеющее лицензию на осуществление страховой деятельности, выданную органом страхового надзора
СУБД Система управления базой данных
Субъект Физическое лицо – страхователь/собственник ТС/ЛДУ, либо юридическое лицо
Тег Именованный раздел элемента, характеризующий и определяющий данные, элемент языка разметки гипертекста
ТЗ Техническое задание
ТО Технический осмотр
ТП Технический проект
ТС Транспортное средство
Файл-запрос XML файл определенной согласованной структуры, содержащий запрос к веб-сервису
ФИО Фамилия, имя, отчество
ФЛ Физическое лицо
ФЛК Форматно-логический контроль
ФОИВ Федеральный орган исполнительной власти
ХЭШ Зашифрованные данные физического лица (ФИО и Дата рождения), хранящиеся в Системе
ЮЛ Юридическое лицо
HTTP HyperTextTransferPrоtocоl — протокол передачи гипертекста
MQ Messagequeue – очередь сообщений
MTOM Message Transmission Optimization Mechanism – механизм оптимизации передачи SOAP-сообщений
SOAP SimpleObjectAccessProtocol — простой протокол доступа к объектам
VIN Идентификационный номер транспортного средства
WS Web service, веб-сервис
XML eXtensible Markup Language — расширяемый язык разметки
XSD XMLSchema — язык описания структуры XML-документа

 


Аннотация

Настоящий документ, разработанный в рамках Договора № Р/ДКС-15/17, является частью комплекта документов программного обеспечения для реализации возможности заключения договора ОСАГО в виде электронного документа и обеспечения МВД России доступа к АИС РСА в части предоставления информации о действующих договорах ОСАГО (далее – Подсистема «Электронный полис» АИС РСА, Система).

Основанием для разработки документа является утвержденный от 24.03.2015 документ «Техническое задание на разработку программного обеспечения для реализации возможности заключения договора ОСАГО в виде электронного документа и обеспечения МВД России доступа к АИС РСА в части предоставления информации о действующих договорах ОСАГО».

В настоящем документе описан механизм взаимодействия оператора СК с программным обеспечением (далее – ПО) Системы.

Назначение Системы

Система предназначена для автоматизации деятельности Российского Союза Автостраховщиков (РСА) по:

- Обработке следующих поступающих от КИС СК запросов:

o Запрос на проверку субъекта – страхователя, собственника ТС;

o Запрос статуса проверки субъекта (страхователя, собственника ТС);

o Запрос на проверку субъекта – ЛДУ;

o Запрос статуса проверки субъекта (ЛДУ);

o Запрос на проверку транспортного средства (ТС);

o Запрос статуса проверки транспортного средства;

o Запрос на загрузку проекта договора е-ОСАГО;

o Запрос статуса загрузки проекта договора е-ОСАГО;

o Запрос на загрузку статуса проекта договора е-ОСАГО;

o Запрос статуса загрузки проекту договора е-ОСАГО статуса;

o Запрос количества свободных номеров проектов договоров е-ОСАГО для СК;

o Запрос списка номеров проектов договоров е-ОСАГО СК.

- Передаче запросов на проверку субъектов и ТС в ДиКБМ;

- Консолидации информации о проектах договоров е-ОСАГО и статусов к ним;

- Перегрузке действующих договоров е-ОСАГО в ДиКБМ;

- Предоставлению и учету номеров проектов договоров е-ОСАГО.

Система позволяет осуществлять:

– проверку данных субъектов – физических и юридических лиц, являющихся страхователями, собственниками ТС, либо ЛДУ;

– проверку данных транспортных средств;

– сбор и хранение информации о проектах договоров е-ОСАГО, а также о присвоенных им статусах;

– заключение договоров е-ОСАГО.

Подключение СК к Системе

Для подключения СК к Системе необходимо:

  1. Создать и настроить подключение к защищаемым ресурсам Системы, обратившись за параметрами подключения в РСА.
  2. Установить Адаптер WS Системы в соответствии Разделом 3 настоящего руководства, при необходимости осуществления взаимодействия с Системой через Адаптер WS.
  3. Запросить у РСА параметры доступа к Системе: логин, пароль и идентификатор СК (InsurerID).
  4. Определить способ информационного обмена:

- использование Адаптера WS;

- обращение к Системе при помощи вызова соответствующего веб-сервиса.

  1. Проверить доступность веб-сервисов Системы с помощью запросов в браузере WSDL по каждому веб-сервису в соответствии с Таблицей 1.

 

Таблица 1 Адреса веб-сервисов

Название веб-сервиса Описание веб-сервиса Адрес веб-сервиса, свойство МТОМ включено Адрес веб-сервиса, свойство МТОМ выключено
CheckSubjectOSAGOService Сервис проверки субъектов/ТС http://АДРЕС_СЕРВЕРА/e-osago-1.0/services/checkSubjectOSAGOService?wsdl http://АДРЕС_СЕРВЕРА/e-osago-1.0/services/checkSubjectOSAGOServiceNoMtom?wsdl
ProjectPolicyService Сервис загрузки проектов договоров е-ОСАГО и статусов проектов договоров http://АДРЕС_СЕРВЕРА/e-osago-1.0/services/projectPolicyService?wsdl http://АДРЕС_СЕРВЕРА/e-osago-1.0/services/projectPolicyServiceNoMtom?wsdl
ProjectPolicyListService Сервис запроса списка номеров проектов договоров http://АДРЕС_СЕРВЕРА/e-osago-1.0/services/projectPolicyListService?wsdl http://АДРЕС_СЕРВЕРА/e-osago-1.0/services/projectPolicyListServiceNoMtom?wsdl
ProjectPolicyCountService Сервис запроса количества свободных номеров http://АДРЕС_СЕРВЕРА/e-osago-1.0/services/projectPolicyCountService?wsdl http://АДРЕС_СЕРВЕРА/e-osago-1.0/services/projectPolicyCountServiceNoMtom?wsdl

В качестве АДРЕС_СЕРВЕРА указывается ip сервера, например, 192.168.0.196.

Если запросы вернули XML файлы, описывающие веб-сервисы (WSDL), то подключение к Системе считается успешным.

 

Назначение Адаптера WS

Адаптер WS Системы предназначен для информационного обмена с КИС СК при запросе на проверку данных субъектов/ТС, импорте проектов договоров е-ОСАГО и их статусов, а также при запросе списка проектов договоров, которым не назначен статус, и запросе на количество свободных номеров для проектов договоров е-ОСАГО.

При взаимодействии с Системой посредством Адаптера WS Учетная система СК формирует файл соответствующего запроса и помещает его в папке входящих сообщений для Системы. Обработку данного файла и обращение к веб-сервисам Системы осуществляет Адаптер WS, обеспечивая обработку запросов к подсистеме «Электронный полис», вызов методов веб-сервисов подсистемы «Электронный полис» и сохранение ответа от Системы.

Адаптер WS подсистемы «Электронный полис» осуществляет:

− анализ типа запроса на основании наименования переданного файла;

− передачу в подсистему «Электронный полис» запроса с содержимым файла путем вызова соответствующего метода веб-сервиса;

− получение ответа от веб-сервиса о результатах постановки запроса в очередь (при проверке субъекта/ТС или загрузке проекта договора е-ОСАГО/статуса проекта договора е-ОСАГО);

− отправку запросов в подсистему «Электронный полис» на получение статусов отправленного запроса (при проверке субъекта/ТС или загрузке проекта договора е-ОСАГО/статуса проекта договора е-ОСАГО);

− анализ содержимого полученного ответа и прекращение отправки запросов в случае, если получен ответ со статусом запроса равным завершенному статусу (ошибка при обработке или обработка успешно завершена);

− передачу файла-ответа в папку ответов для СК.

Установка Адаптера WS

Для установки Адаптера WS необходимо развернуть архив на одном из дисков компьютера. При разархивации будет создана соответствующая структура каталогов программы Адаптера (например, «D:\e-osago-adapter\»).

3.3.1. Структура каталогов Адаптера WS

Структура каталогов Адаптера WS следующая:

\execdir\

\execdir\lib\

В каталоге «execdir» размещается конфигурационный файл настройки адаптера eosago.properties и пакетный файл запуска адаптера start-e-osago.bat.

Для запуска Адаптера в режиме работы с подсистемой «Электронный полис» служит файл start-e-osago.bat. Файл содержит команду вызова Адаптера: «java -Dhttp.keepAlive=true -Dhttp.maxConnections=1000 -Xmx512m -jar dkbm-adapter-1.0.jar -eosago».

В подкаталоге «lib» размещаются файлы библиотек и файл реализации Адаптера dkbm-adapter-1.0.jar.

3.3.2. Настройки Адаптера WS

Настройки Адаптера определяются в файле eosago.properties:

1) параметры, определяющие рабочие каталоги Адаптера:

– configuration.incomingDir - папка для файлов запросов СК к подсистеме «Электронный полис» (папка входящих сообщений), например:

configuration.incomingDir=C:\\e-osago-adapter\\samples\\eosago_incoming

– configuration.outgoingDir - папка для файлов ответов подсистемы «Электронный полис» (папка исходящих сообщений), например:

configuration.outgoingDir=C:\\e-osago-adapter\\samples\\eosago_outgoing

– configuration.statusDir - папка для файлов запросов СК, которые успешно переданы в подсистему «Электронный полис» и ожидают завершения обработки. Адаптер периодически запрашивает статус обработки этих файлов у Системы. Пример установки параметра:

configuration.statusDir=C:\\e-osago-adapter\\samples\\eosago_status

– configuration.errorDir – папка для файлов с ошибками в наименовании, например:

configuration.errorDir=C:\\e-osago-adapter\\samples\\eosago_error

– configuration.tempStatus – папка для файлов ответов на запросы статусов, например:

configuration.tempStatus=C:\\e-osago-adapter\\samples\\eosago_tempStatus

2) параметры настройки процессов работы с сообщениями:

– configuration.incomingCheckPeriod – интервал времени проверки папки входящих запросов адаптером, в секундах, например:

configuration.incomingCheckPeriod=3

– configuration.maxRequestsPerSession – количество файлов, забираемых адаптером за одну итерацию, например:

configuration.maxRequestsPerSession=100

– configuration.statusCheckPeriod – интервал времени проверки статуса обработки запроса веб-сервисом в секундах, например:

configuration.statusCheckPeriod=20

– configuration.uploadThreadsCount – количество одновременных соединений Адаптера с каждым веб-сервисом, например:

configuration.uploadThreadsCount=100

– configuration.overloadTimeOut – период времени бездействия после получения ошибки превышения количества запросов, в секундах, например:

configuration.overloadTimeOut=10

3) параметры, определяющие путь и запрос проверки доступа к веб-сервисам:

– configuration.checkSubjectOSAGOServiceUrl – URL веб-сервиса проверки субъектов/ТС, например:

для тестовой среды:

configuration.checkSubjectOSAGOServiceUrl=http://ТЕСТОВАЯ_СРЕДА/e-osago-1.0/services/checkSubjectOSAGOService?wsdl

для промышленной среды:

configuration.checkSubjectOSAGOServiceUrl=http://ПРОМЫШЛЕННАЯ_СРЕДА/e-osago-1.0/services/checkSubjectOSAGOService?wsdl

 

– configuration.projectPolicyServiceUrl – URL веб-сервиса загрузки проектов договоров е-ОСАГО и статусов проектов договоров, например:

для тестовой среды:

configuration.projectPolicyServiceUrl=http://ТЕСТОВАЯ_СРЕДА/e-osago-1.0/services/projectPolicyService?wsdl

для промышленной среды:

configuration.projectPolicyServiceUrl=http://ПРОМЫШЛЕННАЯ_СРЕДА/e-osago-1.0/services/projectPolicyService?wsdl

 

– configuration.projectPolicyListServiceUrl – URL веб-сервиса запроса списка проектов договоров, например:

для тестовой среды:

configuration.projectPolicyListServiceUrl=http://ТЕСТОВАЯ_СРЕДА/e-osago-1.0/services/projectPolicyListService?wsdl

для промышленной среды:

configuration.projectPolicyListServiceUrl=http://ПРОМЫШЛЕННАЯ_СРЕДА/e-osago-1.0/services/projectPolicyListService?wsdl

 

– configuration.projectPolicyCountServiceUrl – URL веб-сервиса запроса количества свободных номеров, например:

для тестовой среды:

configuration.projectPolicyCountServiceUrl=http://ТЕСТОВАЯ_СРЕДА/e-osago-1.0/services/projectPolicyCountService?wsdl

для промышленной среды:

configuration.projectPolicyCountServiceUrl=http://ПРОМЫШЛЕННАЯ_СРЕДА/e-osago-1.0/services/projectPolicyCountService?wsdl

 

4) параметры учетной записи СК (логин, пароль), например:

configuration.username=test

configuration.password=test

3.3.3. Проверка установки Адаптера WS

После того, как приложение развернуто, проверить работоспособность можно, поместив в директорию «incomingDir» подготовленный файл запроса к подсистеме «Электронный полис». В течение incomingCheckPeriod секунд должен прийти ответ в директорию «outgoingDir».

Логирование Адаптера WS

Для начала работы с Адаптером необходимо выполнить пакетный файл start-e-osago.bat в папке execdir.

При запуске Адаптера в логе пишется следующая информация:

<Дата запуска>@<время запуска>INFO

Далее перечисляется информация по подключению библиотек и xsd-схем.

В (Configuration.java:161) перечисляются настройки из конфигурационного файла, а также номер версии Адаптера в строке ‑ Buildnumber, например,

1114@11:08:30 INFO [main] (Configuration.java:164) ‑ Build number = 1.0_r1488_20121026222451_LEAF-11

Если Адаптер запущен, но в папке входящих сообщений (<configuration.incomingDir>) нет запросов, то Адаптер с периодом, определяемым параметром configuration.incomingCheckPeriod, будет писать строку №1 из Таблицы 2.

Если в папку входящих сообщений (<configuration.incomingDir>) загружены запросы, то признаком их успешной обработкой будет появление одноименного файла в папке ответов от подсистемы «Электронный полис» (<configuration.outgoingDir>) и строк № 3-7 Таблицы 2 в логе Адаптера.

Если запрос долго обрабатывается, то в папке <configuration.statusDir> должны содержаться запросы статусов обработки запросов, которые будут отправляться в подсистему «Электронный полис» с определенной периодичностью, указанной в параметре <configuration.statusCheckPeriod> конфигурационного файла Адаптера. Также будут появляться строки № 8-10 Таблицы 2 в логе Адаптера.

Для просмотра статуса обработки запросов на проверку субъектов/ТС необходимо открыть файл со следующим наименованием: ps_наименование запроса.xml в папке <configuration.tempStatus>.

Когда в строке № 10 Таблицы 2 лога будет указано значение = true, появится новый файл в папке <configuration.outgoingDir> с наименованием: ps_наименование запроса.xml.

В случае ошибки в наименовании запроса, файл отправится в папку <configuration.errorDir> и в логе появится строка № 11 Таблицы 2.

Если файл не уходит из папки <configuration.incomingDir> и в логе пишется строка № 1 Таблицы 2, то возможны следующие причины возникновения ошибки:

1) некорректно заполнен конфигурационный файл eosago.properties;

2) некорректно названы каталоги, прописанные в конфигурационном файле.

3) нет соединения между Адаптером и и подсистемой «Электронный полис» ‑ в логе пишется ошибка соединения, строка № 12 Таблицы 2.

Таблица 2 Строки лога

Наименование строки лога Комментарии
  Получение статусов запросов Эта строка информирует о том, что адаптер вызывает веб-сервис проверки субъектов/ТС для получения статусов обработки запросов. Этот статус записывается с периодичностью параметра <configuration.statusCheckPeriod>
  Выбрано <количество сообщений> сообщений для отправки Строка информирует о количестве файлов-запросов в папке incoming, ожидающих отправку в подсистему «Электронный полис»
  Отправляем файл Message Строка информирует об отправке запроса в Систему В фигурных скобках {} указывается: requestType - тип запроса (например, CHECK_DRIVER_STATUS); attachmentFile ‑ полный путь к файлу и его название; date – дата и время.
  Ответ получен Строка информирует о получении ответа от подсистемы «Электронный полис» о статусе первичной обработки запроса.
  saveAttachmentToDirByMessage OUTGOING <Название файла> Строка информирует о сохранении в очередь ответов от подсистемы «Электронный полис» (OUTGOING) ответа со следующим наименованием <Название файла>
  saveAttachmentToDirByMessage to <Путь, куда сохранен файл> Строка информирует о сохранении ответа от подсистемы «Электронный полис» по указанному пути <Путь, куда сохранен файл>
  Удаляем файл запроса Message Строка информирует об удалении запроса из очереди исходящих сообщений от СК
  Выбрано <количество запросов> запросов для проверки статуса Строка информирует о наличии запросов в папке <configuration.statusDir> на статус обработки запросов на проверку субъектов/ТС
  sendStatusRequestByMessage Message Строка информирует об отправке запроса на статус проверки субъектов/ТС в подсистему «Электронный полис» в фигурных скобках {} указывается: requestType – тип запроса (например, CHECK_DRIVER_STATUS); attachmentFile – полный путь к файлу и его название:\e-osago-adapter-20150426\samples\status\edr_20150426093047_3.xml; date – дата и время
  validateResponseStatusAttachment Message Строка информирует о получении ответа со статусом обработки запроса в папку <configuration.tempStatus>: false – запрос окончательно не обработан; true – запрос окончательно обработан.
  ERROR [pool-1-thread-1] (MessageDaoImpl.java:101) - Неправильный формат даты в имени файла einow_00020828093047_1.xml Строка информирует о неправильном формате в наименовании запроса с подробным объяснением.
  Interceptor for Строка информирует об отсутствии соединения между адаптером и подсистемой «Электронный полис»

Таблица 3 Наименования методов веб-сервисов Системы и их назначение

Название веб-сервиса Название метода веб-сервиса Назначение
CheckSubjectOSAGOService loadInsurerOwner Метод для загрузки запроса на проверку субъекта – страхователя/собственника ТС
loadDriver Метод для загрузки запроса на проверку субъекта – ЛДУ
loadVehicle Метод для загрузки запроса на проверку ТС
getInsurerOwnerStatus Метод для запроса статуса обработки запроса на проверку субъекта – страхователя/собственника ТС
getDriverStatus Метод для запроса статуса обработки запроса на проверку субъекта – ЛДУ
getVehicleStatus Метод для запроса статуса обработки запроса на проверку ТС
ProjectPolicyService loadPolicy Метод для загрузки проекта договора е-ОСАГО
getPolicyStatus Метод для запроса статуса обработки запроса на загрузку проекта договора е-ОСАГО
setStatus Метод для загрузки статуса проекта договора е-ОСАГО
getSetStatusResult Метод для запроса статуса обработки запроса на загрузку статуса проекта договора е-ОСАГО
ProjectPolicyListService getList Метод для запроса списка номеров проектов договоров
ProjectPolicyCountService getFreeNumbers Метод для запроса количества свободных номеров

Формирование SOAP-заголовка

Для отправки запросов в подсистему «Электронный полис» должны быть безошибочно заполнены соответствующие элементы заголовка SOAP-сообщения (тег <SOAP-ENV:Header>). В заголовке обязательно указывается логин и пароль СК. Логины и пароли определяются РСА для каждой страховой компании.

SOAP-заголовок состоит из элемента <wsse:Security>, предназначенного для передачи информации, относящейся к обеспечению безопасности SOAP-сообщения. Элемент <wsse:Security> состоит из подэлемента <wsse:UsernameToken>, который в свою очередь содержит вложенные элементы <wsse:Username> и <wsse:Password>.

В элементе <wsse:Username> передается логин пользования, а в элементе <wsse:Password> – пароль, зашифрованный по формуле Base64 с помощью алгоритма SHA1 (Nonce + Created + Password) (тип пароля PasswordDigest). Элемент <Nonce> содержит случайное число, которое генерируется при каждом отправлении запроса в подсистему «Электронный полис», преобразованное в массив байт и закодированное с помощью base64, а элемент <Created> – дату отправления запроса в формате UTC.

Таким образом, окончательный пароль в PasswordDigest формируется из следующих элементов:

– password, выданный СК: «пароль в чистом виде»;

– nonce из запроса: JlhRUAKiBCvdHg9I4ITPJA==";

– created из запроса: "2012-08-15T08:16:34.495Z".

4.2.1. Пример soap-заголовка

<soapenv:Header>

<wsse:Security soapenv:mustUnderstand="1"

xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"

xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

<wsse:UsernameToken wsu:Id="UsernameToken-14">

<wsse:Username>rsa</wsse:Username>

<wsse:Password

Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">

s9uYfMe+iSmO5zfKl/ZFqzMLE2I=

</wsse:Password>

<wsse:Nonce

EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">

JlhRUAKiBCvdHg9I4ITPJA==

</wsse:Nonce>

<wsu:Created>2012-08-15T08:16:34.495Z</wsu:Created>

</wsse:UsernameToken>

</wsse:Security>

</soapenv:Header>

4.2.2. Контрольные примеры хеширования паролей

Контрольные примеры генерации хеша пароля с исходными данными и результатом:

Пример1:

Пароль (password): wss22wert

Случайное число (nonce): MzI2NjYyNzYxMQ==

Время (created): 2012-10-29T05:39:24Z

Результат:

passwordDigest = "88FDZSIoCwQT9zhMqpcekDvZwVo="

 

Пример2:

password = "test"

nonce = "8kqcOS9SFYxSRslITbBmlw=="

created = "2012-10-29T08:18:34.836Z"

passwordDigest = "LOzA3VPv+2hFGOHq8O6gcEXsc/k="

(результат декодирования из base64 в строку не всегда дает строку из чисел, в руководстве имеется ввиду набор байт сгенерированных случайным образом)

 

Пример3:

password = "ic3"

nonce = "m4feQj9DG96uNY1tCoFBnA=="

created = "2012-10-29T08:49:58.645Z"

passwordDigest = "K80tK4TyuvjuXvMu++O8twrXuTY="

passwordDigest = "GkwwpX23bO588LKc3bNKgPFfE0E="

 

Пример4:

password = "tashkent"
nonce = "NTQ2ODc5Nw=="
created = "2013-01-24T22:00:00.111Z"
passwordDigest = "JdB4xSYW94+IAZqTDXyyaSvaZCs="

 

Пример5:

password = "gd6Eh7Rf"
nonce = "sL4s4rP/UzEeOnGeZ79JEw=="
created = "2013-01-24T19:21:46.565Z"
passwordDigest = "ia1+oDixfzd1Q6WNAlJ/jExJj5o="

4.2.3. Пример реализации хэширования пароля на Java

publicstaticString doPasswordDigest(String nonce, String created, String password) {

String passwdDigest = null;

try {

passwdDigest = doPasswordDigest(nonce, created, password.getBytes("UTF-8"));

} catch (Exception e) {

if (DO_DEBUG) {

LOG.debug(e.getMessage(), e);

}

}

return passwdDigest;

}

 

publicstaticString doPasswordDigest(String nonce, String created, byte[] password) {

String passwdDigest = null;

try {

byte[] b1 = nonce!= null? Base64.decode(nonce): newbyte[0];

byte[] b2 = created!= null? created.getBytes("UTF-8"): newbyte[0];

byte[] b3 = password;

byte[] b4 = newbyte[b1.length + b2.length + b3.length];

int offset = 0;

System.arraycopy(b1, 0, b4, offset, b1.length);

offset += b1.length;

 

System.arraycopy(b2, 0, b4, offset, b2.length);

offset += b2.length;

 

System.arraycopy(b3, 0, b4, offset, b3.length);

 

byte[] digestBytes = WSSecurityUtil.generateDigest(b4);

passwdDigest = Base64.encode(digestBytes);

} catch (Exception e) {

if (DO_DEBUG) {

LOG.debug(e.getMessage(), e);

}

}

return passwdDigest;

}

4.3. Заполнение тега <Body>

Обязательный элемент <Body> предназначен для передачи основных данных конечному SOAP-получателю. Дочерние элементы <Body> содержат передаваемую информацию и могут иметь различные атрибуты. Для передачи веб-сервисам Системы файлов-запросов в формате xml, тег <data> заполняется с учетом использования свойства МТОМ (с использованием МТОМ, либо без использования МТОМ). Адреса веб-сервисов подсистемы «Электронный полис» приведены в подразделе 4.1 «Адреса и методы веб-сервисов Системы» настоящего руководства.

Процесс кодирования/декодирования пересылаемых бинарных данных большого размера занимает большие ресурсы. Использование механизма МТОМ позволяет увеличить эффективность передачи бинарных данных в SOAP-запросе путем включения их в качестве вложения без кодирования в base64Binary-формат.

Структура файла-запроса, передаваемого веб-сервисам Системы в «теле» SOAP-запроса (тег <Body>), должна соответствовать актуальной схеме xsd, описанной в Приложении 3 «Спецификация форматов взаимодействия» настоящего руководства, а его содержание должно быть заполнено в соответствии с правилами, описанными в Разделе 5 «Правила формирования файлов-запросов» и Разделе 7 «Выполняемые проверки».

4.3.1. Пример заполнения тега <data> для передачи сообщения веб-сервисам с использованием МТОМ

При использовании механизма МТОМ основное SOAP-сообщение передается по HTTP-протоколу без вложений, которые запрашиваются клиентом отдельно с помощью HTTP GET-запроса.

В начале сообщения в стандартном наборе HTTP-заголовков должен быть указан HTTP-заголовок Content-Type, определяющий тип данных сообщения. Заголовок Content-Transfer-Encoding определяет представление данных при пересылке. Основное SOAP-сообщение ссылается на вложение, используя значение заголовка Content-ID соответствующего вложения как значение атрибута href. Формат прикрепленных заархивированных файлов – «gzip».

 

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><ns2:getLossKASKOStatusRequest xmlns:ns2="http://ws.dkbm.rsa.com/"><return><data><xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:9fe4e963-cb33-4885-b608-0c62c33e2a9b-2@cxf.apache.org"/></data></return></ns2:getLossKASKOStatusRequest ></soap:Body></soap:Envelope>

 

--uuid:aa475c60-9a04-4fbd-9500-ee778d3c1b47

Content-Type: application

Content-Transfer-Encoding: binary

Content-ID: <9fe4e963-cb33-4885-b608-0c62c33e2a9b-2@cxf.apache.org>

 

­??V?n?@~?????I??V????

77Y?ElG^?[?J?B?=?ih

??????K+^?q???????

--uuid:aa475c60-9a04-4fbd-9500-ee778d3c1b47—

4.3.2. Пример заполнения тега <data> при передаче сообщения для веб-сервисов без использования МТОМ

<ws:attachment>
<data>СТРОКА_ПОЛУЧЕННАЯ_ЧЕРЕЗ_BASE64_ОТ_ФАЙЛА-ЗАПРОСА(gzip)</data> </ws:attachment>

 

Проверка субъектов/ТС

Для осуществления проверки данных субъектов – физических, либо юридических лиц, и ТС КИС СК обращается к сервису CheckSubjectOSAGOService Системы и формирует файл, содержащий запрос к соответствующему методу веб-сервиса с использованием нижеприведенных схем xsd:

- метод loadInsurerOwner, схема InsurerOwnerRequest.xsd – для запроса на проверку данных субъекта - страхователя, собственника ТС;

- метод loadDriver, схема DriverRequest.xsd – для запроса на проверку данных субъекта – ЛДУ;

- метод loadVehicle, схема TSRequest.xsd – для запроса на проверку транспортного средства.

 

Состав запросов, соответствующий указанным схемам, а также правила заполнения и передачи полей (ФЛК) приведены в Приложении 3 «Спецификация форматов взаимодействия», а также в Разделе 7 Таблицах 5-7 настоящего руководства.

 

При направлении запроса на осуществление проверки данных субъектов/ТС необходимо учитывать следующие аспекты:

5.3.1. В рамках одного запроса возможно осуществить проверку только по одному субъекту (страхователю ТС/собственнику ТС/ЛДУ), либо по одному ТС.

5.3.2. В случае несоответствия запроса установленным правилам ФЛК подсистема «Электронный полис» отказывает в загрузке запроса и возвращает соответствующее сообщение об ошибке. Коды ошибок, их описание и поведение Системы при их получении приведены в Приложении 1 «Ошибки валидации» настоящего документа.

5.3.3. В случае соответствия запроса установленным правилам ФЛК подсистема «Электронный полис» формирует ответ СК об успешной постановке запроса в очередь с указанием идентификатора проверки субъекта/ТС. Ответное сообщение СК формируется в соответствие со схемами InsurerOwnerResponse.xsd/ DriverResponse.xsd/TSResponse.xsd состав которых приведен в Приложении 3 «Спецификация форматов взаимодействия» настоящего руководства.

5.3.4. В случае соответствия запроса установленным правилам ФЛК подсистема «Электронный полис» формирует и передает запрос на проверку субъекта/ТС сервису ДиКБМ.

5.3.5. Поиск и проверка ТС в подсистеме ДиКБМ осуществляется по полному совпадению идентификаторов ТС (по указанному количеству идентификаторов и их значениям). Проверка гос.номера осуществляется среди гос.номеров – единственных идентификаторов ТС.

5.3.6. На момент внедрения Системы проверка транспортных средств осуществляется только среди ТС, зарегистрированных на территории РФ.

5.3.7. При использовании Адаптера WS Система автоматически после получения ответа от ДиКБМ возвращает СК файл, содержащий результаты проверки субъекта/ТС в соответствии с п. 5.4 настоящего руководства, либо ошибки в обработке запроса ДиКБМ. В случае если запрос направлялся без использования Адаптера WS, для получения результатов проверки субъекта/ТС необходимо осуществить запрос статуса обработки, порядок направления которого описан в п. 5.4 настоящего руководства.

Идентификация объектов

Правила идентификации объектов в Системе приведены в Таблице 4.

 

Таблица 4 Правила идентификации объектов

Объект Идентифицирующие реквизиты Элементы XML
Проект договора е-ОСАГО Код СК + Идентификатор договора СК InsurerID + DraftPolicyID
Субъект физ.лицо (страхователь, собственник ТС) ХЭШ (ФИО + дата рождения) + Тип документа + Серия документа + Номер документа PersonNameBirthHash + DocPerson + Serial + Number
Субъект физ.лицо - ЛДУ ХЭШ (ФИО + дата рождения) + Серия ВУ + Номер ВУ+ Тип документа PersonNameBirthHash + Serial + Number+(DocPerson=20)
Субъект юр.лицо (страхователь и собственник ТС) Для субъектов – резидентов РФ: «ИНН» Для субъектов – нерезидентов РФ: «Полное наименование» (согласно Свидетельству о регистрации (в открытом, незахэшированном виде) Для резидентов РФ: INN Для нерезидентов РФ: OrgName
Документ субъекта Тип документа + Серия документа + Номер документа DocPerson + Serial + Number
Транспортное средство Идентификация ТС обеспечивается сочетанием значения поля «Страна регистрации ТС» с полями одного из следующих способов: 1) Идентификатор определяется значением одного из следующих реквизитов или их комбинацией (при заполнении нескольких):
  • VIN
  • № кузова
  • № шасси
2) ТС, для которых единственным идентификатором выступает только гос. номер, идентификация определяется значением реквизита Гос. номер при отсутствии CarIdent (VIN, № кузова, № шасси).
CountryCar 1) VIN BodyNumber ChassisNumber   2) LicensePlate

 


Выполняемые проверки

Технические проверки выполняются при получении подсистемой «Электронный полис» запроса, при валидации его на соответствие xsd-схемам. Состав xsd-схем Системы приведен в Приложениие 3 «Спецификация форматов взаимодействия» настоящего руководства.

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

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

В Системе реализована возможнос







ЧТО ПРОИСХОДИТ, КОГДА МЫ ССОРИМСЯ Не понимая различий, существующих между мужчинами и женщинами, очень легко довести дело до ссоры...

Что делать, если нет взаимности? А теперь спустимся с небес на землю. Приземлились? Продолжаем разговор...

Конфликты в семейной жизни. Как это изменить? Редкий брак и взаимоотношения существуют без конфликтов и напряженности. Через это проходят все...

ЧТО ПРОИСХОДИТ ВО ВЗРОСЛОЙ ЖИЗНИ? Если вы все еще «неправильно» связаны с матерью, вы избегаете отделения и независимого взрослого существования...





Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:


©2015- 2024 zdamsam.ru Размещенные материалы защищены законодательством РФ.