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

Приказ и.о. Министра по инвестициям и развитию Республики Казахстан от 28 января 2016 года № 104. Зарегистрирован в Министерстве юстиции Республики Казахстан 25 февраля 2016 года № 13244. Утратил силу приказом и.о. Министра информации и коммуникаций Республики Казахстан от 29 марта 2018 года № 123 (вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования)

      Сноска. Утратил силу приказом и.о. Министра информации и коммуникаций РК от 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) ШЭП проверяет транспортную подпись сообщения:

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

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

"Электрондық үкімет" шлюзінің, "электрондық үкіметтің" төлем шлюзінің ақпараттық жүйелермен интеграциясының қағидаларын бекіту туралы

Қазақстан Республикасы Инвестициялар және даму министрінің м.а 2016 жылғы 28 қаңтардағы № 104 бұйрығы. Қазақстан Республикасының Әділет министрлігінде 2016 жылы 25 ақпанда № 13244 болып тіркелді. Күші жойылды - Қазақстан Республикасы Ақпарат және коммуникациялар министрінің м.а. 2018 жылғы 29 наурыздағы № 123 бұйрығымен

      Ескерту. Күші жойылды – ҚР Ақпарат және коммуникациялар министрінің м.а. 29.03.2018 № 123 (алғашқы ресми жарияланған күнінен кейін күнтізбелік он күн өткен соң қолданысқа енгізіледі) бұйрығымен.

      "Ақпараттандыру туралы" 2015 жылғы 24 қарашадағы Қазақстан Республикасы Заңының 7-бабының 13) тармақшасына сәйкес БҰЙЫРАМЫН:

      1. Қоса беріліп отырған "Электрондық үкімет" шлюзінің, "электрондық үкіметтің" төлем шлюзінің ақпараттық жүйелермен интеграциясының қағидалары бекітілсін.

      2. Мыналардың:

      1) "Мемлекеттік органдардың электрондық ақпараттық ресурстары мен ақпараттық жүйелерін, сондай-ақ ақпараттық-коммуникациялық желілерін пайдалану және олардың өзара іс-қимыл жасау қағидаларын бекіту туралы" Қазақстан Республикасы Ақпараттандыру және байланыс агенттігі төрағасының 2009 жылғы 26 тамыздағы № 365 бұйрығының (Нормативтік құқықтық актілердің мемлекеттік тіркеу тізілімінде № 5783 болып тіркелген);

      2) "Мемлекеттік органдардың электрондық ақпараттық ресурстары мен ақпараттық жүйелерін, сондай-ақ ақпараттық-коммуникациялық желілерін пайдалану және олардың өзара іс-қимыл жасау ережелерін бекіту туралы" Қазақстан Республикасы Ақпараттандыру және байланыс агенттігі төрағасының 2009 жылғы 26 тамыздағы № 365 бұйрығына өзгерістер енгізу туралы" Қазақстан Республикасы Инвестициялар және даму министрінің міндетін атқарушысының 2015 жылғы 16 қазандағы № 991 бұйрығының (Нормативтік құқықтық актілердің мемлекеттік тіркеу тізілімінде № 12324 болып тіркелген, 2015 жылғы 15 желтоқсанда "Әділет" ақпараттық-құқықтық жүйесінде жарияланған) күші жойылды деп танылсын.

      3. Қазақстан Республикасы Инвестициялар және даму министрлігінің Байланыс, ақпараттандыру және ақпарат комитеті (Т.Б. Қазанғап):

      1) осы бұйрықтың Қазақстан Республикасы Әділет министрлігінде мемлекеттік тіркелуін;

      2) осы бұйрық Қазақстан Республикасы Әділет министрлігінде мемлекеттік тіркелгеннен кейін оның көшірмелерін баспа және электрондық түрде күнтізбелік он күн ішінде мерзімді баспа басылымдарында және "Әділет" ақпараттық-құқықтық жүйесінде ресми жариялауға, сондай-ақ тіркелген бұйрықты алған күннен бастап күнтізбелік он күн ішінде Қазақстан Республикасы нормативтік құқықтық актілерінің эталондық бақылау банкіне енгізу үшін Республикалық құқықтық ақпарат орталығына жіберуді;

      3) осы бұйрықты Қазақстан Республикасы Инвестициялар және даму министрлігінің интернет-ресурсында және мемлекеттік органдардың интранет-порталында орналастыруды;

      4) осы бұйрық Қазақстан Республикасы Әділет министрлігінде мемлекеттік тіркелгеннен кейін он жұмыс күні ішінде осы бұйрықтың

      3-тармағының 1), 2) және 3) тармақшаларында көзделген іс-шаралардың орындалуы туралы мәліметтерді Қазақстан Республикасы Инвестициялар және даму министрлігінің Заң департаментіне ұсынуды қамтамасыз етсін.

      4. Осы бұйрықтың орындалуын бақылау жетекшілік ететін Қазақстан Республикасының Инвестициялар және даму вице-министріне жүктелсін.

      5. Осы бұйрық алғаш ресми жарияланған күнінен кейін күнтізбелік он күн өткен соң қолданысқа енгізіледі.

Қазақстан Республикасы


Инвестициялар және даму


министрінің міндетін атқарушы

Ж. Қасымбек


  Қазақстан Республикасы
Инвестициялар және даму
министрінің міндетін атқарушының
2016 жылғы 28 қаңтардағы № 104
бұйрығымен бекітілген

"Электрондық үкімет" шлюзінің, "электрондық үкіметтің" төлем шлюзінің ақпараттық жүйелермен интеграциясының қағидалары
1. Жалпы ережелер

      1. Осы "Электрондық үкімет" шлюзінің, "электрондық үкіметтің" төлем шлюзінің ақпараттық жүйелермен интеграциясының қағидалары (бұдан әрі – Қағидалар) "Ақпараттандыру туралы" 2015 жылғы 24 қарашадағы Қазақстан Республикасы Заңының 7-бабының 13) тармақшасына сәйкес әзірленді және "электрондық үкімет" шлюзінің, "электрондық үкіметтің" төлем шлюзінің ақпараттық жүйелермен интеграциясының тәртібін айқындайды.

      2. Осы Қағидаларда мынадай негізгі ұғымдар мен қысқартулар қолданылады:

      1) ақпараттандыру саласындағы уәкілетті орган (бұдан әрі – уәкілетті орган) – ақпараттандыру және "электрондық үкімет" саласындағы басшылықты және салааралық үйлестіруді жүзеге асыратын орталық атқарушы орган;

      2) ақпараттық жүйе (бұдан әрі – АЖ) – ақпараттық өзара іс-қимыл арқылы белгілі бір технологиялық әрекеттерді іске асыратын және нақты функционалдық міндеттерді шешуге арналған ақпараттық-коммуникациялық технологиялардың, қызмет көрсетуші персоналдың және техникалық құжаттаманың ұйымдастырылып ретке келтірілген жиынтығы;

      3) ақпараттық жүйе әкімшісі - міндетіне интернетке шығудың техникалық қамтамасыз етілуін, АЖ жүйелік бағдарламалық қамтамасыз етілуін қоса алғанда, жүйенің бастапқы орнатылуы, апаттық жағдайларды жойғаннан кейін қайта орнату кіретін, жүйелерге қызмет көрсетуді жүзеге асыратын персонал;

      4) ақпараттық жүйелердің интеграциясы – деректерді берудің Қазақстан Республикасында пайдаланылатын стандарттық хаттамалары негізінде екі және одан да көп ақпараттық жүйе арасындағы ақпараттық өзара іс-қимылды ұйымдастыру және қамтамасыз ету жөніндегі іс-шаралар;

      5) ақпараттық жүйелердің интеграциясын техникалық іске асыру – ақпараттық алмасуға қатысушылардың интеграциясын қамтамасыз ету үшін жүргізілетін техникалық жұмыстар кешені;

      6) ақпараттық жүйелердің сервисі (бұдан әрі – сервис) – ақпараттық жүйе беретін қызметті ерекшелендіру үшін пайдаланылатын операциялар жиынтығынан тұратын сервис;

      7) ақпараттық жүйенің бизнес-деректері – ЭҮШ тарапында тексерілмейтін блок ретінде ЭҮШ форматының хабарламасы құрамына кіретін, Сервис пайдаланушысы мен Сервис иеленушісінің өзара іс-қимыл деректері;

      8) веб-сервистердің қауіпсіздігі (Web Service Security) (бұдан әрі – WS Security) – SOAP веб-сервистері арасында хабарлама алмасу кезіндегі қауіпсіздік функцияларын қолдану стандарты;

      9) логтау журналы – жүйенің жұмысын мониторингілеу және жаңылысу орын алған жағдайда оның пайда болуы себебін анықтау үшін қолданылатын жүйенің жұмысы туралы ақпаратты қамтитын файлдар;

      10) мемлекеттік органдардың бірыңғай көліктік ортасы (бұдан әрі – МО БКО) – "электрондық үкiметтiң" ақпараттық-коммуникациялық инфрақұрылымына кіретін және ақпараттық қауіпсіздіктің талап етілетін деңгейін сақтай отырып, мемлекеттік органдардың, олардың ведомстволық бағынысты ұйымдары мен жергілікті өзін-өзі басқару органдарының, сондай-ақ уәкілетті орган айқындаған өзге де ақпараттандыру субъектілерінің жергілікті (Интернетке қолжетімділігі бар жергілікті желілерді қоспағанда), ведомстволық және корпоративтік телекоммуникациялар желілерінің өзара іс-қимыл жасауын қамтамасыз етуге арналған телекоммуникациялар желісі;

      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. Тестілік пайдалану

3. Тәжірибелік пайдалану

4. Өндірістік пайдалануды таңдау қажет.


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. Тестілік деректер

28

Тестілік сервис мекен жайы

Тестілік сервис мекен жайы (интернетте, БКО)



29

Тестілік сұранымдар және жауаптыра

Деректерге сілтеме




      2. Сервис пайдаланушылары

1

Клиенттің реттік нөмірі (клиенттер бірнешеу болуы мүмкін)


1

2

АЖ иеленушісі

Ұйым – АЖ иесі


ҚР ИДМ

3

АЖ атауы

Электрондық үкіметтің порталы


"Электрондық үкіметтің" порталы

4

АЖ-ның қысқаша атауы

АЖ-ның қысқаша атауы


ЭҮП

5

Жеткізу мекен жайы

Сұранымға жауап хабарламаның URL мекен жайы

Синхронды сервистер үшін міндетті емес

192.89.240.234/bip-management/


      3. Электронды сервис бағдарлары

Элемент

Сипаттамасы

Толтыру ережесі

Мысалы

1

Бағдардың атауы

Бағдардың шартты атауы

Ақпараттық жүйе мен сервистің атауын көрсете отырып латын әрпімен толтыру

GBDUL_UL_SEARCH_p1

2

Жеткізу нүктесі

"Жеткізу мекен жайлары" кестесіндегі жазбаға сілтеме ("Жеткізу мекен жайлары" қосымша бетін қараңыз)

"Хабарлама жеткізу баптаулары" кестесіндегі жазбаға сілтеме ("Жеткізу мекен жайлары" кестесін қараңыз)

1


      4. Хабарламаны жеткізудің баптаулары

Элемент

Сипаттамасы

Толтыру ережесі

Мысалы

1

Сервистің URL мекен жайы

Сервистің URL мекен жайы

Мәтіндік

http://egov2.company1.kz/8080

2

Тротилингді пайдалану белгісі

Асинхронды тәсілмен шақырылатын сервистер үшін ғана. Ескертпені басшылыққа ала отырып тізімнен таңдау

0 - тротлингді жеткізу үшін пайдаланбау;

1 - тротлингді жеткізу үшін пайдалану

1

  "Электрондық үкімет" шлюзінің,
"Электрондық үкіметтің" төлем
шлюзінің ақпараттық жүйелермен
интеграциясының қағидаларына
2-қосымша

      Нысан

Ақпараттық жүйелердің өзара іс-қимылын тіркеу журналы

Сервис туралы ақпарат

Сервис пайдаланушысы

Сервистің жарияланымдар негіз

Клиенттің сервиске қосылуына негіз

Сервис иесінің ұйымы

Ақпараттық жүйе

Сервис

Сипаттамасы

АЖ иесінің ұйымы

Ақпараттық жүйе



1

2

3

4

5

6

7

8

9

  "Электрондық үкімет" шлюзінің,
"Электрондық үкіметтің" төлем
шлюзінің ақпараттық жүйелермен
интеграциясының қағидаларына
3-қосымша

      Нысан

"Электрондық үкімет" шлюзі сервисінде жарияланған ақпараттық
жүйені пайдалану үшін "электрондық үкімет" шлюзімен
интеграциялауға арналған өтінім

Элемент

Сипаттамасы

Толтыру ережесі

Сервис иеленуші-ұйым туралы мәлімет

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

Иә

Хабарламаның мета деректері

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 (ескертпеге жауап)

      Ескертпеге жауап келесі жолдардағы ауқымды ұсынады:

      SendDeliveryNotigicationResponse деректер нысаны

Жол

Тип

Міндеттеме

Сипаттама

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 (Хабарламаның мәртебесіне сұраным)

      Хабарламаның мәртебесіне сұранымы келесі жолдардағы элементтер

      ауқымын ұсынады:

      MessageStatusRequest деректер нысаны

Поле

Тип

Міндеттеме

Сипаттама

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 (Хабарлама қабылдау тәсілі)

      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

Атауы

Осы электронды қызметті ұсынатын ақпараттық жүйенің операторы

Атауларды қысқартуға, сондай-ақ аббревиатуралар қолдануға жол берілмейді.

"Ұлттық ақпараттық технологиялар" Акционерлік қоғамы

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) ЭҮШ хабарламаның көлік қолтаңбасын тексереді:

      а) Көрсетілген ЭЦҚ-ның БСН жіберуші АЖ иесі ұйымының жүйеге тіркелуде енгізілген ұйым БСН-на сәйкестігін тексереді;

      б) Көлік қолтаңбасының нақтылығын тексереді (қолтаңбаның нақтылығын онлайн тексеру немесе кері қайтарылған сертификаттар тізімі бойынша тексеру).