---

Практически сразу после распространения информационных систем в банковской сфере возникла потребность в их интеграции друг с другом. Шло время, появились новые стандарты, новые инструменты и технологии. Сегодня сложно не запутаться во всем разнообразии программных инструментов, предлагаемых для банковской автоматизации. В статье рассматриваются 2 класса продуктов: BPM и сервисная шина, которые в жизни идут рука об руку, из-за чего у ИТ-специалистов часто складывается неверное представление о сферах их применения.

Ключевые слова. Интеграция, шина, сервисная шина, бизнес-процесс, автоматизация, BPM, передача данных.

Взаимодействие информационных систем в банковской сфере приняло промышленные масштабы. Теперь важно не только передавать огромный объем информации, но и делать это максимально быстро и надежно. И если на первых порах разработчикам приходилось долго искать методы интеграции для каждой пары систем, то в начале 2000-х на помощь пришел инструмент нового класса: интеграционная шина, известная также как сервисная шина, или service bus.

Из пункта А в пункт Б: логистика интеграции

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

Взаимодействие между системами (протоколы передачи данных, входящие и исходящие сообщения, точки их ввода и вывода – «эндпойнты», адреса вызова веб-служб), происходящее при помощи интеграционной шины, описывается с использованием языка XML. Большие файлы на XML человеку прочесть довольно трудно, а малых описательных файлов при интеграции промышленных систем вообще не бывает. Ведущие компании – поставщики программного обеспечения создали графические редакторы, преобразующие XML в графические элементы и наоборот. Эти программы призваны помочь разработчикам быстро интегрировать системы в режиме «drag-and-drop» («перетягивание» в специализированной среде разработки графических элементов из палитры в рабочую область). Разработчик задает шаги процесса интеграции, представленные в виде графических иконок, после чего связывает их стрелками, прокладывая «маршрут» входящего/исходящего сообщения.

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

Разумеется, за счет использования графических редакторов моделирования построение такого процесса взаимодействия занимает у разработчика в разы меньше времени, чем если бы он формировал файлы описания в ручном режиме. Именно с появлением графических редакторов произошла сумятица в понимании аналитиками, разработчиками да и некоторыми архитекторами отличий BPM-систем (Business Process Management, англ. Система управления процессами) от интеграционных шин: аналогичный набор графических элементов, разработка решения в виде бизнес-процесса и т.д. В то же время с помощью аналогичных графических редакторов-моделеров проектируются и разрабатываются бизнес-процессы и в ходе автоматизации банковской деятельности.

Ключевые особенности и критерии выбора

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

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

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

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

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

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

• Речь идет об интеграции небольшого количества информационных систем. Возможно, банку нужно наладить взаимодействие между несколькими приложениями в рамках одного филиала. Нет смысла приобретать ради этого дорогостоящие серверные мощности, наличие которых необходимо для многих интеграционных шин. Целесообразнее реализовать приложения на BPM-платформе в виде бизнес-процессов и настроить связь между ними. Такой вариант выглядит особенно подходящим, если в банке уже внедрена BPM-система.
• Масштабы передачи данных далеки от промышленных. Например, нужно передать из одного приложения в другое два документа – и то раз в год. Понятно, что затраты по внедрению интеграционной шины себя не оправдают.
• Необходимо в совокупности с вышеперечисленным пунктами приобретать дорогостоящую лицензию. Кстати, если перед банком стоит задача интеграции в масштабах, далеких от промышленных, путем внедрения BPM-системы, то стоит задуматься о выборе легковесного продукта, так как некоторые BPM-платформы могут составить шинам конкуренцию в требованиях к серверам и лицензиям. Важно заметить, что и внедрение BPM-платформы в банке тоже не простая процедура: при выборе инструмента автоматизации процесса нужно исходить непосредственно из требований банка.

Не стоит забывать также, что приложения, установленные на платформе BPM, могут быть составляющими интеграционного проекта, то есть потребителем или поставщиком сообщений. И, значит, в этом случае можно обойтись без service bus.

Практические задачи

Рассмотрим три примера. Во всех случаях требуется обеспечить интеграцию с помощью BPM-платформы.

Пример первый. В ходе автоматизации банковской деятельности необходимо связать между собой два бизнес-процесса. Процесс 1 автоматизирует документооборот департамента А; процесс 2 принимает от процесса 1 документы определенного типа и отправляет их на согласование определенному кругу лиц. В результате автоматизации процесс 1 должен запустить процесс 2 посредством отправки XML-сообщения. В такой ситуации нет смысла использовать сервисную шину, которая, как уже говорилось, требует для своего нормального функционирования солидных промышленных мощностей. Достаточно построить бизнес-процессы на платформе BPM и обеспечить средствами данной платформы вызов процесса 2 из процесса 1. Это вполне реально.

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

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

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

Важно понимать, что приложения и системы, обменивающиеся сообщениями при помощи сервисной шины, могут действовать на основе разных технологий. В этом также одно из преимуществ service bus: способность интегрировать гетерогенные системы, «на лету» преобразовывать сообщения, полученные из одной системы, приводить их к нужным форматам и передавать в другие системы. Напомним, что Системы, построенные на платформе BPM, не всегда готовы обеспечить интеграционное взаимодействие .

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

pdf-версия публикации