Esb интеграция: объяснение и цель

Когда интеграция не нужна

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

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

Типичным недостатком такого подхода является зависимость от одного вендора. Так, если в портфеле компании разработчика нет какого-то нужного для нашего бизнес процесса решения, то нам придется либо начинать разводить “зоопарк” с другими решениями и интеграцией, или использовать Paper Net. Также, экосистема на основе решений одного вендора в плане лицензий стоит как правило дороже чем “зоопарк” из решений разных вендоров.

Принципы работы корпоративной шины данных

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

1. Единообразие интерфейсов: Корпоративная шина данных предоставляет унифицированные интерфейсы для обмена информацией. Это означает, что приложения могут обмениваться данными, используя общий набор стандартных протоколов и форматов данных. Это упрощает интеграцию различных систем и улучшает совместимость.
2. Асинхронная передача данных: Корпоративная шина данных использует асинхронный подход для передачи информации. Приложения могут отправлять данные на шину данных, не ожидая мгновенного ответа. Это позволяет увеличить производительность и отзывчивость системы, так как приложения могут продолжать работать, даже если получатель данных временно недоступен.
3. Маршрутизация сообщений: Корпоративная шина данных имеет возможность маршрутизации сообщений на основе определенных правил и условий. Это означает, что шина данных может определить, какие приложения или системы должны получить определенные данные. Это улучшает гибкость и контроль при передаче информации.
4. Трансформация данных: Корпоративная шина данных может выполнять трансформацию данных перед их передачей между системами. Это позволяет преобразовывать данные из одного формата в другой или применять различные правила обработки данных. Трансформация данных в шине данных способствует согласованности и совместимости различных систем.
5. Мониторинг и управление: Корпоративная шина данных обеспечивает возможность мониторинга и управления передачей данных. Это позволяет отслеживать статус передачи данных, контролировать производительность системы и реагировать на сбои или ошибки. Мониторинг и управление в шине данных повышают надежность и эффективность интеграционной платформы.

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

Этапы внедрения платформы

Интеграционная платформа «Продвижение» разворачивается на серверах заказчика, включая веб-сервер обработки входящих подключений, сервер веб-приложения, сервер среднего звена и сервер базы данных (рисунок 2). Серверная часть платформы функционирует под управлением операционной системы Ubuntu Linux, также возможно ее функционирование на UNIX или Microsoft Windows Server. Платформа реализована на Java. В качестве сервера приложений используется Wildfly, в качестве СУБД — PostrgeSQL или иная, поддерживающая JDBС.

Допускается масштабирование сервера веб-приложений путем наращивания количества экземпляров при возрастании нагрузки. При масштабировании сервера веб-приложений наличие веб-сервера обработки входящих подключений является обязательным. В его качестве используются Apache или NGINX. Для обеспечения функционирования платформы также требуется установка КриптоПро CSP, EclipseBIRT, Lucene.

Справочники единой НСИ автоматически обновляются из внешних источников — при их наличии по расписанию. Например, справочник учреждений и органов власти обновляется по данным Сводного реестра участников и неучастников бюджетного процесса единого портала бюджетной системы, справочник банков — по данным портала Центрального банка России, перечень федеральных кодов цели — по данным официального сайта Казначейства России и т. д. Актуальные коды региональной и муниципальной классификации вводятся операторами нормативно-справочной информации, при необходимости загружаются из файлов установленного формата.

После наполнения и выверки единых справочников к интеграционной платформе подключаются прикладные информационные системы, настраиваются бизнес-процессы, происходит их интеграция с прикладными системами. В том числе настраиваются бизнес-процессы ведения единой НСИ.

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

Заключительный этап внедрения интеграционной платформы — регистрация и обучение пользователей. В процессе регистрации и настройки прав пользователей участвуют администраторы разных уровней. Глобальные администраторы управляют пользователями любых организаций и любых бюджетов без ограничения. Они могут назначать администраторов любого уровня и определять их полномочия. Ведомственные администраторы управляют пользователями своего и подведомственных учреждений, а также назначают локальных администраторов в пределах своего бюджета. Локальные администраторы управляют пользователями только в пределах своей организации. Пользователи всех прикладных систем регистрируются в реестре единых учетных записей. Для каждой учетной записи настраивается перечень функциональных ролей, которые выполняет пользователь в каждой прикладной системе. После активации учетных записей пользователи могут войти в личный кабинет и далее перейти в доступные им прикладные системы.

Но я слышал, что SOA это XML, SOAP и веб сервисы¶

Да, некоторые люди хотели бы, чтобы вы верили именно в это.

Если люди или вендоры, с которыми Вы работали, отправляли закодированный в BASE64 CSV-файл в защищенном посредством SAML2 SOAP-сообщении, тогда вполне понятно, откуда у Вас сложилось такое впечатление.

XML, SOAP и веб сервисы — имеют свои сценарии использования, но как и все — они могут быть неправильно использованы.

SOA — о понятной и управляемой архитектуре

То, что какой-то сервис может использовать или не использовать SOAP практически не важно. SOA, как подход к архитектуре, будет все еще верным, даже если никакой SOAP сервис не будет использован вовсе

Если архитектор проектирует прекрасное здание, он не может слишком сильно повлиять на цвет интерьера.

Так что нет, SOA — это не XML, SOAP и веб сервисы. Они могут быть использованы, но они лишь часть, а не основа.

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

Типы по характеру взаимодействия

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

• Точечная (point-to-point). Этот метод заключается в прямом соединении двух систем между собой. Он достаточно прост в реализации и может быть эффективным для интеграции небольшого числа систем. Однако при увеличении количества систем такой подход может стать запутанным и трудноуправляемым из-за множества прямых соединений.

• Интеграция через шину (Enterprise Service Bus, ESB). Шина представляет собой промежуточное программное обеспечение, которое обеспечивает обмен данными между различными системами. Вместо множества прямых соединений, системы подключаются к шине, что упрощает архитектуру и улучшает масштабируемость.

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

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

Из чего состоит слой ESB

ESB условно делится на пять компонентов или функций: студия, брокер сообщений, логирование, мониторинг, хостинг.

1. Студия — графическая среда для разработки быстрых интеграций. Системы, параметры, действия визуализированы и максимально понятны. Функционала студии хватает на бóльшую часть действий, таких как передача и получение информации, преобразование и сбор атрибутов из одних потоков в другие. Здесь же можно задать параметры, которые ESB-шина должна отслеживать, считать ошибкой интеграции и пр. Если в рамках интеграции нужно уникальное действие, его можно написать парой строк на традиционных языках (например, Java) или специально разработанных.Без студии и, соответственно, без визуализации интеграций ESB не может считаться low-code решением.

Графическая студия ESB

‍

2. Для обмена сообщениями между системами используется брокер сообщений. Это активный компонент, который «забирает» и «отдаёт» сообщения, соблюдает их очерёдность и нивелирует нагрузку на системы, которые генерируют и получают сообщения (т. н. producer и consumer). Часто разработчики заблуждаются, называя ESB-системой именно брокер сообщений, например Apache Kafka или RabbitMQ.

‍

3. Логирование — это фиксация всего, что происходит с сообщением. Какая система его генерирует, как оно обрабатывается, куда попадает (или не попадает) в итоге. Логирование позволяет чётко понять, движется ли сообщение по заданному маршруту и на каком этапе и по какой причине возникла проблема.

‍

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

Каждое из ESB-решений предлагает на выбор несколько возможностей размещения. Например, некоторые системы позволяют опубликовать интеграцию в частном облаке Kubernetes, OpenShift, Amazon вообще без настройки. Для публикации внутри вашего уникального кластера потребуется работа архитектора.В этой статье мы разберём, как реализованы компоненты ESB в решениях, которые чаще всего предлагают на российском рынке: Talend, Mule, WSO2, Red Hat Fuse. Иногда разработчики дополняют список брокерами сообщений Apache Kafka (плюс Kafka Connect) и RabbitMQ, но эти два решения не являются ESB и рассматривать их в рамках данного разбора нецелесообразно.

Плюсы и минусы различных типов

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

Точечная:

Плюсы:

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

Минусы:

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

Интеграция через шину (ESB):

Плюсы:

Гибкость архитектуры благодаря централизованному управлению.
Упрощение масштабирования и добавления новых систем.

Минусы:

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

Оркестровка процессов:

Плюсы:

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

Минусы:

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

Событийно-ориентированная:

Плюсы:

Динамичное взаимодействие систем в реальном времени.
Оптимизация производительности за счет асинхронного обмена данными.

Минусы:

Platfrom V Synapse — с чего начали

Мы проанализировали возможные варианты и поняли, что паттерн Service Mesh отлично подходит под наши задачи. В Service Mesh за интеграционную обвязку, включая timeouts, retries, circuit breakers и так далее, отвечают конфигурационные файлы. Они поставляются вместе с исходным кодом, подхватываются контрольной панелью и распространяются на все микросервисы, участвующие в миграции через proxy-компонент (в нашем случае — Envoy).

Так как любая миграция — это всегда риск сломать что-то важное, пошли по пути parallel run. Решили оставить старую шину данных, построить рядом новую и добавить «смарт-топоры», которые отслеживают количество ошибок в мониторинге и в нужный момент переключаются на старую шину

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

Но нас ждали интересные открытия.

Перенос данных из УПП 1.3 в ERP 2 / УТ 11 / КА 2

Обработка позволяет перенести из УПП в ERP / 1С:УТ 11 / КА 2 всю возможную информацию. Переносятся документы, а также начальные остатки и справочная информация. Типовая обработка от фирмы 1С не позволяет сохранить документы за период работы. Кроме того, наши алгоритмы выгрузки начальных остатков тоже имеют больше функционала и тщательно проверялись на реальных проектах перехода с УПП на ERP.
При приобретении обработки вы будете 1 месяц получать ее обновления, далее можно приобрести подписку на обновления. Конфигурации 1С постоянно меняются, выходят новые релизы. Имея подписку на обновления, вы всегда можете быть уверены, что правила конвертации данных будут работать на ваших базах 1С.

50722
45650 руб.

341

Построение информационной системы

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

Общепринятой практикой построения ИАС является использование технологии хранилищ данных. Типовые хранилища данных и аналитические системы поддержки принятия решений часто описываются в терминах цепочки доставки информации (ISP – Information Supply Chain), например, см. книгу Ральфа Кимбала «The Data Warehouse Lifecycle Toolkit. Expert Methods for Designing, Developing, and Deploying Data Warehouses». Эта метафора основана на том факте, что данные в таких системах движутся от источников к приемникам (информационным системам) через ряд преобразований (рис. 1).

Рис. 1. Типовая архитектура информационно-аналитической системы

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

РЕКЛАМНЫЙ БЛОК

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

Очищенные в ОСД данные попадают в ЦХД – специализированную БД по всем предметным областям организации. Основное предназначение ЦХД – долговременное хранение всех исторических данных ИАС. Его также можно использовать для выполнения аналитических запросов или в качестве источника данных для моделирующих приложений.

К сожалению, невозможно разработать реляционную БД, одинаково эффективную и для хранения огромных объемов данных (10–1000 Гбайт), и для выполнения оперативных аналитических запросов. Ускорить работу приложений позволяют специализированные аналитические витрины данных (ВД), которые содержат лишь часть информации, связанной с решением одной или нескольких задач.

Следует заметить, что на витрины данных, которые построены на основе денормализованных реляционных или многомерных СУБД, накладывается ряд ограничений. Во-первых, каждая такая витрина должна описываться только в терминах многомерной модели данных, а, во-вторых, в одном хранилище данных все ВД должны строиться на основе одного общего набора измерений и показателей. Поэтому для эффективной интеграции компонентов ИАС и моделирующих приложений на уровне данных, необходимо осуществить их интеграцию на уровне метаданных.

Инструменты, управляющие метаданными, называются репозиториями. Они решают задачи семантической интеграции программных продуктов при создании СЦ (см. www.bi.lanit.ru). При такой интеграции большого количества программных продуктов естественным образом возникает проблема обеспечения информационной безопасности, которая разрешается за счет централизованных средств управления, основанных на использовании корпоративного LDAP-каталога. Единая система авторизации (single sign-on) делает интеграцию различных модулей СЦ совершенно прозрачной и безопасной для конечного пользователя.

Еще один немаловажный аспект функционирования ИАС связан с управлением системой непосредственно в процессе ее работы и получением полной и прозрачной картины обо всех выполняемых задачах и процессах. Для управления системой и для эффективного использования вычислительных ресурсов, необходимо иметь централизованную систему управления процессами, которая позволяет описывать сложную логику регламентов выполнения задач по обработке данных на основе Workflow-технологий.

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

Глубокая интеграция

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

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

Современные интеграционные платформы обладают
широкими функциональными возможностями, в связи с чем способны решать смежные
интеграционные задачи (рис. 3).

Рис. 3. Комплексное интеграционное
решение

Комплексное интеграционное решение на основе
технологий глубокого интеграционного подхода представляет собой интеграционную
платформу, состоящую в общем случае из всех интеграционных компонентов (рис.
3).

Основными преимуществами «глубоко» интеграционного подхода
являются:

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

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

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

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

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

Многоуровневое ЦХД с витринами данных

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

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

Причиной необходимости создания витрин данных является требование к надежности КХД, которое часто определяется, как пять или четыре девятки. Это означает, что КХД может простаивать не более 5 минут в год (99,999%) или не более часа в год (99,99%). Создание комплекса с такими характеристиками является сложной и весьма недешевой инженерной задачей. Требования к защите от терактов, саботажа и стихийных бедствий еще более усложняют построение программно-технического комплекса и осуществление соответствующих организационных мероприятий. Наличие витрин данных резко снижает нагрузку на КХД как по количеству пользователей, так и по объему данных в хранилище, так как эти данные могут быть оптимизированы под хранение, а не под обслуживание запросов. При использовании средств SRD (Sample, Restructure, Delivery – выборка, реструктуризация, доставка) количество пользователей сокращается до 1. В этом случае вся логика информационного снабжения витрин сосредотачивается в SRD. Витрины могут быть оптимизированы под обслуживание пользовательских запросов.

Что такое шина данных

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

Основными компонентами, составляющими современную сервисную шину, являются:

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

Горизонтальная интеграция

Начнем с широко распространенного подхода горизонтальной интеграции – использованию сервисной шины. То есть, мы можем развернуть промежуточное ПО — так называемую корпоративную сервисную шину.

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

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

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

Но у горизонтальной интеграции есть и свои преимущества. Мы можем заменять конечные системы прозрачно для всего процесса взаимодействия с шиной. При этом никаких изменений в других системах не требуется. Нам необходимо только переработать адаптер для новой системы для того, чтобы она могла также публиковать свои функции в шине. То есть, мы можем заменить SAP на 1С просто переписав адаптер. Хотя, сделать это не всегда действительно “просто”.

Почему классическое импортозамещение — машина времени в прошлое

 Часто компании представляют себе процесс импортозамещения Oracle примерно так:

У нас есть набор баз данных Oracle со слоем логики на PL/SQL, есть SAP, есть шина данных. И всё это нужно заменить, желательно один к одному.

Но «просто переезжать» с Oracle на PostgreSQL или любой другой open-source сложно и экономически невыгодно. Придётся останавливать или замедлять бизнес-разработки, переучивать команды, бороться с багами, заниматься миграцией. И всё это только для того, чтобы через год-два все изменения свелись к новому лейблу в архитектуре, а функциональность при этом осталась прежней.

Означает ли это, что импортозамещение невозможно и ничего менять не надо? 

Вот пример такого консервативного подхода — крупные ведомства и компании, которые ни разу не сталкивались с необходимостью импортозамещения.

Хотели бы вы заниматься поддержкой или развитием систем, созданных с использованием технологий полувековой давности? Не думаю. 

Получается, есть две крайности:

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

 Рассказываю, как мы решали эту дилемму в Сбере, с какими вызовами столкнулись и к каким выводам пришли.

Так что же такое Zato?¶

Zato — ESB и сервер приложений, написанный с использованием Python и может быть использован для построения промежуточных и бэкенд-систем. Это программное обеспечение с открытым исходным кодом с коммерческой поддержкой и поддержкой сообщества. И Python — язык программирования, известный своей простотой и эффективностью.

Использование Python и Zato позволяет увеличить производительность и тратить меньше времени впустую.

Zato был написан прагматиками для прагматиков. Это не еще одна наспех сооруженная вендором система на волне ESB/SOA шумихи.

На самом деле, Zato был построен исходя из практического опыта “тушения пожаров”, вызванных такими системами. В самом деле, авторы Zato провели настолько много времени в борьбе с такими окружениями, что они стали практически невосприимчивыми к любым пожарам.

Это кузница, из которой Zato вышел в мир и поэтому он может предложить производительность и простоту использования, которых нет в других похожих решениях.

Корпоративная сервисная шина данных DATAREON ESB (Enterprise Service Bus) предназначена для построения распределённого информационного ландшафта предприятия. Программный продукт обеспечивает взаимодействие всех интегрируемых приложений в одном центре, объединяя существующие источники информации и предоставляя централизованный обмен данными между разными информационными системами.

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

Автоматическая многопоточная выгрузка данных 1С 8.3 в БД Clickhouse и MS SQL (для работы с данными 1С в BI-системах)

Готовое решение для автоматизированной выгрузки данных из 1С 8.3, а также MS Excel в базу данных ClickHouse, а также в Microsoft SQL для работы с данными 1С в Yandex Datalens, Visiology, Apache Superset (и не только) — «Экстрактор данных 1С в BI».
Решение отлично работает со всеми типовыми (и не только) конфигурациями 1С 8.3 для управляемых форм.
Gозволяет автоматизировать работу бизнес-аналитика по ежедневной выгрузке данных из 1С в БД ClickHouse для последующей работы с этой БД в Yandex Datalens/
Система полностью автоматизирует работу с хранилищем данных в БД Clickhouse/MS SQL. Не надо быть программистом, чтобы одной кнопкой получать любые данные из 1С в Вашей BI-системе

230000 руб.

27

Проблемы интеграции данных

Прежде чем продолжить, давайте поймем, что объединение нескольких источников данных само по себе является серьезной проблемой. Вот проблемы, с которыми вы можете столкнуться:

Растущий объем данных

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

Совместимость

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

Качество данных

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

Блокировка поставщика

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

Обслуживание

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

Такие обстоятельства требуют корректировки процесса интеграции, отсюда и важность поддержания