Что государство знает о гражданах и организациях?

Общая схема взаимодействия через СМЭВ

В цикле статей мы, команда Gems Development, расскажем о работе с «Госуслугами» по ту сторону экрана и о том, как оформить эффективное взаимодействие органов государственной власти с порталом.

В материале представлена пошаговая инструкция по предоставлению доступа к Личному кабинету участника межведомственного взаимодействия (ЛК УВ) для двух категорий пользователей: сотрудник организации (сотрудник УВ) и представитель разработчика.

В материале приводится исчерпывающая информация о взаимодействии с сервисами ГИС ГМП посредством СМЭВ. Перечисляются типы организаций, имеющих право работать с Системой государственных и муниципальных платежей, и их полномочия. Описывается порядок регистрации и доступа к сервису. Проводится полный обзор видов сведений ГИС ГМП в СМЭВ3. Разбирается кейс с передачей информации об оплате.

6 октября 2020 года на технологическом портале СМЭВ3 появился раздел «Интеграционный узел Адаптера, доработанного Адаптера СМЭВ 3.0 в соответствии с новыми возможностями СМЭВ 3».

В данной статье мы расскажем о том, что такое Интеграционный узел и какие возможности он предоставляет участникам взаимодействия.

В материале рассмотрены возможности разделения очередей входящих и исходящих сообщений на уровне СМЭВ, Адаптера СМЭВ и информационной системы Участника СМЭВ.

В материале рассмотрены причины снижения скорости работы Адаптера СМЭВ, изучен вариант переустановки Адаптера для повышения его производительности и описано собственное решение команды Хемуль IT для ускорения работы ПО Минкомсвязи — «Бустер Адаптера СМЭВ».

В табличном виде представлен перечень всех информационных систем участников СМЭВ с указанием владельца и мнемоники. Данные актуальны на 29.12.2020. Источник данных — Технологический портал СМЭВ.

На странице собраны ссылки на историю версии бесплатного Адаптера СМЭВ. Ранние версии решения полезны как для последовательного апгрейда до актуальной версии с сохранением пользовательских данных, так и в случае необходимости возврата к более стабильным сборкам..

В материале приводится обзор Модуля мониторинга СМЭВ. Решение предоставляет пользователю набор виджетов и реестр сообщений с полной информацией о процессах обработки межведомственных запросов в электронном виде. Модуль является разработкой команды Хемуль IT и поставляется как в составе Универсального интерфейса Адаптера СМЭВ, так и в качестве самостоятельного серверного решения.

В материале представлен список видов сведений СМЭВ, к которым фактически могут получить доступ юридические лица различных категорий. Материал актуален на декабрь 2021 года.

Органы власти и местного самоуправления планомерно собирают, накапливают и актуализируют значительные объемы данных о людях и организациях. Для обмена структурированными данными в защищенной среде используется Система межведомственного электронного взаимодействия. В настоящий момент наблюдается бурный рост количества электронных сервисов (видов сведений), публикуемых в СМЭВ. В статье приводится информация о том, какие данные может получить участник СМЭВ о физических и юридических лицах.

Данные из СМЭВ

СМЭВ представляет собой колоссальное хранилище информации распределенного типа.  При этом практически все доступные наборы данных так или иначе содержат информацию по конкретном человеку и организации. Эта информация очень разнородна — частично она дублирует опубликованные на ведомственных сайтах и профильном портале «открытые данные» , но по большей части она является закрытой, т.к. содержит:

• персональные данные;
• данные, составляющие коммерческую тайну;
• прочую информацию ограниченного доступа.

В материале представлены сведения, которые кажутся авторам наиболее интересными и показательными. В целом же на момент публикации текста в продуктивной среде СМЭВ доступны 625 наборов данных.

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

Информация о физических лицах

В указанном перечне содержатся далеко не все данные, которые можно получить о человеке и организации через СМЭВ. Материал готовился в сжатые сроки,  отбирались наиболее интересные сведения, некоторые сервисы не были изучены до конца. Кроме того, из списка намерено были исключены ВС, свидетельствующие о наличии у органов власти той или иной информации,  но не позволяющие эту информацию запросить и получить (например, данные о результатах проверок организаций). Также в расчет не брались региональные виды сведений — это материал для отдельного исследования.

Можно заметить, что в СМЭВ создано множество достаточно неожиданных курьезных видов сведений, например: ВС МВД «Предоставление заверенной электронной подписью копии документа, подтверждающего согласование принятых членами казачьего общества обязательств по несению государственной или иной службы».

Отдельно стоит отметить, что лидером по количеству и качеству выводимых в СМЭВ сервисов выступает Федеральная налоговая служба. Виды сведений ФНС наиболее информативны, хорошо организованы и структурированы,  и, как показывает практика, очень востребованы органами власти и частыми компаниями.

В процессе подготовки статьи авторов заинтересовало даже не то, какой объем информации есть в распоряжении органов власти. Мы все пользуемся порталом Госуслуг и имеет учетки в ЕСИА, сдаем «антикоррупционную» отчетность как государственные служащие, подаем налоговые декларации и передаем данные о компаниях в ФНС. Само собой эти данные собираются, обрабатываются и хранятся. Поражает тот факт, что уже полным ходом идет процесс формирования системы, автоматизирующей возможность быстрого и формализованного получения множества данных практически о каждом человеке и организации.  Эти данные представляют собой уже не записи в тетради учета или excel-таблице на диске отдельного пользователя или департамента — они приведены к единому формату, обобщены по всем регионам, систематизированы и подготовлены к передаче заинтересованному  в участнику СМЭВ.

• Бух. отчётность
• Тест фирм

досье №1206300029132 от 11.02.2023

Краткое досье

ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ МИКРОКРЕДИТНАЯ КОМПАНИЯ “СМЭВ”

Обратите внимание

Полное наименование организации: ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ МИКРОКРЕДИТНАЯ КОМПАНИЯ “СМЭВ”

Место нахождения: 443095, обл. Самарская, г. Самара, ул. Стара Загора, влд. 202А, оф. 101

Вид деятельности: Предоставление займов и прочих видов кредита (код по ОКВЭД 64.92)

Статус организации: коммерческая, действующая

Организационно-правовая форма: Общества с ограниченной ответственностью (код 12300 по ОКОПФ)

Регистрация в Российской Федерации

Организация ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ МИКРОКРЕДИТНАЯ КОМПАНИЯ “СМЭВ” зарегистрирована в едином государственном реестре юридических лиц 2 года 8 месяцев назад 15 мая 2020.

Средний возраст юридических лиц для вида деятельности 64.92 “Предоставление займов и прочих видов кредита” составляет 9 лет. Данная организация моложе.

Налоговый орган, в котором юридическое лицо состоит на учёте: Межрайонная инспекция Федеральной налоговой службы № 20 по Самарской области (код инспекции – 6312). Налоговый орган до 16.10.2020 – Инспекция Федеральной налоговой службы по Советскому району г. Самары (код 6318).

Регистрационный номер в ПФР: 077002132805 от 19 октября 2020 г.

Регистрационный номер в ФСС: 630800277763021 от 16 октября 2020 г.

Чем занимается организация, виды деятельности

Основной вид деятельности организации: Предоставление займов и прочих видов кредита (код по ОКВЭД 64.92).

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

Где находится ООО МКК “СМЭВ”, юридический адрес

ООО МКК “СМЭВ” зарегистрировано по адресу: 443095, обл. Самарская, г. Самара, ул. Стара Загора, влд. 202А, оф. 101. (показать на карте)

До 03.11.2022 организация находилась по адресу: .

По текущему юридическому адресу других организаций не значится.

Кто владелец (учредитель) организации

Учредителями ООО МКК “СМЭВ” являются:

Ранее согласно ЕГРЮЛ учредителями значились:

Кто руководит ООО МКК “СМЭВ”

Руководителем организации (лицом, имеющим право без доверенности действовать от имени юридического лица) с 7 октября 2021 г. является директор Черняев Максим Сергеевич (ИНН: 753504328750).

Ранее организацией руководили:

• (директор с 15.05.2020 до 18.09.2020 г.*)
• (директор с 25.03.2021 до 07.10.2021 г.*)
• (директор с 18.09.2020 до 25.03.2021 г.*)

Кем руководит и владеет организация (числится учредителем)

ООО МКК “СМЭВ” не значится учредителем каких-либо российских юридических лиц.

Численность сотрудников

По данным ФНС среднесписочная численность работников за 2021 год равнялась нулю.

Финансы организации

Уставный капитал ООО МКК “СМЭВ” составляет 3 млн руб. Это значительно больше минимального уставного капитала, установленного законодательством для ООО (10 тыс. руб.).

До 09.03.2022 уставный капитал составлял 2 млн руб., до 29.06.2020 – 10 тыс. руб.

Организация не применяет специальных режимов налогообложения (находится на общем режиме).

Организация относится к категории микропредприятий. В соответствии с нормативно утвержденными критериями, микропредприятием считается организация с выручкой до 120 млн. руб. в год и численностью сотрудников до 15 человек.

Сведения об уплаченных организацией суммах налогов и сборов за 2021 год

На основе данных единого государственного реестра юридических лиц прослеживаются следующие взаимосвязи лиц, имеющих прямое или косвенное отношение к организации:

Хронология основных событий

Изменился юридический адрес – с на обл. Самарская, г. Самара, ул. Стара Загора, влд. 202А, оф. 101.

• Уставный капитал увеличен с 2 млн руб. до 3 млн руб..
• Новый учредитель – ЗАО “АВЕНТУС КАПИТАЛ” (Литовская Республика).

• Новый учредитель – .
• больше не числится в ЕГРЮЛ учредителем.

больше не числится в ЕГРЮЛ учредителем.

Сменился руководитель: на .

• Адрес больше не указан в ЕГРЮЛ как юридический адрес организации.
• Налоговый орган, в котором юридическое лицо состоит на учёте, изменён на Межрайонная инспекция Федеральной налоговой службы № 20 по Самарской области (до этого был Инспекция Федеральной налоговой службы по Советскому району г. Самары).

Новый юридический адрес – .

Уставный капитал увеличен с 10 тыс. руб. до 2 млн руб..

Последние изменения в ЕГРЮЛ

• 03.11.2022. Изменение сведений о юридическом лице, содержащихся в Едином государственном реестре юридических лиц.
• 06.04.2022. Изменение сведений о юридическом лице, содержащихся в Едином государственном реестре юридических лиц.
• 09.03.2022. Государственная регистрация изменений, внесенных в учредительные документы юридического лица, связанных с внесением изменений в сведения о юридическом лице, содержащиеся в Едином государственном реестре юридических лиц, на основании заявления.
• 23.12.2021. Исправление ошибок, допущенных заявителем.
• 08.11.2021. Изменение сведений о юридическом лице, содержащихся в Едином государственном реестре юридических лиц.
• 07.10.2021. Изменение сведений о юридическом лице, содержащихся в Едином государственном реестре юридических лиц.
• 21.09.2021. Исправление ошибок, допущенных заявителем.
• 25.03.2021. Изменение сведений о юридическом лице, содержащихся в Едином государственном реестре юридических лиц.
• 18.12.2020. Изменение сведений о юридическом лице, содержащихся в Едином государственном реестре юридических лиц.
• 23.10.2020. Внесение сведений о регистрации в ФСС РФ.

Контактная информация ООО МКК “СМЭВ”

ЕГРЮЛ не содержит в открытом доступе контактные данные организации. Если вы имеете отношение к данной фирме, мы можем добавить здесь координаты для связи с организацией – пришлите нам письмо от имени юридического лица (в такой форме).

Указана дата изменения в ЕГРЮЛ (может не совпадать с фактической).

Представленные на этой странице данные получены из официальных источников: Единого государственного реестра юридических лиц (ЕГРЮЛ), Государственного информационного ресурса бухгалтерской отчетности (ГИР БО), с сайта Федеральной налоговой службы (ФНС), Минфина и Росстата. Указанные данные подлежат опубликованию в соответствии с законодательством РФ.

Разработкой программного обеспечения и обработкой информации занимается ООО “Профсофт” (ИНН 3906992381). Используется информация только из официальных открытых источников. Если вы заметили ошибку или некорректную информацию, пожалуйста, свяжитесь с разработчиком.

Печать
MS Word

Отключить мобильную версию

Например, следующими видами сообщений:

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

То есть делаются попытки стандартизировать и регламентировать, в той или иной мере, только массовое строительство «электронных телег обмена» (без учёта главного — смыслов их содержимого!).

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

Да, можно стандартизовать вид почтового конверта, но получателям и отправителям нужно другое — смысл самого письма!

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

Ничего! Ни Слова!

Результативность своей деятельности по реализации Систем Межведомственного Электронного Взаимодействия с использованием SOA-парадигмы оценивается мировым сообществом количеством запросов на обмен, при этом не учитывается ни их смысл, ни целесообразность, ни синхронизация передаваемых данных по времени, количеству и качеству.

Ничего не напоминает?

И при такой SOA-реализации интеграции и взаимодействия информационных систем кто-то еще надеется получить целостное непротиворечивое единое, синхронизированное по времени, достоверное информационное управленческое пространство?

Повторю, стратегия развития информационных архитектур и технологий, ориентированная на SOA, является тупиком.

Нет в SOA принципиальных решений по реализации высокой динамики структурного изменения информационно-функционального пространства.

Не решен вопрос:

как на изменение требований должны реагировать уже функционирующие распределено разработанные отдельные сервисы? Опять их переделывать, тестировать, итерационно дорабатывать и постоянно катастрофически опаздывать, передавая потребителю всегда «несвежий» продукт вчерашней актуальности?

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

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

SOA — отличный глобальный бизнес-проект не ОБМЕНА, а ОБМАНА и «развития» ИТ для нового вида освоения денежных средств заказчика:

А теперь представьте, что будет со «строительством» единого целостного «здания», если у каждого «кубика» в разное время по-своему и непрерывно должны изменяться форма, содержание и поведение из-за динамичного изменения требований к ним, например, изменились автоматизируемые объекты и процессы управления, выявлены ошибки или необходима дальнейшая оптимизация и развитие.

Модернизация и интеграция миллионов модулей фрагментарных информационных систем всех компаний мира: SAP, ORACLE, GOOGLE, EADS, THALES, LOCKHEED MARTIN, IBM, Microsoft, SAS и других – находится в концептуальном тупике, создает угрозу национальной и глобальной безопасности.

Кроме того, ИТ-специалисты одумайтесь, откройте глаза!

Надо наконец понять полную абсурдность SOA-предложений, в том числе лидеров информационных технологий: IBM, Microsoft, ORACLE, SAP и других:

Предлагается проблемы семантической интероперабельности N-интегрируемых функциональных программных систем (модулей) решить, добавив к ним ещё новых М-программных систем интеграции.

Все равно, что огонь заливать бензином!

То есть попытки справиться со сложностью привели к еще большему усложнению.

Мы понимаем, что ИТ-лидерам сложно отказываться от архаичных, но таких родных десятилетиями выстраданных программных модульных систем и всего разношерстного «лучшего» старья, которое они скупили и поглотили по ИТ-рынку.

Но король-то голый!

Пейджеры, телеги, паровозы, и т.п. нам всем когда-то тоже послужили, но их время безвозвратно прошло.

семантическая интероперабельность трёх и более динамических программных приложений не достижима.

Service-Оriented Architecture/SOA – Сервис-Ориентированная Архитектура, Системы Межведомственного Электронного Взаимодействия/СМЭВ не могут обеспечить единое адаптивное информационно-функциональное управленческое пространство.

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

• многократное избыточное несопоставимое описание в различных функциональных информационных системах одинаковых предметов и процессов;
• концептуальная несовместимость, нецелостность, противоречивость и т.п. описания и реализации общих частей предметной области: структуры данных и методов обработки, а также и самих данных в хранилищах разных систем;
• различное время внесения изменений в идентичные данные в различных системах, принципиальная невозможность запросами и обменными операциями синхронизировать по времени и данным всё информационное пространство и, следовательно, обеспечить достоверность обрабатываемой и передаваемой информации, единое информационное пространство;
• дополнительное программирование в SOA-парадигме по два и более принимающих и передающих сервисов для каждой ведомственной функциональной программы (в зависимости от количества внешних информационных систем, с которыми необходимо реализовать обмен);
• при каждом изменении требований многократное переписывание, тестирование, ввод в опытную и промышленную эксплуатацию как функциональных программных систем, так и принимающих и передающих сервисов;
• необходимость надсистемного описания и дальнейшего поддержания в актуальном состоянии обобщенного знания об обработке данных, произвольным образом распределенного между структурой, методами и интерфейсами в различных интегрируемых системах;
• наличие в системах собственных хранилищ данных исключает возможность простой потоковой обработки;
• распределенная независимая параллельная разработка модулей сложных функциональных систем приводит к тому, что разработка системы одной крупной части предметной области неизбежно входит в противоречие с одновременной, но отдельной разработкой системы другой крупной части предметной области, что в дальнейшем усиливается субъективными аспектами различия в кодировании программ;
• обеспечение взаимодействия систем между собой становится еще одним «видом деятельности», превышающим по времени и другим ресурсам сопровождение эксплуатации и развития самих систем;
• замедление и ограничение скорости модификации в ответ на увеличивающийся рост динамики изменений реальных объектов и процессов управления, увеличение количества интегрируемых систем и повышении их сложности;
• проблемы обеспечения интероперабельности программных комплексов приводят к существенному падению работоспособности информационных систем в целом;
• отсутствие и принципиальная невозможность реализации комплексной системы безопасности фрагментарных программных систем и межсистемного интеграционного информационного пространства;
• низкая надежность сложных программных комплексов, требующих интеграции, которая определяется минимальным уровнем надежности входящей в него системы;
• высокие финансовые, временные, кадровые и другие издержки на развитие, модернизацию, сопровождение и эксплуатацию;
• и многие другие проблемы.

ИТ-лидеры – выдохлись. «Механистическая» кибернетика отжила своё и умирает. Издержки увеличиваются, а полезность, адекватность, надёжность, безопасность и т.п. комплексных сложных систем снижается.

Изобретая информационныесистемы будущего

Растёт потребность в комплексном решении все более сложных, взаимосвязанных, динамично изменяющихся и развивающихся разно-дисциплинарных задач. Сегодня все приходят к пониманию, что необходимо коллективно и распределенно создавать и использовать адекватные адаптивные «живые» (природоподобные) информационные системы.

ПРЕДЛАГАЕТСЯ вообще не решать задач обмена, в том числе сообщениями.

Перейти от обеспечения интеграции, семантической интероперабельности, синхронизации развития ПО к главному – новой сетецентрической GGG-архитектуре (Глобальный Гносеологический Граф/Global Gnoseology Graph, GRAPH, G3): коллективно распределенно создавать единое целостное адаптивное информационно-функциональное сетевое управленческое пространство.

Поэтому в GGG-технологиях изменена сама парадигма решения СИ-проблемы интеграции — в информационных сетецентрических GGG-системах управления она концептуально исключена.

Более детально с сетецентрической GGG-архитектурой можно ознакомиться в работах «Теория эволюционного моделирования», «Конец информационного общества», «Робот по программированию», «Модель знания. Мера знания» и других.

Однако, что же делать с унаследованным программным обеспечением? Ведь нельзя же в одночасье всем вместе перейти на новую сетецентрическую G3-Aархитектуру.

Поэтому в предложенных инновационных GGG-технологиях решались две задачи:

• Создать «идеальную» информационную технологию «бесшовного» Будущего.
• Создать технологию Эволюционной Миграции в Будущее.

При этом для решения данных задач разработаны и промышленно используются следующие технологии:

1. Создание «идеальной» информационной технологии «бесшовного» Будущего включает следующие основные GGG-технологии:

• G3A — сетецентрическая архитектура глобальной информационной системы управления,
• G3LC — «биологический» двухэтапный жизненный цикл информационных систем,
• G3L— визуальный эволюционно развивающийся язык описания единого «генезиса» (семантической модели) сетецентрических информационных систем;
• G3EM— коллективное эволюционное создание единой адаптивной семантической модели наших совокупных знаний в виде однорангового G3-гиперграфа классов – «ДНК» проектируемых информационных систем;
• G3AP — автоматическое программирование адаптивных информационных сетецентрических систем управления на основе единой семантической модели проектирования (G3-гиперграфа классов)

2. Создание технологии Эволюционной Миграции в Будущее: система перехода к GGG-технологиям с постепенным «безболезненным» замещением унаследованного ПО на инновационное сетецентрическое с использованием технологии G3I (G3-Интегратор).

• G3I — GGG-технология, осуществляющая эволюционное «проецирование», то есть описание внешних унаследованных информационных систем на новом языке G3L с помощью специальных классов гиперграфа Хохловой в сетецентрической среде G3EM.
• Автоматическое программирование G3AP создаёт “свои” новые пользовательские интерфейсы к внешним системам, кроме того данные внешних систем используются “на чтение” в различных функциях обработки.

Реализуется постепенное эволюционное замещение («прорастание сквозь» внешние системы). При этом замещение происходит тем быстрее, чем больше объединяется унаследованных систем и динамичней идет изменение требований к ним.

Осуществлен переход от примитивного обмена сообщениями — к главному: совместной взаимосвязанной коллективной работе в единой сетецентрической среде.

Опыт использования «поглощающей» интеграции G3I показал, что сроки и стоимость интеграции уменьшается при увеличении количества интегрируемых систем, то есть наблюдается обратно пропорциональная зависимость.

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

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

Со временем, при использовании G3I, из каждой новой интегрируемой внешней информационной системы порой ничего нового и не почерпнешь, ну может быть ряд свойств, методов, набор данных. На глазах «тает» искусственная сложность, порождаемая фрагментарными модульными информационными системами.

Интеграция G3I является вынужденной временной компонентой эволюционного «бесшокового» перехода в единую новую глобальную сеть GGG, GRAPH коллективного управления.

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

G3-технологии эффективно использовались в более 800 проектах национального масштаба.

На основе реализованных проектов сформированы управленческие тренажёры – сетецентрические информационные G3-системы коллективного пользования с контрольными примерами для демонстрации и обучения навыкам работы в GGG (GRAPH) сетях нового поколения.

Наиболее популярны тренажёры: «G3-РОССИЯ», «G3-КОРПОРАЦИЯ».

В настоящее время робот по программированию успешно работает с единым гиперграфом – G3S, включающим:

сотни тысяч вершин (классы содержание, форма, поведение), более 2 миллиардов связей, около 100 000 взаимоувязанных таблиц базы данных (например, ORACLE), около 10 миллиардов записей, которые описывают знания об объектах и процессах управления проектов «G3-РОССИЯ», «G3-КОРПОРАЦИЯ».

На основании результатов экспертиз и отзывов международных организаций, структур NATO (RTO, SPS, NAMSA,..), ведущих институтов РАН и государственных корпораций можно утверждать, что предлагаемые технологии и системы не имеют мировых аналогов и на 5-10 лет превосходят уровень мировых фундаментальных исследований в этой области.

G3-технологии обладают лицензионной чистотой и прошли регистрацию в Роспатенте. Ряд разработчиков удостоены Премии Правительства РФ в области науки и техники за исследование, разработку и внедрение в промышленность инновационных технологий Глобального Гносеологического Графа.

Виды сведений

Участники обмениваются данным через виды сведений (протоколы обмена) — правила формирования пакетов данных для передачи от одного участника другому.

Хороший пример вида сведений — Всероссийская перепись населения 2020. Данные о переписи передают федеральным органам исполнительной власти в электронном виде. В полученных данных существует чёткая структура сведений: ФИО, пол, дата рождения, гражданство, семейное положение. Также в рамках вида сведений описан ответ, который должен быть получен, если обработка запроса прошла успешно.

На июнь 2020 года в СМЭВ зарегистрировано более 1000 промышленных (рабочих) и 2000 тестовых видов.

Обмен данными в промышленной среде по всем видам сведений ведётся через защищённые каналы связи. Все передаваемые данные сопровождаются электронной цифровой подписью, с помощью которой СМЭВ идентифицирует участников взаимодействия.

Данные передаются по протоколу SOAP, при этом каждое сообщение представляет собой вложенную структуру:

Виды сведений делятся на две группы — простые и универсальные. Рассмотрим схему обмена данными по простому виду сведений:

На схеме видно, что данные форм отображаются непосредственно в конверты обмена данными. Из-за этого появляется ограничение: необходимо разработать структуру блока данных, запроса/ответа для каждого такого вида сведений.

Обмен по универсальному виду сведений можно представить так:

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

• номер заявления портала и сведения, позволяющие определить услугу;
• целевое подразделение, к которому пользователь обращается за услугой.

Данные формы, заполненные пользователем портала, пакуются во вложение к основному сообщению.

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

Постановка задачи

С учётом приведённых выше особенностей, нашей команде предстояло обеспечить интеграцию ИС заказчика с «Госуслугами» по универсальному виду сведений. Информационная система заказчика — ИАС «Градоустройство». С её помощью пользователи ведомств, ответственные за оказания услуг, могут собирать пакеты документов и формировать результаты для дальнейшей передачи на портал через СМЭВ.

Итак, СМЭВ, как в поговорке про слова в песне, нельзя исключить из решения задачи интеграции с порталом государственных услуг. Но это к лучшему: благодаря системе у всех участников есть универсальная среда взаимодействия. Это позволяет опираться на определённый стандарт и не изобретать велосипед.

В следующих статьях мы рассмотрим, как на стороне поставщика сведений организовать обработку заявлений по данным пользователя с использованием движка автоматизации бизнес-процессов Workflow Core.

Участники взаимодействия

Представим, что «Госуслуги» — это магазин, на витрине которого представлены сервисы для граждан и организаций. Запрос «покупателя» на услугу передаётся соответствующим органам через систему межведомственного электронного взаимодействия (СМЭВ). Система передаёт сообщения между порталом и ведомством.

Работа через СМЭВ происходит по протоколу SOAP (Simple Object Access Protocol — простой протокол для доступа к объектам).

Участники взаимодействия, как в магазине, делятся на поставщиков и потребителей. Поставщик — это информационная система (ИС), которая предоставляет сведения по запросу, а потребитель — система, запрашивает сведения.

Одна и та же ИС может действовать сразу в двух ролях. Например, в процессе предоставления услуги нужно уведомить портал о смене её статуса. В этом случае ИС-поставщик исполняет роль потребителя — проводит информационный обмен по статусам.

Очереди сообщений и процесс взаимодействия

В процессе взаимодействия сообщения помещаются в очереди входящих запросов и очереди входящих ответов. По сути очереди — это контейнеры, в которых содержатся сообщения по видам сведений.

Взаимодействие с очередями происходит с помощью специальных запросов. Более подробно они описаны в методических рекомендациях по работе со СМЭВ. Отметим только то, что благодаря очередям становится возможным асинхронный обмен данными: потребитель может оставить заявку на получение сведений, а поставщик — разместить ответ.

Следует помнить: чтобы забрать сообщение из очереди, необходимо подтвердить его получение с помощью Ack-запроса. В противном случае СМЭВ посчитает сообщение недоставленным и вернёт его в очередь через 15 минут после извлечения.

На каждый запрос может поступить как успешный, так и неуспешный ответ.

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

• Произошло расхождение справочных данных на портале и у поставщика;
• Нужного соответствия просто нет в настройках системы поставщика.

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

Успешный ответ предполагает сценарий, в котором результат услуги — это набор файлов (что бывает довольно часто). Перед отправкой результата необходимо выгрузить файлы в файловое хранилище СМЭВ на основе FTP-сервера. Названия файлов и их контрольные суммы нужно зафиксировать в пакете, который отправляем через SOAP. Таким образом, есть две операции по передачи данных, которые нужно связать общим контекстом — сведениями о файлах.

На практике встречаются случаи, когда во время взаимодействия СМЭВ находится в режиме обслуживания, и запросы участника оборачиваются неудачей и требуют повторной отправки. Неудачу нужно зафиксировать и отправить запрос повторно.