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 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:

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]).
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 ( |
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 |
Help | Contents |
None |
Opens the Siebel Tools documentation. |
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:

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 ( |
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.
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.
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. In the Object Explorer, select the Applet type.
2. In the Object List Editor, press Ctrl+Q to initiate a new query.
3. In the Name column, enter Contact Form Applet (paying attention to case sensitivity).
4. Press the Enter key to execute the query.
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. Click the Control object type.
7. You can now use the Object List Editor to review the controls of the Contact Form Applet.
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:
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
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 aROW_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.
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.
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.
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 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, 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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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".
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
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.
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
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.
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.
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 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.
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
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 |
Workflow Policy and assignment-related object types |
Used to define objects related to workflow policies and assignment manager. |
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.