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.
Diagram of a basic Applet object, its corresponding entity relationships, and its layout: This image is described in the surrounding text.

The purpose of this diagram is to illustrate only that the top level (or parent) 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.