Эмулирующих работу ит систем через интеграционную шину

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

Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.

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

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

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

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

Видео:Интеграции с помощью API и интеграционной шиныСкачать

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

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

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

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

Видео:Интеграция систем 1С с помощью сервисной шины предприятия DATAREON ESBСкачать

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

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

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

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

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

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

Читайте также: Мир шин в ижевске адреса

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

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

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

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

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

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

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

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

Видео:лекция 403 CAN шина- введениеСкачать

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

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

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

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

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

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

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

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

Видео:Шины данных и интеграции | ESB шина данных | Интеграция 1С ERPСкачать

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

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

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

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

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

Видео:Интеграция AXELOT WMS X5 и 1С:УТ с помощью шины данных DATAREON ESBСкачать

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

Мы используем второй подход. Все взаимодействия бизнес-систем происходят через интеграционную шину. Шина (в нашем случае 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.

Видео:Лекция 281. Шина ISAСкачать

Интеграционная шина для Банка СОЮЗ (АО): проектирование и автотестирование

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

Что такое интеграционная платформа и для чего она нужна?

В крупных корпоративных системах часто возникают проблемы взаимодействия между внутренними подсистемами. Из-за бесконечных связей и запросов такой клубок с течением времени всё больше запутывается и усложняется. Его становится тяжело размотать поддерживать и управлять им.

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

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

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

1. заменить существующую интеграцию через интеграционную платформу;
2. интегрировать новые системы банка;
3. автоматизировать процессы обмена данными между ними.

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

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

Читайте также: Типоразмер шин для зимы

Видео:Топ 35 вопросов на собеседовании IT - спецу | Что тебя ждет и как отвечать, чтобы получить оффер?Скачать

Реализация

Для реализации выбрали модульную интеграционную платформу Red Hat JBoss Fuse.

Архитектура JBoss Fuse

Немного подробнее про основные инструменты, которые есть «из коробки»:

Apache Camel, построенный на корпоративных шаблонах интеграции (EIP), обеспечивает маршрутизации сообщений, имеет большое количество готовых адаптеров для работы с внешними системами: базами данных, файлами, брокерами сообщений, службой каталогов, почтой и пр.

Apache ActiveMQ, который организует обмен сообщениями, а также обеспечивает их передачу и хранение до тех пор, пока подписчик не заберет их.

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

Интеграционный процесс

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

Видео:1С:Шина — интеграция с внешними ИС, формат Enterprise Data, преобразования CSV/JSON/XDTO — RTD2023Скачать

Пример

Возьмем процесс выдачи кредитов в банке. Клиент в интернет-банке заполняет заявку, отправляет данные с формы и ждет результата. Что при этом происходит внутри: через rest api, предоставленный интернет-банку, шина принимает запрос с основными данными. Далее, он запрашивает через soap-интерфейс в MDM-системе дополнительную информацию о клиенте, объединяет полученное в общий набор и передает через выделенную очередь ActiveMQ системе RTDM для формирования предложения в рамках существующих кредитных продуктов. Далее результат от RTDM возвращается в ответную очередь, и шина транслирует предложение для клиента обратно в интернет-банк.

Видео:лекция 417 Чтение и запись данных на общую шинуСкачать

Тестирование

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

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

Мы сделали два набора сценариев, которые прогонялись при каждой сборке (CI/CD). По коммиту у нас инициировалась сборка и разворачивалась на стенд. После процедуры деплоя прогонялся короткий сценарий (smoke test), который давал нам понять, что никакие интеграционные взаимодействия не сломаны.

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

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

Видео:Питание DALI | Особенности подключения | Шина DALIСкачать

Вместо заключения

После всех пройденных этапов наша команда построила быстрые и прозрачные процессы с контрагентами и заказчиками, и дальнейшие процессы разработки, тестирования, внедрения и поддержки пошли просто. В итоге было автоматизировано 12 бизнес-процессов, которые в своей сущности объединили работу основных систем банка: АБС, MDM, процессинга, RTDM и пр. В таких проектах мы всегда стараемся силами только автоматизированного тестирования, практически не привлекая функциональных тестировщиков. Это снижает конечную стоимость разработки и интеграции проекта, снижает time to market и нивелирует человеческий фактор.

Александр Садыков, Заместитель руководителя отдела тестирования, Центр программных решений, «Инфосистемы Джет»

Павел Иванов, Руководитель группы разработки, Центр программных решений, «Инфосистемы Джет»

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

  
  

  источники:

  https://fasad-adelante.ru/emuliruyuschih-rabotu-it-sistem-cherez-integratsionnuyu-shinu

  📹 Видео

  Интеграция отдельных систем, интеграционная платформа и PSIM или монобрендовая экосистема. ДискуссияСкачать

  

  MCP2515, контроллер CAN шины с интерфейсом SPIСкачать

  

  Лекция 308. Шина I2CСкачать

  

  Логический анализатор шины i2cСкачать

  

  Установка и настройка шины DATAREON ESBСкачать