Версия_1.0 - Институт архитектуры электронного государства

ИНСТИТУТ АРХИТЕКТУРЫ
ЭЛЕКТРОННОГО ГОСУДАРСТВА
ПРОЕКТ СТАНДАРТА
Государственные и муниципальные закупки.
Виды и последовательности сообщений.
Версия 1.0
МОСКВА 2005
1
Предисловие
Организация-разработчик
Министерство экономического
Федерации
развития
и
торговли
Российской
Авторы стандарта
 Потемкин Михаил Игоревич, ООО «УСП Компьюлинк»
 Бегтин Иван Викторович, ООО «УСП Компьюлинк»
 Бездушный Анатолий Николаевич, ООО «Алтимета»
 Бездушный Алексей Анатольевич, ООО «Алтимета»
Регистрационный номер
________________________________________________
Сведения о принятии стандарта
стандартизации
Сведения отсутствуют.
другими
Взамен
Введен впервые.
Версия стандарта
1.0
Объекты патентного или авторского права
Сведения отсутствуют.
2
организациями
по
Содержание
Предисловие ........................................................................................................... 2
Содержание ............................................................................................................. 3
1. ВВЕДЕНИЕ........................................................................................................ 5
2. НАИМЕНОВАНИЕ........................................................................................... 5
3. ОБЛАСТЬ ПРИМЕНЕНИЯ. ........................................................................... 5
4. НОРМАТИВНЫЕ ССЫЛКИ......................................................................... 6
5. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ. .................................................................. 6
6. ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ. .......................................................... 6
7. ОСНОВНЫЕ НОРМАТИВНЫЕ ПОЛОЖЕНИЯ ...................................... 7
7.1. Общие положения ......................................................................... 7
Команда PUSH ............................................................................... 7
7.2.
7.2.1.
Структура XML сообщения запроса...................................... 7
7.2.1.1. push ....................................................................................... 7
7.3.2.
Пример запроса на загрузку данных ..................................... 8
7.3.3.
Структура XML сообщения запроса...................................... 8
7.3.3.1. push-response ...................................................................... 8
7.3.4.
Пример ответа на запрос на загрузку данных ..................... 9
7.3.5.
Обработка ошибок ..................................................................... 9
7.3.6.
Вариант использования команды push............................... 10
Команда PULL ............................................................................. 11
7.3.
7.3.7.
Структура запроса ................................................................... 12
7.3.7.1. pull ...................................................................................... 12
7.3.7.2. date...................................................................................... 13
7.3.7.3. since..................................................................................... 13
7.3.7.4. versions ............................................................................... 13
7.3.7.5. uris ...................................................................................... 14
7.3.7.6. uri ........................................................................................ 14
7.3.7.7. types .................................................................................... 14
7.3.7.8. class-uri............................................................................... 14
7.3.7.9. classifier .............................................................................. 14
7.3.8.
Пример запроса на выгрузку данных.................................. 15
7.3.9.
Структура ответа Брокера на запрос poll ........................... 15
3
7.3.9.1. pull-response ...................................................................... 15
7.3.9.2. eof ........................................................................................ 16
7.3.9.3. lastElement ......................................................................... 16
7.3.10. Пример ответа Брокера на запрос poll ............................... 16
7.4.
Обеспечение безопасности передаваемых данных ................ 17
5. ПРИЛОЖЕНИЕ. Описание WSDL ................................................. 18
4
1. ВВЕДЕНИЕ.
1.1. Целью настоящего стандарта является упорядочение информационного
обмена между автоматизированными системами, используемыми в
процедурах размещения заказа при проведении государственных закупок.
1.2. Настоящая редакция стандарта определяет протокол взаимодействия
автоматизированных систем, участвующих в процессе информационного
обмена в системе государственных закупок Российской Федерации.
2. НАИМЕНОВАНИЕ
1.1. Государственные и муниципальные закупки. Виды и типы сообщений.
Версия 1.0
3. ОБЛАСТЬ ПРИМЕНЕНИЯ.
3.1.
Настоящий
стандарт
определяет
протокол
взаимодействия,
используемый при обмене информацией между автоматизированными
системами, отдельными ЭВМ и вычислительными комплексами,
используемыми в процедурах размещения заказа при проведении
государственных закупок.
3.2.
Соблюдение требований стандарта должно обеспечиваться:
 В отношении форматов передачи команд и обработки ответов –
разработчиками
автоматизированных
систем,
программных
компонентов и комплексов в сфере государственных и муниципальных
закупок, предназначенных для работы в едином информационном
пространстве государственных закупок.
3.3.
Требования настоящего стандарта являются рекомендательными при
создании,
модернизации
и
последующей
эксплуатации
автоматизированных систем, предназначенных для проведения
государственных закупок.
5
4. НОРМАТИВНЫЕ ССЫЛКИ.
 Указ Президента Российской Федерации "О первоочередных мерах по
предотвращению коррупции и сокращению бюджетных расходов при
организации закупки продукции для государственных нужд" от 08.04.97
№ 305
 Федеральный закон "О конкурсах на размещение заказов на поставки
товаров, выполнение работ, оказание услуг для государственных нужд"
от 06.05.1999 №97-ФЗ
 Государственные и муниципальные закупки. Процедуры обмена
сообщениями. Версия 1.0/
 Государственные и муниципальные закупки. Унифицированные
форматы данных. Версия 1.0.
 Расширяемый язык разметки XML 1.0 http://www.w3.org/TR/REC-xml/
5. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ.
В настоящем стандарте применяются следующие термины и
определения:
5.1. Автоматизированная информационная система - совокупность
программных средств вместе с базами данных, которыми манипулируют эти
программные средства.
5.2. База данных - совокупность данных, организованных по
определенным правилам, предусматривающим общие принципы описания,
хранения
и манипулирования данными, независимая от прикладных
программ
5.3. Данные - информация, представленная на электронном носителе в
форме, пригодной для обработки вычислительными и программными
средствами.
5.4. Автоматизированная информационная система государственных
закупок – система, программный продукт, предоставляющий возможность
взаимодействия заказчикам и поставщикам в рамках системы
государственных закупок
5.5. Брокер – автоматизированная информационная система,
обеспечивающая централизованное взаимодействие автоматизированных
информационных систем государственных закупок.
6. ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ.
№
Аббревиатура
АИС
БД
ФИО
Обозначение
автоматизированная информационная система
база данных
фамилия, имя и отчество
6
URI
Universal Resource Identifier, Универсальный
идентификатор ресурса
7. ОСНОВНЫЕ НОРМАТИВНЫЕ ПОЛОЖЕНИЯ
7.1.
Общие положения
Взаимодействие автоматизированных информационных систем с
Брокером осуществляется посредством веб-сервиса Брокера. Данный вебсервис поддерживает две операции:
 push – послать данные брокерной подсистеме для загрузки
 pull – получить данные от брокерной подсистемы
Сервис брокера оформлен как document-style сервис (такой как, например,
UDDI).
7.2.
Команда PUSH
С помощью операции PUSH автоматизированные информационные
системы посылают в Брокер новые данные и обновления ранее
опубликованных данных. Данные оформляются в виде XML сообщения.
7.2.1. Структура XML сообщения запроса
7.2.1.1. push
Описание
Корневой тэг запроса на загрузку данных в брокер.
Атрибуты
Атрибут
Тип
Описание
pushid
Строка
Уникальный идентификатор
запроса, определяемый каждой
системой – источником данных.
Используется для гарантии
однократного исполнения операции
при сетевых сбоях. В этом случае
при повторном обращении с тем же
pushid, брокер вернёт
соответствующую ошибку.
sourceid
Строка
Идентификатор источника,
используемый при авторизации его
в брокере.
key
Строка
Пароль, ключ присвоенный
7
Атрибут
Тип
Описание
данному источнику при
регистрации (*)
*
В данной версии стандарта, в качестве временного решения, пароль
передаётся в открытом виде. Его безопасность обеспечивается
использованием протокола SSL (HTTPS). Данное положение стандарта
должно быть пересмотрено после публикации спецификаций Электронного
государства
Элементы
Элемент
…
Тип
Описание
Элементы-записи загружаемых в
Брокер данных
7.3.2. Пример запроса на загрузку данных
<push pushid=”12345” source=”mert_pgz” key=”some_password”>
<...>
<...>
<...>
</push>
Здесь и далее под символом “<...>” понимается запись, описывающая
некоторый ресурс (например, конкурс или организацию), формат которой
описан в стандарте о формате данных систем государственных закупок.
7.3.3. Структура XML сообщения запроса
7.3.3.1.
push-response
Описание
Корневой тэг ответа на запрос на загрузку данных в брокер.
Атрибуты
Атрибут
Тип
Описание
pushid
Строка
Уникальный идентификатор
запроса, переданный в команде push
status
Строка,
В поле статус возвращается
перечисляемый
результат операции:
тип
queued – данная push-операция
поставлена в очередь на исполнение
(либо как результат текущего
вызова, либо как результат
предыдущего вызова, в процессе
которого произошла потеря
соединения с клиентом)
done – данная push-операция
8
Атрибут
Тип
Описание
успешно выполнена
alreadyDone – данная push-операция
уже была выполнена в результате
предыдущего вызова, в процессе
которого, возможно, произошла
потеря соединения с клиентом
7.3.4. Пример ответа на запрос на загрузку данных
<push-response id=”12345” status="done"/>
7.3.5. Обработка ошибок
В случае возникновения любой ошибки при исполнении pushоперации, все произведенные действия отменяются (обеспечивается
транзакционная целостность данных), и клиент получает текстовое
сообщение об ошибке в стандартном SOAP-поле описания ошибки –
soap:fault. К возможным причинам отклонения push-операции относятся:
 несоответствие XML-формата описания ресурсов (конкурсов,
организаций) стандарту о формате данных систем государственных
закупок. В таком случае клиент получает сообщение об ошибке в XML,
с указанием местоположения.
 недостаточные привилегии клиента для выполнения какой-либо из
операций, указанных в теле push-запроса. Например, запрос может
содержать регистрацию нового конкурса или изменение данных об
организации. Если клиент не обладает правами модератора данных или
не является владельцем конкурса, запрошенные операции не
выполняются, и клиент получает сообщение о недостаточных
привилегиях.
9
Рис 1. Схема исполнения операции push.
7.3.6. Вариант использования команды push
Описание:
При регистрации, загрузке объектов система государственных
закупок передаёт в брокер структурированные описания новых
или обновлённых объектов. Объектами загрузки могут выступать
типы данных, представленные в стандарте описания XMLформатов.
Примерами объектов загрузки являются описания конкурсов,
заказчиков и поставщиков.
Участники:
Информационная система, совместимая с данным стандартом,
Брокер
Предусловия:
В информационной системе создан новый объект или изменен
уже существующий объект
Основной сценарий:
1. Информационная
система
формирует
уникальный
идентификатор для данного запроса (pushid).
2. Информационная система сразу же или по определённому
временному
регламенту
передаёт
интерфейсу
брокера
структурированное описание созданных или изменённых данных
в формате XML.
3. Брокер проверяет, присутствует ли уникальный идентификатор
запроса (комбинация sourceid и pushid) в списке текущих или
выполненных задач брокера. Если присутствует, то переходит к
шагу 5.1, иначе к шагу 5.
10
4. Брокер принимает данные от информационной системы и
формирует новую задачу в списке задач
5. Брокер получает результат выполнения задачи и формирует
ответ информационной системе
6. Брокер отправляет результат выполнения информационной
системе.
Альтернативный сценарий:
5.1. Брокер формирует ответ информационной системе с кодом
результата queued или alreadyDone и переходит к шагу 6.
7.3.
Команда PULL
С помощью операции PULL клиенты могут запрашивать данные у
брокерной подсистемы по определённым критериям (время изменения, тип
данных, рубрика классификатора, и так далее). Для ограничения размера
ответа количество результатов, которые брокер может вернуть в ответе на
один запрос, ограничено. Для получения дополнительных результатов клиент
должен будет повторить запрос, соответствующим образом изменив условия
фильтрации.
Рис 2. Схема запроса pull.
11
7.3.7. Структура запроса
7.3.7.1.
pull
Описание
Корневой тэг запроса на выгрузку данных из брокера.
Атрибуты
Атрибут
sourceid
Описание
Идентификатор
источника,
используемый при авторизации его
в брокере
key
Строка
Пароль, ключ присвоенный
данному
источнику
при
регистрации (*)
*
В данной версии стандарта, в качестве временного решения, пароль
передаётся в открытом виде. Его безопасность обеспечивается
использованием протокола SSL (HTTPS). Данное положение стандарта
должно быть пересмотрено после публикации спецификаций Электронного
государства
Элементы
Элемент
Тип
Строка
date
since
Тип
date (0..1)
Строка (0..1)
versions
Строка (0..1)
uris
Коллекция URI
(0..1)
Коллекция строк
(0..1)
(0..*)
types
classifier
Описание
Элемент определяет интервал дат
Определяет место в
хронологической
последовательности
удовлетворяющих условию фильтра
объектов, с которого следует начать
формирование ответа
Тэг определяет, следует ли
помещать в ответ все версии
объектов, или только последние по
времени, актуальные версии
Позволяет определить список
запрашиваемых объектов
Позволяет ограничить типы
помещаемых в ответ объектов
Позволяет включить в ответ только
объекты, относящиеся к
определенному значению или ветви
классификатора
12
7.3.7.2.
date
Описание
Тэг даты позволяет определить интервал дат. При наличии
элемента date, в ответ будут помещены только данные, дата
изменения или регистрации которых в Брокере попадает в
заданный интервал.
Атрибуты
Атрибут
from
to
datetype
Тип
Описание
Строка даты в формате W3С-
Дата от которой производить
DTF: yyyy-mm-dd[Thh:mm]
выборку данных
Строка даты в формате W3С-
Дата до которой включительно
DTF: yyyy-mm-dd[Thh:mm]
производить выборку данных
Перечислимый тип в виде
Строка с возможными
строки
значениями.
modified – для выборки данных
по дате модификации
published – для выборки данных
7.3.7.3.
since
Описание
Необязательный тэг. Определяет место в хронологической
последовательности
удовлетворяющих
условию
фильтра
объектов, с которого следует начать формирование ответа.
Значением тэга является строка, переданная Брокером в
предыдущем ответе.
7.3.7.4.
versions
Описание
Тэг определяет, следует ли помещать в ответ все
удовлетворяющие критериям фильтрации версии объектов, или
только последние по времени, актуальные версии.
Значение actual означает, что в ответ следует помещать только
последние по времени, актуальные версии объектов.
13
Значение all означает, что в ответ следует включать все
удовлетворяющие критериям фильтрации версии объектов.
Отсутствие в запросе тэга versions соответствует значению actual.
7.3.7.5.
uris
Описание
Коллекция URI запрашиваемых объектов. Этот тэг применяется,
когда в ответ следует включать только определённые объекты.
Элементы
Элемент
uri
7.3.7.6.
Тип
uri (1..*)
Описание
URI объекта, включаемого в ответ
uri
Описание
Каждый тэг uri определяет URI запрашиваемого объекта.
7.3.7.7.
types
Описание
Коллекция типов запрашиваемых объектов. В ответ Брокера
будут включены только объекты перечисленных типов.
Элементы
Элемент
class-uri
Тип
uri (1..*)
Описание
Элемент URI идентификатора
класса объекта
7.3.7.8.
class-uri
Описание
Каждый тэг class-uri определяет тип запрашиваемого объекта.
7.3.7.9.
classifier
Описание
14
Тэг classifier позволяет включить в ответ только объекты,
относящиеся
к
определенному
значению
или
ветви
классификатора
Атрибуты
Атрибут
Тип
Описание
classifier-uri
Строка
URI типа классификатора
value
Строка
Строка значения классификатора, которому
должны соответствовать объекты. Чтобы
включить в фильтр значение классификатора
вместе с подрубриками, следует указать
первые символы кода и добавить символ “*” в
конце строки
7.3.8. Пример запроса на выгрузку данных
<pull sourceid=”mert_pgz” key=”some_password”>
<date from=”2005-12-31” to=”2006-12-31” datetype=”modified”/>
<since>…</since>
<versions>…</versisons>
<uris>
<uri>....</uri>
<uri>....</uri>
</uris>
<types>
<class-uri>....</class-uri>
<class-uri>....</class-uri>
</types>
<classifier classifier-uri="?" value="?"/>
</pull>
7.3.9. Структура ответа Брокера на запрос poll
7.3.9.1.
pull-response
Описание
Тэг начала ответа на запрос на выгрузку данных из брокера.
Этот тэг включает перечисленные ниже элементы и объекты,
определенные стандартом «Государственные и муниципальные
закупки. Унифицированные форматы данных. Версия 1.0».
Элементы
15
Элемент
eof
lastElement
7.3.9.2.
Тип
Строка (1..1)
Строка (0..1)
Описание
признак конца выборки объектов
Служебный идентификатор
последнего переданного в ответе
объекта
eof
Описание
Значение тэга eof определяет, содержит ли ответ Брокера все
запрошенные объекты, или в базе данных Брокера остались
объекты из-за ограничений на размер ответа. Возможны два
значения тэга: yes и no. Значение yes указывает, что ответ
содержит все объекты, соответствующие условиями фильтра.
Значение no указывает, что в базе данных остались объекты,
соответствующие условиями фильтра. Для получения оставшихся
объектов необходимо повторить запрос с новым значением тэга
since.
7.3.9.3.
lastElement
Описание
Значение тэга содержит внутренний идентификатор последнего
включенного в ответ объекта. Это значение может быть
использовано в тэге since следующего запроса, чтобы
продолжить получение объектов.
Если результат запроса не содержит ни одного объекта, тэг
lastElement не включается в poll-response.
7.3.10.Пример ответа Брокера на запрос poll
<pull-response>
<eof>yes</eof>
<lastElement>…</lastElement>
<Organization>
...
</Organization>
...
</pull-response>
16
7.4.
Обеспечение безопасности передаваемых данных
В данной версии стандарта, в качестве временного решения,
обеспечение авторизации и безопасности передачи данных при
взаимодействии брокера и систем государственных закупок обеспечивается
использованием протокола HTTPS (SSL) с взаимным подтверждением
сертификатов брокером и системой государственных закупок.
Необходимость использование SSL распространяется только на
взаимодействие брокера с системами государственных закупок. Для
потребителей информации из брокера использования SSL и процедур
аутентификации не требуется.
В настоящей версии стандарта, в качестве временного решения,
авторизация сторон и безопасность передачи данных при взаимодействии
Брокера и информационных систем – источников или модераторов данных
обеспечивается использованием протокола HTTPS (SSL) с взаимным
подтверждением сертификатов Брокером и информационной системой. При
взаимодействии Брокера и информационных систем – источников или
модераторов данных протокол HTTPS (SSL) должен использоваться как для
операций push, так и для операций poll.
Для информационных систем – потребителей информации из брокера
использование протокола HTTPS (SSL) и процедур аутентификации является
опциональным. Решение об использовании или не использовании HTTPS
(SSL) принимается разработчиками или администраторами ПД-систем
самостоятельно.
17
5. ПРИЛОЖЕНИЕ. Описание WSDL
Формальное WSDL описание веб-службы Брокера временно
исключено из текста документа. Оно будет включено в текст документа
после проведения первоначальных обсуждений и стабилизации текста
документа. Дополнительно, актуальное описание веб-службы будет
опубликовано на сайте www.pgz.economy.gov.ru.
18