5.2.8. Особенности схем сервиса СМЭВ

5.2.8. Особенности схем сервиса СМЭВ

Для взаимодействия со СМЭВ доступен единый электронный сервис в версиях 1.1, 1.2 и 1.3 (каждая версия единого электронного сервиса доступна по отдельному адресу, который следует уточнить в службе эксплуатации СМЭВ).

Для корректного взаимодействия рекомендуется, чтобы оба участника обмена (Инициатор и Ответчик) использовали адрес для обращения к Транспорту СМЭВ с одним endpoint. Например, запрос, направленный в адрес вида http://host:7500/smev/v1.2/ws по методу Send и Виду сведения, поддерживающему только версию схем Единого сервиса 1.2, не может быть извлечен из очереди ИС запросом, направленным по методу Get по версии схем 1.3 в адрес Единого сервиса вида http://host:5000/transport_1_0_2/.

5.2.8.1. Версия 1.2

Все участники взаимодействия, желающие остаться на версии схемы 1.1, смогут отправлять сообщения и получать сообщения из своих очередей доставки через единый электронный сервис в версии 1.1. При этом не доступна возможность получения сообщений из очереди ответов (GetStatus) и возможность получать сообщения со статусами в ответах

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

В случае, когда система-инициатор и система-ответчик работают по разным версиям Единого сервиса (1.1 и 1.2), на стороне получателя сообщения необходимо отключить проверку ЭЦП отправителя сообщения, осуществлять проверку только подписи СМЭВ. В противном случае, для корректной валидации ЭЦП отправителя сообщения, системе-инициатору и системе-ответчику необходимо работать по одной версии (1.1 или 1.2).

Перечень новых элементов схемы 1.2 приведён в таблице 2.

Таблица 2 – Перечень новых элементов схемы 1.2.

№	Элемент	Описание изменения	Комментарий
1	Новые элементы схемы 1.2
1.1	ReferenceMessageID	Идентификатор сообщения, порождающего цепочку сообщений. Включён в содержательную часть: ·         запроса SenderProvidedRequestData (раздел 5.2.2); ·         ответа с сообщением из очереди доставки ответов Response (раздел 5.2.5).	Является опциональным элементом, используется для формирования цепочки запросов в рамках одной бизнес-транзакции, путём помещения в данное поле ID первого сообщения в цепочке запросов (раздел 5.2.2).
1.2	TransactionCode	Идентификатор кода транзакции запроса. Включён в содержательную часть запроса SenderProvidedRequestData.	Описание использования приведено в разделе 10
1.3	OriginalTransactionCode	Идентификатор кода транзакции ответа с сообщением из очереди доставки ответов Response (раздел 5.2.5).	Заполняется автоматически СМЭВ на основании кода транзакции запроса
1.4	RequestStatus	Элемент, определяющий структуру бизнес-статуса обработки ответа на запрос. Включён в содержательную часть ответа на запрос SenderProvidedResponseData как <choice> элемент (раздел 5.2.4).	Элемент включает следующий набор параметров: ·         Код бизнес-статуса запроса (обязательный параметр); ·         Пару параметров «ключ-значение» (опциональный параметр); ·         Расширенное описание бизнес-статуса запроса (обязательный параметр).
1.5	AsyncProcessingStatus	Элемент, определяющий структуру ошибки асинхронной обработки запроса. Включён в содержательную часть ответа на запрос SenderProvidedResponseData как <choice> элемент (раздел 5.2.4).	Используется как элемент выбора в конверте SenderProvidedRequestData (раздел 5.2.2).
1.6	SmevFault	Элемент, определяющий структуру пары параметров «код»-«описание» ошибки. Включён в содержательную часть AsyncProcessingStatus (раздел 5.2.4).	Заполняется кодом ошибки. Элемент конверта AsyncProcessingStatus. Входит в содержательную часть ответа на запрос сообщения из статусной очереди SmevAsyncProcessingMessage и содержится в элементе AsyncProcessingStatusData. Также элемент AsyncProcessingStatus включен в содержательную часть ответа на запрос SenderProvidedResponseData как элемент типа <choice> (раздел 5.2.4) . Является опциональным элементом
1.7	EOL	Элемент, определяющий время актуальности сообщения. Включён в содержательную часть запроса SenderProvidedRequestData (раздел 5.2.2).	Если отправляемое сообщение должно иметь срок актуальности, то в элемент EOL следует добавить метку времени истечения срока актуальности сообщения с указанием временной зоны (раздел 5.2.2). Является опциональным элементом
1.8	AsyncProcessingStatusData	Конверт для AsyncProcessingStatus	Используется только для ошибок push-нотификации (раздел 11). Статусы обработки сообщений возвращаются непосредственно в ответах СМЭВ.
1.9	RejectionReasonCode	Подэлемент – RejectionReasonCode элемента RequestRejected может принимать новое значение FAILURE	Код ошибок запроса может возвращать значение FAILURE (уведомление об отсутствии сведений).

5.2.8.2. Версия 1.3

Версия 1.3 введена для обеспечения возможности использования директивных протоколов обмена. Адрес для обращения http://172.20.3.12:5000/transport_1_0_2/. СМЭВ-конверт, сформированный в соответствии со схемой СМЭВ 3.Х версии 1.3 необходимо передавать в адрес размещения Единого электронного сервиса по версии схем 1.3 (Host: 172.20.3.12:5000) для корректного взаимодействия. Передача в адреса размещения Единого электронного сервиса по версии схем 1.1/1.2 (Host: 172.20.3.12:7500) в данном случае недопустима

Все участники, желающие остаться на более старых версиях сервиса (1.1 или 1.2), могут пользоваться директивными протоколами обмена, с некоторыми условиями:

• При отправке сообщений отсутствует возможность использовать любые варианты маршрутизации, использующие директивы: общая реестровая по мнемоникам, реестровая по мнемоникам, фрагментарная рассылка;
• При получении сообщений, отправленных с использованием сервиса версии 1.3, необходимо на стороне ИС получателя распределять вложения по записям реестра.

Добавлен элемент, содержащий директиву с маршрутной информацией (//SendRequestRequest/Routing). Структура директивы с маршрутной информацией представлена на рисунке 36.

Рисунок 36 – Структура директивы с маршрутной информацией.

Описание элементов директивы приведено в разделе 5.2.2.

Для описания реестра записей, передающихся в блоке структурированных сведений (//MessagePrimaryContent) добавлен элемент //Registry (рисунок 37).

Рисунок 37 – Структура директивы «Реестровая запись»

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

Для сообщения, направленного в адрес системы-ответчика по маршрутизациям, описанным в пп.4.6.2.3 и пп.4.6.3.3 , содержание блока SenderInformationSystemSignature соответствует аналогичному блоку в инициирующем сообщении, полученном от системы-отправителя. В связи с особенностями маршрутизации блок SenderProvidedRequestData в инициирующем сообщении и в сообщении, фактически направленном в адрес системы-ответчика, могут отличаться. При взаимодействии по данным видам маршрутизаций системе-ответчику необходимо отключить проверку ЭЦП отправителя сообщения.

В случае, когда Инициатор и Ответчик работают по разным версиям Единого сервиса (1.1/1.2 и 1.3), на стороне получателя сообщения необходимо отключить проверку ЭЦП отправителя сообщения, осуществлять проверку только подписи СМЭВ. В противном случае, для корректной вариации ЭЦП отправителя сообщения, системе-инициатору и системе-ответчику необходимо работать по одной версии (1.3).