Краткое содержание изменений


НазваниеКраткое содержание изменений
страница7/20
ТипКраткое содержание
1   2   3   4   5   6   7   8   9   10   ...   20

Порядок взаимодействия информационных систем участников с ГИС ГМП посредством веб-сервиса


Веб-сервис ГИС ГМП размещён в СМЭВ и отвечает требованиям документа «Методические рекомендации по разработке электронных сервисов и применению технологии электронной подписи при межведомственном электронном взаимодействии» версии 2.4.4. Данный веб-сервис обслуживает все запросы от информационных систем участников, в ходе обработки которых ГИС ГМП формирует ответы и возвращает их в информационные системы участников.

Для обслуживания входящих запросов веб-сервис предоставляет один метод UnifoTransferMsg, который в синхронном режиме обрабатывает все запросы от информационных систем участников. Форматы сообщений метода описаны в пункте 4. «Форматы сообщений веб-сервиса, размещённого в СМЭВ».

Описание веб-сервиса SmevUnifoService приведено в файле SmevUnifoService.wsdl (пункт 8. «WSDL веб-сервиса, размещённого в СМЭВ»).
      1. Порядок формирования ответов веб-сервиса


Веб-сервис принимает запросы от информационных систем участников, форматы которых описанны в пункте 4. «Форматы сообщений веб-сервиса, размещённого в СМЭВ». По результатам обработки запроса к методу веб-сервиса, вне зависимости от результата его обработки, формируется ответ веб-сервиса и возвращается инициатору запроса. Форматы ответов веб-сервиса описанны в пункте 4. «Форматы сообщений веб-сервиса, размещённого в СМЭВ».

При сбое в обработке запроса ответ должен содержать информацию о произошедшем сбое. Данные об ошибках, возникающих в процессе обработки файла с запросом, представлены в пункте 6. «Перечень контролей».
      1. Электронные подписи запросов и ответов


Все сообщения от информационных систем участников должны содержать ЭП-ОВ (ЭП информационной системы, сформировавшей запрос). Подпись должна находится в заголовке SOAP-пакета сообщения-запроса и соответствовать методическим рекомендациям по разработке электронных сервисов и применению технологии электронной подписи при межведомственном электронном взаимодействии версии 2.4.4 (глава 5. «Электронные подписи субъектов взаимодействия – информационных систем»).

При отправке ответа на запрос ИС ГИС ГМП накладывает ЭП-ОВ. Подпись располагается в заголовке SOAP-пакета сообщения-ответа и соответствует методическим рекомендациям по разработке электронных сервисов и применению технологии электронной подписи при межведомственном электронном взаимодействии версии 2.4.4 (глава 5. «Электронные подписи субъектов взаимодействия – информационных систем»).

В форматах сообщений веб-сервиса теги unifo:ImportDataResponse / ticket:Ticket, unifo:exportData / pdrq:DataRequest, unifo:exportDataResponse / ResponseTemplate, pdr:DoAcknowledgmentRequest и eqrs:DoAcknowledgmentResponse содержат внутри себя тег подписи ds:Signature. Эта подпись не используется ГИС ГМП при взаимодействии через веб-сервис. Подпись оставлена для обеспечения совместимости с форматами сообщений файлового шлюза.

В формате каждой сущности, импортируемой в ГИС ГМП, присутствует тег подписи ds:Signature (сущности передаются в теге AppData / unifo:ImportData / pirq:ImportRequest). Проверку этой подписи ГИС ГМП не осуществляет, но хранит вместе с сущностью. Её наличие обязательно и необходимо для того чтобы участник, запросивший эту сущность и проверив данную подпись, удостоверился в том, что сущность не была изменена. Подпись под сущностью ГИС ГМП должна накладываться в соответствии с алгоритмом, описанным в пункте 3.1.2.1.
        1. Подпись под сущностью ГИС ГМП


Значение подписи должно рассчитываться для элемента сущности и его составных элементов.

В процессе создания электронной подписи информационной системы должны использоваться алгоритмы для расчета хеш-сумм, формирования подписи и каноникализации, приведённые Таблица № . «Алгоритмы формирования подписи».

Таблица № . «Алгоритмы формирования подписи»




Наименование

URI

Расчет хэш-сумм

ГОСТ Р 34.11-94

http://www.w3.org/2001/04/xmldsig-more#gostr3411

Формирования подписи

ГОСТ Р 34.10-2001

http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411

Каноникализация

Exclusive XML Canonicalization от 18 July 2002

http://www.w3.org/2001/10/xml-exc-c14n#


Формирование блока электронной подписи осуществляется в следующем порядке:

  1. Формирование шаблона документа:

    1. Создается элемент Signature;

    2. К элементу Signature добавляется дочерний элемент SignedInfo;

    3. К элементу SignedInfo добавляется дочерний элемент CanonicalizationMethod;

    4. К элементу SignedInfo добавляется дочерний элемент SignatureMethod;

    5. К элементу SignedInfo добавляется первый дочерний элемент Reference;

    6. К элементу Reference добавляется дочерний элемент Transforms;

    7. К элементу Transforms элемента Reference добавляется дочерний элемент Transform (два элемента);

    8. К элементу Reference добавляется элемент DigestMethod;

    9. К элементу Reference добавляется элемент DigestValue;

    10. К элементу Signature добавляется дочерний элемент SignatureValue;

    11. К элементу Signature добавляется дочерний элемент KeyInfo;

    12. К элементу KeyInfo добавляется дочерний элемент X509Data;

    13. К элементу X509Data добавляется дочерний элемент X509Certificate.

  2. Установка предопределенных значений

    1. Для элемента CanonicalizationMethod и для второго элемента Transform элемента Reference значения атрибута Algorithm устанавливается в «http://www.w3.org/2001/10/xml-exc-c14n#».

    2. Для первого элемента Transform алгоритм выставляется значение "http://www.w3.org/2000/09/xmldsig#enveloped-signature".

    3. Для элементов DigestMethod первого значения атрибута Algorithm устанавливается в "http://www.w3.org/2001/04/xmldsig-more#gostr3411".

    4. Для элемента SignatureMethod значение атрибута Algorithm устанавливается в "http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411".

    5. Атрибут URI элемента Reference должен иметь пустое значение.

  3. Установка подписи

    1. Открытый ключ подписи, закодированный по алгоритму «http://www.w3.org/2000/09/xmldsig#base64», добавляется к элементу X509Certificate как дочерний текстовый узел.

    2. Подписываются элементы документа, выбранные посредством XPATH выражения на основе значения атрибута URI элемента Reference (если элемент URI имеет пустое значение, то подписывается полностью весь тег сущности). Полученное значение кодируется по алгоритму «http://www.w3.org/2000/09/xmldsig#base64» и добавляется как дочерний текстовый узел к элементу DigestValue первого элемента Reference.

    3. Элемент SignedInfo трансформируется в соответствии с алгоритмом «http://www.w3.org/2001/10/xml-exc-c14n#». Затем на основании полученной строки и ключа подписи формируется значение ЭП в соответствии с алгоритмом «http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411». Полученное значение ЭП кодируется в соответствии с алгоритмом «http://www.w3.org/2000/09/xmldsig#base64» и значение добавляется как дочерний текстовый узел к элементу SignatureValue.

Пример:















 





Значение хеша в Base64





Значение подписи в Base64





Cертификат X.509 в Base64







  1. Форматы сообщений веб-сервиса, размещённого в СМЭВ

В подглавах данной главы приведены форматы запросов к ГИС ГМП и форматы ответов, передаваемых посредством веб-сервиса, размещённого в СМЭВ, в разрезе функциональности ГИС ГМП.

Сообщение запроса к веб-вервису

Формат сообщения запроса к веб-вервису схематично представлен на Рисунок № . «Сообщение запроса к веб-сернвису», описание элементов приведено в Таблица № . «Структура сообщения запроса к веб-сервису».

Рисунок № . «Сообщение запроса к веб-сернвису»
Таблица № . «Структура сообщения запроса к веб-сервису»

Наименование

Кол-во тегов, обязательность

Тип данных

Комментарий

UnifoTransferMsg

1, обязательно




Корневой тег запроса

Message

0..1, необязательно

Контейнер

Служебный блок атрибутов СМЭВ

Sender

1, обязательно

orgExternalType

Данные о системе-ициаторе взаимодействия

Code

1, обязательно

Xsd:string

Идентификатор системы.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

Name

1, обязательно

Xsd:string

Наименование системы.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

Recipient

1, обязательно

orgExternalType

Данные о системе-получателе сообщения (Поставщике)

Code

1, обязательно

Xsd:string

Идентификатор системы.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

Name

1, обязательно

Xsd:string

Наименование системы.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

Originator

0..1, необязательно

orgExternalType

Данные о системе, инициировавшей цепочку из нескольких запросов-ответов, объединенных единым процессом в рамках взаимодействия

Code

1, обязательно

Xsd:string

Идентификатор системы.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

Name

1, обязательно

Xsd:string

Наименование системы.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

TypeCode

1, обязательно

TypeCodeType

Тип сообщения.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

Status

1, обязательно

StatusType

Статус сообщения.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

В запросе должен принимать значение «REQUEST».


Date

1, обязательно

Xsd:dateTime

Дата создания сообщения.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

ExchangeType

1, обязательно

Xsd:string

Категория взаимодействия.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

RequestIdRef

0..1, необязательно

idType

Не используется

OriginRequestIdRef

0..1, необязательно

idType

Не используется

ServiceCode

0..1, необязательно

Xsd:string

Код государственной услуги, в рамках оказания которой осуществляется информационный обмен.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

CaseNumber

0..1, необязательно

Xsd:string

Номер дела в информационной системе-отправителе.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

TestMsg

0..1, необязательно

Xsd:string

Признак тестового взаимодействия.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

MessageData

1, обязательно

Контейнер

Блок-обертка данных СМЭВ

AppData

1, обязательно

AppDataType

Блок структурированных сведений

ImportData

1, обязательно

Контейнер

Запрос на импорт сущностей

ImportRequest

1, обязательно

ImportRequest




PostBlock

1, обязательно

PostBlock (см. описание в пункте 4.8.3)

Блок почтовой информации

Charge

1, обязательно

ChargeType (см. описание в пункте 2.2)

Начисление

FinalPayment

1, обязательно

PaymentInfoType(см. описание в пункте 2.3)

Платёж

Income

1, обязательно

IncomeInfoType

Не используется.

ImportDataResponse

1, обязательно

Контейнер

Не используется в сообщениях запросов

exportData

1, обязательно

Контейнер

Запрос на экспорт сущностей

DataRequest

1, обязательно

DataRequest

См. описание в пунктах 4.3.1, 4.4.1, 4.5.1 и 4.6.1.

exportDataResponse

1, обязательно

Контейнер

Не используется в сообщениях запросов

DoAcknowledgmentRequest

1, обязательно

DoAcknowledgmentRequestType

Запрос на проведение квитирования начисления с платежами (см. описание в пункте 4.7.1)

DoAcknowledgmentResponse

1, обязательно

DoAcknowledgmentResponseType

Не используется в сообщениях запросов

AppDocument

0..1, необязательно

AppDocumentType

Не используется

Сообщение ответа от веб-вервиса

Формат сообщения ответа от веб-вервиса схематично представлен на Рисунок № . «Сообщение ответа от веб-сервиса», описание элементов приведено в Таблица № . «Структура сообщения ответа к веб-сервису».
Рисунок № . «Сообщение ответа от веб-сервиса»

Таблица № . «Структура сообщения ответа к веб-сервису»

Наименование

Кол-во тегов, обязательность

Тип данных

Комментарий

UnifoTransferMsgResponse

1, обязательно




Корневой тег ответа

Message

0..1, необязательно

Контейнер

Служебный блок атрибутов СМЭВ

Sender

1, обязательно

orgExternalType

Данные о системе-отправителе сообщения

Code

1, обязательно

Xsd:string

Идентификатор системы.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

Name

1, обязательно

Xsd:string

Наименование системы.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

Recipient

1, обязательно

orgExternalType

Данные о системе-получателе сообщения

Code

1, обязательно

Xsd:string

Идентификатор системы.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

Name

1, обязательно

Xsd:string

Наименование системы.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

Originator

0..1, необязательно

orgExternalType

Данные о системе, инициировавшей цепочку из нескольких запросов-ответов, объединенных единым процессом в рамках взаимодействия

Code

1, обязательно

Xsd:string

Идентификатор системы.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

Name

1, обязательно

Xsd:string

Наименование системы.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

TypeCode

1, обязательно

Xsd:string

Тип сообщения.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

Status

1, обязательно

StatusType

Статус сообщения.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

В ответе может принимать значение «RESULT», «INVALID», «REJECT» или «FAILURE».

Date

1, обязательно

Xsd:dateTime

Дата создания сообщения.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

ExchangeType

1, обязательно

Xsd:string

Категория взаимодействия.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

RequestIdRef

0..1, необязательно

idType

Идентификатор сообщения-запроса, инициировавшего взаимодействие. Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

OriginRequestIdRef

0..1, необязательно

idType

Идентификатор сообщения-запроса, инициировавшего цепочку из нескольких запросов-ответов, объединенных единым процессом в рамках взаимодействия.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

ServiceCode

0..1, необязательно

Xsd:string

Совпадает со значением одноименного реквизита сообщения запроса

CaseNumber

0..1, необязательно

Xsd:string

Совпадает со значением одноименного реквизита сообщения запроса

TestMsg

0..1, необязательно

Xsd:string

Признак тестового взаимодействия.

Заполняется в соответствии с методическими рекомендациями версии 2.4.4.

MessageData

1, обязательно

Контейнер

Блок-обертка данных СМЭВ

AppData

1, обязательно

AppDataType

Блок структурированных сведений

ImportData

1, обязательно

Контейнер

Не используется в сообщениях ответов на запросы

ImportDataResponse

1, обязательно

Контейнер

Ответ на запрос импорта сущности

Ticket

1, обязательно

Ticket

См. описание в пунктах 4.1.2 и 4.2.2.

exportData

1, обязательно

Контейнер

Не используется в сообщениях ответов на запросы

exportDataResponse

1, обязательно

Контейнер

Ответ на запрос экспорта сущности

ResponseTemplate

1, обязательно

ResponseTemplate (см. описание в пункте 4.8.2)




DoAcknowledgmentRequest

1, обязательно

DoAcknowledgmentRequestType

Не используется в сообщениях ответов на запросы

DoAcknowledgmentResponse

1, обязательно

DoAcknowledgmentResponseType

Ответ на запрос проведения квитирования начисления с платежами (см. описание в пункте 4.7.2)

AppDocument

0..1, необязательно

AppDocumentType

Не используется
1   2   3   4   5   6   7   8   9   10   ...   20

Похожие:

Краткое содержание изменений iconКраткое содержание акта
О внесении изменений в Кодекс Российской Федерации об административных правонарушениях

Краткое содержание изменений iconКраткое содержание акта
О внесении изменений в Кодекс Российской Федерации об административных правонарушениях

Краткое содержание изменений iconКраткое содержание тем учебной дисциплины «Гражданское право»
Дано краткое содержание изучаемых тем, планы семинарских и практических занятий, тематика контрольных и курсовых работ, примерные...

Краткое содержание изменений iconКраткое содержание тем учебной дисциплины «Гражданское право»
Дано краткое содержание изучаемых тем, планы семинарских и практических занятий, тематика контрольных и курсовых работ, примерные...

Краткое содержание изменений iconКраткое содержание тем учебной дисциплины «Гражданское право»
Дано краткое содержание изучаемых тем, планы семинарских и практических занятий, тематика контрольных и курсовых работ, примерные...

Краткое содержание изменений iconКраткое содержание тем учебной дисциплины «Гражданское право»
Дано краткое содержание изучаемых тем, планы семинарских и практических занятий, тематика контрольных и курсовых работ, примерные...

Краткое содержание изменений iconКраткое содержание тем учебной дисциплины «Гражданское право»
Дано краткое содержание изучаемых тем, планы семинарских и практических занятий, тематика контрольных и курсовых работ, примерные...

Краткое содержание изменений iconКраткое содержание акта
О внесении изменений в Федеральный закон "Об обязательном медицинском страховании в Российской Федерации" и отдельные законодательные...

Краткое содержание изменений iconКраткое содержание изменений Глава Предмет изменения Начисление Внесены...
Государственная информационная система о государственных и муниципальных платежах

Краткое содержание изменений iconКраткое содержание об

Вы можете разместить ссылку на наш сайт:


Все бланки и формы на filling-form.ru




При копировании материала укажите ссылку © 2019
контакты
filling-form.ru

Поиск