Oracle Siebel CRM 8 Developer's Handbook

5 (1 reviews total)
By Alexander Hansal
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Siebel Tools and the Siebel Repository

About this book

Oracle's Siebel CRM is market-leading Customer Relationship Management software. Unmatched in functionality and scalability, Siebel enhances a company's sales performance, improves customer satisfaction, and provides a robust Customer Relationship Management system for an organization.

Written by Oracle employee and Siebel expert, Alexander Hansal, this book is a complete practical guide to configuring, automating, and extending Siebel CRM applications. You will learn how to configure the Siebel CRM user interface objects as well as the underlying business layer objects by using real-life case study examples. In addition, you will learn to safely configure the Siebel data model.

You will learn how the object types in the Siebel Repository are related to each other and how they are organized in different layers. The book then teaches you to configure the Siebel CRM user interface objects such as views and applets as well as the underlying business layer objects by using real-life case-study examples. Always having one eye on performance and upgradeability, you will learn to safely configure the Siebel data model.

Understanding and using the Siebel event framework for automation is also a key focus area of the book. You will gain a thorough and solid understanding of integration objects to support EAI interfaces.

Chapters on Siebel Workflow, Task UI, and scripting prepare you for the most complex automation requirements and ensure that you hit the road running on your first Siebel implementation projects.

If you already consider yourself an experienced Siebel consultant, be prepared for some unprecedented insights and pro tips.

Publication date:
April 2011
Publisher
Packt
Pages
576
ISBN
9781849681865

 

Chapter 1. Siebel Tools and the Siebel Repository

One of the reasons why you decided to read this book might have been that you will contribute to an Oracle Siebel CRM project as a developer. You might have just started your new career or you are able to look back on years of professional experience. You may have had the privilege of receiving decent training or tried to master the steep learning path on your own. In either case, having a concise and complete guidebook at hand is very helpful.

In this book you will find comprehensive descriptions and real-life examples for configuration processes in Oracle's Siebel CRM. After a brief overview of the integrated development environment (IDE), which goes by the name of Siebel Tools, and the typical developer tasks, we are ready to explore all aspects of configuration from the user interface (UI) to the Siebel business logic and physical layer, workflow processes, and scripting.

A case study scenario will provide meaningful examples for your exercises.

In this chapter, we will discuss the following topics:

  • Siebel Tools User Interface

  • Siebel Repository Metadata

    • Data Layer Object Types

    • Business Layer Object Types

    • User Interface Layer Object Types

    • Integration Layer Object Types

    • Automation Layer Object Types

    • Other Object Types

 

Siebel Tools user interface


Siebel Tools is a Microsoft Windows application that has been designed to view, visualize, and modify the repository metadata of Siebel CRM. It is an integrated development environment (IDE) that is used mainly by developers; however, at certain project phases, business analysts and technical architects benefit from access to the repository metadata as well.

We can launch Siebel Tools by clicking the respective item in the Windows start menu. The name and location of the start menu item varies with the version of Siebel CRM and the details entered during installation.

After providing username, password, and the data source in the login dialog box, Siebel Tools launches its GUI. In this section, we will describe the user interface elements of Siebel Tools.

Note

The installation of Siebel Tools and other Siebel software products is documented in the book titled Oracle Siebel CRM 8 Installation and Management by the same author, and in the Siebel Installation Guide for Microsoft Windows of the official Oracle Siebel Applications Documentation Library (also known as Siebel Bookshelf). A quick guide for installing a self-study environment containing the Siebel Developer Web Client, the Siebel Sample Database, and Siebel Tools is also provided in the appendix section at the end of this book.

The Siebel Installation Guide for version 8.1 can be found at the following URL: http://download.oracle.com/docs/cd/E14004_01/books/SiebInstWIN/booktitle.html.

If you have completed the installation of the self-study environment, you can follow the examples in this book.

To log in to Siebel Tools and the Sample Database, click the Siebel Tools shortcut in the Windows start menu, enter SADMIN as the username and password, and select Sample in the Connect to drop-down box. Click OK to log in.

The UI of Siebel Tools can be divided into the following elements:

  • Title bar

  • Menu bar

  • Toolbar

  • Docking windows

  • Editors

  • Status bar

The following screenshot is an example screen of Siebel Tools to help us locate these elements:

Title bar

The title bar displays the application name (Siebel Tools), followed by the name of the currently open repository (Siebel Repository in the preceding example) and the name of the currently open list view in the editors area in square brackets ([Screen Menu Items]).

Menu bar

The Siebel Tools application menu allows access to commonly used commands. The following table describes some of the most important menu items. Many of the commands are also available via keyboard shortcuts, toolbar buttons, or the context menu, which can be opened by right-clicking an object in the editor area:

Menu item

Keyboard shortcut

Description

File | New Object...

None

Opens the New Object Wizards dialog from where various wizards can be launched.

File | Save

Ctrl+S

Saves changes made in graphical editors to the database.

File | Export...

None

Opens the Export dialog which allows exporting the current list data to different file formats such as CSV (comma separated values).

Edit | New Record

Ctrl+N

Creates a new record in list editors.

Edit | Copy Record

Ctrl+B

Copies the selected record including child records.

Edit | Delete Record

Ctrl+D

Deletes the selected record and associated child records.

Edit | Change Records...

None

Opens a dialog that allows setting up to four fields of the selected records to the same value. This menu item is active when two or more records in a list editor have been selected using Shift+Click or Ctrl+Click.

View | Windows | ...

None

Allows opening various docking windows such as the Properties window.

View | Toolbars | ...

None

Selection of toolbars to display.

View | Options...

None

Opens the Options dialog box, which allows setting various user-specific program options.

Tools | Compile Projects...

F7

Opens the Object Compiler dialog, which allows compiling entire projects.

Tools | Check Out...

F10

Opens the Check Out dialog.

Tools | Check In...

Ctrl+F10

Opens the Check In dialog.

Tools | Import from Archive...

None

Opens an archive (.sif) file and launches the Import Wizard.

Tools | Compare Objects...

None

Allows visual comparison of two object definitions in the same repository, in another repository, or in archive files.

Tools | Search Repository

None

Opens the Search Repository dialog, which allows full text search across the entire repository.

Tools | Utilities | Compare SRFs...

None

Allows comparison of two .srf files.

Help | Contents

None

Opens the Siebel Tools documentation.

Toolbar

Many of the most commonly used commands that have been described in the preceding table are available as toolbar buttons. Toolbars can be enabled or disabled by using the View | Toolbars sub menu. The following table describes the most important toolbars:

Toolbar

Description

Edit

Contains the New, Save, Undo, and other buttons.

List

Contains functions that are used in the list editor such as creating new records, navigating, querying, and sorting.

History

Contains the back and forward buttons and bookmark functionality.

Debug

Used during script debugging.

Simulator

Used during testing and simulating of workflow processes.

Format Toolbar

Contains buttons to control the format and layout of items in the form applet grid editor and flowchart editors such as the workflow process designer.

WF/Task Editor Toolbar

This toolbar allows accessing the functions to revise, publish, and activate workflow processes and tasks.

Configuration Context

Allows changing the browser and application context for applet editors. Note that this toolbar can be enabled only from the View | Toolbars menu.

Toolbars can be customized in a sense that a developer can choose which buttons should be available in the toolbar. To do so, we can click the down arrow icon at the right end of a toolbar and select Add or Remove Buttons as shown in the following screenshot:

Docking windows

The various docking windows support the developer during tasks such as creating or modifying applets, views, and workflow processes. The docking windows can be opened via the View | Windows menu. The following table describes the most important docking windows:

Docking window

Description

Object Explorer

This is the main docking window, which displays the object types and their hierarchy in the Siebel Repository.

Properties

This window shows the properties of a selected item in alphabetical order or by category.

Controls/Columns

This window allows the developer to drag and-drop available controls to the form applet editor or available list columns to the list applet editor.

Palettes

Depending on the main editor window, this docking window displays the available object types to drag-and-drop into the editor canvas. For example, when the workflow process editor is open, the window contains the available step types for workflow processes.

Applets

This docking window allows the developer to drag-and-drop different types of applets into the view editor.

Multi Value Property Window

Needed for the configuration of workflow processes, tasks, and entity relationship diagrams. Because of the "list" characteristic of this window, it appears along the bottom of the application by default.

Bookmarks

This window allows us to access bookmarks that can be created by the developer to navigate to commonly used object definitions more quickly.

Web Templates Window

Opens the Web Template Explorer, which allows displaying of the hierarchy of nested Siebel Web Templates and viewing of the content of the web template files (.swt).

Debug Windows

Available via the View | Debug Windows menu, these windows support the debugging processes of scripts and workflow processes.

The docking windows all share the characteristic of being arrangeable on the screen in free floating mode or docked mode. To create a free floating window, we have to right-click the title bar of a docked window and select Floating. The window can now be moved and resized across the available screen area.

To dock a floating window, we grab the window's title bar and drag the window to the desired dock location at the screen border. Once the mouse cursor reaches or crosses a dock location, a gray frame indicates the area and position that the window will occupy when the mouse button is released.

Dragging the title bar of one docked window exactly on top of the title bar of another docking window enables stacked windows. Tabs at the bottom of the window frame allow the selection of stacked windows. This mode is convenient when screen space is limited. The next screenshot shows an example of four stacked docking windows:

Using the pin icon, we can enable or disable the auto-hide functionality. In hidden mode, a docking window, or a stack of docked windows, is reduced to a tab bar at the border of the screen. Holding the mouse cursor over the tabs in this bar pulls out the window.

Editors

The editor area, or workspace, is a frame where the list editor and all other graphical editors and viewers appear. The following table describes the most important editors and viewers:

Editor/viewer

Description

Object List Editor

This is the main window that displays the list of object definitions for an object type selected in the Object Explorer window.

Web Applet Editor

Typically opened from the context menu on the Applet list via the Edit Web Layout command, this is the main graphical editor for form and list applets.

View Editor

The graphical editor for views is typically opened via the Edit Web Layout command of the View list's context menu.

Screen View Sequence Editor

The graphical editor, invoked from the screen list's context menu, allows developers to define the hierarchical structure of screens.

Menu Editor

Supports the graphical design of applet menus.

Script Editors

The script editors allow developers to write and debug scripts. The script editors are described in detail in a separate chapter.

Canvas/Flowchart Editors

Three different object types use the canvas editor for graphical design: Workflow Process, Task, and Entity Relationship Diagram.

View Web Hierarchy

Can be invoked on user interface objects such as applets, views, or screens, and displays the selected object in its hierarchical context.

View Details

This viewer can be invoked from business layer objects such as business components and business objects, and displays the selected object and its relationship to other objects.

View Relationships

Displays the relationships of the selected object (table or business component) to other objects of the same type.

The editor area supports arranging the windows in full screen mode as well as in cascaded or tiled window mode. The respective commands can be found in the Windows menu. In the full screen mode, easily set by double-clicking the title bar of an editor window, the developer can switch between the editor windows using a tab bar.

Status bar

The status bar at the bottom of the application window displays the following information:

  • Record count for the list editor

  • The current working language

  • Status messages (for example, during compilation)

Navigating in Siebel Tools

The typical navigation scenario in Siebel Tools is to use the Object Explorer docking window to select the desired object type and then use the Object List Editor window to query for an existing object definition. The following example procedure shows how to select the Contact Form Applet and display a list of its controls:

  1. 1. In the Object Explorer, select the Applet type.

  2. 2. In the Object List Editor, press Ctrl+Q to initiate a new query.

  3. 3. In the Name column, enter Contact Form Applet (paying attention to case sensitivity).

  4. 4. Press the Enter key to execute the query.

  5. 5. In the Object Explorer, click the plus (+) sign to the left of the applet object type to expand the hierarchy and display the child object types of an applet.

  6. 6. Click the Control object type.

  7. 7. You can now use the Object List Editor to review the controls of the Contact Form Applet.

 

Siebel Repository metadata


The Siebel Repository is a key component of the Siebel architecture. The data stored in a repository is typically named metadata because it describes the architecture and logical behavior of a program in an abstract ("meta") manner. In the next section, we will discuss the content of the Siebel Repository in detail.

Developers and analysts use Siebel Tools to access and modify data in the repository tables of the Siebel database. Each modification must be made available to the Siebel executable by compiling a new version of the Siebel Repository File (SRF). The following diagram depicts the relationships between Siebel Tools, the Siebel Repository File, and the Siebel executable:

We observe that the Siebel executable, which is responsible for rendering the application to the end user in the browser, accesses a different set of tables than Siebel Tools.

Note

Did you know?

There is no technical boundary between user tables and repository tables. There are circumstances where both applications (Siebel Tools and the application used by the end users) access the same tables. An example for this behavior can be found in the administration of List of Values (LOV) data for drop-down in pick lists. LOV data can be administered in Siebel Tools as well as the Siebel Web Client.

As indicated, the Siebel Repository can be described as metadata stored in a set of tables in a relational database. When modern programming patterns arose in the second half of the last century, developers and architects found that it is highly beneficial to separate the program logic into specialized layers.

The Siebel Repository metadata is organized in the following layers:

  • Data layer

  • Business layer

  • Presentation layer

  • Integration layer

  • Automation layer

The data layer

The majority of enterprise software applications use relational database management systems (RDBMS) for data storage. Siebel CRM is no exception. The data layer of the Siebel Repository defines the physical storage of data used by all Siebel applications. The major object types in the data layer are:

  • Tables and columns

  • Interface tables

  • Indexes

Tables and columns

The Siebel Repository holds the definitions of all tables that are present in the relational database. Tables and their columns are the fundamental building blocks of the physical data model or schema that is used by all Siebel applications.

The following list conveys some interesting facts about Siebel tables:

  • The Siebel Industry Applications (SIA) schema contains more than 3000 tables.

  • Each table has a set of system columns that hold data like the timestamp of the last update or the total number of modifications for each individual record.

  • The ROW_ID system column is automatically populated with a unique identifier. This identifier is unique across the enterprise, which means that even if there are thousands of mobile users having their own local database, each record will have a ROW_ID value that will never be used for any other record.

  • Even if the ROW_ID column is marked as the primary key in the repository, this information is not manifest in the RDBMS. The same is true for all foreign key definitions. The referential integrity of primary key-foreign key relationships is maintained by the Siebel application logic exclusively.

  • The preconfigured tables cannot be modified by customers. Developers at customer projects are only allowed to add columns or tables to the repository.

Interface tables

In order to facilitate mass data exchange at the database level, interface tables are part of the Siebel database schema. When integration architects want to import data using the Enterprise Integration Manager (EIM) module, they have to populate the interface tables and then invoke the EIM server component.

Each interface table maps to one or more data tables. During import, EIM reads data from the interface tables and populates the data tables. When exporting data, EIM reads the data tables and writes to the interface tables. Other capabilities of EIM include updating, merging, and deleting operations against the data tables.

Note

Did you know?

Direct manipulation of data in tables other than interface tables by means of SQL statements is not permitted because it can lead to severe data integrity problems and it can even render the Siebel application unavailable.

Indexes

For each table, the Siebel Repository defines a variety of indexes in order to improve query and sorting performance. Indexes are preconfigured to support various column and sorting combinations, and can be added or deactivated depending on the customer requirements.

Object type relationships in the Siebel data layer

Objects in the Siebel Repository reference each other. For example, an index definition references columns of the table it is defined for. Another example is an interface table that references one or more data tables. The following diagram depicts the object types in the data layer of the Siebel Repository and their relationships:

We can observe that a table is a set of columns. For each table, one or more indexes exist that reference one or more columns in the table. A table is mapped by one or more EIM interface tables, which themselves map to one or more tables.

In Chapter 8, The Data Layer, we will explore the object types and the customization options of the data layer in greater detail.

The business layer

The complexity of today's typical business requirements shapes the Siebel business layer. This layer serves as a level of abstraction from the data layer, by mapping real-world entities, their attributes, business logic, and relationships to reusable metadata object definitions.

The following is a list of the major building blocks of the Siebel business layer:

  • Business components, joins, and fields

  • Links

  • Business objects

Business components, joins, and fields

Business components, their fields, and other child object types such as joins define the central application logic for all Siebel applications. We can imagine a business component as a technical implementation of a real life entity. For example, a service request or trouble ticket raised by a customer must be stored in Siebel CRM in a way that it can be easily assigned to internal employees to handle the request. In addition, the service request must be related to a customer account and to the product in question.

The Service Request business component implements this logic. The Siebel executable uses the information in the business component object definitions, in order to generate the SQL statements against the relational database to query and modify the records in the respective tables.

Therefore, business components reference objects of the data layer, namely tables and columns. Because the data accessed by a single business component is stored in more than one table (the physical schema of Siebel is highly normalized), the business component definition includes joins that reference other tables.

We can use Siebel Tools to visualize the relationships between business components and tables by right-clicking on a business component definition and selecting View Details. The resulting visualization, for the Service Request business component for example, is displayed in the following screenshot:

The View Details window in Siebel Tools allows inspecting the mapping from each field in a business component to a column in a table. The screenshot shows how the Asset Number field in the Service Request business component references the ASSET_NUM column in the joined table named S_ASSET. This relationship is graphically indicated by arrows that point from the field to the join and from the join to the column.

Links

In the real world, entities are related to each other. Business analysts use entity relationship diagrams (ERDs) to depict the relationships between entities. The following diagram represents an example of an ERD:

The example defines the relationships between a customer account, its related contact persons, and service requests. While the same contact person can be associated with many other accounts (a many-to-many or M:M relationship), only one account at a time can be associated with a service request (a one-to-many or 1:M relationship).

We have learned above that entities are implemented as business components in the Siebel Repository. The relationship between two business components is implemented as a link. Once business components are connected by a link, the application can easily retrieve a parent record and all associated child records from the database.

Business objects

A business object defines a collection of business components and the links that are used to relate the business components to each other. As a result, a parent—child hierarchy of business components is created. Siebel Tools allows visualizing the hierarchy of business components in a business object, by right-clicking on a business object and selecting View Details. An example result is depicted in the next screenshot:

The example shows the parent—child relationships between the FS Invoice business component and its child business components. The link objects that connect the business components are visible in the screenshot as well.

Relationships of business layer and data layer objects

Business components, their fields and joins, as well as business objects and links have close relationships to other object types in the Siebel Repository metadata model. For example, business components and their fields reference tables and columns in the data layer. The following diagram depicts the major object types in the business layer and data layer along with their relationships:

The relationships can be described as follows:

  • A business component has multiple fields

  • A business component references one base table

  • Multiple joins can be associated with the business component and reference one table each

  • Fields in a business component reference columns in the base or joined tables

  • Links refer to one parent and one child business component

  • Business objects are lists of business components and the links that are used to tie them together

We will learn how to modify and create object definitions in the business layer in various chapters across this book.

The presentation layer

Also named the logical user interface, the presentation layer defines how data is presented to the end user. We can describe the following major object types in the presentation layer:

  • Applets and controls

  • Views

  • Screens

  • Applications

  • Menus and toolbars

Applets and controls

Applets are the major building blocks of the graphical user interface of a Siebel CRM application. Siebel CRM applications use the following applet types:

  • List: Displaying multiple data rows at once

  • Form: Displaying one record at a time

  • Tree: Displaying data hierarchically

  • Chart: Visualizing data in various chart formats

The data itself is displayed to and modified by the end user by means of controls. Text boxes, check boxes, radio groups, along with buttons and lists, are examples for different types of controls.

Developers use graphical editors to define the presentation layer objects. We can access the applet editor, for example, by right-clicking an applet definition in the Object List Editor and selecting Edit Web Layout.

Applets reference a single business component from which they receive data and to which they submit the method invocations when end users interact with the applet. For example, when a user clicks the Delete button on an applet, the respective method is invoked in the business component referenced by the applet. The application engine then generates the necessary SQL statement to delete the record from the database.

Following a strict programming pattern, applets themselves do not define any business logic. Applets and their controls only define which fields and methods of a business component are exposed to the end users.

Note

Did you know?

In Siebel web applications, the look and feel—the font style, background colors, and so forth—is defined by cascading stylesheets that are situated outside of the repository. This is why the presentation layer is also called logical UI, whereas the files necessary to define the look and feel in the browser are part of the physical UI.

Views

We can describe a Siebel View as a web page that defines the arrangement of one or more applets on a layout template. The following screenshot shows the Account Summary View with one form applet on top and four list applets below in the Siebel web client:

The list applets are arranged side by side for maximum visibility of the data that the end user needs for the business process. Each view references a single business object so that the application engine can use the link information to retrieve the correct child records for the selected parent record.

Screens

A screen is a collection of views that serve a similar purpose such as working with service request data or administering Siebel servers. In addition, a screen also defines the hierarchical order of the views and the labels that appear on clickable items such as tabs or links.

Applications

Following a rather simplistic but elegant design pattern, a Siebel application is not much more than a set of screens. In addition, an application object defines menus and web page templates to be used for rendering the user interface.

Menus and toolbars

When end users work with the data provided by the applets, they often have to invoke methods offered by the Siebel framework. Clicking the Site Map button to navigate to the site map, or selecting New Quote from the context menu of the Account List Applet, are just two examples how the end users utilize user interface components such as toolbar buttons or menu items.

The Siebel application architecture allows developers to place buttons and menu items in the following locations:

  • Application menu in the top banner

  • Application toolbar

  • Applet headers

  • Applet menus

Each of these buttons or menu items invokes a method or command, which is handled either by Siebel's out of the box functionality, or by workflow processes or script code written by the developer. This provides the automation functionality required by the end users. Prominent commands such as New Record are often made accessible more than once such as a menu item, a keyboard shortcut, and an applet button at the same time.

Relationships of presentation layer and business layer objects

Views, applets, and controls reference objects in the business layer. The references and the relationships of objects within the presentation layer can be visualized as follows:

We can infer the following from the diagram:

  • A Siebel application is a collection of screens

  • An application defines the main menu and toolbars to be displayed

  • Screens can be reused in other applications

  • A screen is a collection of views

  • A view is a set of reusable applets

  • A view references one business object to establish the data context

  • An applet defines a set of controls such as text boxes or buttons

  • Each applet references a single business component

  • There can be multiple applets referencing the same business component

  • Each control in an applet references a field in the business component referred to by the applet

Chapter 5 and Chapter 6 of this book will discuss how to modify and create presentation layer object definitions.

The integration layer

Modern enterprise applications are never installed and used standalone. On the contrary, they are very often part of complex IT infrastructures with multiple integration touch points. In order to provide a standardized interface definition to access Siebel data, the Siebel Repository provides the ability to define Integration Objects. In order to suit the different integration requirements such as mapping between Siebel and external schemas, integration objects can be defined as "internal" or "external".

Internal integration objects

We can start by imagining a scenario where an integration architect has to define a data interface between Siebel CRM and an external order management application. The architect's duties include determining the exact set of fields to be exchanged between the applications.

When the architect analyzes the definition of the Order Entry - Orders business component, which implements the entity of an order header, and the various child objects such as line items, he/she finds that there are hundreds of fields defined in Siebel CRM to store order data. The external system may either not be capable of storing all this information or simply not need all these fields.

This is why the Siebel Repository includes integration objects. Integration architects can create integration objects that reference business objects, their components and fields, and define a subset of the information made available by the business layer objects.

In other words, a Siebel integration object is a schema definition for data exchange via enterprise application integration (EAI) interfaces.

Note

Did you know?

Whenever the Oracle Siebel CRM design team creates integration touch points with other applications such as Oracle BI Publisher for reporting, they choose integration objects as the mechanism to define the schema of data to be exchanged.

Internal integration objects define the interfaces for the Siebel business layer objects. They have a similar hierarchy as business objects, containing integration components and integration component fields. The following diagram depicts the object types of the integration layer and their relationship to the business layer's object types:

The following list summarizes the concept of internal integration objects:

  • An internal integration object references a single business object

  • The integration component definitions within an internal integration object reference business components within the business object

  • Integration components define a list of integration component fields, each of which references a field in the business component referred to by its parent

External integration objects

The Siebel CRM integration architecture provides data mapping functionality in order to assist Siebel developers in creating rich interface definitions. A developer who wishes to map Siebel data to external data needs to import the external schema definition from a file (typically an XML schema definition file, or .xsd file) in Siebel Tools.

The import of an external schema produces so-called external integration objects, which are subsequently used by the Siebel data transformation engine to produce data sets that match the schema definition of the external systems.

In Chapter 18, Supporting Integration Interfaces, we will learn how to create integration object definitions to support EAI interfaces.

The automation layer

Enterprise software such as Siebel CRM must include features to automate business logic and provide business process guidance for end users. The automation layer of the Siebel Repository includes the following object types that allow developers to fulfill automation requirements:

  • Business services

  • Workflow processes

  • Tasks

  • Commands

Business services

Almost the entire business logic that can be found in a Siebel CRM application is the result of the work of business services. We can imagine a business service as encapsulated program code, which is designed to accomplish a certain task.

The Siebel Repository comes replete with hundreds of preconfigured business services. The following list gives an impression of business-service-based logic in Siebel CRM:

  • Pricing logic in Siebel Order Management

  • Customer self service and registration

  • Asset and agreement management

  • Import and export of XML data

  • Importing external schema definitions in Siebel Tools

  • Integration with queuing systems such as IBM Websphere MQ

Business services can be exposed as web services to provide the foundation for service-oriented architectures (SOA). They can be written in many programming languages, of which Siebel eScript is the most popular at customer projects. Developers at Oracle write C++ classes, which is another way to define functionality in Siebel business services. In addition, the Siebel application framework supports Java and Visual Basic as programming languages for business services.

Workflow processes

The Siebel Workflow module is known for its capability to orchestrate business services by defining the sequence of their invocation. Siebel Workflow is in fact 4GL—a fourth generation programming language that allows developers to implement complex business logic without the need to write program code.

Siebel Industry Applications (SIA) 8.1.1 are shipped with a repository that contains over 1300 workflow process definitions that drive the business logic of complex application modules such as order management, marketing, pricing, and user self registration. The following screenshot shows an example workflow process in the Workflow Process Designer in Siebel Tools:

Siebel developers use the process designer to create and modify workflow processes. We can observe that a workflow is a series of steps, decision branches, and exception handlers—very similar to a written program.

We can access the Workflow Process Designer in Siebel Tools by right-clicking a workflow process object definition and selecting Edit Workflow Process.

Tasks

End users must be trained to perform various business processes and tasks in Siebel CRM. But some business processes are rather complex and also rarely executed, making it difficult to flawlessly perform a business process.

End users might require guidance for complex business processes in order to carry out all steps correctly and enter high quality data. The Siebel Task UI provides the technological foundation for creating task-based user interfaces and the technical flow behind them.

Similar to workflow processes, tasks define a sequence of steps with the main difference to workflow that user navigation is at the core of the task. So-called task views can be created to provide the input controls and data that a user needs at a certain step in the business process.

Developers use the Task Editor to create and modify task definitions. A task definition contains one or more task view steps, which implement the user interface for the given step of the business process.

Commands

Commands are reusable object definitions and act as invocation mechanisms for business services, workflows, or built-in methods of the Siebel application. They are typically referenced by menu items and toolbar buttons, and define the foundation for the invocation of Siebel functionality by the end user.

We will learn how to create business services, workflow processes, tasks, and commands in later chapters of this book.

The logical architecture of Siebel applications

We have now discussed the major object types of the Siebel Repository. Together with other object types and features, they form the logical application architecture. We can combine the information about the layers of the Siebel Repository in a logical architecture map as shown in the following diagram:

We can summarize the information in the diagram as follows:

  • The data layer (hexagon shaped objects) of the Siebel Repository defines the physical storage of data such as tables, columns, and indexes

  • The business layer objects (rectangle shaped objects), namely the business components, reference the data layer and serve as a level of abstraction to allow the modeling of real-world entities into metadata

  • The presentation layer (trapezoid shaped boxes) includes all object types that are used to present data and functionality provided by the business layer to end users

  • The integration layer (bookmark shaped objects) provides the foundation for data exchange with external systems

  • The automation layer (rhombus shaped objects) and its business services enable the automation functionality of Siebel CRM

  • External systems can be integrated with Siebel CRM by exposing objects of the automation layer or by using interface tables

Other object types

The following table serves as a quick reference, in alphabetical order, for other important object types in the Siebel Repository:

Object type

Description

Bitmap Category

Collections of bitmaps used for toolbar buttons or icons.

Content Object

Used in Siebel Content Management and Application Deployment Manager to represent data objects.

Entity Relationship Diagram

Allows drawing of entity relationship diagrams and links them to business layer object definitions such as business components, links, and fields.

Icon Map

Collections of bitmaps related to a specific value. Allows displaying of a graphic instead of text data in the user interface.

Message Category

Collection of messages to display to the end user.

Pick List

This object type defines the list of values (LOV) for drop-down lists and single value selection fields.

Project

A container for objects. Each object definition in the Siebel Repository must belong to one project.

Symbolic String

Represents a text string and its translations to multiple languages. Can be referenced from every object that displays static text in the user interface.

Type

Defines the object types and their attributes (properties) in the Siebel Repository.

Web Page

Relatively static user interface elements such as the login page.

Web Template

Pointer to physical .swt files in the WEBTEMPL folder of a Siebel application.

Workflow Policy and assignment-related object types

Used to define objects related to workflow policies and assignment manager.

 

Summary


Siebel Tools allows us to inspect, create, and modify various object types in the Siebel Repository. The logical Siebel architecture follows a strict principle of separated layers, thus providing the foundation for a stable yet extensible application framework.

The Siebel Repository metadata defines anything from the menu that an application displays to the tables and columns where the data is stored physically.

The business layer consisting of business objects, business components, and links (to mention the most important members) is the main abstraction layer and entry point for data access for end users and external systems alike.

In the next chapter, we will discuss the typical tasks for a Siebel developer.

About the Author

  • Alexander Hansal

    Alexander Hansal has worked as an IT professional in small, medium, and global corporations. Since 2001, Alexander works as a technical instructor and consultant for Siebel CRM and Oracle Business Intelligence in Europe. He enjoys teaching, and shares his knowledge and expertise in his classes at Oracle University and in his weblog, http://siebel-essentials.blogspot.com/

    Browse publications by this author

Latest Reviews

(1 reviews total)
Excellent
Book Title
Access this book, plus 7,500 other titles for FREE
Access now