Ошибка! Источник ссылки
не найден. CV010
CV010. Высокоуровневая архитектура интеграции
Таблица 2. Ключевые сущности Siebel, задействованные в проекте
Бизнес-сущность
Бизнес-объект Siebel
Описание
Отображение
банка
в АБС
Юридическое
лицо.
Потенциальный
либо
существующий клиент
Account
Хранит всю необходимую
информацию
о
клиентеюридическом
лице
(см.
документ BP060 CL. Управление
профилем
корпоративного
клиента)
Контрагент
(существующий
клиент)
Бизнес-партнер ЮЛ
Контактное лицо
Contact
Хранит всю необходимую
корпоративному
бизнесу
информацию о контактных
лицах
корпоративных
клиентов
Бизнес-партнер ФЛ
Связь между сторонами
Party Relation
Хранит информацию о связях
между сторонами
Связь между бизнеспартнерами
Потенциальная сделка (до
момента
оформления
в
учетной системе или отказа)
по
продаже
пассивного
продукта
Opportunity
Регистрация намерения о
продаже
какого-либо
из
банковских
продуктов
и
поддерживает
весь
его
жизненный цикл до момента
оформления или отказа от
продажи (см. BP060 PO.
Потенциальные сделки)
В момент передачи в
АБС порождает сделки
(АиК,
начисления
процентов,
депозит
ЮЛ)
и
счета).
Интеграция с АБС
осуществляется только
в рамках процесса
первоначального
оформления текущих
(CASA) и депозитных
счетов.
Кредитная
заявка
(до
момента
оформления
в
учетной системе или отказа)
по
продаже
активного
продукта
FINS CBanking Request
Хранит всю необходимую
информацию о кредитной
заявке и поддерживает весь ее
жизненный цикл до момента
оформления или отказа от
продажи (см. BP060
LN.
Управление
корпоративным
кредитованием)
В рамках Этапа 2
предполагается
создание сделок типа
«Коммерческий
кредит», «Разрешение
на
кредитование»,
«Овердрафт»,
«Кредитная линия», а
также
«Транш»,
«Обеспечение»,
«Договор
страхования»
Договор
сделка)
Service Agreement
Хранит
необходимую
информацию
об
оформленных
договорах
(перечень типов продуктов, по
которым
предполагается
хранить договора в системе,
приведен в документе BP060
PO. Потенциальные сделки)
Сделка АиК, сделка
начисления
процентов,
сделка
коммерческого
депозита
Счет
Financial Account
Информация об открытых в
АБС счетах клиентов
Аналитический счет
Задача/взаимодействие
Action
Задачи
Нет
40851490
(оформленная
(взаимодействия
стр. 1 из 22
между
подразделениями
банка)
и
взаимодействия
(входящие либо исходящие
коммуникации с клиентами) –
см.
документы
BP060
CM.Управление
взаимодействиями с клиентами
и
BP060
AC.Контроль
и
постановка задач
Продукт
Internal Product
Информация о продукте и
условиях
его
продажи
(включая как продукты, по
которым
предполагается
интеграция с АБС, так и
продукты, по которым в CRMсистеме
будут
только
регистрироваться
потенциальные сделки)
Параметры
сделок
Сотрудник
Employee
Сотрудник с полномочиями
для выполнения каких-либо
функций в системе
Учетная
запись
сотруднике в АБС
Организация
Organization/Division
Элемент
структуры
организационной
Организационная
структура
(региональное
управление, ТОБО). В
рамках
Этапа
1
интеграции
по
данным сущностям не
предполагается.
В
перспективе
–
интеграция с системой
HRM
Штатная единица
Position
Штатная единица, на которую
трудоустроен сотрудник
Нет. В перспективе –
интеграция с системой
HRM
типов
Взаимосвязь сущностей Siebel
Высокоуровневая диаграмма взаимосвязей между основными сущностями
Siebel, задействованными в рамках Этапа 1, представлена на рис. 3
о
Договор
Service Agreement
Счет
Financial Account
Продукт
Internal Product
Потенциальная сделка
Opportunity
Задача/Взаимодействие
Action
Команда продаж
Юридическое лицо
Account
Команда продаж
Отношение сторон
Party Relation
Сотрудник
Employee
Физическое лицо
Contact
Кредитная заявка
FINS Cbanking Request
Рис. 3. Высокоуровневая диаграмма взаимосвязей между сущностями Siebel
Интеграция Siebel и АБС Б2
В данном разделе описывается подход к интеграции Siebel и АБС Б2 в
рамках первого этапа внедрения
SIEBEL
АБС
Change Data
Capture
(LASTMODIFIED,
SYNCTIMESTAMP)
Виртуальные БК (над таблицами/представлениями АБС) или EIM через DBLink
(ночная синхронизация)
Таблицы
СУБД
MIDDLEWARE
Бизнес-объекты
Интеграционные
объекты
Адаптеры входящих вебсервисов
Интеграционные URL
SOA over PL/SQL
(Повседневное взаимодействие между Siebel и Б2)
PL/SQL API
Печать документов (Web-приложение)
Сервер печати
Таблицы СУБД
Рис. 4. Общая идеология интеграции
Общая идеология интеграции представлена на рис. 4 и подразумевает:
Со стороны Siebel

Обмен информацией с веб-сервисами, размещенными на
интеграционной шине (middleware) и реализующими базовые
операции в АБС. Оконечные трансформации данных из
внутренних структур хранения Siebel в формат SOAP-сообщения
осуществляется на стороне Siebel.

Разработку
интеграционных
бизнес-компонент
(виртуальных/внешних бизнес-компонент) и процессов EIM для
работы
процедур
ежесуточной
обратной
синхронизации
измененных данных из АБС. При этом со стороны АБС реализуется
DBLink (через технологического пользователя) для доступа
напрямую к таблицам и/или представлениям СУБД, содержащим
необходимые данные (таблицы/представления контрагентов,
бизнес-партнеров, связей, сделок, счетов, справочников)

Формирование по заданным правилам URL для вызова вебприложения печати документов АБС при оформлении сделок.
Со стороны Middleware

Размещение веб-сервисов для работы с процедурами АБС. Такие
сервисы реализуются как обертки над PL/SQL-процедурами АБС

Размещение веб-приложения для печати документов АБС Б2 при
оформлении сделок, воспринимающего параметризованный URL с
идентификатором сделки и типа документа.
Со стороны АБС

Реализацию механизма Change Data Capture (отслеживания
изменений в ключевых сущностях) для реализации механизма
обратной синхронизации с Siebel. Не во всех таблицах АБС Б2
стандартно
протоколируется
дата
последнего
изменения
(LASTMODIFIED,
SYNCTIMESTAMP)
либо
имеются
соответствующие базовым таблицам таблицы журналов (%_LOG). В
таком случае потребуется реализация дополнительных механизмов
выборки изменившихся данных либо заказ у производителя АБС
соответствующей функциональности.
Точки интеграции
Точки интеграции Siebel и АБС Б2 сведены в таблицу ниже
Таблица 3. Точки интеграции Siebel/Б2
Сущность Siebel
Сущность Б2
Клиентюридическое лицо
(включая адреса,
телефоны)
Клиент + Бизнеспартнер
Мастерсистема
Интерфейс
Пакет Б2 (API)2
Онлайн, синхронный (вебсервисы)
+
обратная
синхронизация изменений
из АБС 1 раз в сутки (новые
и изменившиеся клиенты
минуя Siebel)
PKG_CONTRAGENT
1
Siebel
Операции:
создание, изменение
ключевых
реквизитов
Связь между
клиентами
Связь между бизнеспартнерами
Siebel
Онлайн, синхронный (вебсервисы) + обратная
синхронизация изменений
из АБС 1 раз в сутки (новые
и изменившиеся связи
минуя Siebel)
Бизнес-партнер
Siebel
Онлайн, синхронный (вебсервисы)
+
обратная
синхронизация изменений
из АБС 1 раз в сутки (новые
и изменившиеся бизнеспартнеры – ФЛ минуя
Siebel)
PKG_BP
Аналитический cчет
2600 и сопутствующие
счета
(2608,
3570,
2605), сделка АиК со
стандартными
пакетами,
Сделка
начисления %%
Siebel
Онлайн, синхронный (вебсервисы)
+
обратная
синхронизация изменений
из АБС 1 раз в сутки (новые
и
изменившиеся
счета
указанных типов и сделки
минуя Siebel)
EPRAACCOUNT_%
Операции:
добавление,
изменение типа,
изменение стороны,
удаление
Контактное
лицо
(физическое лицо)
Операции: создание
(как
бизнеспартнеров),
изменение
ключевых
реквизитов (в т.ч.
существующих
клиентов – ФЛ, если
они
являются
связанными
сторонами для корп.
клиентов)
Сделка по продаже
продукта «Текущий
счет ЮЛ», договор
продажи продукта
«Текущий
счет
ЮЛ»,
связанные
счета
PKG_BP
PKG_BP_LINK
PKI_DEALACCRUAL
PKD_MF
Операции: создание
1 В рамках онлайновой синхронизации. В рамках обратной (ночной) синхронизации изменений мастер-
системой является АБС Б2
2 Наименования пакетов даны в информационных целях. Решение об использовании того или иного пакета в
качестве основы для веб-сервисов принимает Заказчик в результате исследования операций и
консультаций с производителем АБС
новой сделки
Сделка по продаже
продукта «Депозит
ЮЛ»,
договор
продажи продукта
«Депозит
ЮЛ»,
связанные счета
Сделка
«Депозиты
ЮЛ#»
(только
стандартизированные
депозиты)
Siebel
Курсы валют НБУ
Б2
Операции: создание
новой сделки
Курсы валют НБУ
Онлайн, синхронный (вебсервисы)
+
обратная
синхронизация изменений
из АБС 1 раз в сутки (новые
и
изменившиеся
счета
указанных типов и сделки
минуя Siebel)
EPRAACCOUNT_%
Загрузка 1 раз в день
Представление
creator.VcurrencyRate
Операции: загрузка
ежедневных
обновлений
PKI_DEALACCRUAL
PKI_DEP
Кроме того, в процессе создания новой сделки из Siebel возникает
необходимость печати соответствующих документов, для чего в
распоряжение Siebel предоставляется механизм, позволяющий распечатать
необходимые формы документов Б2 из интерфейса Siebel (вебприложение, принимающее запрос в виде URL и возвращающее
сформированный документ в необходимом формате)
Синхронизация данных о клиентах и бизнес-партнерах
Siebel CRM станет основной (в перспективе – единственной) системой, из
которой будет осуществляться заведение новых клиентов – ЮЛ и
сопровождение (смена параметров) существующих клиентов – ЮЛ.
Синхронизация потенциальных клиентов
Потенциальные клиенты (клиенты, которые были заведены через Siebel и
у которых отсутствуют оформленные договора по активным или
пассивным продуктам, и которые отсутствуют в АБС Б2) – хранятся в Siebel
и не попадают в АБС Б2 до наступления одного из следующих случаев:



Потенциальный клиент стал существующим (в момент
оформления сделки пассивного продукта через Siebel), в этот
момент он передается в Б2 как клиент, ему присваивается B2 ID.
Между данным потенциальным клиентом и другим ЮЛ, которое
синхронизировано с Б2 (как клиент или бизнес-партнер)
устанавливается связь, синхронизируемая с B2. В этот момент
потенциальный клиент передается в B2 как бизнес-партнер, после
чего устанавливается связь
Принудительная передача записи о потенциальном клиенте в
Siebel. В этом случае запись передается как запись о клиенте (без
сделок)
Таким образом, если не использовать функцию принудительной передачи,
из Siebel в B2 не будут передаваться записи о потенциальных клиентах (как
о клиентах).
Клиенты и бизнес-партнеры в Siebel
В Siebel CRM, в отличие от B2, юридическое (и физическое) лицо имеет
одну запись. В B2 для каждого ЮЛ существует как минимум бизнес-
партнер, а если ЮЛ является клиентом, то записи и о бизнес-партнере, и о
клиенте.
Соответствие сущностей Siebel и B2 представлено в таблице:
Таблица 4. Взаимосвязь сущностей Siebel/B2 (контрагент)
Сущность Siebel
Отражение в Б2
Потенциальный клиент (клиент в
статусе «Потенциальный»)
Существующий клиент
Контактное лицо, связанное с
клиентом (для типов связей,
передаваемых в B2)
Связи между физическими и
юридическими лицами
Бизнес-партнер
Бизнес-партнер + Клиент
Бизнес-партнер, связь между
бизнес-партнерами
Связь между бизнес-партнерами
Т. обр., всегда для потенциальных клиентов в Siebel создается только запись
о бизнес-партнере B2. Для существующих клиентов создаются обе
сущности B2.
Внутренняя структура сущности «Клиент» в Siebel более универсальна, чем
в B2. В частности, адреса и телефоны клиента в Siebel являются дочерними
с отношением 1:М. В B2 данная информация хранится в нормализованном
виде.
SIEBEL
B2
Клиент
(Account)
Адреса
Контрагент
1:1
Бизнес-партнер
1:M
Телефоны
Адрес 1
Адрес 2
Адрес 1
Адрес 2
Телефон 1
Телефон 2
Телефон 1
Телефон 2
Рис. 5. Особенности хранения контактной информации
Одной из задач интеграционных механизмов будет являться
осуществление трансформаций между этими двумя форматами хранения.
В рамках данного проекта не предполагается использование (и,
соответственно, интеграция) Siebel для обслуживания счетов юристов и
частных нотариусов, для которых в АБС Б2 может быть создана как запись о
бизнес-партнере – физическом лице, так и о юридическом лице. Данный
случай находится за рамками рассмотрения этого документа.
Структура веб-сервисов
Необходимая номенклатура веб-сервисов по клиенту – ЮЛ со стороны B2
(интеграционной шины) представлена в таблице 3:
Веб-сервис
B2_BusinessPartner
Назначение
Веб-сервис для работы с
бизнес-партнерами B2
Таблица 5. Веб-сервисы для работы с контрагентом - ЮЛ
Метод
Логика работы
Create
Создание нового бизнеспартнера в Б2. На входе –
Update
Close
Query
B2_BusinessPartnerLink
Веб-сервис для работы со
связями между бизнеспартнерами B2
Create
Update
Delete
B2_CorpAccount
Веб-сервис для работы с
контрагентами – ЮЛ
Create
Update
Close
Query
структура данных о БП,
на выходе – BP_ID, код
результата
Обновление
информации о бизнеспартнере в Б2 по его
BP_ID
Закрытие карточки
бизнес-партнера из Б2 по
его BP_ID (после
выполнения всех
регламентных операций
– закрытия счетов,
закрытия связанных
контрагентов и т.д.
Данные операции к
реализации через Siebel
не предполагаются)
Запрос информации о
бизнес-партнере из Б2 по
одному или нескольким
существенным
реквизитам
Создание связи
определенного
(произвольного) типа
между двумя бизнеспартнерами (по
переданным BP_ID и
типу связи)
Обновление (смена типа)
связи между двумя
бизнес-партнерами
Удаление связи между
двумя бизнеспартнерами
Создание контрагента в
B2
Обновление
информации о
контрагенте в B2
Закрытие карточки
контрагента по его B2_ID
(после выполнения всех
регламентных операций)
Запрос информации о
контрагенте в B2
Предпочтительным подходом для реализации данных сервисов там, где это
возможно,является использование публичных API, размещенных в пакетах
pkg_contragent, pkg_bp, pkg_bp_link АБС Б2.
Типовые события срабатывания сервисов
Типовые события срабатывания веб-сервисов по контрагенту представлены
в таблице 6
Таблица 6. Типовые события срабатывания веб-сервисов
Сценарий срабатывания
Событие
Для потенциального клиента
(отсутствующего в Siebel)
проведено оформление сделки,
инициирована ее передача в Б2
У существующего клиента
(синхронизированного с Б2)
изменен атрибут, участвующий в
синхронизации
На карточке клиента нажата
кнопка «Передать в АБС»
Для клиента добавлены новые
контактные лица
Прежде чем приступить к обработке сделки, осуществляется передача
записи о клиенте в Б2 (B2_CorpAccount.Create). В случае, если имеются
связи с другими клиентами или бизнес-партнерами, инициируются
вызовы соотв. сервисов.
Инициируется вызов сервиса B2_CorpAccount.Update для обновления
информации о контрагенте в Б2
Осуществляется вызов B2_CorpAccount.Create
Осуществляется вызов B2_BusinessPartner.Create для каждого из новых
контактных лиц, после чего B2_BusinessPartnerLink.Create для
установления связей
Первоначальная загрузка и обратная синхронизация данных
Для осуществления задачи первоначальной загрузки Заказчик на
основании технического задания Исполнителя должен разработать набор
соответствующих представлений СУБД, содержащих необходимую
информацию о клиентах, бизнес-партнерах, связях, сделках, счетах, а также
представления для загрузки мастер-данных (справочники, параметры
типов сделок). Также должен быть реализован прямой доступ (DBLink) к
таблицам и представлениям АБС Б2 из СУБД Siebel CRM.
Ключом обратной синхронизации для клиентов, бизнес-партнеров
является код в АБС Б2 (BP_ID, B2_ID соответственно). Со стороны АБС
должна быть обеспечена уникальность данного ключа.
В случае, если между сущностями с одинаковыми BP_ID, B2_ID Siebel иАБС
в рамках ночной синхронизации имеются расхождения, информация
приводится в соответствие с данными из АБС Б2.
Со стороны Siebel будут реализованы необходимые трансформации, а
также обеспечена инфраструктура для запуска процессов по расписанию.
Тот же механизм будет использоваться и для ежесуточной обратной
синхронизации изменений, произошедших в АБС, но не инициированных
из Siebel. Для этого на стороне АБС должна быть предусмотрена
инфраструктура отслеживания таких изменений по сущностям
«Контрагент»,
«Бизнес-партнер»,
«Связь»
для
реализации
инкрементальной загрузки изменений в Siebel.
Синхронизация данных о сделках и счетах
Типы сделок
В рамках Этапа 1 внедрения CRM-Корпоративный предполагается, что из
Siebel будет осуществляться оформление сделок:
 Текущий счет юридического лица (открытие через Мастер создания
нового аналитического счета) – для счетов 2600
 Сделка начисления процентов на текущий счет
 Сделка «Абонплаты и комиссии» при открытии текущих счетов
(стандартные пакеты)
 Депозит юридического лица – сделка «Депозит ЮЛ#») (кроме депозитов
с индивидуальными условиями)
В Siebel CRM механизм оформления данных сделок единообразен. Для всех
типов продуктов используется сделочный механизм. В АБС Б2 (в бизнеспрактике ВТБ) сделочный механизм используется только для оформления
сделки Депозит юридического лица (сделка «Депозит ЮЛ #»). В случае с
текущим счетом, происходит открытие нового аналитического счета и
привязка к нему сделки начисления процентов и сделки АиК.
Siebel не будет обеспечивать порождение каких-либо платежных
документов АБС Б2 в рамках открытия сделок кроме случаев, когда это
предусмотрено логикой работы соответствующих веб-сервисов или
процедур АБС Б2.
В соответствии с ограничениями, озвученными
Исполнителем в Тендерном предложении, Siebel не обеспечит возможности
наложения электронной цифровой подписи на такие документы. Данное
обстоятельство может привести к нарушению непрерывности бизнеспроцесса оформления депозитной сделки и потребовать осуществления
дополнительных операций (ввода и авторизации документов) через
интерфейс АБС. Для решения данной проблемы Исполнитель
рекомендует использовать подход к интеграции, предложенный в
Тендерном предложении (использование тонкого клиента АБС Б2)
Структура веб-сервисов
Необходимая веб-сервисов по сделкам пассивных продуктов со стороны B2
(интеграционной шины) представлена в таблице 6:
Веб-сервис
B2_Corp_CASA_Deal
Назначение
Веб-сервис для работы
со сделками текущих и
сберегательных
(текущих + сделка
начисления процентов)
счетов.
CASA = Current And
Savings Account
Таблица 7. Веб-сервисы для работы с контрагентом - ЮЛ
Метод
Назначение
Create
Обеспечивает создание нового
текущего счета (аналогично
работе мастера создания
аналитического счета),
дополнительных счетов 2608,
2570, 2605 в зависимости от
переданных параметров),
сделки начисления процентов
и сделки АиК (либо привязке к
существующей сделке АиК в
зависимости от настроек АБС),
связанных с созданным
текущим счетом. Возвращает
структуру данных с
информацией о параметрах
созданной сделки (сделок) и
связанных с ней счетах.
AddServedAccount
B2_Corp_TD_Deal
Веб-сервис для
работы со сделками
коммерческих
депозитов
Create
Добавление счета
обслуживания в новой валюте
(с сохранением порядкового
номера и ключа счета) к
существующему текущему
счету
Логика работы аналогична
логике работы при создании
новой сделки «Депозит ЮЛ#»,
включая автоматическое
открытие сопутствующих
TD = Term Deposit
Prolong
B2_Corp_MF_Deal
Веб-сервис для
работы со сделками
АиК
Create
Create
Update
B2_FinancialAccount
Веб-сервис работы со
счетами
Query
счетов (дисконта, премии и
др.) и счетов платежных
инструкций (при
необходимости). Возвращает
структуру данных с
информацией о параметрах
созданной сделки (сделок) и
связанных с ней счетах.
Пролонгировать депозит на
новый срок
Веб-сервис осуществляет
создание новой сделки АиК с
выбранным пакетом и
привязку ее к выбранному
счету.
Веб-сервис создания нового
счета (соответствует процедуре
eprAAccount_create)
Веб-сервис обновления
параметров счета
(соответствует процедуре
eprAAccount_update)
Возвращает информацию о
счете, включая онлайновый
остаток (соответствует
результату выполнения
запроса к представлению
VAAccount_Ex)
Механизм веб-сервисов должен повторять логику работы по открытию
указанных типов сделок (исходя из набора переданных параметров), а
также все необходимые валидации переданных параметров, которые
осуществляются в рамках стандартного режима функционирования АБС.
В качестве ответа в случае успешного оформления сделки из АБС Б2
должна быть передана структура данных оформленного договора и его
счетов.
Номенклатура возвращаемых параметров (полей договора) будет
определена позднее.
Потенциальная сделка Siebel
(Opportunity)
Создание сделки
Договор Siebel
(Service Agreement)
Ответ Б2
Сделка Б2
Сделка Б2
Счета
(Financial Account)
Ответ Б2
Счета
Рис. 6. Создание сделки
Первоначальная загрузка и обратная синхронизация данных
Для осуществления задачи первоначальной загрузки Заказчик на
основании технического задания Исполнителя должен разработать набор
соответствующих представлений СУБД, содержащих необходимую
информацию о клиентах, бизнес-партнерах, связях, сделках, счетах, а также
представления для загрузки мастер-данных (справочники, параметры
типов сделок). Также должен быть реализован прямой доступ (DBLink) к
таблицам и представлениям АБС Б2 из СУБД Siebel CRM.
Ключом обратной синхронизации для сделок, счетов является код в АБС Б2
(DEALID, AACCOUNT.ID соответственно). Со стороны АБС должна быть
обеспечена уникальность данного ключа.
В случае, если между сущностями с одинаковыми идентификаторами Siebel
и АБС в рамках ночной синхронизации имеются расхождения,
информация приводится в соответствие с данными из АБС Б2.
Остатки по счетам будут запрашиваться в режиме онлайн (метод
B2_FinancialAccount.Query), храниться в Siebel на постоянной основе они не
будут.
Со стороны Siebel будут реализованы необходимые трансформации, а
также обеспечена инфраструктура для запуска процессов по расписанию.
Тот же механизм будет использоваться и для ежесуточной обратной
синхронизации изменений, произошедших в АБС, но не инициированных
из Siebel. Для этого на стороне АБС должна быть предусмотрена
инфраструктура отслеживания таких изменений по сущностям «Счет»,
«Сделка начисления процентов», «Сделка АиК», «Сделка Депозит ЮЛ#»
для реализации инкрементальной загрузки изменений в Siebel.
Сервис печати документов
Завершающим этапом оформления сделки в АБС Б2 является печать
необходимых
документов
(уведомления
об
открытии
счетов,
мемориальные ордера, договора и др.). При открытии соответствующих
сделок из Siebel должна быть обеспечена аналогичная функциональность.
Учитывая, что печать возможна только на основе информации,
хранящейся
в
АБС,
необходимо
использовать
существующую
инфраструктуру и шаблоны печатных форм, хранящихся с АБС.
Сервис печати должен функционировать в виде веб-приложения с
возможностью доступа к нему в HTTPS-режиме с передачей кода сделки и
шаблона документа, после чего возвращать сформированный документ на
локальный ПК в формате PDF или другом формате, определенном в
настройках шаблона в АБС Б2. Для реализации данного сервиса Заказчику
не обходимо обратиться к производителю АБС, либо осуществить reverseengineering существующего сервиса печати и реализовать веб-приложение
на его основе.
Отсутствие официального API АБС Б2
Документация на публичный API АБС Б2 не содержит информации о
возможности использования каких-либо процедур для создания или
модификации сделок начисления процентов, АиК или коммерческих
депозитов. В связи с этим, для создания веб-сервисов Заказчику необходимо
либо обратиться к производителю АБС, либо осуществить reverseengineering процессов, происходящих при заведении соответствующих
типов сделок (например, путем трассировки сессии в СУБД Oracle и
определения номенклатуры и последовательности вызываемых пакетов).
Мастер-данные
В рамках первого этапа внедрения предусматривается автоматическая
синхронизация мастер-данных, источником которых является АБС Б2
(статистические справочники НБУ, другие ключевые справочники АБС,
параметры сделок).
Для реализации данного механизма Заказчик реализует набор
соответствующих представлений СУБД над таблицами справочников и
параметров сделок. Со стороны Siebel будет обеспечена синхронизация
этой информации по расписанию.
Следует учитывать, что автоматическая синхронизация возможна не по
всем мастер-данным. В частности, не будет обеспечена синхронизация
параметров сделок в части логики, которая содержится в пользовательских
PL/SQL-процедурах.
Ограничения и допущения относительно интеграции с системой HRM
В рамках последующих этапов внедрения, может быть рассмотрена
возможность интеграции Siebel и HRM-системы банка для синхронизации
по организационной структуре и учету кадровых соытий.
Учитывая определенную логику, заложенную производителем Oracle Siebel
CRM в подсистему управления организационной и штатной структурой,
при реализации автоматизированных механизмов взаимодействия с этой
функциональностью Siebel CRM, должны приниматься во внимание
следующие ограничения:

Интегрируемые системы должны поддерживать сходную
идеологию работы с организационной и штатной структурой, а
именно:
o
В системе должны существовать понятия «Организация»,
«Подразделение», «Штатная единица»
o
В системе должны существовать понятия «иерархия
организацй», «иерархия штатных единиц» (независимые
друг от друга)
o
Уровни детализации организационной и штатной
структуры в Siebel и интегрируемой системе должны
совпадать.
o
Одна штатная единица может быть сопоставлена с одной и
только одной организацией
o
Наименования организаций, подразделений и штатных
единиц должны быть уникальными.
o
Не должно допускаться назначение нескольких физических
лиц на одну штатную единицу кроме случаев внутреннего
(временного) совмещения (то есть, каждый клиентский
менеджер должен быть трудоустроен на уникальную
штатную единицу, и на одну штатную единицу не может
быть трудоустроено более одного клиентского менеджера
кроме случаев временного совмещения обязанностей или
замещения)
o
Регистрация кадровых событий, связанных с замещением
одного сотрудника другим сотрудником должна
осуществляться путем временного назначения замещающего
сотрудника на штатную единицу замещаемого сотрудника
(с явным указанием начальной и конечной даты такого
замещения)
o
Удаление организаций, подразделений, штатных единиц в
интегрируемых системах должно быть запрещено
o
Реорганизации в интегрируемых системах должны
осуществляться способом, соответствующим идеологии
работы с организационной и штатной структурой в Siebel
CRM (т.е. путем закрытия реформируемых подразделений с
перводом штатных единиц в другие, либо путем
переопределения родительских организаций/штатных
единиц).

Одному пользователю должна соответствовать одна и только одна
учетная запись в интегрируемой системе

Следует учитывать также следующие особенности идеологии Siebel
CRM:
o
Закрепление клиентов осуществляется за штатными
единицами менеджеров (таким образом, назначение другого
менеджера на штатную единицу приведет к
автоматическому назначению его менеджером связанных с
данной штатной единицей клиентов)
o
Закрепление задач, взаимодействий, запросов на
обслуживание осуществляется за учетными записями
пользователей. Таким образом, не существует стандартной
возможности массового переназначения данных сущностей
при смене владельца данных сущностей.
Общие требования к веб-сервисам
Базовые принципы
Все WSDL-файлы должны быть оформлены в стиле DOC/Literal;
Все даты принимаются/передаются в формате “дд.мм.гггг”;
Web-сервисы должны поддерживать “пакетный” режим, который
позволяет за один вызов метода web-сервиса произвести действия
(создать/модифицировать/удалить) сразу над несколькими экземплярами
сущности АБС Б2
Синхронность
Осуществление синхронизации по описанным выше сущностям
осуществляется в синхронном режиме. Siebel ожидает сообщения об успехе
операции или об ошибке после инициирования операции и не переходит к
выполнению следующей операции до получения ответа.
Логика валидации и трансляция ошибок АБС
В рамках проекта не предполагается реализация внутренней логики АБС
Б2 для валидации атрибутов создаваемых сущностей в Siebel. Корректным
является осуществление таких валидаций в АБС и поддержка
соответстувующей логики производителем АБС. Siebel обеспечит базовые
валидации. Веб-сервисы должны быть разработаны таким образом, чтобы
включать в себя все специальные виды валидаций, выполняемые на стороне
АБС.
Сообщения об ошибках, выдаваемые механизмами АБС при попытке
выполнения операций, должны быть транслированы в Siebel в ответном
сообщении (атрибут ErrorMessage)
Аутентификация пользователя при взаимодействии Siebel и АБС Б2
Подключение к веб-сервисам должно осуществляться в защищенном
режиме (HTTPS), перед началом работы веб-сервиса должна быть
осуществлена аутентификация и персонализация пользователя, от имени
которого предполагается осуществление операции в АБС Б2. Необходимым
условием при этом является наличие в АБС Б2 одной и только одной
учетной записи для каждого физического лица, которое является
пользователем АБС.
Учитывая, что:
1.
АБС Б2 не интегрирована с MSAD
2.
Siebel CRM использует MSAD для хранения собственного логина и
пароля
3. Хранение логина и пароля АБС
незащищенном виде недопустимо,
Б2
во
внешних
системах
в
4. Пользователи в праве изменять пароль в АБС Б2 без уведомления
будет использован следующий подход:
1. Пароли пользователей Б2 не хранятся в Siebel
2. На стороне АБС Б2 создается ряд технологических пользователей,
которые соотносятся с группами пользователей Зибель и имеют
определенные права на изменения.
3. Своевременная смена паролей технологических пользователей и
переконфигурация их прав - зона ответственности Банка. Авторизация
технологического пользователя происходит на уровне middleware
4. Вызывающий процесс Зибель в теле сообщения передает веб-сервису
логин технологического пользователя и логин пользователя Siebel.
5. Задача интеграционного middleware – осуществить соединение с АБС
Б2 от имени технологического пользователя АБС, персонализировать
пользователя и выполнить вызов необходимых операций в АБС от
имени реального пользователя, логин которого передан из Siebel, с
учетом прав и полномочий этого пользователя в АБС, а также
обработать исключения, связанные с отсутствием такого пользователя в
АБС
или
недостаточностью
его
прав
для
осуществления
запрашиваемой операции.
Регламент синхронизации
Учитывая специфику закрытия дня в АБС Б2 (процедура закрытия дня
сопровождается переводом АБС в монопольный режим и закрытием всех
пользовательских соединений), процедура ночной синхронизации будет
начинаться после окончания закрытия операционного дня в АБС.
Основные параметры, которых необходимо достичь в рамках внедрения:
1. Длительность ночной синхронизации по ключевым сущностям (бизнеспартнеры, контрагенты, связи, сделки, счета): не более 3 часов3
2. Допустимое время нахождения систем в рассинхронизированном
состоянии: не более 36 часов.
3 При реализации механизмов отслеживания изменений по всем перечисленным сущностям в АБС, а также
использовании прямого доступа к таблицам или представлениям СУБД
Миграция данных из заменяемых систем
В процессе внедрения предполагается вывести из эксплуатации следующие
используемые банком системы:
1. Журнал регистрации дополнительных соглашений о предоставлении
доступа к системе «Расчетный центр клиента» (MS Excel)
2. Реестр договоров по приему наличной выручки (Lotus Notes)
3. Реестр кредитных заявок (MS Excel)
По системам 1 и 2 будет осуществлена первоначальная миграция всей
истории (существующих в них договоров) в Siebel CRM
По системе 3 ввиду существенного изменения структуры данных и подхода
к ведению кредитных заявок, миграция истории заявок из заменяемой
системы не предполагается (см. документ BP060.LN.Управление
корпоративным кредитованием).
Интеграция с базой данных Государственного комитета статистики
В рамках первого этапа внедрения предполагается загрузка информации о
потенциальных клиентах из базы данных Государственного комитета
статистики (ГКС).
Данная
интеграция
предполагает
загрузку
информации
из
соответствующей базы данных (исходный формат – Microsoft Access) в
таблицы СУБД Siebel и реализацию механизмов отображения сведений из
ГКС в интерфейсе Siebel CRM.
Интеграция Siebel и внешних СУБД-потребителей информации и
Oracle Hyperion Planning
Для исходящей интеграции с внешними хранилищами данных с целью
выгрузки информации из Siebel CRM в аналитические витрины, а также
ПО Oracle Hyperion Planning, на стороне Siebel CRM будет сформирован
ряд представлений СУБД (views, materialized views), денормализующих
информацию из таблиц в необходимый для загрузки в ETL-средства вид.
Между СУБД Siebel CRM и СУБД потребителей информации должны быть
настроены соответствующие DBLinks, либо подключения по другим
интерфейсам (OCI, ODBC).
Номенклатура представлений и их наполнение будет определяться
требованиями, предъявляемыми внешними системами.
Для входящей интеграции (в случае, если требуется использование какихлибо данных, находящихся во внешних реляционных СУБД в Siebel) будут
использоваться, там где это возможно, механизмы EBC/VBC (см. раздел
«Интеграционные механизмы») над таблицами или представлениями в
соответствующих СУБД. Для организации доступа к объектам внешних
СУБД потребуется создание DBLinks.
На первом этапе внедрения такая интеграция предполагается со
стандартными витринами СУБД CS:BI, а также дополнительными
витринами CS:BI, накапливающими информацию из системы IS-Card.
Интеграция Siebel и Microsoft Active Directory
Аутентификация пользователей Siebel будет осуществляться путем
проверки реквизитов пользователя в LDAP-каталоге (Microsoft Active
Directory) с деперсонализированной работой с базой данных Siebel CRM.
Для интеграции с Active Directory будет использован адаптер Siebel ADSI
Security Adapter.
Сценарий аутентификации пользователя Siebel выглядит следующим
образом:
1. Пользователи Siebel CRM вводит свои логин и пароль при входе в Oracle
Siebel CRM.
2. ADSI Security Adapter устанавливает соединение с Active Directory от
имени технологического пользователя LDAPUSER
3. Введенные пользователем логин и пароль передаются в Active Directory
и проверяются на принадлежность к группе пользователей имеющих право
на работу в Siebel
4. В случае успешной проверки обратно возвращается идентификатор
сессии и устанавливается соединение с Siebel DB от имени пользователя
LDAPUSER
5. Все изменения в Siebel DB отслеживаются на уровне LoginID,
принадлежащего конкретному пользователю Siebel, который прошел
аутентификацию через Active Directory
6. Сценарий не распространяется на технологических пользователей
системы
7. Физические пользователи не имеют персональных учетных записей в
Siebel DB
Все пользователи, работающие в Siebel, должны иметь учетную запись в
MSAD. Максимальное полное имя пользователя (CN) от корня должно быть
ограничено 256 символами.
Интеграция Siebel и Oracle Business Intelligence Enterprise Edition
Пользователи Siebel CRM используют аналитические приложения Oracle BI
в качестве основного средства отчетности. Отчеты Oracle BI размещаются
на дашбордах в соответствии с функциональным дизайном. Доступ к
дашбордам регулируется полномочиями Siebel CRM. Для работы с Siebel
используется выделенный экземпляр приложения Oracle Business
Intelligence Enterprise Edition, который может размещаться на отдельном
оборудовании либо на оборудовании продуктивной среды Siebel CRM.
Для доступа к отчетам непосредственно из интерфейса Siebel CRM
используется экран «Отчеты» (SB BI Reports), который осуществляет
отображение интерфейса Oracle BI в соответствующем IFrame и
настроенный в соответствии с Metalink Note Integrating Siebel Analytics with
Siebel Applications [ID 477377.1] (Method 2 – Iframe) либо встраивание
отчетов непосредственно в формы Siebel CRM (контекстно-зависимые
отчеты)
При переходе на экран «Отчеты» реализуется следующий сценарий:
1. Осуществляется формирование Symbolic URL с подстановкой
динамических параметров и передачей реквизитов пользователя в URL
(метод POST)
2. Сервер Oracle BI проверяет реквизиты пользователя (nqUser,
nqPassword) в инициализационном блоке ADUserAuthentification
(источник данных – сервер AD для аутентификации)
3. В результате успешной аутентификации параметр nqUser
инициализирует значение системной переменной USER
4. Для установления принадлежности пользователя тем или иным
группам доступа, для переменной GROUP создается новый
инициализационный блок UserRespAuthorisation (Row-Wise
Initialization, Cache Disabled) со следующим запросом к БД Siebel:
SELECT
FROM
WHERE
'GROUP', UPPER(R.NAME)
SIEBEL.S_RESP R, SIEBEL.S_PER_RESP P, SIEBEL.S_USER U
U.LOGIN = upper(':USER')
AND U.ROW_ID = P.PER_ID
AND P.RESP_ID = R.ROW_ID
5. В результате успешной аутентификации и авторизации, пользователь
получает право доступа к тем дашбордам и отчетам, которые включены
в правила доступа для тех групп, которым он принадлежит.
Интеграция Siebel и SMTP-сервера
Взаимодействие с SMTP-сервером для рассылки сообщений электронной
почты осуществляется с помощью механизмов Siebel Communication Server.
Для функционирования данных механизмов необходимо наличие SMTPсервера и учетной записи, от имени которой будет осуществляться
рассылка электронной почты.
Других типов интеграции с серверами электронной почты на первом этапе
внедрения не предполагается.