Знакомство с Oracle Siebel CRM

Эта статья пишется для того, чтобы дать представление о довольно специфическом программном комплексе, который используется во многих крупных предприятиях по всему миру, но при этом остается малоизвестным широкому кругу IT-специалистов, даже в сравнении с подобными ему продуктами, как, например, SAP.
Доступной литературы по ней довольно немного, или она настолька туманна и запутанна, что человеку «с улицы» может быть нелегко понять, что это вообще такое. Здесь мы попробуем прояснить этот вопрос.

Весь этот комплекс я буду называть просто Siebel, официально он называется Oracle Siebel CRM. Название Siebel представляет собой фамилию основателя компании (Thomas Siebel). В 2006 году компания была продана корпорации Oracle.

Siebel в первую очередь представляет собой систему управления взаимоотношениями с клиентами (Customer Relationship Manаgement — CRM). Эта система может быть установлена во множестве уже готовых «из коробки» конфигураций, как-то Siebel Call Center, Siebel Finance, Siebel Loyalty (с движком для системы программ лояльности клиентов), Siebel Hospitality (для гостиничного бизнеса) и многих других. Тем не менее, потребители продуктов Siebel (обычно это достаточно крупные компании, работающие по крайней мере с десятками тысяч клиентов), как правило, требуют «заточки» системы под нужды не только отрасли, но и конкретного предприятия. Поэтому создатели системы старались обеспечить максимальную гибкость настройки и разработки.

С точки зрения пользователя (сотрудника компании-заказчика) Siebel, как декларируется, представляет собой практически zero-footprint application, т.е для работы не требуется установка какого-то специального клиента. Работа с Siebel осуществляется просто в окне Internet Explorer. На самом деле при первом обращении к серверу устанавливаются соответствующие ActiveX компоненты, обеспечивающие действия с элементами управления.
К сожалению, на данный момент другие броузеры (кроме IE) не поддерживаются. Как легко понять, это привязывает пользователей к Windows (что касается серверов Siebel, то они могут работать как под Windows, так и под Linux, а также Solaris, HP-UX и т.д.).
Графический интерфейс пользователя выглядит примерно так:

Разумеется, доступны модули поддержки множества языков, включая русский.

Основной объект GUI Siebel — так называемый апплет. Это часть экрана, отображающая таблицу (list-applet) или данные из одной записи в виде формы (form-applet). Апплет обычно содержит меню и элементы управления в виде кнопок на экране. С их помощью пользователь добавляет или удаляет записи, совершает запросы (query) и другие действия, например, запуск какого-либо бизнес-процесса. Как уже говорилось, Siebel представляет огромные возможности для кастомизации, ограниченные разве что фантазией заказчика/разработчика. На картинке мы можем видеть один лист-апплет и один форм-апплет.

Здесь мы не можем вдаваться в тонкости работы с GUI, лучше опишем, как все это реализовано технически.

Как уже стало понятно, Siebel в первом приближении представляет собой некую графическую надстройку над БД, работающую, как веб-приложение. Базой может быть не только Oracle, но и, например, MS SQL Server или что-то еще. При установке системы автоматически создается огромное количество таблиц — создатели старались включить в комплект все, что кому-то может понадобиться. Тем не менее, всегда можно добавить и кастомные таблицы и колонки. Подавляющая часть информации о конфигурации самого Siebel (списки элементов GUI, кастомные скрипты, взаимосвязи между объектами) также хранится в той же базе, причем там может находиться множество репозиториев (версий конфигурации Siebel) сразу. Тем не менее, та конфигурация, которая реально используется сервером в данный момент, должна быть скомпилирована в специальный файл с расширением SRF. Без этого файла сервер работать не может.

Серверы Siebel объединяются в логические группировки (Enterprises). Работой энтерпрайза управляет служба под названием Siebel Gateway Name Server. К этому серверу обращается веб-сервер (Оracle, IIS..), снабженный специальными «расширениями» (SWSE — Siebel Web Server Extensions). Таковы основные элементы среды Siebel.

Основной инструмент разработчика Siebel — программа под названием Siebel Tools, которая и осуществляет компиляцию.

В простых случаях разработка осуществляется декларативно, посредством «перетаскивания мышкой» ЭУ GUI на форму и заполнения соответствующих полей данными, наподобие того, как создается приложение Windows Forms в Visual Studio. Для программирования более сложного поведения системы обычно используется либо встроенный язык (фактически это JScript или VBScript, на выбор разработчика), либо графический Workflow Designer.

Основной инструмент отладки — Siebel Dedicated Web Client (на жаргоне его называют «толстым клиентом», в отличие от «тонкого клиента», с которым работают пользователи работающей системы). Несмотря на название, «толстый клиент» представляет собой некий мини-сервер Siebel, запускаемый, как и Siebel Tools, на машине разработчика. Обычно работа разработчика представляет собой последовательность следующих действий:

• Запускается Siebel Tools, который соединяется с БД среды разработки, в ней выбирается нужный репозиторий Siebel
• Изменяемый объект или набор объектов (проект) копируется в локальную базу разработчика, а на серверной БД защищается от изменений другими разработчиками (check-out)
• На машине разработчика совершается работа с этими объектами, после чего они компилируются в локальный SRF-файл
• Запускается Dedicated Web Client, соединенный с этим SRF-файлом
• Если тестирование в «толстом клиенте» проходит успешно, измененные объекты записываются в серверную базу, после чего защита от изменений снимается (check-in)
• В какой-то момент репозиторий компилируется в SRF сервера, после чего изменения становятся доступны для пользователей

Автоматизация поставок Siebel: На пути от хаоса к порядку

Разработка под Siebel имеет свои отличительные черты. В её основе лежит конфигурирование объектов, и автоматизация бизнес процессов c их использованием, как из кубиков, использование справочников особых значений. Возможность написания скриптов присутствует, но не занимает доминирующее положение. Все изменения производятся через IDE Siebel Tools, либо в интерфейсе приложения. Особенностей много, но ничто человеческое Siebel не чуждо, и в том числе проблема переноса изменений с dev контура на другие среды. В этой статье мы хотели бы рассказать о том, как работает наш ci/cd конвейер.

Авторы материала Horkin и Mryavka

RosbankSiebelTeam

Проблематика

Стоит начать с того, что изначально процесс переноса изменений состоял только из инструментов Siebel. После того, как разработчик внес изменение в объект, он должен вручную его экспортировать и положить в папку со своей задачей. При этом нельзя экспортировать только ту часть, которая была изменена, необходимо выгружать объект целиком. А решение задачи, вроде формирования PIN-кода для карты, или списания комиссии за справку, состоит из изменений большого количества таких объектов. При этом IDE не отслеживало список изменений и его приходилось вести вручную. Кстати, такие объекты хранятся в репозитории Siebel, и потому называются repo объектами. К этому добавляется то, что некоторые объекты имеют свои характерные особенности, например, Workflow-процессы (WF) нужно активировать, и чтобы изменения применились и работали, нужно написать инструкцию для администратора, и указать, какой именно процесс нужно активировать. Также нужно выгрузить справочники, которые содержат определенные значения бизнес логики, например, типы банковских счетов и их коды. Если справочник был изменен, например, появился новый тип счета, необходимо его также добавить в поставку. (Такие справочники экспортируются с помощью инструмента Siebel Application Deployment Manager и называются ADM объектами).

Скорее всего, если читатель не знаком с Siebel, то уже загружен новой инфой, но стоит сказать, что и это еще не все. Также есть элементы кастомизации интерфейса, скрипты БД и некоторые конфигурации, которые требует ручных действий. Все это также необходимо выгружать отдельно и указывать в инструкции.

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

Инструменты

Для корректной работы конвейера и коммуникации с участниками процесса были выбраны следующие инструменты:

• JIRA – используется для ведения задач для поставки; Частично используется для коммуникации: разработчики уведомляются о проблемах в сборке, заказчики уведомляются о завершении установки (посредствам комментариев и изменении статусов задач). Так же Jira используется для ведения истории поставок – в задачах отмечается, в рамках каких поставок была произведена установка на наши стенды.
• RocketSiebel (RS) – система контроля версий Siebel. В ней происходит версионирование стендов, разработчики размечают изменения в рамках задач, а конвейер – собирает поставку на требуемую среду.
• Jenkins – оркестратор конвейера. Занимается упорядочиванием действий конвейера, сигнализирует о наличиях ошибок.
• Ansible – “руки” нашего конвейера. При помощи скриптов, написанных на Python и PowerShell, выполняет сборку и установку поставки на стенды Siebel.
• Bitbucket – на данный момент исполняет только роль хранилища исходного кода конвейера. В будущем планируется использоваться для передачи ADM, неверсионируемых в RocketSiebel, и файлов Web-серверов.
• нативные инструменты Siebel 🙂

Описание работы

На текущий момент в Росбанке используется Siebel CRM Innovation Pack 20.5. При разработке функционала (в рамках требований задач Jira) разработчики вносят изменения на dev-стенде. Все эти изменения подтягивает в себя RocketSiebel и позволяет использовать эти изменения для сборки поставки и их передачи по средам. По завершении задачи разработчик размечает свои изменения в Task и называет ключом задачи Jira (чтобы в дальнейшем он мог быть использован при работе конвейера).

Рисунок 1. Тикет в JIRA

По расписанию (в 12:00 и 17:00 для ТЕСТ и в 14:00 для СЕРТ) конвейер начинает работу. Первым шагом он скачивает актуальные версии скриптов установки из Bitbucket. Затем конвейер выгружает по фильтрам Jira задачи для поставки (для ТЕСТ и СЕРТ отдельный фильтр), формирует патч для требуемого стенда в RockerSiebel. Если по какой-то причине по задаче нет Task’а – конвейер её просто пропускает.

Рисунок 2. Таск в RocketSiebel

После сборки конвейер производит проверку патча на наличие конфликтов. Если таковые имеются – идёт оповещение разработчиков через комментарий в Jira и сообщение в Telegram. Для решения конфликтов разработчикам даётся время на их исправление (по умолчанию – 1 час), если конфликты решены не будут – задача исключается из поставки.
При отсутствии конфликтов конвейер продолжает свою работу.

Рисунок 3. Оповещение о конфликте

По завершении работы с конфликтами конвейер делает Merge патча и формирует итоговую поставку для стенда Siebel CRM. После чего начинается процесс установки патча.
Следующим шагом конвейер скачивает и распаковывает архив с поставкой на Windows-сервере, откуда будет производиться установка на стенд. Обязательное условие – наличие на этом сервере подключения к БД Siebel CRM и Siebel Tools.

Рисунок 4. Пайплайн в Jenkins

Установка на требуемый стенд начинается с создания Workspace, в который будут импортироваться объекты. Имя воркспейса соответствует названию поставки в RocketSiebel (для удобства разбора проблем с поставкой).

По нашему опыту работы с IP 20.5 есть определённые проблемы с импортом Workflow процессов, в связи с этим после создания Workspace конвейер переименует WF на стенде по списку объектов поставки, во избежание проблем после установки. SQL скрипт для переименования формируется при помощи java-метода, который вызывается Ansible’ом в БД Siebel.

Затем конвейер блокирует все проекты и происходит импорт объектов из поставки. Далее формируется и применяется скрипт изменения объектов БД (Apply DDL). После происходит инкрементальная компиляция таблиц в Runtime-репозиторий. Список таблиц для компиляции формируется на основании объектов в поставке.

Следующим шагом происходит Checkpoint и Deliver Workspace в Main (применяются изменения к Runtime-репозиторию). При помощи Soap-сервиса отправляется запрос в Siebel с названиями Workflow процессов для их активации.

Последним шагом в установке является заливка справочников ADM. Импорт производится при помощи вызова утилиты RocketSiebel.

По завершении установки конвейер делает оповещения в задачах JIRA из поставки о завершении установки:

1. Указывается имя поставки, в рамках которой производилась установка;
2. Публикуется комментарий о том, что поставка завершена;
3. Меняется статус, сигнализирующий о том, что можно начинать тестирование.
   Дополнительно идёт оповещение разработчиков в Telegram-канале о завершении установки (и наличии возможных ошибок). Дополнительно, информация об установке и лог заливки объектов дублируются в почте.

Рисунок 5. Оповещение об успешной установке

Ближайшие планы

Хотя все справочники версионируются в RocketSiebel, есть печатные формы (ПФ), которые тоже относятся к АДМ объектам, но стоят особняком. На данный момент RS их не версионирует, а в задачах они встречаются часто. Чтобы встроить деплой ПФ в пайплайн, на стороне Siebel сделали отдельный веб-сервис, а сами формы планируем передавать через BitBucket.
Кроме этого, на данной момент конвейер не содержит шаг с рестартом сервера, а не смотря на введения нового Innovation Pack, рестарт часто требуется, так как некоторые серверные компоненты, например, EAIObjMgr не подтягивают изменения из рантайм репозитория без рестарта.

На данный момент разработчики тратят гораздо меньше времени на формирование поставок по своим задачам. Администраторы тратят меньше времени на установку изменений на целевые среды, а некоторых кейсах даже не привлекаются к установке. Существенно сократилось время поставок на непроизводственные контуры и теперь мы выносим изменения в среду тестирования 2 раза в день, а препродакшена 1 раз. Косвенно это повлияло и на количество багов на продакшене, которых заметно сократилось.

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

• RosbankSiebelTeam
• siebel

При подготовке материала использовались источники:
https://habr.com/en/post/123477/?mobile=no
https://habr.com/ru/companies/rosbank/articles/556122/