V1600013244 Утратил силу

Об утверждении Правил интеграции шлюза "электронного правительства", платежного шлюза "электронного правительства" с информационными системами

Министерство по инвестициям и развитию Республики Казахстан (реорганизовано Указом Президента РК от 26.12.2018 г. № 806 путем его преобразования в Министерству индустрии и инфраструктурного развития Республики Казахстан)

Анализ Ссылки История PDF DOCX

Принят

28.01.2016

Изменён

29.03.2018

Форма

Правила, Приказ

Рег. номер

99837

Юридическая сила

Акт Министерства или ведомства

Опубликован

14.03.2016

Об утверждении Правил интеграции шлюза «электронного правительства», платежного шлюза «электронного правительства» с информационными системами

В соответствии с подпунктом 13) статьи 7 Закона Республики Казахстан от 24 ноября 2015 года «Об информатизации» ПРИКАЗЫВАЮ:

1. Утвердить прилагаемые Правила интеграции шлюза «электронного правительства», платежного шлюза «электронного правительства с информационными системами.

2. Признать утратившим силу:

1) приказ Председателя Агентства Республики Казахстан по информатизации и связи от 26 августа 2009 года № 365 «Об утверждении Правил эксплуатации и взаимодействия электронных информационных ресурсов и информационных систем, а также информационно-коммуникационных сетей государственных органов» (зарегистрированный в Реестре государственной регистрации нормативных правовых актов за № 5783);

2) приказ исполняющего обязанности Министра по инвестициям и развитию Республики Казахстан от 16 октября 2015 года № 991 «О внесении изменений в приказ Председателя Агентства Республики Казахстан по информатизации и связи от 26 августа 2009 года № 365 «Об утверждении Правил эксплуатации и взаимодействия электронных информационных ресурсов и информационных систем, а также информационно-коммуникационных сетей государственных органов» (зарегистрированный в Реестре государственной регистрации нормативных правовых актов за № 12324, опубликованный 15 декабря 2015 года в информационно-правовой системе «Әділет»).

3. Комитету связи, информатизации и информации Министерства по инвестициям и развитию Республики Казахстан (Қазанғап Т.Б.) обеспечить:

1) государственную регистрацию настоящего приказа в Министерстве юстиции Республики Казахстан;

2) направление копии настоящего приказа в печатном и электронном виде на официальное опубликование в периодические печатные издания и информационно-правовую систему «Әділет» в течение десяти календарных дней после его государственной регистрации в Министерстве юстиции Республики Казахстан, а также в Республиканский центр правовой информации в течение десяти календарных дней со дня получения зарегистрированного приказа для включения в эталонный контрольный банк нормативных правовых актов Республики Казахстан;

3) размещение настоящего приказа на интернет-ресурсе Министерства по инвестициям и развитию Республики Казахстан и на интранет-портале государственных органов;

4) в течение десяти рабочих дней после государственной регистрации настоящего приказа в Министерстве юстиции Республики Казахстан представление в Юридический департамент Министерства по инвестициям и развитию Республики Казахстан сведений об исполнении мероприятий, предусмотренных подпунктами 1), 2) и 3) пункта 3 настоящего приказа.

4. Контроль за исполнением настоящего приказа возложить на курирующего вице-министра по инвестициям и развитию Республики Казахстан.

5. Настоящий приказ вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования.

Исполняющий обязанности министра по инвестициям и развитию Республики Казахстан

Ж. Касымбек

Утверждены

приказом исполняющего обязанности Министра по инвестициям и развитию Республики Казахстан

от 28 января 2016 года

№ 104

Правила интеграции шлюза электронного правительства, платежного шлюза «электронного правительства» с информационными системами

1. Общие положения

1. Настоящие Правила интеграции шлюза «электронного правительства», платежного шлюза «электронного правительства» с информационными системами (далее – Правила) разработаны в соответствии с подпунктом 13) статьи 7 Закона Республики Казахстан от 24 ноября 2015 года «Об информатизации» (далее – Закон) и определяют порядок интеграции шлюза «электронного правительства», платежного шлюза «электронного правительства c информационными системами.

2. В настоящих Правилах используются следующие основные понятия и сокращения:

1) уполномоченный орган в сфере информатизации (далее – уполномоченный орган) – центральный исполнительный орган, осуществляющий руководство и межотраслевую координацию в сфере информатизации и «электронного правительства»;

2) информационная система (далее – ИС) – организационно-упорядоченная совокупность информационно-коммуникационных технологий, обслуживающего персонала и технической документации, реализующих определенные технологические действия посредством информационного взаимодействия и предназначенных для решения конкретных функциональных задач;

3) администратор информационной системы – персонал, осуществляющий обслуживание системы, в обязанности которого входит первичная установка системы, повторная установка после ликвидации аварийных ситуаций, обслуживание системы, включая техническое обеспечение выхода в Интернет, системного программного обеспечения ИС;

4) интеграция информационных систем – мероприятия по организации и обеспечению информационного взаимодействия между двумя и более информационными системами на основании используемых в Республике Казахстан стандартных протоколов передачи данных;

5) техническая реализация интеграции информационных систем –

5) техническая реализация интеграции информационных систем – комплекс технических работ, проводимых для обеспечения интеграции участников информационного обмена;

6) сервис информационных систем (далее – сервис) – сервис, состоящий из набора операций, используемого для спецификации услуг, предоставляемых информационной системой;

7) бизнес-данные информационной системы – данные взаимодействия Пользователя сервиса и Владельца сервиса, входящие в состав сообщений формата ШЭП как блок, не проверяемый на стороне ШЭП;

8) безопасность веб-сервисов (Web Service Security) (далее – WS Security) – стандарт применения функций безопасности при обмене сообщениями между веб-сервисами SOAP;

9) журнал логирования – файлы, содержащие информацию о работе системы, используемую для мониторинга ее работы и выявления причин, в случае возникновения сбоя;

10) единая транспортная среда государственных органов (далее – ЕТС ГО) - сеть телекоммуникаций, входящая в информационно-коммуникационную инфраструктуру «электронного правительства» и предназначенная для обеспечения взаимодействия локальных (за исключением локальных сетей, имеющих доступ к Интернету), ведомственных и корпоративных сетей телекоммуникаций государственных органов, их подведомственных организаций и органов местного самоуправления, а также иных субъектов информатизации, определенных уполномоченным органом, с соблюдением требуемого уровня информационной безопасности;

11) простой протокол доступа к объектам (Simple Object Access Protocol) (далее – SOAP) – протокол, основанный на XML для передачи сообщений при интеграции ИС;

12) расширяемый язык разметки (eXtensible Markup Language) (далее – XML) – расширяемый язык разметки, используемый для хранения и передачи данных в структурированном и машиночитаемом формате;

13) транспортная подпись – ЭЦП, используемая для обеспечения целостности и авторства передаваемых сообщений при информационном взаимодействии ИС с применением спецификации WS Security;

14) владелец сервиса – владелец ИС, реализующий сервис;

15) пользователь сервиса – владелец ИС, инициирующий запрос на предоставление сервиса;

16) внешняя информационная система – информационная система, находящаяся в Интернете, негосударственная ИС;

17) внешний шлюз «электронного правительства» (далее – ВШЭП) – подсистема шлюза «электронного правительства», предназначенная для обеспечения взаимодействия информационных систем, находящихся в ЕТС ГО, с информационными системами, находящимися вне ЕТС ГО;

18) платежный шлюз «электронного правительства» (далее – ПШЭП) - информационная система, автоматизирующая процессы передачи информации о проведении платежей в рамках оказания возмездных услуг, оказываемых в электронной форме;

19) шлюз «электронного правительства» (далее – ШЭП) – информационная система, предназначенная для интеграции государственных и негосударственных ИС в рамках «электронного правительства»;

20) электронное сообщение – электронный документ в формате XML, предназначенный для обмена информацией между информационными системами;

21) электронная цифровая подпись (далее – ЭЦП) – набор электронных цифровых символов, созданный средствами электронной цифровой подписи и подтверждающий достоверность электронного документа, его принадлежность и неизменность содержания;

22) администратор шлюза «электронного правительства» – персонал, осуществляющий обслуживание работы ШЭП, ПШЭП и ВШЭП, в обязанности которого входит управление сервисами, мониторинг и обеспечение бесперебойной работы ШЭП, ПШЭП и ВШЭП.

3. Интеграции со шлюзом «электронного правительства», платежным шлюзом «электронного правительства» не подлежат ИС, которые содержат сведения, составляющие государственные секреты Республики Казахстан и служебную информацию ограниченного распространения.

4. Сведения из ИС, используемые в процессе интеграции шлюза «электронного правительства», платежного шлюза «электронного правительства» равнозначны соответствующим сведениям из документов на бумажном носителе.

2. Порядок интеграции шлюза «электронного правительства», платежного шлюза «электронного правительства» с информационными системами

5. Мероприятия по организации интеграции ИС владельцев сервиса с ШЭП осуществляются в следующем порядке:

1) техническая реализация и тестирование интеграции ИС владельца сервиса с ШЭП осуществляется в порядке, указанном в пункте 8 настоящих Правил;

2) по завершению технической реализации интеграции и совместного тестирования ИС владельца сервиса с ШЭП, владелец сервиса направляет в адрес уполномоченного органа заявку на публикацию сервиса на ШЭП (далее – Заявка) по форме согласно приложению 1 к настоящим Правилам;

3) владелец сервиса и уполномоченный орган вводят в эксплуатацию взаимодействие ИС владельца сервиса с ШЭП на основании совместного решения (протокол, акт) владельца сервиса и уполномоченного органа о вводе в эксплуатацию ;

4) уполномоченный орган осуществляет электронную регистрацию сведений о подключенном сервисе в журнале регистрации взаимодействия ИС по форме согласно приложению 2 к настоящим Правилам.

6. Мероприятия по организации интеграции ИС пользователей сервиса с ШЭП проводятся в следующем порядке:

1) пользователь сервиса получает от владельца сервиса разрешение в письменном виде на подключение к ИС;

2) пользователь сервиса направляет в уполномоченный орган заявку на интеграцию ИС с ШЭП для использования опубликованного на ШЭП сервиса (далее – Заявка на интеграцию) по форме согласно приложению 3 к настоящим Правилам с приложением разрешения владельца сервиса на подключение к его ИС;

3) техническая реализация и тестирование интеграции ИС пользователя сервиса с ШЭП осуществляется в порядке, указанном в пункте 8 настоящих Правил;

4) в случае положительного результата технической реализации интеграции ИС пользователя сервиса с ШЭП, на основании совместного решения (протокол, акт), владелец сервиса, пользователь сервиса и уполномоченный орган вводят в эксплуатацию взаимодействие;

5) уполномоченный орган осуществляет электронную регистрацию сведений об ИС пользователя сервиса в журнале регистрации взаимодействия ИС по форме согласно приложению 2 к настоящим Правилам.

7. Техническая реализация интеграции ИС пользователя сервиса с ШЭП заключается в обеспечении информационного взаимодействия ИС владельца сервиса и ИС пользователя сервиса посредством ШЭП.

Для обеспечения взаимодействия ИС владельца сервиса с ИС пользователя сервиса на стороне ШЭП производится регистрация сервиса в реестре сервисов ШЭП с указанием ИС владельца сервиса, ИС пользователей сервиса и параметров взаимодействия.

Техническая реализация интеграции участников взаимодействия с ШЭП осуществляется согласно форматам данных сообщений, указанным в приложении 4 к настоящим Правилам.

В процессе технической реализации интеграции ИС с ШЭП принимают участие:

1) администратор ШЭП (со стороны уполномоченного органа);

2) разработчики сервиса (со стороны владельца сервиса);

3) разработчики ИС пользователя сервиса (со стороны пользователя сервиса).

8. Основанием для согласования технической реализации и совместного тестирования интеграции ИС с ШЭП является согласование уполномоченным органом заявки владельца сервиса или пользователя сервиса на интеграцию ИС с ШЭП в следующем порядке:

1) пользователь сервиса разрабатывает технический документ на интеграцию ИС с ШЭП с учетом форматов данных сообщений указанных в приложении 4 к настоящим Правилам. Технический документ согласовывается и утверждается руководителями, ответственными за информационное взаимодействие;

2) участники взаимодействия вносят изменения в ИС для интеграции с ШЭП в сроки согласованные участниками взаимодействия;

3) участники взаимодействия предоставляют администратору ШЭП заявку на публикацию сервиса в тестовом режиме по форме согласно приложению 5 к настоящим Правилам;

4) для начала тестирования работы сервисов администратор ШЭП регистрирует в реестре сервисов ШЭП данные о сервисах и их пользователях;

5) совместно с разработчиками сервиса, разработчиками ИС пользователя сервиса и администратором ШЭП проводится тестирование интеграции ИС с ШЭП. В случае успешной интеграции ИС с ШЭП составляется документ (протокол) об успешном тестировании интеграции.

9. Со стороны ШЭП основанием успешной интеграции с ИС является успешная передача сообщений (для асинхронного сервиса - получение отправителем уникального идентификатора сообщения, для синхронного - получение ответного сообщения) между участниками взаимодействия, которая фиксируется в журнале логирования, по форме согласно приложению 6 к настоящим Правилам.

10. Со стороны участников взаимодействия (владельца сервиса и пользователя сервиса) основанием успешной интеграции с ШЭП является успешное выполнение условий взаимодействия и обработка данных самими участниками взаимодействия.

11. Интеграция ШЭП с внешними ИС осуществляется через ВШЭП.

12. В случае если осуществляется обмен информации о деталях платежей и иной информации в части платежей, ИС интегрируются с ПШЭП, посредством ШЭП.

13. Факты получения/отправки электронных сообщений фиксируются в журналах логирования.

14. ШЭП, ПШЭП и ВШЭП работают в круглосуточном режиме, принимают сообщения от ИС двадцать четыре часа в сутки, 365 дней в году за исключением технологических перерывов.

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

16. Технологические перерывы в работе ИС заранее оговариваются и согласовываются администраторами ИС и администратором ШЭП за три дня до начала их проведения (по умолчанию технологические перерывы приходятся на ночное время с 22:00 до 6.00, а также в выходные и праздничные дни).

17. В случае технической необходимости администратор ШЭП и/или администратор ИС владельца сервиса производит перезагрузку системы, о чем уведомляют администраторов других ИС в виде телефонограммы или по электронной почте с указанием времени отсутствия доступа.

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

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

20. Организационные мероприятия регламентируют доступ персонала к серверам, активному сетевому оборудованию, системе электропитания серверов.

21. Защита информации при информационном обмене обеспечивается:

1) использованием механизмов контроля целостности и достоверности информации, в том числе подтверждением авторства, подписанных XML сообщений;

2) авторизацией ИС отправителей сообщения по логину и паролю, которые выдаются администратором ШЭП;

3) шифрованием всей передаваемой информации в зависимости от критичности обрабатываемой информации;

4) журналированием всех событий;

5) мероприятиями технического и организационного характера по защите информации в соответствии с Законом.

22. Подтверждением авторства сообщений является положительный результат проверки соответствия транспортной подписи регистрационным свидетельством ЭЦП владельца ИС, направившего сообщение.

23. Транспортная подпись не содержит метку времени. Наличие метки времени в бизнес-данных ИС регулируется в соответствии с согласованным техническим документом на интеграцию. ШЭП не проводит проверку на наличие метки времени в бизнес-данных ИС.

24. Метка времени в бизнес-данных ИС необходима для подтверждения действительности отправленных данных в момент отправления.

25. Проверка транспортной подписи в ЕТС ГО выполняется на ШЭП. Проверка транспортной подписи при взаимодействии с внешними ИС выполняется на ВШЭП. Транспортная подпись ШЭП и ВШЭП не содержит метку времени.

26. При вызове сервиса на ШЭП использование транспортной подписи осуществляется:

1) с использованием транспортной подписи ШЭП и осуществлением ее проверки, согласно сценарию использования транспортной подписи, указанному в приложении 8 к настоящим Правилам;

2) с использованием транспортных подписей ШЭП и вызывающей стороны, и осуществлением их проверки согласно сценарию использования транспортной подписи, указанному в приложении 8 к настоящим Правилам;

3) с использованием транспортных подписей ШЭП и вызывающей стороны, с использованием метода шифрования сообщений и осуществлением проверки транспортных подписей согласно сценарию, согласно приложению 8 к настоящим Правилам.

27. Проверка транспортной подписи в ЕТС ГО на ШЭП состоит из процедур:

1) проверка принадлежности ЭЦП отправителю сообщения;

2) проверка действительности ЭЦП.

28. При информационном взаимодействии все электронные сообщения должны быть подписаны ЭЦП владельцев ИС, за исключением информационных взаимодействий ИС, реализованных до вступления в силу настоящих Правил.

29. При применении ЭЦП при информационном взаимодействии ИС необходимо руководствоваться Законом Республики Казахстан «Об электронном документе и электронной цифровой подписи».

30. Полноту, подлинность, достоверность и не искаженность передаваемых данных обеспечивает владелец ИС государственного органа или внешней ИС.

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

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

33. В случае возникновения споров между участниками взаимодействия, создается специальная комиссия. Если участники взаимодействия не придут к взаимному согласию, споры и разногласия между ними разрешаются в порядке, установленном законодательством Республики Казахстан.

34. Владелец сервиса уведомляет уполномоченный орган и всех пользователей сервиса за три календарных дня в случае временного отключения сервиса ИС (модификации сервиса, модификации ИС, предоставляющей доступ к сервису) или не позднее месяца в случае отключения сервиса в связи с прекращением работы.

35. Владельцы ИС государственных органов или внешней ИС и ШЭП определяют ответственных лиц, которые обеспечивают информационную безопасность и постоянную готовность программных и технических средств.

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

Приложение 1

к Правилам интеграции шлюза

«электронного правительства»,

платежного шлюза

«электронного правительства»

с информационными системами

Форма

Заявка на публикацию сервиса на шлюз «электронного правительства»

1. Описание сервисов

№

Элемент

Описание

Правила заполнения

Пример

1.Сведения об организации-владельце ИС сервиса

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

Организация, осуществляющая права собственности на информационную систему, реализующую электронный сервис

Не допускаются сокращения в названии, а также использование аббревиатур.

Министерство юстиции Республики Казахстан

Краткое наименование

Краткое наименование организации

Необходимо указывать максимально короткое значимое наименование. Рекомендуется - аббревиатура.

МЮ РК

Идентификатор в сертификатах Национальный удостоверяющий центр Республики Казахстан (Бизнес идентификационный номер)

Бизнес идентификационный номер

214452507

2.Контактные данные владельцев и разработчиков сервиса

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

Оператор информационной системы, предоставляющей данный электронный сервис.

Не допускаются сокращения в названии, а также использование аббревиатур.

Акционерное общество «Национальные информационные технологии»

Краткое наименование

Краткое наименование оператора

Необходимо указывать максимально короткое значимое наименование. Рекомендуется - аббревиатура.

АО «НИТ»

Эксплуатационное подразделение

Подразделение Оператора, ответственное за эксплуатацию электронного сервиса

Не допускаются сокращения в названии, а также использование аббревиатур.

Проектный офис

Руководитель эксплуатационного подразделения

ФИО, должность, контактный телефон, электронная почта

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

Должностное лицо, ответственное за эксплуатацию

ФИО, должность, контактный телефон, электронная почта

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

Контактные данные разработчиков

Наименование компании, Контактное лицо, контактный телефон, электронная почта

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

3.Сведения об информационной системе, предоставляющей электронный сервис

Краткое наименование ИС

Необходимо указать максимально короткое наименование. Рекомендуется аббревиатура

Государственная база данных «Физические лица»

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

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

ГБД «ФЛ»

Стадия использовани

Стадия использования

Выбрать из нижеперечисленного:

электронного сервиса.

1. Разработка

2. Тестовая эксплуатация

3. Опытная эксплуатация

4. Промышленная эксплуатация

Режим доступности

Режим гарантированной доступности электронного сервиса.

ЧЧ/ДД (Стандартный режим: 24/365)

8/252, 16/252, и т.д.

4.Сведения о документах

Основание на публикацию сервиса на ШЭП

Ссылка на документ

Приложение 1

Специфические требование к програмному обеспечению на сервис

Ссылка на документ

Приложение 2- СТПО на сервис.doc

Описание форматов сообщений

Ссылка на документ (файл) с описанием WSDL и XSD

Приложение 3 - «wsdl.rar»

5.Сведения о сервисе

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

Полное наименование электронного сервиса

Не допускаются сокращения в названии, а также использование аббревиатур

Сервис «Сервис по проверке статуса Заявителя юридического лица (основные сведения о юридическом лице, адресные сведения)»

Описание

Развернутое описание назначения электронного сервиса

электронного сервиса.

Необходимо указывать исчерпывающее описание назначения электронного сервиса.

1. Опытная эксплуатация

2. Промышленная эксплуатация

Сервис услуги предоставление государственную базу данных «физические лица» сведений ПЭП о статусе пользователе-юридического лица и его регистрационных сведений приналичии статуса

Режим доступности

Режим гарантированной доступности электронного сервиса.

ЧЧ/ДД (Стандартный режим: 24/365)

8/252, 16/252, и т.д.

4.Сведения о документах

Основание на публикацию сервиса на ШЭП

Ссылка на документ

Приложение 1

Описание форматов сообщений

Ссылка на документ (файл) с описанием WSDL и XSD

Приложение 3 - «wsdl.rar»

5.Сведения о сервисе

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

Полное наименование электронного сервиса

Не допускаются сокращения в названии, а также использование аббревиатур

Описание

Развернутое описание назначения электронного сервиса

Необходимо указывать исчерпывающее описание назначения электронного сервиса.

Ключ сервиса

Условное наименование сервиса

1) Заполнять латинскими буквами.

2) В названии надо включить краткое название ИС и краткое название сервиса

GbdulFullInfo

Режим взаимодействия сервиса

Выбрать из списка, руководствуясь примечанием

Необходимо выбрать «Синхронный», «Асинхронный» либо «Синхронный/Асинхронный» режим.

Синхронный - запрос с быстрым ответом электронного сервиса. Он возвращает результат исполнения запроса непосредственно в ответе на запрос.

Асинхронный - запрос с отложенным ответом. В данном режиме сервис «Запрашивает исполнение», в результате возвращает № созданной задачи. Далее потребитель сервиса в соответствии с указанным в пункте 5 вкладки «Реестр прав доступа» таймаутом запрашивает результат, в следствии чего он будет представлен (если уже готов) либо появится сообщение об ошибке (если результат ещё не готов). В случае отсутствия решения потребитель повторно запрашивает результат не раньше чем через рекомендуемый интервал.

Асинхронный

Адрес описания

Ссылка на WSDL документ, описывающий электронный сервис

http://10.10.10.10:7788/ WS-Bankrot /BankrotWebServiceSoapHttpPort?WSDL

Признак наличия маршрутизации сообщений

Используется если по одному сервису есть несколько адресов доставки (смотреть таблицу Маршруты сервиса)

Признак наличия маршрутизации сообщений

0-нет

1-да

Адрес сервиса

Не заполняется при наличии маршрутизации сообщения. Адрес электронного сервиса у Поставщика.

http://10.10.10.10:7788/ WS-Bankrot /BankrotWebServiceSoapHttpPort?WSDL

Режим отправки сообщений

Только для асинхронных сервисов. Выбрать из списка, руководствуясь примечанием.

PUSH или PULL

PUSH

Необходимость получения уведомления Информационной системой-Отправителей сообщений об изменении статусов сообщений от ШЭП

Только для асинхронных сервисов. Выбрать из списка, руководствуясь примечанием.

0 - не требуется,

1 - требуется

Необходимость получения дополнительного уведомления о доставке от ШЭП

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

0 - не требуется,

1 - требуется

6.Тестовые данные

Адреса тестового сервиса

Адреса тестового сервиса (в интернете, ЕТС)

Тестовые запросы и ответы

Ссылки на данные

2. Пользователи сервиса

№

Порядковый номер пользователя (пользователей может быть несколько)

Таймаут тротлинга

Только для сервисов с асинхронным способом вызова. Таймаут тротлинга

Заполнять с с указанием единиц измерения.

45 секунд

Количество запросов

Только для сервисов с асинхронным способом вызова. Количество запросов тротлинга

Целое число

Количество повторных запросов

Только для сервисов с асинхронным способом вызова. Количество повторных запросов

Целое число

Таймаут при асинхронном вызове

Только для сервисов с асинхронным способом вызова. Таймаут при асинхронном вызове

Заполнять с указанием единиц измерения.

40 секунд

Максимальное количество ошибок

Максимальное количество ошибок, после которых доставка будет выключена

Целое число

Максимальный интервал времени

Интервал времени, в секундах, в который должно произойти максимальное количество ошибок для выключения доставки

Заполнять с указанием единиц измерения.

1 минута

Безопасность при вызове сервиса

Выбрать из списка, руководствуясь примечанием

0 - без дополнительной безопасности;

1 - с использованием транспортной подписи ШЭП

2 - с использованием транспортной подписи ШЭП и транспортной подписи вызывающей стороны

5. Описание форматов сообщений сервиса

№

Элемент

Описание

Правила заполнения

Пример

Сообщение

Сообщение - запрос или Ответное сообщение

Обязательное поле

Запрос

Наименование параметра

Да/Нет

Обязательное поле

ИИН

Формат параметра

Да/Нет

Обязательное поле

Строковый

Поле

Название параметра в XSD схеме

Обязательное поле. Заполнять латинскими буквами

IIN

Обязательность

Обязательность заполнения параметра сообщения

Обязательное поле

Да

Примечание

Не обязательное поле

Приложение 2

к Правилам интеграции шлюза

«электронного правительства»,

платежного шлюза

«электронного правительства»

с информационными системами

Форма

Журнал регистрации взаимодействий ИС

№

Информация о сервисе

Пользователь сервиса

Основание публикации сервиса

Основание подключение пользова-теля к сервису

Организация Владелец сервиса

Информационная система

Сервис

Описание

Организация Владелец ИС

Информационная система

Приложение 3

к Правилам интеграции шлюза

«электронного правительства»,

платежного шлюза

«электронного правительства»

с информационными системами

Форма

Заявка на интеграцию информационной системы со шлюзом «электронного правительства» для использования опубликованного на шлюзе «электронного правительства» сервиса

№

Элемент

Описание

Правила заполнения

1.Сведения об организации-владельце сервиса

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

Организация, осуществляющая права собственности на информационную систему, реализующую электронный сервис.

Не допускаются сокращения в названии, а также использование аббревиатур.

Краткое наименование

Краткое наименование организации

Необходимо указывать максимально короткое значимое наименование. Рекомендуется - аббревиатура.

Идентификатор в сертификатах НУЦ РК (БИН)

БИН организации

Заполнять цифрами

2.Сведения об информационной системе, предоставляющей сервис

Краткое наименование ИС

Необходимо указать максимально короткое наименование. Рекомендуется аббревиатура

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

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

Не допускаются сокращения в названии, а также использование аббревиатур.

Адрес Информационной системы

URL адрес доставки Ответных сообщений от сервиса Пользователю

3.Сведения о сервисе

Сведения об организации-владельце

Наименование информационной системы, предоставляющей электронный сервис

Не допускаются сокращения в названии, а также использование аббревиатур.

Краткое наименование ИС

Необходимо указать максимально короткое наименование. Рекомендуется аббревиатура

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

Полное наименование электронного сервиса

Описание

Развернутое описание назначения электронного сервиса

Необходимо указывать исчерпывающее описание назначения электронного сервиса.

Приложение 4

к Правилам интеграции шлюза

«электронного правительства»,

платежного шлюза

«электронного правительства»

с информационными системами

Форма

Форматы данных сообщений

1. Описание сообщений асинхронного канала

1.1. Интерфейс сервиса на ШЭП:

Метод для отправки сообщений на асинхронный канал ШЭП (SendMessage):

Запрос на предоставление Сервиса (SendMessageRequest) содержит следующие поля: Формат данных SendMessageRequest

Поле

Тип

Обязательность

Описание

request

AsyncSendMessagerequest

Да

messageInfo

AsyncMessageInfo

Дa

Мета данные сообщения

messageId

xsd: string

Нет

Идентификатор сообщения в системе получателя (заполняет система получателя запроса (система отрабатывающая сообщение)

correlationId

xsd: string

Нет

Идентификатор цепочки сообщения в системе получателя запроса (если сообщения существует в рамках цепочки сообщений системы ( отправителя) система отрабатывающая сообщение)

serviceId

xsd: string

Да

Идентификатор сервиса

messageType

xsd: string

Да

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

REQUEST - первое сообщения взаимодействия

routeId

xsd: string

Нет

Идентификатор маршрута сообщения (если есть необходимость в дополнительной маршрутизации, идентификатор по реестру, заполняется системой отправителя)

messageDate

xsd: dateTime

Да

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

sessionId

guid

Да

Идентификатор сессии ШЭП. Заполняется на ШЭП, отправителю заполнять не надо.

sender

SenderInfo

Да

Объект информация об отправителе (заполняется отправителем)

senderId

xsd: string

Да

Идентификатор отправителя (системы отправителя)

password

xsd: string

Нет

Пароль отправителя

properties

property

Нет

Массив свойств, можно добавить дополнительные свойства запроса (по согласованию с ШЭП и системой получателя

key

xsd: int

Ключ свойства

value

xsd: int

Нет

Значение свойства

messageData

messagedata

Да

Объект передачи данных

data

xsd: Anytype

Нет

Объект данные сообщения (формат определяется системой получателя сообщения)

Ответ ШЭП на сообщение (sendMessageResponse) представляет собой массив элементов со следующими полями: Формат данных SendMessageResponse

Поле

Тип

Обязанность

Описание

response

AsyncSendMessagerequest

Да

Ответ

messageId

xsd: string

Да

Идентификатор сообщения

correlationId

xsd: string

Да

Идентификатор цепочки сообщения

responseDate

xsd: dateTime

Да

Дата ответа

sessionId

Guidа

Нет

Идентификатор сессии ШЭП.

Ответ об ошибке (SendMessagefault) представляет собой массив элементов со следующими полями: Формат данных SendMessagefault

Поле

Тип

Обязанность

Описание

ErrorInfo

Информация об ошибке

errorCode

xsd: string

Да

Код ошибки

errorData

xsd: string

Да

Дополнительное описание ошибки

errorDate

xsd: dateTime

Да

Дата ошибки

subError

ErrorInfo

Нет

Дочерняя ошибка

sessionId

guid

Нет

Идентификатор сессии в которой произошла ошибка

Метод отправки уведомления на ШЭП о доставке или не доставке сообщения (SendDeliveryNotification):

Запрос на уведомление представляет собой массив элементов со следующими полями (sendDeliveryNotificationRequest): Формат данных SendDeliveryNotificationRequest

Поле

Тип

Обязанность

Описание

request

Async SendDeliveryNotificationRequest

Да

Запрос

notification

DeliveryNotification

Да

Уведомления о статусе доставки сообщения

messageId

xsd: string

Да

Идентификатор сообщения

serviceid

xsd: string

Да

Идентификатор сервиса

notificationDate

xsd: dateTime

Да

Дата создания уведомления

deliveryStatus

deliveryStatusInfo

Да

Статус доставки (приема сообщения)

receiveStatus

xsd: string

Да

Статус доставки сообщения:

MESSAGE_NOT_ACCTEPTED – сообщения не принято

MESSAGE_ACCEPTED – сообщения принято

statusDate

xsd: dateTime

Да

Дата изменения статуса

resendMessage

xsd: string

Да

Повторное сообщение

error

ErrorInfo

Нет

Информация об ошибке

errorCode

xsd: string

Да

Код ошибки

errorData

xsd: string

Нет

Дополнительное описание ошибки

errorDate

xsd: dateTime

Да

Дата ошибки

subError

ErrorInfo

Нет

Дочерняя ошибка

sessionId

guid

Нет

Идентификатор сессии в которой произошла ошибка

requestDate

xsd: dateTime

Да

Дата запроса

sender

SenderInfo

Нет

Отправитель

senderId

xsd: string

Да

Идентификатор отправителя

password

xsd: string

Нет

Пароль отправителя

Ответ на уведомление (sendDeliveryNotificationResponse) представляет собой массив со следующими полями: Формат данных SendDeliveryNotificationResponse

Поле

Тип

Обязанность

Описание

Response

Async SendDeliveryNotificationResponse

Ответ

notificationId

xsd: string

Да

Идентификатор сообщения

responseDate

xsd: dateTime

Да

Дата ответа

sessionId

guid

Нет

Идентификатор сессии ШЭП

Ответ об ошибке (SendMessageFault) представляет собой массив элементов со следующими полями: Формат данных SendMessageFault .

Поле

Тип

Обязанность

Описание

ErrorInfo

Информация об ошибке

errorCode

xsd: string

Да

Код ошибки

errorData

xsd: string

Да

Дополнительное описание ошибки

errorDate

xsd: dateTime

Да

Дата ошибки

subError

ErrorInfo

Нет

Дочерняя ошибка

sessionId

guid

Нет

Идентификатор сессии в которой произошла ошибка

Метод получения статуса сообщения с ШЭП (GetMessageStatus)

Запрос на статус сообщения (GetMessageStatusRequest) представляет собой массив элементов со следующими полями: Формат данных GetMessageStatusRequest

Поле

Тип

Обязанность

Описание

request

AsyncGetmessagestatus

Да

Запрос

messageId

xsd: string

Да

Идентификатор сообщения

requestDate

xsd: dateTime

Да

Дата запроса

sender

senderinfo

Да

Объект информация об отправителе (заполняется отправителем)

senderId

xsd: string

Да

Идентификатор отправителя (системы отправителя)

password

xsd: string

Нет

Пароль отправителя

properties

property

Нет

Массив свойств запроса

key

xsd: int

Ключ свойства

value

xsd: int

Нет

Значение свойства

В ответе на запрос на статус (getMessageStatusResponse) должна быть возвращена структура следующего вида: Формат данных GetMessageStatusResponse

Поле

Тип

Обязанность

Описание

response

Async GetmessagestatusResponse

Ответ

messageState

Да

Состояние сообщения

responseDate

xsd: dateTime

Да

Дата ответа

sessionId

xsd: string

Нет

Идентификатор сессии на ШЭП

status

MessagestatusInfo

Объект «Информация о статусе»

statusсode

xsd: int

Да

Код статуса сообщения

statusmessage

xsd: string

Да

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

statusDate

xsd: dateTime

Да

Дата изменения статуса

В случае возникновении ошибки в Системе, передается сообщение об ошибке (SendMessageFault), которая представляет собой массив элементов со следующими полями: Формат данных SendMessageFault

Поле

Тип

Обязанность

Описание

ErrorInfo

Информация об ошибке

errorCode

xsd: string

Да

Код ошибки

errorData

xsd: string

Да

Дополнительное описание ошибки

errorDate

xsd: dateTime

Да

Дата ошибки

subError

ErrorInfo

Нет

Дочерняя ошибка

sessionId

guid

Нет

Идентификатор сессии в которой произошла ошибка

Метод выборки сообщений с ШЭП (GetMessages) осуществляется по параметрам:

идентификатору сообщения + получателю (только для запросившего)+идентификатору сервиса;

идентификатору цепочки сообщений + получателю (только для запросившего) + идентификатору сервиса;

получателю (только для запросившего) + идентификатору сервиса.

Параметр GetMessagesRequest.

Запрос содержит следующие поля: Формат данных GetMessageRequest.

Поле

Тип

Обязанность

Описание

request

Async GetmessagesRequest

Да

Мета данные запроса

messageId

xsd: string

Нет

Идентификатор сообщения

correlationId

xsd: string

Нет

Идентификатор цепочки сообщения

requestdate

xsd: dateTime

Нет

Дата запроса

serviceId

xsd: string

Да

Идентификатор сервиса

sender

Senderinfo

Нет

Объект информация об отправителе (заполняется отправителем)

senderId

xsd: string

Идентификатор отправителя (системы отправителя)

password

xsd: string

Пароль отправителя

amount

xsd: int

Нет

Максимальное кол-во сообщений в выборке.

Если данное поле отсутствует в запросе или равно 0, то будет принято настроенное на ШЭП значение

properties

Property

Да

Массив свойств, можно добавить дополнительные свойства запроса (по согласованию с ШЭП и системой получателя

key

xsd: string

Да

Ключ свойства

value

xsd: string

Да

Значение свойства

Ответ getMessagesResponse со следующими полями: Формат данных GetMessageResponse

Поле

Тип

Обязанность

Описание

response

Async GetmessageResponse

Да

Ответ

responseDate

xsd: dateTime

Да

Дата ответа

sessionId

xsd: string

Да

Идентификатор сессии на ШЭП

messages

Asynmessage

Нет

messageInfo

Asynmessageinfo

Да

Мета данные сообщения

messageId

xsd: string

Нет

Идентификатор сообщения

correlationId

xsd: string

Да

Идентификатор цепочки

serviceId

xsd: string

Да

Идентификатор сервиса

messageType

xsd: string

Да

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

REQUEST - первое сообщения взаимодействия

routeId

xsd: string

Нет

messageDate

xsd: dateTime

Да

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

sessionId

guid

Нет

Идентификатор сессии ШЭП. Заполняется на ШЭП, отправителю заполнять не надо.

Sender

SenderIndo

Да

Объект информация об отправителе (заполняется отправителем)

senderId

xsd: string

Да

Идентификатор отправителя (системы отправителя)

password

xsd: string

Нет

Пароль отправителя

properties

property

Массив свойств, можно добавить дополнительные свойства запроса (по согласованию с ШЭП и системой получателя

Key

xsd: string

Да

Ключ свойства

Value

xsd: string

Да

Значение своиства

messageData

Да

Объект передачи данных

Data

xsd: Anytype

Да

Объект данные сообщения (формат определяется системой получателя сообщения)

Ответ об ошибке (SendMessagefault) представляет собой массив элементов со следующими полями: Формат данных SendMessagefault

Поле

Тип

Обязанность

Описание

ErrorInfo

Информация об ошибке

errorCode

xsd: string

Да

Код ошибки

errorData

xsd: string

Да

Дополнительное описание ошибки

errorDate

xsd: dateTime

Да

Дата ошибки

subError

ErrorInfo

Нет

Дочерняя ошибка

sessionId

guid

Нет

Идентификатор сессии, в которой произошла ошибка

1.2. Интерфейс для реализации сервиса на стороне пользователей ШЭП для работы с асинхронным каналом.

Сервис реализуется как на стороне провайдера сервиса, так и на стороне использующей сервис. Сервис реализуют в случае необходимости доставки ШЭП сообщений методом вызова сервиса получателя сообщения (PUSH).

Метод приема сообщений: (SendMessage)

Запрос на предоставление cообщения (SendMessageRequest) содержит следующие поля: Формат данных SendMessageRequest

Поле

Тип

Обязанность

Описание

request

Async SendMessageRequest

Да

messageInfo

Async SendMessageInfo

Да

Мета данные сообщения

messageId

xsd: string

Нет

Идентификатор сообщения.

Генерируется ШЭП. В случае отправки сообщения на ШЭП данное поле должно быть пустым. В случае передачи сообщения получателю номер будет проставлен ШЭП.

correlationId

xsd: string

Нет

Идентификатор цепочки сообщений. Генерируется ШЭП. В случае отправки сообщения типа REQUEST на ШЭП данное поле должно быть пустым. При отправке сообщений других типов на ШЭП, данное поле ДОЛЖНО БЫТЬ ЗАПОЛНЕНО. В случае передачи сообщения получателю номер будет проставлен ШЭП.

serviceId

xsd: string

Да

Идентификатор взаимодействия. По реестру сервисов ШЭП.

messageType

xsd: string

Да

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

REQUEST - первое сообщения взаимодействия

routeId

xsd: string

Нет

messageDate

xsd: dateTime

Да

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

sessionId

guid

Нет

Идентификатор сессии ШЭП. Заполняется на ШЭП, отправителю заполнять не надо.

sender

SenderInfo

Да

Объект информация об отправителе (заполняется отправителем)

senderId

xsd: string

Да

Идентификатор отправителя (системы отправителя)

password

xsd: string

Нет

Пароль отправителя

properties

Property

Нет

Массив дополнительных свойств сообщения

key

xsd: int

Да

Ключ свойства

value

xsd: int

Да

Значение свойства

messageData

Да

Объект передачи данных

data

xsd: Anytype

Да

Объект данные сообщения (формат определяется системой получателя сообщения)

Поле

Тип

Обязанность

Описание

response

Async SendMessageResponse

Да

Ответ

messageId

xsd: string

Да

Идентификатор сообщения

correlationId

xsd: string

Да

Идентификатор цепочки сообщения

responseDate

xsd: dateTime

Да

Дата ответа

sessionId

guid

Нет

Идентификатор сессии ШЭП.

Ответ об ошибке (SendMessageFault) представляет собой массив элементов со следующими полями: Формат данных SendMessageFault

Поле

Тип

Обязанность

Описание

ErrorInfo

Информация об ошибке

errorCode

xsd: string

Да

Код ошибки

errorData

xsd: string

Да

Дополнительное описание ошибки

errorDate

xsd: dateTime

Да

Дата ошибки

subError

ErrorInfo

Нет

Дочерняя ошибка

sessionId

guid

Нет

Идентификатор сессии в которой произошла ошибка

Метод приема уведомлений об изменении статуса сообщения в ШЭП (ChangeMessageStatusNotification)

Запрос уведомления об изменении статуса сообщения (ChangeMessageStatusNotificationRequest) представляет собой массив элементов со следующими полями: Формат данных ChangeMessageStatusNotificationRequest

Поле

Тип

Обязанность

Описание

request

Async ChangeMessageStatus NotificationRequest

Да

notification

ChangeStatus Notification

Да

Уведомления о статусе доставки сообщения

notificationid

xsd: string

Да

Идентификатор уведомления

messageId

xsd: string

Да

Идентификатор сообщения

notificationDate

xsd: dateTime

Да

Дата создания уведомления

messageState

Да

Состояние сообщения

Status

messageStatusinfo

Да

Статус доставки (приема сообщения)

statusCode

xsd: string

Да

Код статуса

statusMessage

xsd: string

Да

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

statusDate

xsd: dateTime

Да

Идентификатор маршурута сообщения (если есть необходимость в дополнительной маршрутизации, идентификатор по реестру, заполняется системой отправителя)

error

Нет

Информация об ошибке

errorCode

xsd: string

Да

Код ошибки

errorMessage

xsd: string

Да

Сообщение ошибки

errorData

xsd: string

Да

Дополнительное описание ошибки

errorDate

xsd: dateTime

Да

Дата ошибки

subError

xsd: string

Нет

Дочерняя ошибка

sessionId

guid

Нет

Идентификатор сессии в которой произошла ошибка

requestdate

xsd: dateTime

Да

Дата запроса

sessionid

guid

Нет

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

Ответ о принятии уведомления (changeMassageStatusNotificationResponse) представляет собой массив элементов со следующими полями: Формат данных ChangeMessageStatusNotificationResponse

Поле

Тип

Обязанность

Описание

response

Async ChangeMessageStatus NotificationResponse

Да

Ответ

responseDate

xsd: dateTime

Да

Дата ответа

sessionid

guid

Да

Идентификатор сессии (указанное в запросе)

Ответ об ошибке (sendMessageFault) представляет собой массив элементов со следующими полями: Формат данных SendMessageFault

Поле

Тип

Обязанность

Описание

ErrorInfo

Информация об ошибке

errorCode

xsd: string

Да

Код ошибки

errorData

xsd: string

Да

Дополнительное описание ошибки

errorDate

xsd: dateTime

Да

Дата ошибки

subError

ErrorInfo

Нет

Дочерняя ошибка

sessionId

guid

Нет

Идентификатор сессии в которой произошла ошибка

2. Описание сообщений синхронного канала

2.1. Интерфейс сервиса на ШЭП:

Метод отправки сообщений по синхронному каналу (SendMessage)

Запрос на предоставление Сервиса (SendMessageRequest) представляет собой массив элементов со следующими полями: Формат сообщения типа SendMessageRequest

Поле

Тип

Обязанность

Описание

request

SyncsendMessagerequest

Да

Запрос

requestInfo

SyncMessageInfo

Да

Объект информация о сообщения запроса

messageId

xsd: string

Да

Идентификатор сообщения в системе получателя (генерирует ШЭП)

correlationId

xsd: string

Нет

Идентификатор цепочки сообщения в системе получателя запроса (Генерирует ШЭП)

serviceid

xsd: string

Да

Идентификатор взаимодействия (ведется в реестре сервисов ШЭП)

messegeDate

xsd: dateTime

Да

Дата создания сообщения в Системе Отправителя (Инициатора взаимодействия). Заполняется Отправителем (инициатором взаимодействия).

routeId

xsd: string

Нет

Идентификатор маршрута сообщения (если есть необходимость в дополнительной маршрутизации, идентификатор по реестру, заполняется системой Отправителя, т.е. Инициатора взаимодействия)

sessionId

guid

Нет

Идентификатор сессии на ШЭП. Устанавливается на ШЭП.

sender

senderinfo

Да

Объект информация об отправителе (заполняется отправителем)

senderId

xsd: string

Да

Идентификатор отправителя (системы отправителя)

password

xsd: string

Да

Пароль отправителя

properties

property

Нет

Массив своиств, можно добавить дополнительные своиства запроса (по согласовнию с ШЭП и системой получателя

key

xsd: int

Ключ свойства

value

xsd: int

Значение свойства

requestData

Да

Объект передачи данных запроса

data

xsd: Anytype

Нет

Объект данные сообщения (формат определяется системой получателя сообщения)

Ответное сообщения на запрос (SendMessageResponse) представляет собой массив элементов со следующими полями: Формат сообщения типа SendMessageResponse.

Поле

Тип

Обязанность

Описание

response

SyncsendMessageresponse

Да

Ответ

responseInfo

SyncMessageInfoResponse

Да

Информация об ответе

messageId

xsd: string

Да

correlationId

xsd: string

Нет

Идентификатор цепочки сообщения в системе получателя запроса (если сообщения существует в рамках цепочки сообщений системы отправителя (система отрабатывающая сообщение)

responseDate

xsd: dateTime

Да

Дата ответа в системе получателя запроса (заполняется системой получателя запроса)

sessionId

guid

Нет

Идентификатор сессии на ШЭП. Устанавливается на ШЭП. При отправки ответа системой получателя запроса заполнять не нужно.

status

StatusInfo

Да

Объект «Информация о статусе»

code

xsd: int

Да

Код статуса (проставляется системой получателя запроса)

message

xsd: string

Да

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

responseData

responsedata

Да

Объект «данные ответа»

data

xsd: Anytype

Нет

Объект данные сообщения (формат определяется системой получателя сообщения)

Сообщение об ошибке (SendMessageFault1_SendMessageFault) представляет собой массив элементов со следующими полями: Формат сообщения типа SendMessageFault

Поле

Тип

Обязанность

Описание

errorCode

xsd: string

Да

Код ошибки

errorMessage

xsd: string

Да

Сообщение ошибки

errorData

xsd: string

Нет

Дополнительное описание ошибки

errorDate

xsd: dateTime

Нет

Дата ошибки

subError

ErrorInfo

Нет

Дочерняя ошибка

sessionId

Guid

Нет

Идентификатор сессии в которой произошла ошибка

Приложение 5

к Правилам интеграции шлюза

«электронного правительства»,

платежного шлюза

«электронного правительства»

с информационными системами

Форма

Заявка на публикацию сервиса в тестовом режиме

1. Описание сервиса

№

Элемент

Описание

Правила заполнения

Пример

1.1.Сведения об организации-владельце ИС сервиса

Контактные данные владельцев и разработчиков сервиса

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

Оператор информационной системы, предоставляющей данный электронный сервис.

Не допускаются сокращения в названии, а также использование аббревиатур.

Акционерное общество «Национальные информационные технологии»

Краткое наименование

Краткое наименование оператора

Необходимо указывать максимально короткое значимое наименование. Рекомендуется - аббревиатура.

АО НИТ

Контактные данные разработчиков

Наименование компании, Контактное лицо, контактный телефон, эл. Почта, skype

ТОО «Симба», Бисембаев Мурат, начальник отдела разработки, 8(7172)346706, biba@bk.kz

1.2.Сведения об информационной системе, предоставляющей сервис

Краткое наименование ИС

Правила заполнения: Необходимо указать максимально короткое наименование. Рекомендуется аббревиатура

ГБД ФЛ

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

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

Государственная база данных «Физические лица»

1.3.Сведения о документах

Основание на публикацию сервиса на ШЭП

Ссылка на документ

Приложение 1

СТПО на сервис

Ссылка на документ

Приложение 2- СТПО на сервис.doc

Описание форматов сообщений

Ссылка на документ (файл) с описанием WSDL и XSD

Приложение 3 - «wsdl.rar»

1.4 Сведения о сервисе

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

Полное наименование электронного сервиса

Не допускаются сокращения в названии, а также использование аббревиатур

Сервис «Сервис по проверке статуса Заявителя ЮЛ (основные сведения о юридическом лице, адресные сведения)»

Ключ сервиса

Условное наименование сервиса

Правила заполнения: 1) Заполнять латинскими буквами. 2) В названии надо включить краткое название ИС и краткое название сервиса

GbdulFullInfo

Режим взаимодействия сервиса

Выбрать из списка, руководствуясь примечанием

Синхронный или асинхронный

Асинхронный

Признак наличия маршрутизации сообщений

Используется если по одному сервису есть несколько адресов доставки (смотреть таблицу Маршруты сервиса)

Правила заполнения: Признак наличия маршрутизации сообщений

0-нет

1-да

Признак наличия маршрутизации сообщений

Не заполняется при наличии маршрутизации. Ссылка на запись в таблице «Адреса доставки» (см. вкладку «Адреса доставки»)

Ссылка на запись в таблице «Адреса доставки» (см. вкладку «Адреса доставки»)

Признак наличия маршрутизации сообщений

Используется если по одному сервису есть несколько адресов доставки (смотреть таблицу Маршруты сервиса)

Правила заполнения: Признак наличия маршрутизации сообщений

0-нет

1-да

Режим отправки сообщений

Только для асинхронных сервисов. Выбрать из списка, руководствуясь примечанием.

PUSH или PULL

Только для асинхронных сервисов. Выбрать из списка, руководствуясь примечанием.

0 - не требуется

1 - требуется

Необходимость получения дополнительного уведомления о доставке от ШЭП

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

0 - не требуется

1 - требуется

2. Пользователи сервиса

№

Элемент

Описание

Правила заполнения

Пример

№

Порядковый номер пользователя

Владелец ИС

Организация -Владелец ИС

МИР РК

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

Веб-портал «электронного правительства»

Краткое наименование ИС

ПЭП

3. Маршруты сервиса

№

Элемент

Описание

Правила заполнения

Пример

Название маршрута

Условное название маршрута

Заполнять латинскими буквами с указанием названия информационной системы и сервиса

GBDUL_UL_SEARCH_p1

Точка доставки

Ссылка на запись в таблице «Адреса доставки» (см. вкладку «Адреса доставки»)

4. Параметры доставки сервиса

№

Элемент

Описание

Правила заполнения

Пример

Идентификатор точки доставки

Идентификатор точки доставки (указывается в таблицах «Сервис» и «Маршруты»

Формат заполнения: Целое число

URL адрес сервиса

Текстовый

http://egov2.company1.kz/8080

Способ вызова сервиса

Выбрать из списка, руководствуясь примечанием

1 - синхронный;

2 - асинхронный

Признак использования тротлинга

Выбрать из списка, руководствуясь примечанием

0 - не использовать тротлинг для доставки;

1 - использовать тротллинг для доставки

Таймаут тротлинга

Только для сервисов с асинхронным способом вызова. Таймаут тротлинга

Заполнять с с указанием единиц измерения.

45 секунд

Количество запросов

Только для сервисов с асинхронным способом вызова. Количество запросов тротлинга

Формат заполнения: Целое число

Количество повторных запросов

Только для сервисов с асинхронным способом вызова. Количество повторных запросов

Формат заполнения: Целое число

Таимаут при асинхронном вызове

Только для сервисов с асинхронным способом вызова. Таймаут при асинхронном вызове

Заполнять с указанием единиц измерения.

40 секунд

Максимальное количество ошибок

Только для сервисов с асинхронным способом вызова. Максимальное количество ошибок, после которых доставка будет выключена

Формат заполнения: Целое число

Максимальный интервал времени

Только для сервисов с асинхронным способом вызова. Интервал времени, в секундах, в который должно произойти максимальное количество ошибок для выключения доставки

Заполнять с указанием единиц измерения.

1 минута

Безопасность при вызове сервиса

Выбрать из списка, руководствуясь примечанием

0 - без дополнительной безопасности;

1 - с использованием транспортной подписи ШЭП

2 - с использованием транспортной подписи ШЭП и транспортной подписи вызывающей стороны

Приложение 6

к Правилам интеграции шлюза

«электронного правительства»,

платежного шлюза

«электронного правительства»

с информационными системами

Журнал логирования

№

Идентификатор сообщения

Канал

Дата приема сообщения

Дата отправки сообщения

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

Отправитель сообщения

Получатель сообщения

Состояние

Приложение 7

к Правилам интеграции шлюза

«электронного правительства»,

платежного шлюза

«электронного правительства» с

информационными системами

Журнал регистрации внештатной ситуации

п/н

Дата

Время получения электронного сообщения

Время уведомления о задержке отправки электронного сообщения ответственного лица (Администратор)

Время прибытия ответственного лица

Причина задержки

Принятые меры

Время отправки

ФИО сотрудника

Подпись

Приложение 8

к Правилам интеграции шлюза

«электронного правительства»,

платежного шлюза

«электронного правительства»

с информационными системами

Сценарии использования транспортной подписи

1. Сценарий приема сообщения с использованием транспортной подписи ШЭП. Данный сценарий используется при взаимодействии Внутренних ИС с Внешними ИС. Сценарий:

1) ШЭП проверяет сообщение (авторизацию, валидацию конверта сообщения);

2) ШЭП подписывает сообщение собственной транспортной подписью;

3) ШЭП передает подписанное сообщение ВШЭП.

2. Сценарий приема сообщения с использованием транспортных подписей ШЭП и вызывающей стороны.

Сценарий:

1) Отправитель сообщения подписывает сообщения транспортной подписью и отправляет на ШЭП;

2) ШЭП проверяет транспортную подпись сообщения:

а) проверяет соответствие БИН указанного в ЭЦП на БИН организации, внесенный в систему при регистрации Организации Владельца ИС Отправителя;

б) Проверяет транспортную подпись на действительность (онлайн проверка действительности подписи или проверка по списку отозванных сертификатов).

3. Сценарий приема сообщения с использованием транспортных подписей ШЭП и вызывающей стороны, с использованием метода шифрования сообщений.

Сценарий:

1) Отправитель сообщения шифрует сообщение;

2) Отправитель сообщения подписывает сообщения транспортной подписью и отправляет ШЭП;

3) ШЭП расшифровывает сообщение;

4) ШЭП проверяет транспортную подпись сообщения:

а) Проверяет соответствие БИН указанного в ЭЦП на БИН организации, внесенный в систему при регистрации Организации Владельца ИС Отправителя;