Oracle Siebel CRM 8 Developer's Handbook: Configure, Automate, and Extend Siebel CRM applications with this Oracle book and eBook

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:

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.

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.

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:

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

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

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.

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:

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:

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

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.

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:

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.

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:

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.