Siebel Business Rules Administration Guide > Configuring the Business Rules Development Environment >

Understanding Building and Deploying Rules

In order to invoke rules in a Siebel application, the following events take place:

• You build a HaleyAuthority knowledge base by importing Siebel object metadata from a Siebel Master Repository database and creating rule modules.
• You deploy rule modules to a Siebel runtime database.
• The rules are invoked at Siebel application runtime.

Figure 2 represents the interaction among the HaleyAuthority knowledge base, Siebel runtime database, and Siebel Master Repository database when rules are created, deployed, and invoked.

Figure 2. Database Interaction for Rules Creation and Deployment

The following three databases participate in implementing rule modules.

• Siebel Master Repository database. The Siebel Master Repository database must contain the most current Siebel object model for your enterprise, from which you import Siebel objects into HaleyAuthority. The Master Repository database may or may not contain transaction data. The Master Repository database in a development environment is the database to which you check in repository changes using Siebel Tools.
• Siebel runtime database. A Siebel runtime database is a database with transaction data and seed data (lists of values, price lists, and so on). It must have the same repository data as your Master Repository database. A Siebel runtime database and the corresponding Siebel Master Repository database may or may not be the same database. In a primary development environment, they are likely separate databases for security and performance reasons.
• HaleyAuthority knowledge base. A HaleyAuthority knowledge base is the rules design environment. It is modified directly by HaleyAuthority and consists of the Haley schema definition and Haley data - concepts, relations, statements and so on. A knowledge base must not reside in the Siebel runtime database or in the Siebel Master Repository database.

  NOTE:  Haley's runtime knowledge base is neither the Siebel runtime database nor the HaleyAuthority knowledge base. The runtime knowledge base is a representation of the semantic role model and rules that is instantiated in the Application Object Manager. For more information on Haley's runtime knowledge base, see About Rule Modules Invocation: Loading, Using, and Caching.

The following processing occurs when you create, deploy, and invoke rule modules.

About Rule Modules Creation

Whenever you use Object Importer, a COM Data Control (CDC) connection to a Siebel Master Repository database is created and a CDC connection to a Siebel runtime database is created.

When you import Siebel objects using Object Importer:

• Siebel object metadata is read from the Master Repository database.
• When Object Importer has the final list of objects to import, it tells HaleyAuthority, through the Haley API, to create concepts, relations, and phrasings in the HaleyAuthority knowledge base.
• Concurrently, Object Importer writes data to the Siebel runtime database that keeps track of the business components and fields that are imported. This data allows knowledge base data to be interpreted correctly by the Siebel runtime database at runtime.

  NOTE:  When you import objects the first time into a knowledge base, Object Importer verifies that the runtime tables do not contain pre-existing data, such as from another knowledge base. If data is found, a message warns you that the runtime tables will be cleared. When you affirm, the runtime tables are cleared. Do not affirm unless you want to abort any existing knowledge base that accesses the runtime knowledge base.

As expected, the length of time to import objects depends on the number of objects you import.

When you subsequently create statements and rule modules, they are written to the HaleyAuthority knowledge base.

For information about tables provided for rules data in the Siebel runtime database, see Rule Tables in the Siebel Runtime Database.

For detailed information about importing Siebel objects and creating rules, see Using Siebel Object Importer and Creating and Deploying Rules.

About Rule Modules Deployment

When you deploy rule modules from HaleyAuthority:

• The Siebel Deployment plug-in compiles the HaleyAuthority object model (semantic role model) and each selected rule module in the HaleyAuthority knowledge base.
• The Deployment plug-in updates the runtime database by inserting or modifying the runtime tables with the compiled binaries.

For information about tables provided for rules data in the Siebel runtime database, see Rule Tables in the Siebel Runtime Database.

For detailed information about deploying rule modules, see Deploying Rule Modules.

About Rule Modules Invocation: Loading, Using, and Caching

You can implement rule modules to execute in various scenarios; for example, in a runtime event or in a business service within a Siebel workflow. Independent of how a rule module is invoked, the activity that occurs consists of loading the binaries (object model and rule modules) that exist in the runtime database into the Haley's runtime knowledge base for execution.

Haley's runtime knowledge base is instantiated in the Application Object Manager when the object manager process starts, and persists until the object manager process stops.

NOTE:  Haley's runtime knowledge base is neither the Siebel runtime database nor the HaleyAuthority knowledge base. For more information on the Siebel runtime database and the HaleyAuthority knowledge base, see Understanding Building and Deploying Rules.

A rule module is loaded into Haley's runtime knowledge base for execution when the rule module is first invoked. Haley's runtime knowledge base is loaded with rule modules on demand and shared among different user sessions. Once a rule module is loaded into the Haley's runtime knowledge base, it is ready to be used until it needs to be excised.

When a rule module is re-deployed or deactivated, the loaded rule module is excised from Haley's runtime knowledge base. The next time the rule module is invoked, the newly deployed or re-activated rule module is loaded into the runtime knowledge base.