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



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

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

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

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

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

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

    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 и нивелирует человеческий фактор.

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

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

    Comments 0

    Only users with full accounts can post comments. Log in, please.