Siebel collection что это
Обновлено: 17.05.2024
Чтобы рассказать обо всех особенностях Siebel CRM одной статьи точно не хватит, нужно написать как минимум книгу. Поэтому в данной статье мы постараемся осветить самые главные моменты, расскажем об основных составляющих, архитектуре и функциональных возможностях одной из самых востребованных на рынке управления взаимоотношениями с клиентами системе – Siebel CRM.
Компания Siebel Systems была одной из первых, вышедших на рынок CRM систем, в 2000-х годах ее доля относительно остальных вендоров подобных решений составляла 45%. Ее заказчиками в разное время становились такие компании как Cisco Systems и Compaq. В 2005 Siebel Systems была поглощена компанией Oracle и теперь полное название системы управления взаимоотношениями с клиентами выходит под брендом Oracle Siebel CRM.
Стоит сразу оговориться, что Siebel CRM ориентирована на большие компании, с численностью 10 000 и более сотрудников, а значит должна быть легко масштабируема и абсолютно совместима с различными платформами, обеспечивая одновременный доступ тысяч пользователей к корпоративным данным. Поэтому современные версии Siebel CRM имеют стандартную вэб-ориентированную, модульную архитектуру.
ОСНОВНЫЕ СОСТАВЛЯЮЩИЕ АРХИТЕКТУРЫ SIEBEL CRM
Хранит в себе клиентскую и административную информацию, а также репозитории (различные версии конфигураций Siebel CRM). В качестве такой базы данных может использоваться MS SQL, Oracle Enterprise Server, IBM D2B и др.
Хранит нереляционную и бинарную информацию, например: вложения, документы и временные файлы.
В системе может быть один или несколько Siebel серверов, вместе они образуют Enterprise сервер. Enterprise сервер – это некое логическое объединение, которое обеспечивает доступ ко всей базе данных и файловой системе и которое управляется одним Siebel Gateway Name Server’ом.
Обеспечивает управление всеми Siebel серверами, входящими в Enterprise и, соответственно, хранит его конфигурацию.
Устанавливается на вэб-сервер, осуществляет взаимодействие web-браузеров с объектами Siebel серверов, обеспечивает аутентификацию пользователей и балансировку нагрузки.
Обеспечивает графическое отображение объектов Siebel CRM и доступ к интерфейсу пользователя. Полный доступ обеспечивает только Internet Explorer, в ограниченном режиме поддерживаются Mozilla Firefox и Safari.
Выводы
С учетом того, как Oracle Siebel CRM обрабатывает события, я рекомендую запускать валидацию данных на ветке Pre-Branch события WriteRecord. В этом случае при попытке пользователя сохранить созданную им запись система говорит, в каких полях данные не соответствуют определенной бизнес-логике. Пользователь вносит соответствующие корректировки и вновь пробует всё сохранить.
Проверка значений каждого поля потребует написания скрипта, так как Run-Time Event не имеет доступа к новому значению, когда находится на ветке Pre-Branch события SetFieldValue.
SetFieldValue – скрипт
Что именно делает это свойство, мы увидим позже.
Далее рассмотрим такой скрипт на уровне бизнес-компоненты Contact:
Было до ввода нового значения:
Ввод нового значения:
После перехода на другое поле:
Повторяем все те же самые действия и видим немного другой результат:
Во-первых, в тексте ошибки отображается новое значение. Во-вторых, несмотря на ошибку, которую видит пользователь, введенное значение осталось на месте.
 | Если система дошла до выполнения Post Branch, то можно утверждать, что стандартный обработчик закончил свое выполнение без ошибок. Значит, из приведенного примера можно сделать вывод, что стандартный обработчик SetFieldValue обновляет значение поля на уровне бизнес-компоненты. Тут важно заметить, что на уровне таблицы в этот момент ничего не поменялось. Убедиться в этом можно, выполнив простой запрос в базу данных. |
Из приведенного примера можно сделать вывод: если обращаться к полю бизнес-компоненты на Pre-Branch события SetFieldValue, то система вернет текущее значение поля, которое там было до ввода нового значения. С другой стороны, если обращаться к полю бизнес-компоненты на Post-Branch события SetFieldValue, то система вернет введенное пользователем значение.
29.4 Siebel Gateway
The configuration categories and their associated configuration items for the Siebel Gateway target type follow.
29.4.1 Siebel Gateway Configuration
This metric captures details for the Siebel Gateway Configuration in parameter pairs of Property Name and Property Value. The Property Names are parameters that are appropriate for or affect the Siebel Gateway.
Following is an example of parameter pairs for a Siebel Gateway:
| Property Name | Property Value |
|---|---|
| host | sdchpi01 |
| SIEBEL_GATEWAY | sdchpi01 |
Знакомство с 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, на машине разработчика. Обычно работа разработчика представляет собой последовательность следующих действий:
SetFieldValue – Run-Time Event
Все приведенные принципы работают и в том случае, если обработчики для Post-Branch и для Pre-Branch будут запускаться через механизм Run-Time Events, а не через скрипты.
Для демонстрации этого рассмотрим вот такое простое правило валидации (Administration – Data Validation):
Чтобы запустить это правило, нужно создать Action Set (Administration – Runtime Events) с одним действием. Параметры для этого действия приведены таблице:
| Action Type | BusService |
| Business Service Name | Data Validation Manager |
| Business Service Method | Validate |
| Business Service Context | «Rule Set Name», «SBL Contact Dummy Validation» |
В результате обработчик готов и его нужно прицепить к соответствующему событию. Для этого потребуется создать Event:
В данном случае обработчик будет запущен на ветке Pre-Branch события SetFieldValue бизнес-компоненты Contact, если будет обновляться поле [Email Address]. Тут важно обратить внимание на Conditional Expression. В его рамках система должна считать значение из поля [Email Address] и убедиться, что длина этого значения меньше 3 символов. Только в случае выполнения условия обработчик будет запущен.
Теперь можно проверить, как система будет реагировать на внесение изменений почтового адреса физического лица.
Ввод нового значения, длина которого меньше 3-х символов:
После перехода на другое поле:
Если теперь ввести старое значение в это поле:
и перейти на другое поле:
то, во-первых, пользователь увидит ошибку, во-вторых, значение в поле не изменится. Фактически мы получили сразу две ошибки: первая – системная, вторая – ошибка от Data Validation. Если кто-нибудь знает, как избавиться от первой в данном случае, напишите в комментариях. Если понимать принцип работы стандартного обработчика для события SetFieldValue, то полученный результат окажется вполне логичным.
Теперь можно внести маленькое изменение в рассмотренный Event:
В данном случае обработчик привязан к Post-Branch события SetFieldValue. Всё остальное остается, как было, но поведение системы будет существенно другим.
Но если попытаться внести значение меньше 3-х символов, то произойдет следующее:
WriteRecord
Если стандартный обработчик события SetFieldValue фактически спускает значения с уровня апплета на уровень бизнес-компоненты, то стандартный обработчик WriteRecord спускает данные с уровня бизнес-компоненты на уровень таблицы. То есть происходит обновление данных в соответствующих таблицах, которые потом смогут увидеть другие пользователи системы.
Разница между SetFieldValue и WriteRecord заключается ещё в том, что в первом случае обновление полей происходит по отдельности, а во втором случае в базу данных спускаются изменения сразу по всем полям.
Если разработчик напишет свой обработчик и привяжет его к Pre-Branch события WriteRecord, то все действия система выполнит до записи данных в базу, в другом случае запись в базу данных уже будет произведена. Соответственно, если на ветке Pre-Branch произойдет ошибка, то данные в базе не изменятся, и наоборот, если ошибка произойдет на ветке Post-Branch, то это не повлияет на стандартный обработчик и данные в базе обновятся.
Immediate Post Change
Свойство поля Immediate Post Change, в случае если оно равно «Y», говорит системе о том, что событие SetFieldValue для соответствующего поля нужно запустить в тот момент, когда пользователь внес изменения и пытается перевести курсор в другое место. Если оно не выставлено, а у большинства полей это так, то событие SetFieldValue происходит в рамках обработки события WriteRecord. То есть система смотрит, какие данные с уровня апплета не были перенесены на уровень бизнес-компонента, и для каждого поля запускает SetFieldValue, а уже потом запускается WriteRecord.
Событийная модель Oracle Siebel CRM (Часть 1)
Данная статья предназначена для тех, кто знаком с системой Oracle Siebel CRM и кто хорошо понимает её трехуровневую архитектуру.
При проектировании системы важно хорошо понимать, как она будет реагировать на различные действия пользователя: создание или удаление записи бизнес-компоненты, нажатие на кнопку на апплете, редактирование поля, сохранение данных и т.д. Чтобы создать именно ту архитектуру, которая с одной стороны реализует требования заказчика, а с другой не будет увеличивать издержки на дальнейшую поддержку и масштабирование, нужно знать, как Oracle Siebel CRM обрабатывает каждое событие, которое инициирует пользователь либо процедура.
- Pre-Branch
- Стандартный обработчик
- Post-Branch
Фактически Pre-Branch и Post-Branch – это заглушки, внутри которых у разработчиков есть возможность написать свои обработчики, то есть заложить свой алгоритм обработки события. Выбор ветки, в которой пишется этот алгоритм, зависит от того, что делает стандартный обработчик. В данной статье подробно разбираются два самых часто используемых события на уровне бизнес-компонент: SetFieldValue (обновление значения поля) и WriteRecord (сохранение изменений в базу данных).
29.3 Siebel Enterprise
The configuration categories and their associated configuration items for the Siebel Enterprise target type follow.
29.3.1 Siebel Enterprise Configuration
This metric captures details for the Siebel Enterprise Configuration in parameter pairs of Property Name and Property Value. The Property Names are parameters that are appropriate for or affect the entire Siebel Enterprise. This would include Siebel Enterprise parameters as well as Siebel Named Subsystems. Named Subsystem Property Names are in the format of:
Following is an example of parameter pairs for a Siebel Enterprise:
| Property Name | Property Value |
|---|---|
| filesystem | vol1/sia80ora/siebsrvr/fs |
| secadptmode | DB |
| secadptname | DBSecAdpt |
| SIEBEL_GATEWAY | sdchpi01 |
| SubSys_DBSecAdptdatasourcename | ServerDataSrc |
| SubSys_GatewayDataSrcdsconnectstring | sdchpi01:3220 |
| SubSys_ServerDataSrcdsmaxcursorsize | -1 |
| tableowner | usia05 |
29.3.2 Siebel Upgrade
This metric represents a list and history of all Fix Packs and Quick Fixes that have been applied to the Siebel system. The upgrade.txt file that contains this information is located in the $SIEBEL_HOME directory and the data present in this file is collected using Perl file siebel_upgrade.pl.
| UPGRADE_NUMBER | ACTION | FIX_PACK_VERSION | QUICK_FIX | DATA_TIME |
|---|---|---|---|---|
| 1 | INSTALLED | 7.8.2.16 | Not Applicable | Wed Feb 02 11:04:53 GMT-07:00 2011 |
| 2 | INSTALLED | 7.8.2.16 | QFTEST | Wed Feb 09 11:04:53 GMT-07:00 2011 |
29 Siebel Collections
The configuration categories and their associated configuration items for the Siebel Component target type follow.
The relationship between the deployment of a Siebel Server and dependent database is collected only for Oracle database.
29.1.1 Siebel Component Configuration
This metric captures details for the Siebel Component Configuration in parameter pairs of Property Name and Property Value. Not all Siebel components contain the same set of parameters so the actual output may vary from one component to another. For example, an Application Object Manager (AOM) component may have different parameters than a Transaction Router component. This generic pairing of Property Name and Property Value allows for any parameter to be captured for all Siebel components.
Following is an example of parameter pairs for the SCCObjMgr_enu component:
| Property Name | Property Value |
|---|---|
| datasource | ServerDataSrc |
| host | sdchpi01 |
| maxtasks | 500 |
| maxmtservers | 10 |
| SIEBEL_ENTERPRISE | sia80 |
| SIEBEL_COMPNAME | SCCObjMgr_enu |
29.2 Siebel Component Group
The configuration categories and their associated configuration items for the Siebel Component Group target type follow.
29.2.1 Siebel Component Group Configuration
This metric captures details for the Siebel Component Group Configuration in parameter pairs of Property Name and Property Value. This is similar in nature to the Siebel Component Configuration, however the Component Groups will have the same Property Names for all groups (though the Property Values may be different). A Component Group Configuration is not the same as a Siebel component definition, although some of the same parameter names may appear.
Following is an example of parameter pairs for the Call Center component group:
| Property Name | Property Value |
|---|---|
| SIEBEL_COMPGROUP | CallCenter |
| SIEBEL_ENTERPRISE | sia80 |
| SIEBEL_GATEWAY | sdcp520a001 |
29.5 Siebel Server
The configuration categories and their associated configuration items for the Siebel Server target type follow.
29.5.1 Siebel Server System Configuration
This metric captures details for the Siebel Server System Configuration in parameter pairs of Property Name and Property Value. The Property Names gathered for this section contains the Siebel server parameter names while the Property Values are those specific to the settings for this Siebel server.
Following is an example of parameter pairs for a Siebel Server System Configuration:
| Property Name | Property Value |
|---|---|
| host | sdchpi01 |
| logdir | /vol1/sia80ora/siebsrvr/enterprises/sia80/srvr1/log |
| rootdir | /vol1/sia80ora/siebsrvr |
| SIEBEL_ENTERPRISE | sia80 |
| SIEBEL_SERVER | srvr1 |
29.5.2 Siebel Server General Configuration
This metric captures details for the Siebel Server General Configuration in parameter pairs of Property Name and Property Value. The Property Names gathered for this section are not necessarily Siebel server parameter settings, but could contain applicable details for the Siebel server which might be found in other files on the server (such as base.txt). These Property Names would be associated with their corresponding Property Values.
Following is an example of parameter pairs for a Siebel Server General Configuration:
Читайте также: