Siebel Business Rules Administration Guide > Integrating Rules with Siebel Runtime Events > Scenario for Using Rules to Validate Data at Runtime >

Adding Business Logic

This topic is a task in the development process that is listed in Scenario for Using Rules to Validate Data at Runtime.

The business logic requirement is implemented in a PreWriteRecord runtime event and a WriteRecord runtime event, each of which makes a call to the Business Rule Service business service.

You must do the following tasks to add the business logic. Except as noted, these tasks are typical for creating and deploying rules from HaleyAuthority.

• Creating a Knowledge Base, if necessary. This task is only done once for each environment.
• Importing Siebel Objects, including establishing connectivity to the Master Repository and runtime database on the first import.
• Organizing Business Logic Into Rule Modules and Submodules.

Creating a Knowledge Base

You can use an existing knowledge base for this example or create a new knowledge base, if no knowledge base is associated with the target repository and Siebel database.

When you launch HaleyAuthority, choose an existing knowledge base or choose to create a new knowledge base. For this example, you create a new Access knowledge base that is associated with a Siebel sample database. The new Access knowledge base must be the only knowledge base associated with the target repository and database.

To create the knowledge base

1. Launch HaleyAuthority.
   • By default, launch Siebel Business Rules Developer from the Windows program group that contains Siebel Tools.
2. In the HaleyAuthority dialog box, select New knowledge base file (*.akb).

   NOTE:  For this example, you create an Access knowledge base and connect to a Siebel sample database. For information on using a non-Access database, see Setting Up Your Knowledge Base.

3. Name the knowledge base, for example Test, and click Save.

   HaleyAuthority opens with the knowledge base name in the title bar.

Importing Siebel Objects

You import Siebel object definitions - business objects, business components, and fields - from the Siebel Master Repository in order to create rules modules that reflect the business logic. The business logic for this example is based on the Service Request business object and the Service Request business component. Several child business components of Service Request and fields in the various business components are required to be imported to implement the business logic.

On your first import of Siebel Objects into the knowledge base, you provide connectivity parameters to the Master Repository and runtime database.

To import Siebel objects and define connectivity

1. In HaleyAuthority, choose File > Import > Siebel Object.

   Siebel Object Importer Wizard launches.

2. From the Siebel Object Importer Wizard Welcome screen, click Next.
3. In the Login screen, enter database connection parameters, then click Next. For this example, a local database is used for both the repository database and as the runtime database. You may want to use the Siebel sample database, sse_samp.dbf, instead.
   • Specify (or browse to) the Siebel application cfg file (for example, uagent.cfg or siebel.cfg) which points to the sample database. It is typically located in the \BIN\LANG directory in your Siebel developer client's root directory, where LANG is the language code (for example, ENU).
   • Enter the login credentials to the sample database.
   • Choose Sample as the datasource.
   • For the runtime data connection, also choose Local mode.
4. In the Pick Task screen, click the Import Siebel objects radio button, then click Next.
5. From the Pick Business Object screen, select the Service Request business object from the picklist, then click Next.
6. In the Pick Business Components screen, click the checkbox for the Service Request business component. Expand the Service Request business component hierarchy as necessary and also select the Action and Activity Plan business components, then click Next.
7. On subsequent screens of the Pick Business Component Fields dialog box, select the following fields. In the Available Fields list, select fields, then click the right arrow to move the selected fields to the Selected Fields list, then click Next.

   Business Component	Fields
   Service Request	Area Contact Last Name Organization Priority Account Commit Time Reproduce Description
   Action	Status Activity SR Id NOTE:  Activity SR Id is the foreign key to the parent service request in the Service Request/Action link.
   Activity Plan	Name

8. The Finish screen displays the hierarchy of the business object, business component, and fields to be imported. Confirm to import this hierarchy by clicking Finish.
9. Click No when prompted whether to perform another task.

   The Output screen displays a log of the concepts, relations, and dictionary objects that are automatically created in HaleyAuthority.

For more detailed information about importing Siebel objects, see Using Siebel Object Importer.

If you expand the concepts hierarchy, you see new concepts and phrasings that you can use with HaleyAuthority's natural English language editor to reference the imported business components and their fields with your rule statements. These phrasings are generated automatically by the Object Importer and represent the relations between the business components that are imported and between business components and fields that are imported. The phrasings are all of the form A business component name has a business component name or A business component name has a field name; for example, a service request has a description.

Organizing Business Logic Into Rule Modules and Submodules

You now create rule modules to represent your business logic. For this example there are two rule modules, one for the PreWriteRecord event and one for the WriteRecord event.

To create the rule modules

1. In HaleyAuthority, navigate to the Module Explorer by clicking its tab at the bottom of the screen.
2. Select Modules & Statements, then choose Object > Add a module, and name the new module Service Request Validation - PreWriteRecord.
3. Repeat Step 2 to create a module named Service Request Validation - WriteRecord and a module named Service Request Activity - PreWriteRecord.

Now you add statements to the modules to execute your business logic.

To add statements to the modules

1. Select the Service Request Validation - PreWriteRecord module and choose Object > Add a statement.
2. In the Edit Statement dialog box, type in the following statement or pick its components (except quoted strings, which you must type in) from the Words picklist, then click OK. Do not capitalize any words, except those that are in quoted strings.

   if a service request does not have an account then invalidate the service request with "A service request must have an account."

   NOTE:  The period is part of the text to be displayed. It must be inside the double quotes. A period cannot be part of the HaleyAuthority statement syntax, so a period cannot be outside of quotes.

3. Verify that your statement is understood by HaleyAuthority. If it is not understood, a question mark is displayed at the beginning of the statement when it is displayed in the Module Explorer. If your statement is not understood, choose Object > Reparse statement. If the statement is still not understood, choose Object > Edit, and make changes so that the statement matches the direction in this procedure.
4. Repeat Step 1 through Step 3 to add the following statements to the Expense Validation module:

   if a service request does not have a contact last name then invalidate the service request with "A service request must have a contact."

   if a service request does not have a description then invalidate the service request with "A service request must have a description."

   if a service request does not have an area then raise an error as "Enter the area for the service request."

   if a service request has an activity plan that does not have a name then raise an error as "This service request has an activity plan that does not have a name."

5. Select the Service Request Validation - WriteRecord module and repeat Step 2 through Step 3 to add the following statements:

   if a service request has an organization and the organization's name begins with "PCS" and the service request does not have a primary organization then set "Organization" of the service request to "Default Organization"

   if a service request's commit time is unknown then set "Commit Time" of the service request to now

   if a service request's reproduce is "Always" then set "Priority" of the service request to "4-Low"

   if a service request's reproduce is unknown then set "Reproduce" of the service request to "Always"

6. Select the Service Request Activity - PreWriteRecord module and repeat Step 2 through Step 3 to add the following statement:

   if the status of an action is "Unscheduled" then set "Status" of the action to "Alerted"

   Right click the statement and choose Is applicable > if, and add the applicability statement:

   an action has an activity sr id that is not unknown

   NOTE:  Testing for a field being not unknown tests for the field being not null; that is, that the field has a value.