Региональная интеграционная шина что это в госуслугах
Обновлено: 17.05.2024
Сегодня практически все компании внедрили в свою структуру множество систем. Разной архитектуры, на разных платформах, для решения разных задач — но все эти приложения и процессы нужно связать в единую комплексную систему каким-то одним удобным средством. Чтобы для пользователя процесс был цельным, понятным, всё работало слаженно и не требовалось бы двойного ввода данных.
Развитие потребности
Эволюция интеграционных решений
Принято выделять три эпохи в развитии интеграционных систем.
Раньше возможности виртуализации позволяли просто добавлять виртуальной машине все больше ядер и больше памяти, создавая монструозные единые системы.
Сейчас цифровая трансформация требует разбиения этих единых решений, внедряя вместо этого интеграцию систем. Сегодня необходимо повторно использовать многие куски кода, обеспечить их независимость, возможность создания новых версий, форков этого кода.
Стоит отметить рост подобных запросов именно от бизнеса.
Тренд смещается от ИТ для ИТ, к ИТ для бизнеса.
Основных схем интеграции две : оркестровка и хореография. Оркестровка — это большая централизованная схема, где всем управляет оркестратор. Хореография — схема, где элементы распределённые, децентрализованные, и каждый, как танцор, выстраивает свой танец, взаимодействуя с другими. На уровне бизнеса схемы одинаковы, а вот на технологическом уровне — это разные процессы.
Сложности интеграции
На этапе запуска глобальных проектов, после внедрения обращений в службу технической поддержки много: возникают инциденты, дефекты, запросы на доработку. А вот на этапе стабильной работы практически никакие изменения в систему не вносятся. Для финансовой организации есть и такая специфика: в конце года, в период высоких продаж, изменений в коде лучше избежать.
Так когда нужна шина?
Перед внедрением технологии всегда важно верно оценить затраты, которые предприятие готово понести на начальном этапе. Многие аналитические компании, такие как Forrester и IDC, отмечают: более половины провалов проектов вне зависимости от масштабов компаний объясняются недооценкой сложности интеграции.
Шина не панацея. Уместность её применения зависит от конкретных случаев: так, она однозначно подходит для разрозненных приложений, работающих с огромными массивами данных, или там, где нужно осуществлять много мелких итераций приложений между собой (например, XML).
В случае высококонкурентного бизнеса потребность в интеграционной шине диктуется необходимостью изменений бизнес-модели. Более статичный бизнес позволяет отложить такое решение: иногда вместо внедрения шины достаточно привлечь одного дополнительного сотрудника для закрытия возникших потребностей.
В последние годы всё больше запросов на интеграцию исходит от бизнеса. Часто речь идёт об инициативах запуска приложений в новых средах, интеграции с возможностями мобильного устройства — то есть о задачах фронт-офиса, а задачи бэк-офиса уже так или иначе решены.
Открытый исходный код: спасение или угроза?
Многие пользователи опасаются открытых платформ, ведь это может означать недостаточную защищённость данных. Здесь важна репутация разработчика.
Open-source как бизнес-модель, приносящая клиентам инновации, выигрывает. Продакт-менеджеры постоянно находятся в интернациональном сообществе разработчиков, черпая оттуда инновации, когда новый код возникает в ответ на бизнес-потребность — и в этом разительное отличие от проприетарных конкурентов и последователей. Компания-клиент иногда не может себе позволить штат даже из 50 программистов — а так она получает доступ к сотням тысяч специалистов. В современных экономических условиях это особенно важно.
Считаем затраты
В прежней системе 80% процентов затрат уходило на ИТ, на бизнес-задачи оставалось 20%. Во внутренней экосистеме интегрированных информационных сервисов, наоборот, 20% расходов тратится на поддержку и общие сервисы, а 80% — на то, что нужно бизнесу.
В целом, на начальном этапе выше затраты на непосредственное внедрение, чем на поддержку, а вот затем поддержка может разрастись, поскольку увеличивается количество процессов, а затраты на разработку могут сократиться.
Ярослав Макаров
Директор по развитию бизнеса ГК Аплана
Во второй версии продукта реализован ряд доработок и улучшений на основании опыта внедрений системы у наших заказчиков. Рассказываем подробнее о нововведениях
Мониторинг состояния транспортного слоя
Переотправка и повторная загрузка пакетов
Замеры времени и оценка производительности
В универсальный коннектор добавлены замеры времени суммарной длительности обращений к транспортному слою. Замеры считаются в рамках работы одного потока и записываются один раз в конце работы потока при его успешном завершении. В качестве веса замера используется количество обработанных пакетов или иных итераций обработки.
Также был проведен рефакторинг замеров по всем регламентам, например, были добавлены замеры длительности прикладной обработки пакетов и проверки конфигурации на изменение.
Активный режим работы
В новом релизе стала удобнее настройка активного режима работы системы - появился параметр “Приоритет активного режима”, который помогает настраивать применение активного режима исходя из приоритета пакета.
Повышение юзабилити при работе с форматами и правилами
Реализован импорт объектов формата из объектов метаданных с заполнением описания объектов формата по синонимам реквизитов, а также импорт различий из обработки сравнения
форматов, а также автогенерация кода правил для регистров сведений.
Подсветка кода, форматов и правил
Стала доступна подсветка xml и xsd документов (например, в журналах отправки и получения). В универсальном коннекторе 1С подсветка поддерживается и для версий платформы ниже, чем 8.3.14
Также для удобной работы и написания кода правил конвертации реализовали подсветку кода встроенного языка 1С, это помогает программистам быстрее ориентироваться в коде и писать его путем автоматического дополнения.
Доработана обработка по управлению версиями формата и конвертаций, которая упрощает настройку за счет подсветки только несопоставленных форматов и правил.
Редактор маршрутов
Реализовали настройку маршрутов для транспортного слоя в визуальном виде без программирования (по принципам low code). Можно реализовать любой произвольный маршрут (для которого есть нужные библиотеки в транспортном слое).
Отложенное выполнение заданий и их контроль
Теперь в универсальном коннекторе задания интеграционной шины (например, по выгрузке данных) можно либо приостановить, либо запланировать к отправке не ранее указанной даты, не меняя приоритет.
В том числе, в случае ошибки при выполнении задания (например, при переполненности очереди получателя), теперь задания откладываются для выполнения на будущее. Информация о приостановленных по причине ошибки заданиях выводится на специальной странице Панели Администратора (нет необходимости ручного контроля и перехода в отдельную форму), из которой их можно выборочно или все сразу повторить.
Стоп-лист на загрузку отдельных объектов метаданных
В системе с внедренным универсальным коннектором администратор теперь может задать в разрезе метаданных признак блокировки загрузки этих объектов при любых обменах от любых отправителей (это может потребоваться, например, если база является эталонной системой для каких-то определенных объектов).
Уведомления по ответственному и переход в журналы
Стало доступно персональное оповещение по объектам - в случае ошибки обмена в системе-получателе, уведомление получит конкретный пользователь, ответственный за объект в системе-отправителе.
Также теперь доступен быстрый переход из События к соответствующим записям в журнал отправки или получения (определяется автоматически).
Настройка доступности систем
обеспечивают взаимодействие операторов ЭДО и EDI с интеграционной шиной DiState: Мультипровайдер, что снимает нагрузки с ERP компании.
избавляет от потерь документов и упрощает настройку ЭДО с контрагентами — взаимодействие с любыми операторами происходит напрямую через коннекторы.
с учетной системой настраивается один раз и не зависит от количества подключенных сервисов ЭДО и EDI к DiState: Мультипровайдер
формируется автоматически и включает электронные документы, подписанные до внедрения
DiState: Мультипровайдер.
документов компании в DiState: Мультипровайдер и её документов в подключенных системах ЭДО и EDI полностью идентична.
реализован в рамках собственного сервиса ЭДО, где функции доверенного оператора удаленно выполняет компания ДиСтэйт.
Коннекторы Получение документов Отправка документов Согласование Маршрутизация Автоподписание Мультиподпись Сверка документов Свой сервис ЭДО
Коннекторы обеспечивают обмен данными между личными кабинетами компании в других системах ЭДО и EDI и DiState: Мультипровайдер. Именно они отвечают за получение и отправку документов.
Контрагент отправляет документ в любой системе ЭДО. Подключенный к этой системе коннектор загружает документ в DiState: Мультипровайдер. Доставка документа в учетную систему происходит за несколько секунд. Подробнее
Как это происходит:
Решение автоматически определяет маршрут и направляет исходящий документ контрагенту через личный кабинет нужной системы ЭДО. Подробнее
Как это происходит:
- Исходящий документ обрабатывается и попадает в шину данных.
- Из шины данных его забирает коннектор и направляет в личный кабинет контрагента в системе ЭДО.
Компания определяет маршрут утверждения документов. Перед окончательным подписанием и отправкой документы проходят внутреннее согласование.
Документ проверяется на отсутствие ошибок и отправляется далее по заданному компанией маршруту.
Позволяет автоматически подписывать и отправлять обратно поступающие документы.
Позволяет использовать несколько КЭП для подписания документов и деактивировать их при необходимости.
Альтернативным решением обмену через коннекторы является свой сервис ЭДО. Контрагенты, не подключенные к операторам, смогут бесплатно обмениваться с вами документами на вашей площадке.
Поддержка различных стандартов и сценариев интеграции с помощью интеграционной шины данных
Довольно часто при построении композитных приложений приходится сталкиваться с ситуацией, когда различные типы приложений рассчитаны на различные стандарты и схемы интеграции. Также не редка ситуация, когда изменение интеграционных механизмов существующих приложений невозможно или трудоемко по ряду причин: отсутствие разработчика, отсутствие исходного кода и т.д. Интеграционная шина DATAREON ESB позволяет объединять такие приложения в единое целое, скрывая различия в интеграции на уровне механизмов и настроек типовых коннекторов, что приводит взаимодействие приложений к единой управляемой схеме интеграции.
В DATAREON ESB существуют следующие типы коннекторов:
Все коннекторы имеют возможности параметрической настройки подключения к системе-источнику и взаимодействию с ней.
Список доступных коннекторов постоянно расширяется, полный перечень необходимо уточнять в компании DATAREON.
Реализованы удобные мастера, которые позволяют создавать обработчики для 1С:
В DATAREON ESB реализованы механизмы отладки обработчиков 1С без использования конфигуратора 1С. Отладка кода 1С выполняется непосредственно из центра управления DATAREON ESB.
Данный механизм позволяет проверить, каким образом будут выгружены или загружены данные в 1С без их сохранения в 1С и без прямого доступа к системе.
Централизованное управление
Для выполнения задач централизованного управления интеграционным ландшафтом DATAREON ESB использует экосистему Eclipse. Использование Eclipse предоставляет пользователю широчайшие возможности по расширению доступного функционала DATAREON ESB. Центр Управления предоставляет мощные и удобные инструменты проектирования потоков данных, разработки алгоритмов трансформации, развитые средства администрирования и контроля.
В DATAREON ESB присутствует множество визуальных инструментов настройки. Например, мастер настройки и управления информационными потоками:
Трансформация данных
Масштабируемость интеграционной шины
С помощью интеграционной шины DATAREON ESB можно организовать передачу данных любого размера. Поддерживаются возможности вертикального и горизонтального масштабирования. Развитые механизмы диагностирования состояния оборудования и балансировки нагрузки позволяют получить максимальную отдачу от имеющегося серверного и сетевого оборудования. Использование DATAREON ESB дает возможность плавно наращивать мощности в соответствии с планами развития ИТ-ландшафта компании. При этом архитектура сети может строиться из решений различного типа под управлением различных операционных систем (построение гетерогенного ландшафта). На уровне серверов передачи данных DATAREON ESB возможно реализовать секционирование информационных доменов с выделением изолированных кустов.
Архитектура DATAREON ESB построена на компонентной модели со слабыми связями, что позволяет легко выполнять горизонтальное масштабирование сети передачи данных. Все компоненты работают в среде с активным мониторингом их состояния и отдельным механизмом, реализующим управление в сценариях отказа или потери управляемости любым компонентом системы. Реализована реактивная модель управления в рамках физического узла сети.
Использование DATAREON ESB позволяет выйти на новый уровень интеграции и получить высокую скорость обмена информацией. В отличие от традиционных схем интеграции, когда производится накопление информации, DATAREON ESB позволяет построить интеграцию на базе событийной модели с передачей небольших информационных пакетов. Такой подход резко снижает требования к пропускной способности каналов связи, повышает скорость доставки и последующей обработки информации. Использование событийной модели позволяет строить композитные приложения с высокой доступностью и оперативной реакцией внутри распределенных бизнес-процессов. При этом DATAREON ESB позволяет централизовать разработку и управление потоками данных в рамках различных процессов, предоставляет единую точку администрирования потоков данных.
Безопасность и ролевая модель
Обеспечение безопасности при передаче данных традиционно недооценивается, а ведь в большинстве случаев утечки конфиденциальных данных происходят именно при их передаче.
Для обеспечения безопасности данных в DATAREON ESB поддерживается шифрование передаваемых данных с помощью алгоритмов шифрования AES, RC2 или TripleDES. Также поддерживается установка безопасного сетевого соединения по протоколу SSL или TLS.
Несмотря на то, что управление и настройка передачи данных для всей сети выполняется из единого инструмента управления, ответственность за работоспособность различных компонент может разделяться между пользователями. Разграничение прав доступа выполняется посредством ролевой модели. Уровень доступа пользователей может быть настроен в разрезе каждого объекта DATAREON ESB. Это позволяет разделять группы пользователей по зонам ответственности и ограничивать доступ к объектам DATAREON ESB согласно полномочиям.
Проактивная диагностика и мониторинг
DATAREON ESB обладает широкими возможностями для диагностики и мониторинга состояния как всей сети передачи данных, так и каждого компонента DATAREON ESB в отдельности.
В центре диагностики представлена полная схема компонентов DATAREON ESB, их взаимосвязи, текущий статус и детальная информация по каждому компоненту (состояние точек подключения, статистика и состояние очередей передачи данных, журнал трассировки информационных пакетов, журнал работы узла).
Центр диагностики сигнализирует не только об ошибках, но и потенциальных проблемах в схеме сети до появления самих ошибок, а также дает рекомендации по их устранению.
Для более глубокого анализа в центре диагностики доступна работа со счетчиками производительности системы за определенный период времени. Данные могут быть экспортированы в MS Excel.
Предусмотрены механизмы рассылки уведомлений для оповещения системных администраторов об ошибках системы.
В DATAREON ESB также имеются мощные инструменты для отладки сценариев передачи данных, включающие:
Диагностическая информация представляется в виде следующей диаграммы:
Для детального разбора инцидентов, возникающих в процессе передачи данных, в DATAREON ESB предусмотрены механизмы трассировки. Специальный трассировочный журнал можно включить в том или ином компоненте DATAREON ESB; в журнале собирается большое количество данных, в том числе содержимое информационного пакета.
Пример построения сети объектов ESB:
Читайте также: