Друзья, привет! Я Никита Климов, владелец платформы Oracle FlexCube (FCUBS) для обработки операций корпоративных депозитов, межбанковских кредитов, валютных операций и деривативов в Росбанке.
Сегодня я расскажу вам, как мы реализовали платформу FCUBS и что делает этот проект уникальным для российского рынка.
Все детали под катом.
Начну с того, что мы первые в России рискнули адаптировать западную систему к реалиям российского бухгалтерского учета в такой сложной продуктовой линейке, как финансовые рынки и рынки капитала.
Задача осложнялась тем, что мы внедряли систему не с нуля, а заменили существующую систему, которая работала в банке около 20 лет. Более того, система располагалась отдельно в периметре банка, а это значит, что нам пришлось развивать интеграцию со всеми внешними и внутренними системами.
Архитектура
Архитектура системы представляет собой классическую трехуровневую систему.
В нашем случае бэкенд — Oracle 12c (хотя на данный момент он больше не поддерживается, и мы переходим на 19c… но это совсем другая история), а фронтенд — IBM WebSphere. Опытный читатель сразу задаст вопрос — а почему бы не использовать родной для Oracle Weblogic? И, конечно же, он будет прав, ведь это первое, что нам порекомендовал сам Oracle. Но так получилось, что для банка стандартом является сервер приложений IBM WebSphere, к тому же у нас есть ULA для этого продукта, и было принято решение адаптировать уровень приложений под возможности WebSphere. Не сказать, что это была очень сложная задача, но ряд особенностей в организации внутренних очередей все же имелся, и нашей команде пришлось потратить немало часов на трехсторонние конференц-звонки с поддержкой Oracle и IBM. 
Пока мы пытались настроить тестовую среду и показать интерфейс проектной команде, наши бизнес-аналитики проводили GAP-анализ, описывали требования к функциональности и думали о миграции данных из старой системы.
Я не буду заострять внимание на миграции данных, потому что.
по сути это процесс заполнения промежуточных, транспортных таблиц внутри FlexCube. Все это действие сводилось к итеративному заполнению и проверке данных до успешного завершения миграции — ведь главное перенести нужное значение в нужное поле таблицы.
Отличительной особенностью нашего внедрения было то, что вместо системы с полным ручным управлением и постоянным участием пользователей мы создали событийную систему на STP-процессах, которая требовала минимального участия бизнес-пользователей.
Для контроля обработки предусмотрены только контрольные точки.
Для этого нам пришлось сломать старые бизнес-процессы и построить новые.
Функциональность
Как я уже отмечал ранее, готовая система была совершенно не готова к российским реалиям, начиная от отсутствия плана счетов и заканчивая налоговым учетом.По сути, это было просто ядро с набором событийных моделей, из которого нужно было построить космический корабль.
Следовательно, вооружившись функциональными требованиями бизнеса, мы начали разрабатывать свой собственный слой на основе ядра системы.
Мы разработали нашу систему учета для создания двадцатизначных счетов и начали внедрять процессы STP. Устранение ручного вмешательства пользователя оказалось нетривиальной задачей и не решалось только с помощью триггеров на уровне СУБД.
Пришлось построить логику событий на JOB и ввести расписание задач.
Этого тоже оказалось недостаточно, и мы были вынуждены использовать Quartz, на основе которого автоматизировали наш рабочий процесс.
В результате в полностью автоматическом процессе происходит следующее:
- Контракт приходит к нам из фронт-системы Кондор+ и в зависимости от его суммы либо автоматически авторизуется, либо отправляется бизнесу на авторизацию;
- После успешной авторизации система анализирует клиента – является ли он клиентом головного офиса, то есть его счета находятся в GL1, или он является клиентом регионов, то есть его счета находятся в GL2. Также бывает случай, когда это совершенно новый клиент, и тогда мы должны запросить его в нашей CRM-системе и на основании полученной информации инициировать открытие для него необходимых счетов в соответствующей GL;
- В результате обработки система запрашивает остатки на счетах в режиме онлайн и при их наличии формирует и передает необходимые транзакции в соответствующий GL, формирует и отправляет SWIFT-сообщения и платежи в SRC;
- В течение суток в системе происходят стандартные операции – погашение, начисление процентов, досрочное закрытие и т.д.;
- Мы автоматически передаем различную информацию о движениях по счетам, контрагентам и договорам в ФНС, ПОД, Ностро.
Не забыли мы и об Интернет-Клиент-Банке, с помощью которого клиенты видят, что происходит с их счетами после открытия и погашения вкладов;
- Мы готовим различную информацию для обязательной и управленческой отчетности и отправляем ее в DWH — здесь стоит отметить, что мы не только создаем классические представления для сбора информации, но и генерируем журналы транзакций для IBM CDC, который собирает и агрегирует эту информацию в режиме онлайн.
Интеграция
Здесь для наглядности прикреплю нашу архитектуру и скажу лишь, что в связи с выбором фронтенда - IBM WebSphere, было принято решение отказаться от стандартного Gateway для FCUBS, который разворачивается как дополнительное приложение и работает по старинке.
со списками и очередями и перейти к работе со Спецификацией активации MDB. В результате мы разработали дополнительные интеграционные приложения, опубликовали их на нашем сервере и подключили к банковской интеграционной шине для взаимодействия с другими системами.
Кроме того, мы также используем интеграцию с помощью Systematica Modullar на базе TIBCO Rendezvous, которая взаимодействует с нашим фронтом и является точкой входа для всех контрактов, и инструмента ETL IBM DataStage. Однако функциональность DataStage используется для интеграций, не связанных с СХД.
Для одного из GL была специально разработана логика пакетной загрузки/выгрузки данных с проверкой статусов и точками останова для ожидания вычислений.
Полученные результаты
- Заменена морально и технически устаревшая система.
- На базе ядра FlexCube создали собственную платформу с неограниченными возможностями параметризации и учета вариаций.
- Минимизированное участие пользователей в дневном процессе обработки
- Мы оптимизировали время выполнения EOD — 15 минут вместо 3 часов ранее.
- Мы создали центр компетенции внутри банка и можем поддерживать и развивать платформу независимо от поставщика.
- Мы можем практически неограниченно менять удобство пользовательского интерфейса и создавать любые тестовые экраны консолидированной информации для удобства управления.
- Мы внедрили систему контроля точек непрерывного процесса обработки.
- Мы создали платформу, на которой готовы реализовать любой банковский продукт.
Теги: #java #oracle #платформа #база данных Oracle #обработка #CDC #stp #quartz #системная интеграция #societe Generale #ibm websphere #flexcube #backoffice
-
Bpmn Простыми Словами
19 Oct, 24 -
Более 30 Лучших Онлайн-Курсов Русского Языка
19 Oct, 24 -
Мошенничество. Через Сервис «Донор» От Опсос
19 Oct, 24 -
Автотест Для Php
19 Oct, 24
