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

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

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

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

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

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

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

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

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

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

Реализация

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

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

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

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

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

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

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

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

Пример

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

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

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

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

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

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

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

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

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

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

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