|
|
Механизмы взаимодействия Пользователей с СистемойСтр 1 из 7Следующая ⇒ Программного обеспечения для реализации возможности заключения договора ОСАГО в виде электронного документа и обеспечения МВД России доступа к АИС РСА в части предоставления информации о действующих договорах ОСАГО
Листов 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
Термины и сокращения
Аннотация Настоящий документ, разработанный в рамках Договора № Р/ДКС-15/17, является частью комплекта документов программного обеспечения для реализации возможности заключения договора ОСАГО в виде электронного документа и обеспечения МВД России доступа к АИС РСА в части предоставления информации о действующих договорах ОСАГО (далее – Подсистема «Электронный полис» АИС РСА, Система). Основанием для разработки документа является утвержденный от 24.03.2015 документ «Техническое задание на разработку программного обеспечения для реализации возможности заключения договора ОСАГО в виде электронного документа и обеспечения МВД России доступа к АИС РСА в части предоставления информации о действующих договорах ОСАГО». В настоящем документе описан механизм взаимодействия оператора СК с программным обеспечением (далее – ПО) Системы. Назначение Системы Система предназначена для автоматизации деятельности Российского Союза Автостраховщиков (РСА) по: - Обработке следующих поступающих от КИС СК запросов: o Запрос на проверку субъекта – страхователя, собственника ТС; o Запрос статуса проверки субъекта (страхователя, собственника ТС); o Запрос на проверку субъекта – ЛДУ; o Запрос статуса проверки субъекта (ЛДУ); o Запрос на проверку транспортного средства (ТС); o Запрос статуса проверки транспортного средства; o Запрос на загрузку проекта договора е-ОСАГО; o Запрос статуса загрузки проекта договора е-ОСАГО; o Запрос на загрузку статуса проекта договора е-ОСАГО; o Запрос статуса загрузки проекту договора е-ОСАГО статуса; o Запрос количества свободных номеров проектов договоров е-ОСАГО для СК; o Запрос списка номеров проектов договоров е-ОСАГО СК. - Передаче запросов на проверку субъектов и ТС в ДиКБМ; - Консолидации информации о проектах договоров е-ОСАГО и статусов к ним; - Перегрузке действующих договоров е-ОСАГО в ДиКБМ; - Предоставлению и учету номеров проектов договоров е-ОСАГО. Система позволяет осуществлять: – проверку данных субъектов – физических и юридических лиц, являющихся страхователями, собственниками ТС, либо ЛДУ; – проверку данных транспортных средств; – сбор и хранение информации о проектах договоров е-ОСАГО, а также о присвоенных им статусах; – заключение договоров е-ОСАГО. Подключение СК к Системе Для подключения СК к Системе необходимо:
- использование Адаптера WS; - обращение к Системе при помощи вызова соответствующего веб-сервиса.
Таблица 1 Адреса веб-сервисов
В качестве АДРЕС_СЕРВЕРА указывается 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 Строки лога
Таблица 3 Наименования методов веб-сервисов Системы и их назначение
Формирование 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"
Пример5: password = "gd6Eh7Rf" 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>
Проверка субъектов/ТС Для осуществления проверки данных субъектов – физических, либо юридических лиц, и ТС КИС СК обращается к сервису 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 Правила идентификации объектов
Выполняемые проверки Технические проверки выполняются при получении подсистемой «Электронный полис» запроса, при валидации его на соответствие xsd-схемам. Состав xsd-схем Системы приведен в Приложениие 3 «Спецификация форматов взаимодействия» настоящего руководства. После выполнения первичной валидации присланных запросов на соответствие xsd-схемам осуществляется логическая проверка присланных запросов, включающая проверку заполнения атрибутов запросов в зависимости от значения других атрибутов. В соответствии с логикой проверки, сначала выполняются проверки для родительских элементов, затем, при наличии родительского элемента, выполняются проверки для его дочерних элементов, таким образом если для родительского элемента в свойствах указана необязательность, а для его дочерних обязательность, при отсутствии родительского элемента в файле проверка считается успешно пройденной. В Системе реализована возможнос   Конфликты в семейной жизни. Как это изменить? Редкий брак и взаимоотношения существуют без конфликтов и напряженности. Через это проходят все...  Живите по правилу: МАЛО ЛИ ЧТО НА СВЕТЕ СУЩЕСТВУЕТ? Я неслучайно подчеркиваю, что место в голове ограничено, а информации вокруг много, и что ваше право...  ЧТО ПРОИСХОДИТ ВО ВЗРОСЛОЙ ЖИЗНИ? Если вы все еще «неправильно» связаны с матерью, вы избегаете отделения и независимого взрослого существования...  Что вызывает тренды на фондовых и товарных рынках Объяснение теории грузового поезда Первые 17 лет моих рыночных исследований сводились к попыткам вычислить, когда этот... Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:
|