Сноска. Утратил силу приказом и.о. Министра информации и коммуникаций РК от 29.03.2018 № 123 (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования).
В соответствии с подпунктом 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 | Стадия использования | Стадия использования электронного сервиса. | Выбрать из нижеперечисленного: 1. Опытная эксплуатация 2. Промышленная эксплуатация | |
13 | Режим доступности | Режим гарантированной доступности электронного сервиса. | ЧЧ/ДД (Стандартный режим: 24/365) | 8/252, 16/252, и т.д. |
4. Сведения о документах | ||||
14 | Основание на публикацию сервиса на ШЭП | Ссылка на документ | Приложение 1 | |
15 | Описание форматов сообщений | Ссылка на документ (файл) с описанием WSDL и XSD | Приложение 3 - "wsdl.rar" | |
5. Сведения о сервисе | ||||
16 | Наименование | Полное наименование электронного сервиса | Не допускаются сокращения в названии, а также использование аббревиатур | Сервис "Сервис по проверке статуса Заявителя юридического лица (основные сведения о юридическом лице, адресные сведения)" |
17 | Описание | Развернутое описание назначения электронного сервиса | Необходимо указывать исчерпывающее описание назначения электронного сервиса. | Сервис услуги предоставление государственную базу данных "физические лица" сведений ПЭП о статусе пользователе-юридического лица и его регистрационных сведений при наличии статуса "зарегистрирован" |
18 | Ключ сервиса | Условное наименование сервиса | 1) Заполнять латинскими буквами. 2) В названии надо включить краткое название ИС и краткое название сервиса | GbdulFullInfo |
19 | Режим взаимодействия сервиса | Выбрать из списка, руководствуясь примечанием | Необходимо выбрать "Синхронный", "Асинхронный" либо "Синхронный/Асинхронный" режим. Синхронный - запрос с быстрым ответом электронного сервиса. Он возвращает результат исполнения запроса непосредственно в ответе на запрос. Асинхронный - запрос с отложенным ответом. В данном режиме сервис "Запрашивает исполнение", в результате возвращает № созданной задачи. Далее потребитель сервиса в соответствии с указанным в пункте 5 вкладки "Реестр прав доступа" таймаутом запрашивает результат, в следствии чего он будет представлен (если уже готов) либо появится сообщение об ошибке (если результат еще не готов). В случае отсутствия решения потребитель повторно запрашивает результат не раньше чем через рекомендуемый интервал. | Асинхронный |
20 | Адрес описания | Ссылка на WSDL документ, описывающий электронный сервис | http://10.10.10.10:7788/ WS-Bankrot /BankrotWebServiceSoapHttpPort?WSDL | |
21 | Признак наличия маршрутизации сообщений | Используется если по одному сервису есть несколько адресов доставки (смотреть таблицу Маршруты сервиса) | Признак наличия маршрутизации сообщений 0-нет 1-да | 0 |
22 | Адрес сервиса | Не заполняется при наличии маршрутизации сообщения. Адрес электронного сервиса у Поставщика. | http://10.10.10.10:7788/ WS-Bankrot /BankrotWebServiceSoapHttpPort?WSDL | |
23 | Режим отправки сообщений | Только для асинхронных сервисов. Выбрать из списка, руководствуясь примечанием. | PUSH или PULL | PUSH |
24 | Необходимость получения уведомления Информационной системой-Отправителей сообщений об изменении статусов сообщений от ШЭП | Только для асинхронных сервисов. Выбрать из списка, руководствуясь примечанием. | 0 - не требуется, 1 - требуется | 0 |
25 | Необходимость получения дополнительного уведомления о доставке от ШЭП | Выбрать из списка, руководствуясь примечанием (только для асинхронных сервисов) | 0 - не требуется, 1 - требуется | 0 |
6. Тестовые данные | ||||
26 | Адреса тестового сервиса | Адреса тестового сервиса (в интернете, ЕТС) | ||
27 | Тестовые запросы и ответы | Ссылки на данные | ||
2. Пользователи сервиса
1 | № | Порядковый номер пользователя (пользователей может быть несколько) | 1 | |
3 | Таймаут тротлинга | Только для сервисов с асинхронным способом вызова. Таймаут тротлинга | Заполнять с с указанием единиц измерения. | 45 секунд |
4 | Количество запросов | Только для сервисов с асинхронным способом вызова. Количество запросов тротлинга | Целое число | 45 |
5 | Количество повторных запросов | Только для сервисов с асинхронным способом вызова. Количество повторных запросов | Целое число | 10 |
6 | Таймаут при асинхронном вызове | Только для сервисов с асинхронным способом вызова. Таймаут при асинхронном вызове | Заполнять с указанием единиц измерения. | 40 секунд |
7 | Максимальное количество ошибок | Максимальное количество ошибок, после которых доставка будет выключена | Целое число | 5 |
8 | Максимальный интервал времени | Интервал времени, в секундах, в который должно произойти максимальное количество ошибок для выключения доставки | Заполнять с указанием единиц измерения. | 1 минута |
9 | Безопасность при вызове сервиса | Выбрать из списка, руководствуясь примечанием | 0 - без дополнительной безопасности; 1 - с использованием транспортной подписи ШЭП 2 - с использованием транспортной подписи ШЭП и транспортной подписи вызывающей стороны | 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 | Да | Тип сообщения: 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 | 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 | 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 | Нет | Максимальное кол-во сообщений в выборке. Если данное поле отсутствует в запросе или равно 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 | 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 | Да | Тип сообщения: 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 | 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-нет 1-да | 0 |
13 | Признак наличия маршрутизации сообщений | Не заполняется при наличии маршрутизации. Ссылка на запись в таблице "Адреса доставки" (см. вкладку "Адреса доставки") | Ссылка на запись в таблице "Адреса доставки" (см. вкладку "Адреса доставки") | |
14 | Признак наличия маршрутизации сообщений | Используется если по одному сервису есть несколько адресов доставки (смотреть таблицу Маршруты сервиса) | Правила заполнения: Признак наличия маршрутизации сообщений 0-нет 1-да | 0 |
15 | Режим отправки сообщений | Только для асинхронных сервисов. Выбрать из списка, руководствуясь примечанием. | PUSH или PULL | |
16 | Необходимость получения уведомления Информационной системой-Отправителей сообщений об изменении статусов сообщений от ШЭП | Только для асинхронных сервисов. Выбрать из списка, руководствуясь примечанием. | 0 - не требуется 1 - требуется | 0 |
17 | Необходимость получения дополнительного уведомления о доставке от ШЭП | Выбрать из списка, руководствуясь примечанием (только для асинхронных сервисов) | 0 - не требуется 1 - требуется | 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 - асинхронный | 2 |
4 | Признак использования тротлинга | Выбрать из списка, руководствуясь примечанием | 0 - не использовать тротлинг для доставки; 1 - использовать тротллинг для доставки | 1 |
5 | Таймаут тротлинга | Только для сервисов с асинхронным способом вызова. Таймаут тротлинга | Заполнять с с указанием единиц измерения. | 45 секунд |
6 | Количество запросов | Только для сервисов с асинхронным способом вызова. Количество запросов тротлинга | Формат заполнения: Целое число | 45 |
7 | Количество повторных запросов | Только для сервисов с асинхронным способом вызова. Количество повторных запросов | Формат заполнения: Целое число | 10 |
8 | Таимаут при асинхронном вызове | Только для сервисов с асинхронным способом вызова. Таймаут при асинхронном вызове | Заполнять с указанием единиц измерения. | 40 секунд |
9 | Максимальное количество ошибок | Только для сервисов с асинхронным способом вызова. Максимальное количество ошибок, после которых доставка будет выключена | Формат заполнения: Целое число | 5 |
10 | Максимальный интервал времени | Только для сервисов с асинхронным способом вызова. Интервал времени, в секундах, в который должно произойти максимальное количество ошибок для выключения доставки | Заполнять с указанием единиц измерения. | 1 минута |
11 | Безопасность при вызове сервиса | Выбрать из списка, руководствуясь примечанием | 0 - без дополнительной безопасности; 1 - с использованием транспортной подписи ШЭП 2 - с использованием транспортной подписи ШЭП и транспортной подписи вызывающей стороны | 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) ШЭП проверяет транспортную подпись сообщения:
а) Проверяет соответствие БИН указанного в ЭЦП на БИН организации, внесенный в систему при регистрации Организации Владельца ИС Отправителя;
б) Проверяет транспортную подпись на действительность (онлайн проверка действительности подписи или проверка по списку отозванных сертификатов).
