Что такое шина в интеграции

Содержание
  1. Функциональные возможности DATAREON ESB
  2. Поддержка различных стандартов и сценариев интеграции с помощью интеграционной шины данных
  3. Взаимодействие с продуктами на платформе «1С:Предприятие 8»
  4. Централизованное управление
  5. Трансформация данных
  6. Масштабируемость интеграционной шины
  7. Безопасность и ролевая модель
  8. Проактивная диагностика и мониторинг
  9. Шины Данных (Enterprise Service Bus, ESB)
  10. Почему компании делают выбор в пользу Шины Данных
  11. Пример действующего решения
  12. Заключение
  13. Содержание
  14. Основные функции ESB
  15. Архитектура ESB
  16. Достоинства и недостатки
  17. Разработка Enterprise Service Bus
  18. Шлюз служб
  19. Шина сообщений
  20. Что такое шина в интеграции
  21. Что такое ESB и чем это отличается от брокера сообщений
  22. Шина данных и Apache Kafka: рекомендации и антипаттерны
  23. Кафка и шина данных на пример Авито: self- service для эффективной интеграции
  24. Интеграционная шина для Банка СОЮЗ (АО): проектирование и автотестирование
  25. Реализация
  26. Пример
  27. Тестирование
  28. Вместо заключения

Функциональные возможности DATAREON ESB

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

Поддержка различных стандартов и сценариев интеграции с помощью интеграционной шины данных

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

В DATAREON ESB существуют следующие типы коннекторов:

Все коннекторы имеют возможности параметрической настройки подключения к системе-источнику и взаимодействию с ней.

podderzka standartov1

Список доступных коннекторов постоянно расширяется, полный перечень необходимо уточнять в компании DATAREON.

podderzka standartov2

Взаимодействие с продуктами на платформе «1С:Предприятие 8»

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

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

Реализованы удобные мастера, которые позволяют создавать обработчики для 1С:

1s1

1s2

В DATAREON ESB реализованы механизмы отладки обработчиков 1С без использования конфигуратора 1С. Отладка кода 1С выполняется непосредственно из центра управления DATAREON ESB.

1s3

Данный механизм позволяет проверить, каким образом будут выгружены или загружены данные в 1С без их сохранения в 1С и без прямого доступа к системе.

Все реализованные интеграционные сценарии учитывают особенности лицензионной политики фирмы «1С», в частности те, которые запрещают прямой доступ к данным системы на платформе 1С через СУБД.

Централизованное управление

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

Центр управления DATAREON ESB может быть интегрирован со средой разработки «1С:Enterprise Development Tools», также построенной на платформе Eclipse, что делает работу в DATAREON ESB еще более удобной для разработчиков на платформе «1С:Предприятие 8».

В DATAREON ESB присутствует множество визуальных инструментов настройки. Например, мастер настройки и управления информационными потоками:

upravleniye

Трансформация данных

Одной из проблем построения композитных приложений является различие интеграционных форматов и протоколов приложений, входящих в периметр интеграции. При этом довольно часты случаи, когда изменение форматов и протоколов невозможно из-за закрытости системы или отсутствия поддержки со стороны компании-разработчика. DATAREON ESB имеет в своем составе инструменты, позволяющие эффективно решать данную проблему. Эти инструменты предоставляют возможность настраивать правила трансформации в различные форматы с различными алгоритмами преобразования данных. Механизмы трансформации позволяют строить многошаговые алгоритмы преобразования данных с контролем различных условий, вплоть до написания кода на языках высокого уровня. Визуальные средства разработки снижают требования к специалистам, отвечающим за создание схем трансформации. Самые «ходовые» форматы – XML, JSON, DBF, CSV, Base64 – представлены в виде «мастеров» настройки. Возможно построение алгоритмов с обогащением данных (когда для определенных потребителей исходный пакет расширяется другими данными).

transformaziya

Масштабируемость интеграционной шины

С помощью интеграционной шины 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 согласно полномочиям.

bezopasnost

Проактивная диагностика и мониторинг

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

monitoring1

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

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

monitoring2

Для более глубокого анализа в центре диагностики доступна работа со счетчиками производительности системы за определенный период времени. Данные могут быть экспортированы в MS Excel.

monitoring3

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

В DATAREON ESB также имеются мощные инструменты для отладки сценариев передачи данных, включающие:

Диагностическая информация представляется в виде следующей диаграммы:

monitoring4

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

Пример построения сети объектов ESB:

esb 1

Менеджеры DATAREON будут рады ответить на все вопросы по тел. +7(495)280-08-01. Также вы можете написать нам через форму

Источник

Шины Данных (Enterprise Service Bus, ESB)

Почему компании делают выбор в пользу Шины Данных

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

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

В начале 2000 годов на рынке программного обеспечения стали появляться решения, сформировавшие кластер под названием Сервисная шина масштаба предприятия (Enterprise Service Bus, ESB), или сокращенно Шина Данных. Шина Данных – это, в первую очередь, концепция, элемент архитектуры IT-ландшафта, используемый для решения задачи интеграции разрозненных информационных систем в единый программный комплекс с централизованным управлением передачей информации и применением сервис-ориентированного подхода.

enterprise service bus esb Enterprise Service Bus (ESB)

Архитектура ESB строится на 3 компонентах:

Коннекторы используются для подключения к различным системам и обеспечивают прием и отправку данных.
Очередь сообщений (Message Queue, MQ) служит для организации промежуточного хранения сообщений в ходе их доставки.

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

К основным преимуществам современных ESB-решений относятся:

Пример действующего решения

К настоящему времени на рынке представлено более двух десятков шин данных, однако наибольшее распространение получили следующие решения:

По результатам проведенного анализа различных Шин Данных нашей компанией был сделан выбор в пользу программного продукта JBoss Fuse. В число критериев входили такие вопросы как: наличие широкого спектра адаптеров (включая работу с web-сервисами), возможности маршрутизации и трансформации сообщений, оркестровка, поддерживаемые протоколы обмена, удобство администрирования, стоимость приобретения и поддержки. Данное решение по своим функциональным характеристикам не уступает аналогам от IBM, Oracle и Microsoft, но при этом доступно для бесплатного использования (лицензия приобретается только на поддержку).

На рисунке показан пример реализации web-сервиса, который по запрошенному идентификатору выдает из базы данных информацию о клиенте. Задача решена в инструменте редактирования JBoss Fuse, входящем в состав Jboss Fuse ESB.

Заключение

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

Читайте также:  Утилизация автомобильных шин как бизнес

Источник

ESB (Enterprise Service Bus) — дословно можно перевести как «сервисная шина предприятия». ESB описывает вполне реальный программный продукт, в задачи которого входит упрощение вызова службы за счет управления всеми взаимодействиями на пути от потребителя службы к поставщику и обратно. Двумя наиболее часто упоминаемыми возможностями ESB являются преобразование сообщений и их маршрутизация. На шину ESB в архитектуре SOA возложена важнейшая задача обеспечения взаимодействия систем из слабосвязанных сервисов в сети. Аналитики Gartner определяют ESB как новый тип программного обеспечения промежуточного уровня, который объединяет функциональные возможности других уже существующих типов промежуточного обеспечения. Корпоративная сервисная шина поддерживает Web-сервисы, реализуя протокол SOAP (Simple Object Access Protocol, Простой протокол доступа к объектам) и используя язык WSDL (Web Services Description Language, Язык описания Web-сервисов) и спецификацию UDDI (Universal Description, Discovery and Integration, Универсальное описание, обнаружение и интеграция).

Содержание

300px ESB

300px ESB1

Основные функции ESB

Архитектура ESB

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

Достоинства и недостатки

Достоинствами ESB является:

К числу недостатков ESB относят:

Разработка Enterprise Service Bus

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

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

Шлюз служб

Так называемый шлюз служб является краеугольным камнем синхронной ESB. Он выступает посредником между провайдерами и потребителями служб, оказывая при этом содействие в обработке синхронных вызовов с использованием брокера. Данный шлюз открывает доступ ко всем известным службам и прокси-службам каждой из них, поэтому он является своего рода «единым окном» для потребителя, желающего вызывать любую службу у любого провайдера, который известен шлюзу. Когда Web-службы координирует шлюз, они обладают способностью к самоописанию. Каждая служба предоставляет свой интерфейс с помощью WSDL, который состоит из следующих четырех частей:

Web-службы шлюза, а точнее их прокси-службы являются также обнаруживаемыми. Шлюз дает такую возможность в виде UDDI-службы. Чтобы найти адрес вызова службы потребитель подает запрос в UDDI-службу шлюза список провайдеров необходимой WSDL-операции и получает обратно адрес прокси-службы шлюза для этой операции.

Шина сообщений

Шаблон Message Bus (Шина сообщений) является основой асинхронной ESB. Шина сообщений — это набор каналов сообщений, которые настроены как пары каналов запрос-ответ. Каждая пара представляет службу, которую может вызвать потребитель, использующий шину. Потребитель посылает сообщение в очередь запросов службы и после этого выслушивает очередь ответов для получения результата. О том, кто предоставляет службу потребитель на самом деле не знает. Провайдеры служб также подсоединены к шине сообщений и прослушивают ее на наличие сообщений запросов. При наличии нескольких провайдеров службы, между ними происходит соревнование как между потребителями за получение конкретного запроса. Система сообщений, выполняемая шиной сообщений, функционирует как диспетчер сообщений и рассылает запросы провайдерам служб, оптимизируя эту рассылку в зависимости от степени нагрузки, сетевых задержек и т. д. После того как провайдер получил запрос, он выполняет службу и вносит результат в сообщение в очередь ответов, то есть провайдер и потребитель никогда не знают о месторасположении друг друга. Эта шина сообщений и является сущностью ESB.

Источник

Что такое шина в интеграции

Есть мнение, что использование Apache Kafka в качестве корпоративной сервисной шины (ESB, Enterprise Service Bus) является антипаттерном. Сегодня мы проясним это категоричное утверждение и рассмотрим, как корректно реализовать ESB с помощью Kafka на практическом примере шины данных в компании Avito.ru.

Что такое ESB и чем это отличается от брокера сообщений

Таким образом, брокер сообщений является частью ESB-решения, которое в целом обеспечивает мониторинг и контроль маршрутизации обмена сообщениями между сервисами на основе контента, разрешая конфликты между ними. Также ESB позволяет управлять развертываниями и версиями сервисов. Поэтому постановка вопроса «Apache Kafka vs ESB» не совсем корректна: Кафка дополняет ESB, выступая в качестве масштабируемой отказоустойчивой стриминговой платформы, что особенно актуально для высоконагруженных распределенных Big Data систем [2].

Шина данных и Apache Kafka: рекомендации и антипаттерны

Именно в таком ключе перед разработчиками компании Avito и была поставлена задача создания корпоративной шины данных (service data bus), реализацию которой мы рассмотрим далее. Этот кейс был наглядно представлен сотрудником компании Антоном Суховым на 5-м Backend-митапе Авито в декабре 2019 года [4].

Кафка и шина данных на пример Авито: self- service для эффективной интеграции

Основными бизнес-требованиями к корпоративной шине данных в Авито были следующие [4]:

Из требований к решению наиболее значимыми считались:

С учетом этих требований было решено проектировать систему следующим образом:

При том смещение (offset) может указывать на самую старую запись (oldest), самую новую (newest), или вычисляться по метке времени (timestamp).

Читайте также:  Шаровой кран с нижней подводкой на бачок

Таким образом, шина данных обеспечивает простую работу с Apache Kafka в режиме self-service, предоставляя все преимущества этой Big Data системы, но скрывая от пользователя специфические особенности ее работы. Аналогичный подход к самообслуживанию мы недавно описывали на примере администрирования кластеров Apache Kafka в Booking.com, рассматривая доклад Александра Миронова, представленный на зимнем Кафка-митапе Авито в январе 2020 года. Напомним, подробности реализации шины данных компании Авито изложены в видеодокладе ее ведущего разработчика Антона Сухова [4].

А технические детали эксплуатации ApacheKafka для потоковой обработки больших данных в проектах цифровизации своего бизнеса, а также государственных и муниципальных предприятий, вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Источник

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

1c5adc2cbf15e871e95a29948eaab3e2

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

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

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

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

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

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

Реализация

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

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

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

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

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

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

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

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

Пример

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

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

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

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

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

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

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

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

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

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

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

Источник

Оцените статью
Adblock
detector