Интеграционная шина данных что это

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

Примеры сценариев интеграции:

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

Консолидированная по магазинам информация по остаткам товаров отправляется из офиса в магазины автоматически по расписанию или по требованию. Эта же информация отправляется из магазинов в офис для консолидации в ответ на запрос из офиса остатков автоматически при получении запроса.

Видео:СПРОСИ ЭКСПЕРТА: Выпуск 1. Чем отличается шина данных от ETL?Скачать

Продукт «Интеграционная шина»

Для организации взаимодействия систем предлагается следующая последовательность:

1. Разработчик описывает интеграцию систем в специализированном редакторе, используя простую графическую нотацию.
   1. Маршрут движения сообщений представляется направленным графом, который показывает, как сообщения передаются от источников к назначениям.
   2. При необходимости можно определить сложный алгоритм маршрутизации сообщений или трансформировать сообщение при помощи процедуры на встроенном языке.
   3. Источником сообщения может быть файл, результат HTTP запроса, внешний брокер сообщений или подключенная к «Интеграционной шине» внешняя система (такие системы называются участниками взаимодействия).
   4. Полученное описание сохраняется в специальном объекте Процесс интеграции.
   5. Определяются параметры Процесса интеграции, значения которых будут определены во время исполнения (пути, адреса сервисов и пр.).
2. Созданные разработчиком Процессы интеграции разворачиваются на сервере «Интеграционной шины».
3. Администратору сервера доступен графический интерфейс управления «Интеграционной шиной», в котором:
   1. Задаются значения дополнительным параметрам Процесса интеграции
   2. Определяются правила подключения Участников взаимодействия к серверу «Интеграционной шины» и способ их участия в процессах интеграции
   3. Запускаются Процессы интеграции и начинают доставлять сообщения
   4. Останавливаются Процессы интеграции
   5. Доступны данные мониторинга работы Процессов интеграции: количество обработанных сообщений, ошибок и пр.

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

Видео:Плюсы и минусы сервисной шины данных I Enterprise service bus (ESB) I kt.teamСкачать

Подключение 1С:Предприятия к «Интеграционной шине»

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

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

Механизм сервисов интеграции в 1С:Предприятие не является альтернативной механизмам планов обмена, так как отвечает только за транспортировку сообщений, а не за формирование исходящих и интерпретацию входящих сообщений.

Взаимодействие с «Интеграционной шиной» выполняется с гарантированной доставкой сообщения, что означает:

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

Читайте также: Сканер для маркировки шин

Видео:Интеграционные шиныСкачать

Пример сценария интеграции

Офис отправляет в магазины и на сайт изменения в прайс-листе.

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

В момент изменения прайс-листа в офисе формируется сообщение, содержащее актуальный прайс-лист в формате EnterpriseData. Это сообщение отправляется в канал «ИзОфисов».

В узле «ДляВсех» все сообщения из канала «ИзОфисов» маршрутизируются по трем направлениям:

1. Для передачи магазинам, использующим старое ПО, в формате JSON. Преобразование из исходного XML происходит в узле вида «Транслятор» с именем «JsonДляМагазинов». Полученный JSON отправляется в канал «ДляМагазиновСоСтарымПО».
2. Для передачи магазинам, использующим ПО 1С, сообщение в исходном виде отправляется в канал «ДляМагазиновНа1С».
3. Для публикации на сайте. Преобразование из исходного XML происходит в узле вида «Транслятор» с именем «JsonДляСайта». Полученный JSON отправляется на сайт HTTP запросом в узле «НаСайт».

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

Видео:Интеграционная шина данных для ВУЗовСкачать

Преимущества нашей «Интеграционной шины»

После знакомства с «Интеграционной шиной» может возникнуть естественный вопрос: рынок ПО класса ESB достаточно обширен, на нем представлено немало достойных продуктов, в том числе и бесплатных; зачем же фирме «1С» делать ещё один продукт, не изобретаем ли мы велосипед?

Конечно, перед тем, как принять решение разрабатывать «Интеграционную шину», мы задались тем же вопросом. И ответили себе на него так — да, делать продукт сто́ит, потому что:

1. Мы постарались сделать наш продукт максимально простым и удобным в использовании.
2. Мы сделали интеграцию нашего продукта с приложениями 1С максимально гладкой.
3. «Интеграционная шина» от 1С легка в освоении для разработчиков 1С и позволит клиентам во многих случаях для настройки процессов интеграции обходиться усилиями существующих ИТ-специалистов (партнера 1С и/или своего ИТ-отдела, обслуживающего клиента).
4. Наш продукт будет органично вписываться в экосистему 1С и позволит решить нашим клиентам задачи своего бизнеса наиболее эффективным способом.

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

Мы планируем этап бета-тестирования «Интеграционной шины» и будем рады помощи партнеров и клиентов. Чтобы участвовать в бета-тестировании продукта нажмите зелёную кнопку «Пробовать» в начале статьи.

Видео:Интеграционная шина - обмен данными между подразделениями предприятияСкачать

Сравнение ESB-решений, популярных на российском рынке

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

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

Один из продуктов, работающих в парадигме low-code, — ESB-система (сокр. от англ. enterprise service bus, рус. «сервисная шина предприятия»). ESB — это набор программного обеспечения, которое работает как единый центр для обмена сообщениями между информационными системами и приложениями. Сервисная шина позволяет легко настраивать маршруты движения сообщений, хранит историю сообщений, фиксирует путь каждого из них.

Читайте также: Размер шин для bmw e34

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

ESB — это не монолитная система, а слой в IT-инфраструктуре компании, который состоит из нескольких продуктов. Каждый из них берёт на себя одну или несколько функций сервисной шины. В этой статье мы разложим слой ESB по функциям и расскажем, как эти функции реализованы в продуктах, популярных на российском IT-рынке.

Видео:Шина данныхСкачать

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

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

Без студии и, соответственно, без визуализации интеграций ESB не может считаться low-code решением.

Каждое из ESB-решений предлагает на выбор несколько возможностей размещения. Например, некоторые системы позволяют опубликовать интеграцию в частном облаке Kubernetes, OpenShift, Amazon вообще без настройки. Для публикации внутри вашего уникального кластера потребуется работа архитектора.

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

Укажите свою почту, и мы будем присылать вам еженедельный анонс новых статей.

+ — студия есть в «коробке».

± — студия есть, но она сложнее в настройке и требует постоянного участия разработчиков, что идёт вразрез с парадигмой low-code.

Как видите, внутреннее логирование в ESB-системах реализовано практически идентично — с небольшими особенностями, индивидуальными для каждого из продуктов.

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

Логирование во внешней системе даёт ESB дополнительную гибкость. Скорее всего, у бизнеса масштаба enterprise в IT-архитектуре уже есть компонент для логирования, и системы не будут дублировать функции друг друга.

Видео:Интеграция систем на примере шины ESB · Евгений Путилин · ЛАФ #системныйаналитикСкачать

Резюме

Talend, Mule, WSO2 позволяют решить проблему скорости проведения интеграций и соответствуют парадигме low-code.

Red Hat Fuse по функционалу близка к предыдущим трём продуктам, но уже не может считаться low-code решением: даже для рядовых операций здесь нужен именно разработчик. Однако в ней сохраняется принцип самодокументируемости.

Apache Kafka и RabbitMQ являются не ESB-системами, а брокерами сообщений. Их недостаточно, чтобы создать полноценный слой ESB, они не дают никаких преимуществ в плане упрощения интеграций и масштабирования, но при этом могут стать частью слоя ESB.

Понятно, что каждое внедрение индивидуально и должно учитывать особенности бизнеса, продуктовую и IT-стратегию. Но из существующих решений именно low-code позволяет быстрее всего проводить цифровую трансформацию, масштабироваться, интегрироваться с партнёрами. Поэтому компаниям, которые заинтересованы в быстром росте с сопутствующей оптимизацией затрат на разработку, мы рекомендуем именно low-code решения: ESB, BPMS, CRM.

Читайте также: Как сбросить датчик давления в шинах опель

Отдельно обозначим, что само внедрение low-code ESB происходит не мгновенно. Как и всякая масштабная интеграция, оно требует времени и ресурсов: затрат на команду разработчиков, на серверы (при необходимости) и т. д. В этом low-code решения ничем не отличаются от привычных. Экономия на разработке начинается только после их внедрения.

Видео:Способы интеграции системСкачать

Как мы работаем со справочниками на интеграционной шине

Видео:CAN шина👏 Как это работаетСкачать

Принципы решения

При интеграции корпоративных систем возникает задача управления справочными данными. Для решения этой задачи часто используется Master Data Managment(MDM). MDM — это хранилище, которое содержит “эталонные” справочные данные, так называемые “золотые записи”. Справочники в MDM содержат очищенные полные и непротиворечивые данные.

Часто MDM используется как платформа для централизованного ведения справочников. Ввод и валидация справочных данных производится в MDM, а оттуда они реплицируются в IT-системы. Такой подход имеет несколько проблем

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

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

Видео:03. Основы устройства компьютера. Память и шина. [Универсальный программист]Скачать

Трансформация на интеграционной шине.

Мы используем второй подход. Все взаимодействия бизнес-систем происходят через интеграционную шину. Шина (в нашем случае Oracle Service Bus) трансформирует сообщение, которое посылает система Поставщик, в сообщение, понятное системе Потребителю. Такая трансформация включает мапирование значений справочников.

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

(source_system, source_value, valid_from, valid_to, target_system, target_value)

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

Для кэширования мы используем Oracle Coherence. Это очень и очень платный продукт. Однако, в данном случае все его мега-функции не используются, поэтому его вполне можно заменить на бесплатное решение (например, hazelcast). Подробнее про coherence можно прочитать здесь. Также лицензия на coherence входит в различные Oracle Suite.

Использования кэша имеет очевидные преимущества:

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

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

Для справочных данных используется схема Distributed Cache Map. Во время старта Oracle Service Bus создается кэш внутри JVM, который держит данные в памяти. На каждом физическом сервере имеется coherence сервер, который хранит справочники (в памяти и на диске) и синхронизируется с базой данных.

При трансформации osb workflow обращается к coherence через Java callout. Можно также обращаться через вызов Enterprise Java Bean.

• Свежие записи
  • Нужно ли менять пружины при замене амортизаторов
  • Скрипят амортизаторы на машине что делать
  • Из чего состоит стойка амортизатора передняя
  • Чем стянуть пружину амортизатора без стяжек
  • Для чего нужны амортизаторы в автомобиле

  
  

  источники:

  https://fasad-adelante.ru/integratsionnaya-shina-dannyh-chto-eto

  📽️ Видео

  Интеграционная шина данных | 1C ERP интеграция | Связь между системамиСкачать

  

  Как работает LIN шина автомобиля. K-Line L-Line шины данных. Лин шина автомобиля. Lin-bus networkСкачать

  

  Интеграционная шина: потребности бизнесаСкачать

  

  Передача данных - шина SPIСкачать

  

  Интеграционная шина предприятия. Правило импорта.Скачать

  

  PSO - корпоративная интеграционная шина данныхСкачать

  

  Системная шина процессораСкачать

  

  Интеграционная шина предприятия. Структура правила экспортаСкачать

  

  С чего начать ремонт ЭБУ: Типы шин данных, CANСкачать