Система Нотификации банка ВТБ-24 предоставляет единый сервис информационной рассылки для различных банковских систем, реализующих банковские продукты, в адрес клиентов этих банковских продуктов.

1. Система Нотификации ВТБ 24
Основной задачей Системы Нотификации ВТБ 24 (здесь и далее — Система) является предоставление
единого сервиса информационной рассылки для различных банковских систем, реализующих банковские
продукты, в адрес клиентов этих банковских продуктов.
Система реализует следующий процесс нотификации:
• принимает сообщения от банковских систем, выполняя при этом проверку корректности и допусти-
мости сообщений;
• для каждого сообщения определяет подписчиков — клиентов банковских продуктов, заинтересо-
ванных в информации по сообщениям;
• формирует соответствующие уведомления — конечные сообщения для подписчика, учитывающие
тип сообщений, форму представления информации и тип канала доставки;
• выполняет доставку сформированных уведомлений подписчикам, выполняя при этом учет оплаты
доставки платных уведомлений.
Структура Системы
Система реализована как набор подсистем, выполняющих конечные этапы процесса нотификации (см.
Рисунок 1):
Рисунок 1 - Общий состав Системы
• Модуль регистрации — осуществляет прием сообщений, представленных в XML-виде, выполняет
разбор данных сообщения, проверку их корректности и допустимости, записывает принятые сооб-
щения во внутреннюю БД Системы.
• Модуль определения подписки — на основании данных сообщений, представленных в БД Системы,
и данных справочников, определяет перечень клиентов — подписчиков, заинтересованных в полу-
чении информации по этим сообщениям, и все каналы представления информации, заказанные
подписчиком. Результат работы модуля – определение необходимости формирования уведомле-
ния для конкретного канала и конкретного подписчика.

2. • Модуль формирования уведомлений — модуль формирует уведомления — конечные сообщения,
предназначенные для отправки конкретному подписчику по конкретному каналу доставки. Уведом-
ления формируются на основании фактов, обнаруженных модулем определения подписки, и со-
храняются во внутренней БД Системы.
• Модуль доставки уведомлений — выполняет доставку сформированных уведомлений через соот-
ветствующие каналы доставки. При этом модуль ведет учет оплаты уведомлений — проверяет
факт предварительной оплаты уведомлений клиентом-подписчиком. В текущей версии Системы
модуль реализует доставку через каналы SMTP и HTTP-шлюз сервиса рассылки SMS.
• Модуль взаимодействия с СУБД — специализированный внутренний модуль Системы, обеспечи-
вающий общую для всех остальных модулей инфраструктуру взаимодействия с СУБД.
Каждый модуль Системы реализован в виде набора библиотек и функционирует в составе специальной
подсистемы — контейнера, объединяющей набор модулей Системы в отдельный процесс-приложение ОС,
управляемый как одна конфигурационная единица. Реализация Системы включает два типа контейнеров:
• Web-приложение на основе Microsoft Internet Information Server (IIS) — в данном случае контейнер
представляет набор библиотек, развертываемых в web-приложение на базе IIS. Все модули, скон-
фигурированные в составе такого контейнера, работают в рамках соответствующего web-
приложения, управляемого стандартными средствами IIS.
• Системная служба Microsoft Windows Service — специальное приложение, устанавливаемое как
системная служба Microsoft Windows Service. Все модули, сконфигурированные в составе такого
контейнера, работают в рамках соответствующего сервиса, управляемого посредством стандарт-
ной оснастки.
Разделение Системы на модули и возможность их организации в составе контейнеров позволяет органи-
зовать горизонтальное масштабирование ключевых элементов процесса нотификации за счет параллель-
ного развертывания нескольких однотипных модулей Системы. При этом реализация каждого модуля
«замкнута» на конечном этапе процесса нотификации, и при параллельной работе однотипных модулей
отказ одного из них не помешает работе остальных модулей (и, соответственно, всей Системе). Таким об-
разом, модульная реализация Системы обеспечивает возможность организации более защищенной кон-
фигурации, устойчивой как к программным, так и к аппаратным ошибкам. Пример возможной конфигурации
Системы (см. «Рисунок 2 — Пример конфигурации Системы, удовлетворяющей требованиям к повышенной
устойчивости»):

3. Рисунок 2 - Пример конфигурации Системы, удовлетворяющей требованиям к
повышенной устойчивости
Схема работы Системы
Система Нотификации представляет собой автоматический сервис — все основные функции Система вы-
полняет без участия человека, взаимодействуя только с другими автоматизированными системами Банка.
Работа Системы строится по следующему сценарию:
1. Модуль регистрации сообщений выполняет приемку сообщений от исходных систем-владельцев о
наступивших или наступающих событиях, предварительную проверку, разбор и запись сообщений
во внутреннюю БД.
Сообщение принимается в пассивном режиме — модуль Системы выступает в качестве клиента,
получающего сообщения. Все сообщения передаются через HTTP, на адрес специальной страницы
web-приложения, принимающей сообщение в виде POST-запроса.

4. 2. Модуль определения подписки отслеживает факт регистрации нового входящего сообщения, авто-
матически проверяя внутреннюю БД. Для каждого зарегистрированного сообщения модуль опреде-
ляет все подписки, активные на момент получения сообщения — как персональные подписки на со-
общение для конкретных клиентов-подписчиков, так и массовые подписки. Для каждой выявленной
подписки модуль регистрирует во внутренней БД задание на формирование уведомления.
3. На его основании модуль формирования уведомлений генерирует конечные исходящие уведомле-
ния. Формируемое уведомление — это, прежде всего, текст содержания уведомления. Модуль
обеспечивает специальный механизм генераторов — подключаемой реализации логики генерации
текста. В текущую поставку включены следующие генераторы:
a. подстановка значений в шаблон текста, задаваемый для каждого типа сообщения. Подстав-
ляемые параметры выделяются из содержания исходного сообщения;
b. получение содержания (текста) уведомления как результат выполнения XSLT-
преобразования XML-содержания исходного сообщения при помощи XSLT-шаблона, зада-
ваемого для каждого типа сообщения. При этом перед выполнением преобразования в
XSLT-шаблон могут быть подставлены значения, выделенные из исходного сообщения.
При этом модуль обеспечивает механизм анализаторов — подключаемой реализации логики вы-
деления подставляемых значений из исходного сообщения. В исходной поставке модуль включает
реализацию анализатора, обеспечивающего выделение данных из XML-документа исходного со-
общения при помощи XPath-выражений.
Выбор конкретного анализатора и генератора, применяемых для конкретной подписки, осуществ-
ляется на основании данных внутреннего справочника трансформаций.
4. Модуль доставки уведомлений реализует функцию доставки сформированных уведомлений с
двухфазным учетом оплаты их доставки (резервирование оплаты — взимание оплаты по факту
доставки). В данной поставке Системы модуль реализует доставку по следующим каналам:
a. SMTP — формирование и отправка сообщений электронной почты по протоколу SMTP;
b. SMS — формирование и отправка SMS-сообщений при помощи внешнего SMS-шлюза —
специального сервиса, осуществляющего рассылку SMS-сообщений; вызов шлюза выпол-
няется по протоколу HTTP специальным GET-запросом.
Модуль также реализует два варианта учета оплаты доставки уведомления (выбор конкретной
реализации определяется конфигурационными параметрами):
a. внутренний учет — на основании внутренних данных о пакетах оплаченных уведомлений,
соотнесенных с данными о клиентах-подписчиках;
b. внешний учет— в этом случае учет оплаты выполняется во внешней системе, вызов кото-
рой осуществляется через web-сервис.
В общем случае реализация модуля допускает подключение другой логики доставки уведомления и
логики учета оплаты доставки уведомлений.
Количественные характеристики

5. ения).
Целевые характеристики, реализуемые Системой Нотификации:
• Производительность — от 20 входящих сообщений в секунду. Среднее время обработки сообщения
(от регистрации до передачи в службу доставки) — 3 секунды, максимально допустимое — 10 се-
кунд. Система рассчитана на обработку сообщений, предполагающих формирование и рассылку
уведомлений в количестве, порядок которого составляет миллионы.
• Надежность — в случае ошибок обработки принятое сообщение/сформированное уведомление со-
храняется во внутренней БД и обрабатывается после восстановления работоспособности модуля
(Системы). Модули системы реализуют внутренние механизмы автоматического перезапуска обра-
ботки сообщений/уведомлений.
В процессе опытной эксплуатации Системы Нотификации в Банке было проведено нагрузочное
тестирование1
, в результате которого получена общая оценка производительности Системы — обработка
100-110 исходных сообщений в секунду (при условии генерации и доставки 2-3 уведомлений для каждого
сообщ
1
Конфигурация боевого контура: сервер СУБД — MS SQL Server 2008 Enterprise Edition SP1, на кластере из двух серверов HP Blade
680 (4x4), 16 Gb RAM, с внешним хранилищем; ферма серверов приложений, HP Blade 460 (2x4) 4 Gb RAM, балансировка SLB. На
каждом узле фермы развернут идентичный набор приложений Системы в рамках одного контейнера IIS в выделенном пуле.