В соответствии с подпунктом 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) техническая реализация интеграции информационных систем – комплекс технических работ, проводимых для обеспечения интеграции участников информационного обмена;
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. Сведения об организации-владельце ИС сервиса |
||||
1 |
Наименование |
Организация, осуществляющая права собственности на информационную систему, реализующую электронный сервис |
Не допускаются сокращения в названии, а также использование аббревиатур. |
Министерство юстиции Республики Казахстан |
2 |
Краткое наименование |
Краткое наименование организации |
Необходимо указывать максимально короткое значимое наименование. Рекомендуется - аббревиатура. |
МЮ РК |
3 |
Идентификатор в сертификатах Национальный удостоверяющий центр Республики Казахстан (Бизнес идентификационный номер) |
Бизнес идентификационный номер |
214452507 |
|
2. Контактные данные владельцев и разработчиков сервиса |
||||
4 |
Наименование |
Оператор информационной системы, предоставляющей данный электронный сервис. |
Не допускаются сокращения в названии, а также использование аббревиатур. |
Акционерное общество «Национальные информационные технологии» |
5 |
Краткое наименование |
Краткое наименование оператора |
Необходимо указывать максимально короткое значимое наименование. Рекомендуется - аббревиатура. |
АО «НИТ» |
6 |
Эксплуатационное подразделение |
Подразделение Оператора, ответственное за эксплуатацию электронного сервиса |
Не допускаются сокращения в названии, а также использование аббревиатур. |
Проектный офис |
7 |
Руководитель эксплуатационного подразделения |
ФИО, должность, контактный телефон, электронная почта |
Необходимо указывать контактное лицо, с кем контактировать для организации взаимодействия с администраторами и разработчиками сервиса |
|
8 |
Должностное лицо, ответственное за эксплуатацию |
ФИО, должность, контактный телефон, электронная почта |
Необходимо указывать контактное лицо, напрямую отвечающее за администрирование сервиса - с кем контактировать для уточнения технических деталей функционирования сервиса или устранения инцидентов при его неработоспособности (технический специалист). |
|
9 |
Контактные данные разработчиков |
Наименование компании, Контактное лицо, контактный телефон, электронная почта |
Необходимо указывать контактное лицо, напрямую отвечающее за разработку (техническую поддержку) сервиса - с кем контактировать для уточнения технических деталей функционирования сервиса или устранения инцидентов при его неработоспособности (технический специалист). |
|
3. Сведения об информационной системе, предоставляющей электронный сервис |
||||
10 |
Краткое наименование ИС |
Краткое наименование ИС |
Необходимо указать максимально короткое наименование. Рекомендуется аббревиатура |
Государственная база данных «Физические лица» |
11 |
Наименование |
Наименование ИС |
ГБД «ФЛ» |
|
12 |
Стадия использования |
Стадия использования электронного сервиса. |
Выбрать из нижеперечисленного: |
|
13 |
Режим доступности |
Режим гарантированной доступности электронного сервиса. |
ЧЧ/ДД |
8/252, 16/252, и т.д. |
4. Сведения о документах |
||||
14 |
Основание на публикацию сервиса на ШЭП |
Ссылка на документ |
Приложение 1 |
|
15 |
Описание форматов сообщений |
Ссылка на документ (файл) с описанием WSDL и XSD |
Приложение 3 - «wsdl.rar» |
|
5. Сведения о сервисе |
||||
16 |
Наименование |
Полное наименование электронного сервиса |
Не допускаются сокращения в названии, а также использование аббревиатур |
Сервис «Сервис по проверке статуса Заявителя юридического лица (основные сведения о юридическом лице, адресные сведения)» |
17 |
Описание |
Развернутое описание назначения электронного сервиса |
Необходимо указывать исчерпывающее описание назначения электронного сервиса. |
Сервис услуги предоставление государственную базу данных «физические лица» сведений ПЭП о статусе пользователе-юридического лица и его регистрационных сведений при наличии статуса «зарегистрирован» |
18 |
Ключ сервиса |
Условное наименование сервиса |
1) Заполнять латинскими буквами. |
GbdulFullInfo |
19 |
Режим взаимодействия сервиса |
Выбрать из списка, руководствуясь примечанием |
Необходимо выбрать «Синхронный», «Асинхронный» либо «Синхронный/Асинхронный» режим. |
Асинхронный |
20 |
Адрес описания |
Ссылка на WSDL документ, описывающий электронный сервис |
http://10.10.10.10:7788/ WS-Bankrot /BankrotWebServiceSoapHttpPort?WSDL |
|
21 |
Признак наличия маршрутизации сообщений |
Используется если по одному сервису есть несколько адресов доставки (смотреть таблицу Маршруты сервиса) |
Признак наличия маршрутизации сообщений |
0 |
22 |
Адрес сервиса |
Не заполняется при наличии маршрутизации сообщения. Адрес электронного сервиса у Поставщика. |
http://10.10.10.10:7788/ WS-Bankrot /BankrotWebServiceSoapHttpPort?WSDL |
|
23 |
Режим отправки сообщений |
Только для асинхронных сервисов. Выбрать из списка, руководствуясь примечанием. |
PUSH или PULL |
PUSH |
24 |
Необходимость получения уведомления Информационной системой-Отправителей сообщений об изменении статусов сообщений от ШЭП |
Только для асинхронных сервисов. Выбрать из списка, руководствуясь примечанием. |
0 - не требуется, |
0 |
25 |
Необходимость получения дополнительного уведомления о доставке от ШЭП |
Выбрать из списка, руководствуясь примечанием (только для асинхронных сервисов) |
0 - не требуется, |
0 |
6. Тестовые данные |
||||
26 |
Адреса тестового сервиса |
Адреса тестового сервиса (в интернете, ЕТС) |
||
27 |
Тестовые запросы и ответы |
Ссылки на данные |
2. Пользователи сервиса
1 |
№ |
Порядковый номер пользователя (пользователей может быть несколько) |
1 |
|
3 |
Таймаут тротлинга |
Только для сервисов с асинхронным способом вызова. Таймаут тротлинга |
Заполнять с с указанием единиц измерения. |
45 секунд |
4 |
Количество запросов |
Только для сервисов с асинхронным способом вызова. Количество запросов тротлинга |
Целое число |
45 |
5 |
Количество повторных запросов |
Только для сервисов с асинхронным способом вызова. Количество повторных запросов |
Целое число |
10 |
6 |
Таймаут при асинхронном вызове |
Только для сервисов с асинхронным способом вызова. Таймаут при асинхронном вызове |
Заполнять с указанием единиц измерения. |
40 секунд |
7 |
Максимальное количество ошибок |
Максимальное количество ошибок, после которых доставка будет выключена |
Целое число |
5 |
8 |
Максимальный интервал времени |
Интервал времени, в секундах, в который должно произойти максимальное количество ошибок для выключения доставки |
Заполнять с указанием единиц измерения. |
1 минута |
9 |
Безопасность при вызове сервиса |
Выбрать из списка, руководствуясь примечанием |
0 - без дополнительной безопасности; |
1 |
5. Описание форматов сообщений сервиса
№ |
Элемент |
Описание |
Правила заполнения |
Пример |
1 |
Сообщение |
Сообщение - запрос или Ответное сообщение |
Обязательное поле |
Запрос |
2 |
Наименование параметра |
Да/Нет |
Обязательное поле |
ИИН |
3 |
Формат параметра |
Да/Нет |
Обязательное поле |
Строковый |
4 |
Поле |
Название параметра в XSD схеме |
Обязательное поле. Заполнять латинскими буквами |
IIN |
5 |
Обязательность |
Обязательность заполнения параметра сообщения |
Обязательное поле |
Да |
6 |
Примечание |
Не обязательное поле |
Приложение 2
к Правилам интеграции шлюза
«электронного правительства»,
платежного шлюза «электронного
правительства» с информационными
системами
Форма
Журнал регистрации взаимодействий ИС
№ |
Информация о сервисе |
Пользователь сервиса |
Основание публикации сервиса |
Основание подключение пользователя к сервису |
||||
Организация Владелец сервиса |
Информационная система |
Сервис |
Описание |
Организация Владелец ИС |
Информационная система |
|||
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
Приложение 3
к Правилам интеграции шлюза
«электронного правительства»,
платежного шлюза «электронного
правительства» с информационными
системами
Форма
Заявка на интеграцию информационной системы со шлюзом
«электронного правительства» для использования опубликованного
на шлюзе «электронного правительства» сервиса
№ |
Элемент |
Описание |
Правила заполнения |
1. Сведения об организации-владельце сервиса |
|||
1 |
Наименование |
Организация, осуществляющая права собственности на информационную систему, реализующую электронный сервис. |
Не допускаются сокращения в названии, а также использование аббревиатур. |
2 |
Краткое наименование |
Краткое наименование организации |
Необходимо указывать максимально короткое значимое наименование. Рекомендуется - аббревиатура. |
3 |
Идентификатор в сертификатах НУЦ РК (БИН) |
БИН организации |
Заполнять цифрами |
2. Сведения об информационной системе, предоставляющей сервис |
|||
4 |
Краткое наименование ИС |
Краткое наименование ИС |
Необходимо указать максимально короткое наименование. Рекомендуется аббревиатура |
5 |
Наименование |
Наименование ИС |
Не допускаются сокращения в названии, а также использование аббревиатур. |
6 |
Адрес Информационной системы |
URL адрес доставки Ответных сообщений от сервиса Пользователю |
|
3. Сведения о сервисе |
|||
7 |
Сведения об организации-владельце |
||
8 |
Наименование информационной системы, предоставляющей электронный сервис |
Не допускаются сокращения в названии, а также использование аббревиатур. |
|
9 |
Краткое наименование ИС |
Краткое наименование ИС |
Необходимо указать максимально короткое наименование. Рекомендуется аббревиатура |
10 |
Наименование сервиса |
Полное наименование электронного сервиса |
|
11 |
Описание |
Развернутое описание назначения электронного сервиса |
Необходимо указывать исчерпывающее описание назначения электронного сервиса. |
Приложение 4
к Правилам интеграции шлюза
«электронного правительства»,
платежного шлюза «электронного
правительства» с информационными
системами
Форма
Форматы данных сообщений
1. Описание сообщений асинхронного канала
1.1. Интерфейс сервиса на ШЭП:
Метод для отправки сообщений на асинхронный канал ШЭП
(SendMessage):
Запрос на предоставление Сервиса (SendMessageRequest) содержит
следующие поля:
Формат данных SendMessageRequest
Поле |
Тип |
Обязательность |
Описание |
request |
AsyncSendMessagerequest |
Да |
|
messageInfo |
AsyncMessageInfo |
Дa |
Мета данные сообщения |
messageId |
xsd: string |
Нет |
Идентификатор сообщения в системе получателя (заполняет система получателя запроса (система отрабатывающая сообщение) |
correlationId |
xsd: string |
Нет |
Идентификатор цепочки сообщения в системе получателя запроса (если сообщения существует в рамках цепочки сообщений системы (отправителя) система отрабатывающая сообщение) |
serviceId |
xsd: string |
Да |
Идентификатор сервиса |
messageType |
xsd: string |
Да |
Тип сообщения: |
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 |
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 |
Да |
Статус доставки сообщения: |
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 |
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 |
messageState |
Да |
Состояние сообщения |
responseDate |
xsd: dateTime |
Да |
Дата ответа |
sessionId |
xsd: string |
Нет |
Идентификатор сессии на ШЭП |
status |
MessagestatusInfo |
Объект «Информация о статусе» |
|
statusсode |
xsd: int |
Да |
Код статуса сообщения |
statusmessage |
xsd: string |
Да |
Сообщение статуса |
statusDate |
xsd: dateTime |
Да |
Дата изменения статуса |
В случае возникновении ошибки в Системе, передается сообщение
об ошибке (SendMessageFault), которая представляет собой массив
элементов со следующими полями: Формат данных SendMessageFault
Поле |
Тип |
Обязанность |
Описание |
ErrorInfo |
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 |
Нет |
Максимальное кол-во сообщений в выборке. |
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 |
Да |
Тип сообщения: |
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 |
messageData |
Да |
Объект передачи данных |
Data |
xsd: Anytype |
Да |
Объект данные сообщения (формат определяется системой получателя сообщения) |
Ответ об ошибке (SendMessagefault) представляет собой массив
элементов со следующими полями: Формат данных SendMessagefault
Поле |
Тип |
Обязанность |
Описание |
ErrorInfo |
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 |
Да |
Тип сообщения: |
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 |
Async SendMessageResponse |
Да |
Ответ |
messageId |
xsd: string |
Да |
Идентификатор сообщения |
correlationId |
xsd: string |
Да |
Идентификатор цепочки сообщения |
responseDate |
xsd: dateTime |
Да |
Дата ответа |
sessionId |
guid |
Нет |
Идентификатор сессии ШЭП. |
Ответ об ошибке (SendMessageFault) представляет собой массив
элементов со следующими полями: Формат данных SendMessageFault
Поле |
Тип |
Обязанность |
Описание |
ErrorInfo |
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 |
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 |
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 |
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. Сведения об организации-владельце ИС сервиса |
||||
Контактные данные владельцев и разработчиков сервиса |
||||
1 |
Наименование |
Оператор информационной системы, предоставляющей данный электронный сервис. |
Не допускаются сокращения в названии, а также использование аббревиатур. |
Акционерное общество «Национальные информационные технологии» |
2 |
Краткое наименование |
Краткое наименование оператора |
Необходимо указывать максимально короткое значимое наименование. Рекомендуется - аббревиатура. |
АО НИТ |
3 |
Контактные данные разработчиков |
Наименование компании, Контактное лицо, контактный телефон, эл. Почта, skype |
Необходимо указывать контактное лицо, напрямую отвечающее за разработку (техническую поддержку) сервиса - с кем контактировать для уточнения технических деталей функционирования сервиса или устранения инцидентов при его неработоспособности (технический специалист). |
ТОО «Симба», Бисембаев Мурат, начальник отдела разработки, 8(7172)346706, biba@bk.kz |
1.2. Сведения об информационной системе, предоставляющей сервис |
||||
4 |
Краткое наименование ИС |
Краткое наименование ИС |
Правила заполнения: Необходимо указать максимально короткое наименование. Рекомендуется аббревиатура |
ГБД ФЛ |
5 |
Наименование |
Наименование ИС |
Государственная база данных «Физические лица» |
|
1.3. Сведения о документах |
||||
6 |
Основание на публикацию сервиса на ШЭП |
Ссылка на документ |
Приложение 1 |
|
7 |
СТПО на сервис |
Ссылка на документ |
Приложение 2- СТПО на сервис.doc |
|
8 |
Описание форматов сообщений |
Ссылка на документ (файл) с описанием WSDL и XSD |
Приложение 3 - «wsdl.rar» |
|
1.4 Сведения о сервисе |
||||
9 |
Наименование |
Полное наименование электронного сервиса |
Не допускаются сокращения в названии, а также использование аббревиатур |
Сервис «Сервис по проверке статуса Заявителя ЮЛ (основные сведения о юридическом лице, адресные сведения)» |
10 |
Ключ сервиса |
Условное наименование сервиса |
Правила заполнения: 1) Заполнять латинскими буквами. 2) В названии надо включить краткое название ИС и краткое название сервиса |
GbdulFullInfo |
11 |
Режим взаимодействия сервиса |
Выбрать из списка, руководствуясь примечанием |
Синхронный или асинхронный |
Асинхронный |
12 |
Признак наличия маршрутизации сообщений |
Используется если по одному сервису есть несколько адресов доставки (смотреть таблицу Маршруты сервиса) |
Правила заполнения: Признак наличия маршрутизации сообщений |
0 |
13 |
Признак наличия маршрутизации сообщений |
Не заполняется при наличии маршрутизации. Ссылка на запись в таблице «Адреса доставки» (см. вкладку «Адреса доставки») |
Ссылка на запись в таблице «Адреса доставки» (см. вкладку «Адреса доставки») |
|
14 |
Признак наличия маршрутизации сообщений |
Используется если по одному сервису есть несколько адресов доставки (смотреть таблицу Маршруты сервиса) |
Правила заполнения: Признак наличия маршрутизации сообщений |
0 |
15 |
Режим отправки сообщений |
Только для асинхронных сервисов. Выбрать из списка, руководствуясь примечанием. |
PUSH или PULL |
|
16 |
Необходимость получения уведомления Информационной системой-Отправителей сообщений об изменении статусов сообщений от ШЭП |
Только для асинхронных сервисов. Выбрать из списка, руководствуясь примечанием. |
0 - не требуется |
0 |
17 |
Необходимость получения дополнительного уведомления о доставке от ШЭП |
Выбрать из списка, руководствуясь примечанием (только для асинхронных сервисов) |
0 - не требуется |
0 |
2. Пользователи сервиса
№ |
Элемент |
Описание |
Правила заполнения |
Пример |
1 |
№ |
Порядковый номер пользователя |
1 |
|
2 |
Владелец ИС |
Организация-Владелец ИС |
МИР РК |
|
3 |
Наименование ИС |
Веб-портал «электронного правительства» |
Веб-портал «электронного правительства» |
|
4 |
Краткое наименование ИС |
Краткое наименование ИС |
ПЭП |
3. Маршруты сервиса
№ |
Элемент |
Описание |
Правила заполнения |
Пример |
1 |
Название маршрута |
Условное название маршрута |
Заполнять латинскими буквами с указанием названия информационной системы и сервиса |
GBDUL_UL_SEARCH_p1 |
2 |
Точка доставки |
Ссылка на запись в таблице «Адреса доставки» (см. вкладку «Адреса доставки») |
Ссылка на запись в таблице «Адреса доставки» (см. вкладку «Адреса доставки») |
1 |
4. Параметры доставки сервиса
№ |
Элемент |
Описание |
Правила заполнения |
Пример |
1 |
Идентификатор точки доставки |
Идентификатор точки доставки (указывается в таблицах «Сервис» и «Маршруты» |
Формат заполнения: Целое число |
50 |
2 |
URL адрес сервиса |
URL адрес сервиса |
Текстовый |
http://egov2.company1.kz/8080 |
3 |
Способ вызова сервиса |
Выбрать из списка, руководствуясь примечанием |
1 - синхронный; |
2 |
4 |
Признак использования тротлинга |
Выбрать из списка, руководствуясь примечанием |
0 - не использовать тротлинг для доставки; |
1 |
5 |
Таймаут тротлинга |
Только для сервисов с асинхронным способом вызова. Таймаут тротлинга |
Заполнять с с указанием единиц измерения. |
45 секунд |
6 |
Количество запросов |
Только для сервисов с асинхронным способом вызова. Количество запросов тротлинга |
Формат заполнения: Целое число |
45 |
7 |
Количество повторных запросов |
Только для сервисов с асинхронным способом вызова. Количество повторных запросов |
Формат заполнения: Целое число |
10 |
8 |
Таимаут при асинхронном вызове |
Только для сервисов с асинхронным способом вызова. Таймаут при асинхронном вызове |
Заполнять с указанием единиц измерения. |
40 секунд |
9 |
Максимальное количество ошибок |
Только для сервисов с асинхронным способом вызова. Максимальное количество ошибок, после которых доставка будет выключена |
Формат заполнения: Целое число |
5 |
10 |
Максимальный интервал времени |
Только для сервисов с асинхронным способом вызова. Интервал времени, в секундах, в который должно произойти максимальное количество ошибок для выключения доставки |
Заполнять с указанием единиц измерения. |
1 минута |
11 |
Безопасность при вызове сервиса |
Выбрать из списка, руководствуясь примечанием |
0 - без дополнительной безопасности; |
1 |
Приложение 6
к Правилам интеграции шлюза
«электронного правительства»,
платежного шлюза «электронного
правительства» с информационными
системами
Журнал логирования
№ |
Идентификатор сообщения |
Канал |
Дата приема сообщения |
Дата отправки сообщения |
Тип сообщения |
Отправитель сообщения |
Получатель сообщения |
Состояние |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
Приложение 7
к Правилам интеграции шлюза
«электронного правительства»,
платежного шлюза «электронного
правительства» с информационными
системами
Журнал регистрации внештатной ситуации
п/н |
Дата |
Время получения электронного сообщения |
Время уведомления о задержке отправки электронного сообщения ответственного лица (Администратор) |
Время прибытия ответственного лица |
Причина задержки |
Принятые меры |
Время отправки |
ФИО сотрудника |
Подпись |
Приложение 8
к Правилам интеграции шлюза
«электронного правительства»,
платежного шлюза «электронного
правительства» с информационными
системами
Сценарии использования транспортной подписи
1. Сценарий приема сообщения с использованием транспортной подписи ШЭП. Данный сценарий используется при взаимодействии Внутренних ИС с Внешними ИС. Сценарий:
1) ШЭП проверяет сообщение (авторизацию, валидацию конверта сообщения);
2) ШЭП подписывает сообщение собственной транспортной подписью;
3) ШЭП передает подписанное сообщение ВШЭП.
2. Сценарий приема сообщения с использованием транспортных подписей ШЭП и вызывающей стороны.
Сценарий:
1) Отправитель сообщения подписывает сообщения транспортной подписью и отправляет на ШЭП;
2) ШЭП проверяет транспортную подпись сообщения:
а) проверяет соответствие БИН указанного в ЭЦП на БИН организации, внесенный в систему при регистрации Организации Владельца ИС Отправителя;
б) Проверяет транспортную подпись на действительность (онлайн проверка действительности подписи или проверка по списку отозванных сертификатов).
3. Сценарий приема сообщения с использованием транспортных подписей ШЭП и вызывающей стороны, с использованием метода шифрования сообщений.
Сценарий:
1) Отправитель сообщения шифрует сообщение;
2) Отправитель сообщения подписывает сообщения транспортной подписью и отправляет ШЭП;
3) ШЭП расшифровывает сообщение;
4) ШЭП проверяет транспортную подпись сообщения:
а) Проверяет соответствие БИН указанного в ЭЦП на БИН организации, внесенный в систему при регистрации Организации Владельца ИС Отправителя;
б) Проверяет транспортную подпись на действительность (онлайн проверка действительности подписи или проверка по списку отозванных сертификатов).