5Customizing in Siebel CRM

Customization in Siebel CRM: Overview

Siebel CRM is extremely customizable, allowing you to modify and create new objects, properties, validation rules, workflow, guided help (iHelp), integration with other applications, and so on.

This customization requires an understanding of the following:

• Siebel Repository. Contains metadata that defines how the application behaves. For example, it defines all of the tables in which data is stored, the business logic layer, the objects that allow integration with other systems, the user interface, and so on. The Siebel CRM application provides an extensive set of repository metadata, providing you with functionality supporting all aspects of customer relationship management across many industries and 22 out-of-the-box languages with the ability to add more. Customers can modify and augment the repository to support their business needs.

• Workspaces. Provide a version-controlled mechanism for business analysts and developers to make changes to the Siebel Repository. It allows for many users to make changes simultaneously and in parallel, for example, when they are working on unrelated features, different timelines, or for other reasons. Workspaces provide standard version control features, such as checkpointing, delivery, reversions, and rebasing. Workspaces replace the older process of checking in and out that was previously used in Siebel Business Applications. In Innovation Pack 2017, it is mandatory to use Workspaces. This provides more flexibility, parallel repository development, and the ability to integrate with Siebel Approval Manager (or other tools) for change control.

Siebel Repositories: Overview

Technically speaking, there are actually two Repositories involved in the implementation of Siebel CRM.

• Siebel Design Repository (DR). This repository contains the editable definitions of the metadata. Siebel Tools and Siebel Web Tools applications use this repository to make changes to the repository.

• Siebel Runtime Repository (RR). This contains a compiled, denormalized version of the Siebel Repository. Siebel Application Object Managers use this at runtime to provide application functionality to users and integration points. This in-database version of the repository replaces the old Siebel Repository File (SRF). Changes to the runtime repository affect application behavior in real-time, unlike the old SRF paradigm, which required compilation and restarting Application Object Managers and other components for changes to take effect.

About the Siebel Design Repository

The Siebel Design Repository is the traditional repository that has always been part of Siebel CRM. It contains editable metadata that defines application behavior. It is used make modifications to the delivered Siebel CRM applications.

To configure these modifications, you make changes to the Siebel Design Repository by using either one, or both, of the following tools:

• Siebel Web Tools. This allows configuration of repository objects within a Web browser.

• Siebel Tools. This allows for more complex configuration, such as, creating or updating Workflow Processes or Task Based UIs. Developers usually perform this level of configuration. Eventually, all functionality remaining in Tools will be migrated to and only available in Siebel Web Tools.

The Siebel Design Repository consists of a hierarchical set of objects. For more information, see Siebel Object Types Reference, but let’s consider some simple examples:

• Table Objects. Describe the physical tables in which data is stored. Table objects and their child objects are often referred to as the data layer.

  • Column Objects. Describe the individual data attributes within those tables.

  • Index Objects. Describe database indices used for optimization, uniqueness, or performance.

• Business Component Objects. Provide an abstraction layer on top of the data layer. These are often referred to as part of the business layer that helps define relationships between data as well as business rules affecting that data. This allows for far more complexity than you define at the database layer.

  • Field Objects. Describe data elements and basic validation rules, for example, which fields are required, numeric, read-only, and so on.

  • Join and Multivalue Link Objects. Define relationships between objects, for example, a Contact object can have many Address objects.

• Applet Objects. Provide a visual representation of a business component so that a user can interact with it, and can then form part of the user interface layer.

  • Control Objects. Define the possible items that can appear on the applet, for example, buttons, labels, fields, menus, and so on.

  • Web Templates. Provide possible physical layouts for the applet, that is, specifying controls and their corresponding locations.

There are 50 top-level repository object types, many of which have child objects as described in the examples above. By default, only the most commonly used object types are displayed in Siebel Tools and Siebel Web Tools, as illustrated below:

To expose or remove object types from being available, do one of the following:

• Siebel Web Tools. Click the pencil icon.

• Siebel Tools. Click Options, then Object Explorer in the View menu.

About the Siebel Runtime Repository

Whether operating as the user interface, or operating in the background as an interface with other systems, how the Siebel CRM application behaves depends on the contents of the Siebel Repository.

In theory, the Siebel CRM application could read its configuration directly from the Design Repository tables, and then to function according to this specific configuration. This approach, however, is inefficient. These tables store hierarchical data with great-grandparent objects, grandparent objects, parent objects, and so on, and pulling information from the supporting tables at runtime would inhibit performance at runtime.

Consider the following diagram, which illustrates a basic Applet object, its corresponding entity relationships, and its layout, as physically defined in the database.

Note: This diagram only identifies some of the Applet objects attributes, and, for example, does not illustrate foreign keys to other objects.

The purpose of this diagram is to illustrate only that the top level object has many child objects, and that there are relationships from each child object to the parent, as well as relationships from the grandchild to the child objects, and so on.

When you create applets, make changes to existing applets, and so on, the underlying tables in the Design Repository are updated to reflect those changes.

In its entirely, the Applet object has a top level object based on S_APPLET, and 13 child objects (Controls, Lists, Charts, Web Templates). Some of child objects have grandchild objects (for example, Web Template Items), which add a further thirteen tables to the applet. In addition, there are another six great-grandchild objects, these are mostly locale-specific captions. To get a full definition of an applet from the Design Repository at runtime, would require the Siebel CRM application to query 33 tables.

To improve runtime performance, the Siebel Design Repository data is compiled into the Siebel Runtime Repository. This process summarizes each object type into an easily queried set of tables that has a one-to-one mapping to the top- level repository objects. For example, an Account List Applet has 822 distinct records across 33 tables in the seeded repository. However, in the Siebel Runtime Repository, these 822 records are condensed to a single denormalized, compiled record that summarizes all 822 records and is placed in a runtime repository table, for example S_RR_APPLET.

Siebel CRM Workspaces: Overview

Understanding Workspaces is critical to modifying the Siebel Design and Siebel Runtime Repositories, and to accommodating specific customer business requirements effectively.

A Workspace is a sandbox environment in which you can update Siebel CRM application configuration, and in which you can validate those configuration changes before deployment. You can also use Workspaces for parallel development, geographically distributed teams, and, in conjunction with Siebel Approval Manager, providing a governance process to changes to the application.

We will illustrate the basic use of workspaces through a simple example: you want to display contact home phone numbers instead of work phone numbers on the Contact List Applet.

The configuration process is illustrated in the following diagram:

Before diving into configuration changes, it is important to have an understanding of the scope of the requirement and have a clear plan for addressing it in the most appropriate way. By way of example, there are multiple ways that this requirement could be met, including the following possibilities:

• Modify the label on the existing column in the list applet to be: Home Phone #. Analysis: While this approach would work, the underlying field and physical database storage would still be using the Work Phone # field. There may be other areas of the application or other types of users who want to continue to use this field for the Work Phone #, so relabeling it here would cause confusion and possible data loss.

• Create a new physical column at the database layer, map a BusComp Field to that column, and add it to the list. Analysis: This would also work, but by examining the existing Table and BusComp definitions, we can observe that a column already exists for this purpose. Creating a new column would mean that home phone numbers could be stored in two different columns–the original and our new column. This is clearly not desirable.

• Make use of the existing Home Phone # field on the Contact BusComp. Analysis: This is the best approach–it will ensure that the types of problems inherent in the first two approaches are not encountered. It will also be the fastest and easiest, as there is no requirement to make changes at the data or business object layers–all changes are done at the user interface layer.

Having performed our analysis, we can confine the scope of the change needed to meet the requirement to the following two changes:

• Expose the existing Home Phone # Field on the Contact List View so that users may see and edit it.

• Remove the existing Work Phone # Field

Creating and Opening a Workspace

The first step in making changes to the configuration and behavior of the application is to create a Workspace in which to make those changes. One of the most fundamental things to understand about a Workspace is that changes made within it will not affect other users, therefore enabling the developer or business analyst to test and verify changes safely without adverse effects to the system.

In order to create (or have any other interaction with) any Workspace, a user must first be granted the Responsibility: Composer Administrator. Once the Web Tools user – developer or business analyst – has been granted access, use the following procedure to create and open a Workspace in which to make the required configuration changes.

To create and open a Workspace, do the following:

1. Log into Siebel Web Tools (for example, https://myserver.mycompany.com/siebel/app/webtools/enu). This will present the user with an Object Explorer view that shows the objects in the Siebel Design Repository, all of which are in read-only mode. In order to make changes, the user must create a Workspace. To do so, navigate to the Workspace Administration view by clicking on the Workspace icon at the upper right.

   Note: If the Workspace icon is not available, the user has not been granted the Composer Administrator Responsibility. The Siebel Administrator will need to grant the Responsibility to the user and the user will have to log out and completely close the browser, then log back in to see the icon.

2. On the Siebel application window, click the Workspace Dashboard icon after the menu bar and next to the Settings icon.

   The Workspace dashboard appears and displays all existing Workspaces. If you have recently installed a new instance of the Siebel CRM application, then only one Workspace is displayed: MAIN

3. Click the Create button on the Workspaces dashboard.

   The Create Workspace dialog appears.

   Note: The name of the Workspace automatically populates with the prefix for your environment, in this example dev, and then the current username, for example, jsmith.

4. In the Name field, append a descriptive Workspace name text to the pre-populated prefix, for example, ChangeContactPhone.

5. Enter a description for your Workspace in the Comments field.

   See the following diagram for more information:

   

6. Click Create Workspace.

   The Workspace opens, and the Workspace name is displayed in the right corner.

   Note: If the user already has a Workspace in progress, it is possible to open an existing Workspace by selecting it and by clicking the Open icon.

   To close the Workspace Administration View, and open the Object Explorer in Siebel Web Tools to being configuration within the Workspace, click the Close icon.

Configuring Changes in Siebel CRM

Configuring in the browser-based Siebel Web Tools application is very similar to the configuration performed in Siebel Tools. In this example, you add the existing Business Component field called Home Phone # to the Contact List Applet. This Business Component Field replaces the existing field called: Work Phone #.

Do the following:

1. Open your end-user application, for example, Siebel Call Center.

2. Navigate to the specific area Siebel Call Center where the changes are required.

3. Navigate to Help, and then About View to identify the required applet name, in this case, Contact List Applet.

4. Return to the browser window where Siebel Web Tools is running.

5. Navigate to the Applet object and query for the Contact List Applet.

6. Expand the List and List Column child object types in Object Explorer.

7. Query for fields containing the word Phone using the following syntax: *Phone*

   This step verifies that the Home Phone # field is available on this applet.

8. In the Home Phone # list column, select the Available and Show in List checkboxes.

   This makes the Home Phone # list column available in the list at runtime.

   Note: For more information on the Available and Show in List attributes, see Siebel Object Interfaces Reference in Siebel Bookshelf.

9. In Object Explorer, expand the Applet Web Template object.

10. Select the Edit List child object, and then expand the Applet Web Template Item child object.

11. In the Applet Web Template items applet, perform a search for the existing Work Phone # field.

    This identifies three different records: the Contact List Applet is rendered differently in Siebel Life Sciences, Siebel Hospitality, and the remaining Siebel applications. In this example, we are configuring the Call Center application, so update the record with no Expression attribute defined.

12. Update the value in the Control value field to: Home Phone #

13. Update the value in the Name attribute to: Home Phone #

Testing Your Siebel CRM Configuration Changes

Only the user who opens the Workspace, and any user with Composer Administrator Responsibility, can see any changes implemented in that Workspace.

To validate your configuration changes, do the following:

1. Using a different Web browser tab or window, log into the required application, in this example, Siebel Call Center.

   Note: It is recommended that you keep the Siebel Web Tools tab open in case you need to implement further changes.

2. Click the Workspace Dashboard icon after the menu bar and next to the Settings icon.

3. Locate and select the required Workspace in the application.

4. Click the Open icon to open the Workspace.

5. Click the Inspect icon to inspect the changes you implemented.

6. Click the Close icon to leave Workspace Administration mode and to return to the application.

7. Navigate to the area that needs to be tested, in this example, the Contact List View.

8. Verify that Home Phone # appears in the Call Center UI as expected.

9. Enter a value for one of the records, then verify that it appears in the database by doing the following:

   1. Enter a value in the Home Phone # field in a Contact record, and click anywhere outside of the new row to save your changes.

   2. Using a database-appropriate utility, validate that this value is stored to the correct column in the database.

Submitting the Siebel CRM Configuration Changes

After configuration changes are implemented and validated in the Workspace, you submit these for review by an approving user. Once reviewed, these changes are delivered to the Siebel Runtime Repository, making them available to all users.

Optionally, this process can leverage Siebel Approval Manager application for governance, but basic approval is possible without requiring that integration. For more information, see Siebel Approval Manager Guide in Siebel Bookshelf. To submit the configuration changes, do the following:

1. Open Siebel Web Tools and click Workspace icon.

2. Locate the updated Workspace, and click the Version icon.

   This allows you to checkpoint your Workspace. After creating a version, you can continue to work while preserving a point to which you can roll back to a previous version, or you can submit your changes.

3. Click the Submit button.

4. In the Deliver Workspace dialog, enter relevant comments and click Submit to confirm your changes.

After submitting the changes, the following occurs:

• In the Workspaces pane, the Workspace icon and the comment after the Workspace name are updated to indicate that it has been submitted.

• In the Workspace version pane, the most recent version has a lock icon, indicating that you cannot implement further changes because the Workspace has been submitted for approval.

• The Workspace name at the upper right is highlighted with a different color, indicating that you cannot implement further changes because the Workspace has been submitted for approval.

Delivering the Updated Siebel CRM Workspace

Once you submit the updated Workspace, this is usually reviewed and approved by another user, who then inspects it and delivers it.

To deliver the changes to the Siebel Runtime Repository, you must have the Workspace Administrator Responsibility.

This requires the following steps:

1. Open the Workspace and examine the changes in the Workspace Administration pane.

   In left-to-right languages, these changes are available in the right pane.

2. Using the target application, in this example, Siebel Call Center, perform testing to ensure that the desired results have been achieved.

3. Confirm that the changes are correct, and then in Workplace Administration, click Deliver to publish the changes to the Siebel Runtime Repository, making the changes available to all users.

4. In the Deliver dialog, enter relevant comments and click Submit to confirm your changes.

Verifying Changes in the Delivered Workspace

When the Workspace has been submitted, approved and delivered to the Siebel Runtime Repository, the configuration changes are available to all users.

To validate these configuration changes, do the following:

• Log in as a standard user.

• Validate that all changes are visible on the Contact List Applet.