Siebel Business Rules Administration Guide: November 2008

Siebel Business Rules Administration Guide
Version 8.1 November 2008
Copyright 2005, 2008, Oracle. All rights reserved. The Programs (which include both the software and documentation) contain proprietary information; they are provided under a license agreement containing restrictions on use and disclosure and are also protected by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly, or decompilation of the Programs, except to the extent required to obtain interoperability with other independently created software or as specified by law, is prohibited. The information contained in this document is subject to change without notice. If you find any problems in the documentation, please report them to us in writing. This document is not warranted to be errorfree. Except as may be expressly permitted in your license agreement for these Programs, no part of these Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose. PRODUCT MODULES AND OPTIONS. This guide contains descriptions of modules that are optional and for which you may not have purchased a license. Siebels Sample Database also includes data related to these optional modules. As a result, your software implementation may differ from descriptions in this guide. To find out more about the modules your organization has purchased, see your corporate purchasing agent or your Oracle sales representative. If the Programs are delivered to the United States Government or anyone licensing or using the Programs on behalf of the United States Government, the following notice is applicable: U.S. GOVERNMENT RIGHTS. Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial Computer Software--Restricted Rights (June 1987). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065. The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup, redundancy and other measures to ensure the safe use of such applications if the Programs are used for such purposes, and we disclaim liability for any damages caused by such use of the Programs. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. The Programs may provide links to Web sites and access to content, products, and services from third parties. Oracle is not responsible for the availability of, or any content provided on, third-party Web sites. You bear all risks associated with the use of such content. If you choose to purchase any products or services from a third party, the relationship is directly between you and the third party. Oracle is not responsible for: (a) the quality of third-party products or services; or (b) fulfilling any of the terms of the agreement with the third party, including delivery of products or services and warranty obligations related to purchased products or services. Oracle is not responsible for any loss or damage of any sort that you may incur from dealing with any third party.
Contents
Siebel Business Rules Administration Guide 1
Chapter 1: Chapter 2:
Whats New in This Release Siebel Business Rules Overview

9 12
17
About Benefits for Siebel Business Rules
About the Siebel Business Rules Architecture

HaleyAuthority Development Environment 12 Siebel Client and Server Run-Time Environment
Chapter 3:
Designing Siebel Business Rules

21 25
Roadmap for Developing Business Rules Process of Designing Business Rules
Defining the Business Process 25 Specifying Business Process Logic Requirements 26 Identifying the Mechanism that Invokes the Business Process Specifying UI Elements for the Business Process 28 Identifying the Tool to Develop the Business Process 28
26
Chapter 4:
Configuring the Development Environment

31
32
Overview of the Business Rules Development Environment

User and Group Management in HaleyAuthority Data Migration Between Environments 33
Process of Setting Up the Knowledgebase
34
34
Installing the Business Rules Developer 34 Creating a Database to Store the Knowledgebase Defining Connectivity to the Knowledgebase 35 Defining Multiple Knowledgebases 37 Deleting a Knowledgebase 38
Migrating Rules Between Environments
39
Migrating Knowledgebase Data Between Environments 39 Migrating Run-Time Data Between Environments 40 Migrating Run-Time Data with Application Deployment Manager
42
Guidelines for Configuring the Rules Development Environment
46
Siebel Business Rules Administration Guide Version 8.1
Contents
Chapter 5:
Developing Siebel Business Rules

47
48
Process of Developing Business Rules
Importing Siebel Objects into HaleyAuthority Creating a Rule Module 50 Creating a Rule Statement 51 Testing a Rule Module 52 Deploying a Rule Module 56 Activating a Rule Module 57 Implementing Business Rules 59 Verifying Business Rule Functionality 62 Migrating a Rule Module 63 Administering Business Rules 63
Guidelines for Creating a Rule Module and a Rule Statement
66
Chapter 6:
Implementing Rules Through a Script on a Business Component

69 70
Overview of Implementing Business Rules Through a Script Process of Validating an Account Through a Script
Designing the Business Rules Implementation 70 Importing Siebel Objects 71 Creating the Rule Module 72 Deploying and Activating the Rule Module 72 Configuring the Run-Time Event 73 Creating the Script 73 Verifying Business Rule Functionality 78
Chapter 7:
Implementing Rules Through Declarative Configuration in a Workflow Process

79 80
Overview of Implementing Business Rules Through Declarative Configuration Process of Qualifying an Opportunity Through a Workflow Process
Designing the Business Rules Implementation 80 Defining the Project 82 Creating the Child Business Component 82 Creating the Workflow Process 84 Importing Siebel Objects 89 Creating the Rule Module 90 Testing the Rule Module 91 Deploying and Activating the Rule Module 93 Defining Calls to the Siebel Rules Engine 94 Verifying Business Rule Functionality 97
Contents
Publishing and Activating the Workflow Process
99
Chapter 8:
Implementing Rules Through a Run-Time Event

101 102
Overview of Implementing Business Rules Through a Siebel Run-Time Event Process of Validating a Service Request Through a Run-Time Event
Designing the Business Rules Implementation 102 Configuring the Action Set 104 Associating the Action Set with an Event 107 Importing Siebel Objects 108 Creating the Rule Modules 109 Testing the Rule Module 111 Deploying the Rule Modules 114 Activating the Rule Modules 114 Configuring and Activating the Run-Time Event 115 Verifying Business Rule Functionality 118
Chapter 9:
Implementing Rules Through a Script in a Task UI
Overview of Implementing Business Rules Through a Script on a Custom Business Service 121 Process of Creating an Opportunity Through a Siebel Task UI
Designing the Business Rules Implementation 122 Defining a New Siebel Task UI 127 Defining UI Elements for the Opportunity Info View 129 Defining UI Elements for the Excellent Lead Info View 133 Defining UI Elements for the Good Lead Info View 135 Binding Views to Task UI Steps 137 Defining the Task UI Groups 139 Importing Siebel Objects 140 Creating the Rule Module 141 Deploying and Activating the Rule Module 142 Testing the Rule Module 143 Creating a Custom Business Service 145 Defining Calls to the Siebel Rules Engine 152 Publishing, Activating, and Verifying the Task UI 155
122
Appendix A: Reference Topics for Siebel Business Rules

Mapping Between Siebel and HaleyAuthority 159
159 Overview of Mapping Between Siebel and HaleyAuthority Siebel Objects Mapped to HaleyAuthority Objects 161
Contents
Siebel Concepts, Relations, Actions, Functions, and Predicates
165
Business Rule Tables in a Siebel Run-Time Database Run-Time Events Supported by Business Rules Business Rule Service 181 180
178
Preparing the Business Rule Service 182 RunRules Business Service Method 185 ProcessOutput Method 192 Input and Output Property Usage With Siebel Development Tools Business Rule Service Run-Time Log Files 195 Input Property Schema for the Business Rule Service 196 Output Property Schema for the Business Rule Service 199
193
Rule Modules and Rule Statements

Rule Modules 204 Rule Module Activation Rule Statements 207 206
204
Siebel Test Harness
215
215
Test Harness Output Window
Guidelines for Implementing Siebel Business Rules Troubleshooting Siebel Business Rules 218
Technical Support for Business Rules 218 Rules Configuration and Activation Troubleshooting Rules Deployment Troubleshooting 221 Rules Output Troubleshooting 223
216
219
Appendix B: Glossary for Siebel Business Rules

Rules Glossary 225
Index
Whats New in This Release
Whats New in Siebel Business Rules Administration Guide, Version 8.1

Table 1 lists changes in this version of the documentation to support release 8.1 of the software.
Table 1. Topic
New Product Features in Siebel Business Rules Administration Guide, Version 8.1 Description Because the run-time database executes business rules, you are not required to set up nor maintain a separate HaleyAuthority knowledgebase in a test environment or a production environment. A single HaleyAuthority knowledgebase can deploy rules to both environments. Multiple HaleyAuthority knowledgebases can be defined. You can declaratively build the input property set, and process the output property set in a workflow process or task UI. It is no longer necessary to use special techniques, such as scripting a business service, to define the input and process the output. Topic revised. This example now uses declarative configuration rather than scripting. It also uses a new workflow process technique known as traversing a recordset. This topic includes an updated list of Siebel Actions, Functions, and Predicates in HaleyAuthority, including several actions and functions new in Siebel CRM version 8.1. Topic revised. The Business Rule Service includes several new input and output arguments. The Siebel test harness plug-in to HaleyAuthority can test rules that use several new Siebel functions and predicates.
HaleyAuthority Knowledgebase Presence Requirements on page 15
Defining Multiple Knowledgebases on page 37 Overview of Implementing Business Rules Through Declarative Configuration on page 79
Process of Qualifying an Opportunity Through a Workflow Process on page 80 Siebel Concepts, Relations, Actions, Functions, and Predicates on page 165 Business Rule Service on page 181 Siebel Test Harness on page 215
Additional Changes
This guide also includes: structural changes to the content, such as topic organization and heading arrangement, revised procedures, and an expanded glossary.
Whats New in This Release
Siebel Business Rules Overview
This chapter provides the business case for implementing Oracles Siebel Business Rules. It includes the following topics: About Benefits for Siebel Business Rules on page 9 About the Siebel Business Rules Architecture on page 12
About Benefits for Siebel Business Rules

Changes in your business strategies can result from changes in environmental factors, such as business conditions, inventory levels, seasons, and changes in personnel. Your CRM applications must adapt to these changes and reflect shifts in business priorities. You can implement Haley System Inc.s HaleyAuthority natural language business rules to automate decisions declaratively rather than implementing those decisions programatically, as with a script. By replacing a script that is difficult to develop and maintain with business rules that are created and modified directly by a business manager, the overall cost of maintenance and configuration of a Siebel application is minimized. A business rule is the familiar, generic connotation that describes a well defined business process. Such processes provide a way to define the operations, definitions and constraints applied to organizational procedures in a way that allows the organization to achieve organizational goals. A rule statement is a logical statement that is built in HaleyAuthority to capture and implement business process logic in a Siebel application. Consider the following example rule statement: if a service request does not have a description then invalidate the service request with "A service request must have a description."
Benefits of Using Business Rules

This topic describes benefits for using Business Rules.
Benefits of Using Business Rules in a Siebel Application Benefits of using Siebel Business Rules in a Siebel application include: No need to compile the srf then restart the server. Dynamic business processes frequently include requirements and parameters that change on a regular basis. For example, prerequisites for insurance application approval, credit card approval, and insurance claim processing can change over time. Siebel Business Rules allow you to implement a change to a business process through declarative configuration in a natural language context. It is not necessary to rewrite script logic or redefine Siebel objects, and then recompile the Siebel Repository File.
Siebel Business Rules Overview About Benefits for Siebel Business Rules
Can reflect a complex business process. Business processes, such as those you develop through Siebel Workflow or Siebel Task UI (task UI), frequently contain decision branching that depends on results of earlier steps. Siebel Business Rules allow for more complex processing of data to generate more refined input values for decision making. Changes to the business logic governing the input are maintained declaratively, instead of relying on entirely scripted solutions. Can perform field validation. Besides easier implementation and maintenance during the life of a Siebel release, field validation implemented with Siebel Business Rules are more directly maintained across a Siebel upgrade rather than performing validation through a script. Can automatically populate a field value. You can declaratively populate a field that depends on a value from another field. Siebel Business Rules allows changing the logic without having to recompile the Siebel Repository File, and without having to modify a script.
Benefits of Implementing HaleyAuthority Rules From a Single Source Benefits of implementing HaleyAuthority rules from a single source that is external to a Siebel application includes: Groups of rules that include different purposes or used in different applications are developed and implemented separately:

A versioned object can revert to a prior version Access levels define who can modify particular rules and rule modules
Participants other than a software developer, such as a business analyst or a business manager, can define and modify the logic. If logic is represented as a rule in natural language, then it is readily understood. The HaleyAuthority authoring tool also provides support through visual cues to help the business analyst validate rules as they are written. Business logic is maintained in a single location for use with various Siebel applications and functionalities. You can write rules to reflect your business logic immediately after Siebel objects are imported. When Siebel objects are imported to HaleyAuthority, the necessary HaleyAuthority metadata is created automatically. Example metadata includes concepts, relations, and phrasings. You can simulate rule execution before you implement a rule module in a production environment. The Siebel Test Harness provides this capability, and also provides a way to perform regression testing. Siebel Business Rules are invoked through a number of ways, including:

Run-time event Siebel Workflow Siebel Task UI Business service
10
Siebel Business Rules Overview About Benefits for Siebel Business Rules
Siebel Business Rules can invoke methods, including:

Siebel business component methods Application methods
Business logic is represented in a rule module, which is reusable. Changes to the Siebel object model in the Siebel Repository File and to the imported HaleyAuthority objects are synchronized on demand.
11
Siebel Business Rules Overview About the Siebel Business Rules Architecture
About the Siebel Business Rules Architecture

This topic describes the Siebel Business Rules architecture. It includes the following topics: HaleyAuthority Development Environment on page 12 Siebel Client and Server Run-Time Environment on page 17.
Figure 1 illustrates the architecture for Siebel Business Rules.
Figure 1.
Siebel Business Rules Architecture
The rules implemented in a Siebel business application are authored in Haley System Inc.s HaleyAuthority authoring environment. HaleyAuthority must possess knowledge of the Siebel objects on which you write a business rule. The results of the executed rule are mapped to the operations that are executed on the Siebel objects in a Siebel application. The components of the rules architecture allow the rules authored in HaleyAuthority to execute in the Siebel application.
HaleyAuthority Development Environment

HaleyAuthority is a rule authoring environment in which you define business rules. HaleyAuthority provides a set of tools for modeling a business policy as a rule statement in English without the requirement to employ a programming language. HaleyAuthority allows you to test and deploy rule statements. The statements are executed by the Haley Inference Engine. If implemented with a Siebel application, then the executed rules can act on data or make decisions in a Siebel application. Thus, HaleyAuthority allows business logic to be maintained declaratively and in a location that is external to your Siebel implementation.
12
HaleyAuthority documentation, included in HaleyAuthority through the Help menu, provides the primary information on using HaleyAuthority to build generic rules. For more information, see Documentation for Business Rules on page 24.
Siebel Object Importer

The Siebel Object Importer is a plug-in to HaleyAuthority. Using Siebel Object Importer, you choose a subset of the Siebel object model and import it to HaleyAuthority to define the concepts and relations that define rules on Siebel objects.
HaleyAuthority Semantic Role Model Before you can write a rule, HaleyAuthority must be made aware of conditions on which the rule operates. The Haley System Inc.s HaleyAuthority knowledgebase includes a semantic role model. Basic structural components in the HaleyAuthority semantic role model include: Concepts play roles in relations. Relationships are instances of relations. Roles in a relationship are filled by instances of the concepts that play the corresponding roles in the base relation. For example, the relation A person has a mother could include a relationship Jills mother is Lee. Determiners and quantifiers are supported on roles in relationships within sentences. Relations can include verb phrasings. Concepts can include nouns or noun phrasings, including adjectives.
To write a rule that operates with a Siebel object, the object definition must first be mapped to the semantic role model for HaleyAuthority. The Siebel Object Importer is integrated with HaleyAuthority and performs the mapping on demand. With Siebel Object Importer, you can choose and import to HaleyAuthority the minimal set of business components and fields that are required to write a particular rule or set of rules. Work performed by the Siebel Object Importer includes: Import Siebel object definitions by helping you to pick only the subset of objects required to define business rules. When you pick a business object, the business components belonging to the business object are listed. You can drill down and pick individual business components and fields. Synchronize the HaleyAuthority knowledgebase with the Siebel Repository File. That is, make the HaleyAuthority concepts and relations that represent imported Siebel objects consistent with the current Siebel object model. Initialize a new HaleyAuthority knowledgebase by adding a set of concepts, relations, procedures, verbs, and verb phrasings that are required to implement rules in a Siebel application.
13
HaleyAuthority Objects Built by the Siebel Object Importer When you import Siebel objects to HaleyAuthority, you first specify the HaleyAuthority knowledgebase name. This name provides the context that makes sure the import and synchronization by Siebel Object Importer is performed within the context of the specified knowledgebase. HaleyAuthority objects built by the Siebel Object Importer when the knowledgebase name is specified include: HaleyAuthority concepts that represent Siebel business components and fields. HaleyAuthority relations generated from links, or 1:M relations, between Siebel business components. Phrasings are generated for such relations, such as An expense has an expense item. HaleyAuthority relations generated between Siebel business components and child fields. Phrasings are generated for such relations, such as An account has a name.
Rule Module Creation When you use Siebel Object Importer, a COM Data Control (CDC) connection to the Siebel master repository database and a CDC connection to the Siebel run-time database are created. Logic executed when you import Siebel objects using Siebel Object Importer include: Siebel object metadata is read from the Siebel master repository database. When Siebel Object Importer possesses the final list of objects to import, it tells HaleyAuthority, through the Haley API, to create concepts, relations, and phrasings in the HaleyAuthority knowledgebase. Concurrently, Siebel Object Importer writes data to the Siebel run-time database that tracks the business components and fields that are imported. This data allows knowledgebase data to be interpreted correctly by the Siebel run-time database at run time.
The length of time required 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 knowledgebase.
HaleyAuthority Knowledgebase
The Haley System Inc.s HaleyAuthority knowledgebase is a database that stores HaleyAuthority schema, data, and metadata, including Siebel object definitions and rules created by the Object Importer. It consists of the HaleyAuthority schema definition and HaleyAuthority data, such as concepts, relations, statements, and so forth. It resides in the rules design environment and is modified directly by HaleyAuthority. The Haley System Inc.s HaleyAuthority run-time knowledgebase is a database that represents the semantic role model and rules instantiated in the Application Object Manager at run time.
14
Note the following: When the HaleyAuthority knowledgebase resides within your Siebel Repository database , the knowledgebase tables and columns do not appear as viewable objects in Siebel Tools because the tables are not part of the Siebel schema. Instead, these tables typically exist in a Microsoft Access database. The HaleyAuthority run-time knowledgebase does not displace nor fulfill the role of the Siebel run-time database or the HaleyAuthority knowledgebase. The HaleyAuthority run-time knowledgebase is a representation of the semantic role model and rules instantiated in the Application Object Manager. For brevity, it is not shown in Figure 1 on page 12. A HaleyAuthority knowledgebase must not reside in the Siebel run-time database.
CAUTION: It is recommended that your knowledgebase does not reside in the Siebel master repository database for security and performance reasons.
HaleyAuthority Knowledgebase Presence Requirements Because the Siebel rules engine executes rules using data from the Siebel run-time database, you are not required to set up nor maintain a separate HaleyAuthority knowledgebase in a test environment or a production environment. A HaleyAuthority knowledgebase is only required to be present in the development environment. Because the HaleyAuthority run-time database includes the necessary details when the rule module is deployed, it is not necessary to include a separate HaleyAuthority knowledgebase on every machine that executes business rules. After it is created, the HaleyAuthority knowledgebase is deployed and made available in the run-time database that is accessed to execute the business rules. Rules can be deployed to a run-time environment, such as test or production, from a single HaleyAuthority knowledgebase that exists in the development environment.
Multiple HaleyAuthority Knowledgebases Multiple HaleyAuthority knowledgebases are configured to meet the distinct requirements of a business. For example, one HaleyAuthority knowledgebase is dedicated for a call center and another for a service organization. Both groups might include their own knowledgebase running independently. If multiple knowledgebases are present, then each knowledgebase runs independently of other knowledgebases, and on one run-time environment. You can deploy rule modules from different knowledgebases to the same Siebel run-time database, but you can only open a single HaleyAuthority knowledgebase against a single Siebel Tools master repository.
Siebel Deployment Plug-In

A rule module is created in HaleyAuthority, then compiled and stored in the Siebel run-time database by using the Siebel Deployment plug-in. Logic executed by the Siebel Deployment plug-in when you deploy a rule module from HaleyAuthority includes: Compiles the HaleyAuthority semantic role model and each chosen rule module in the HaleyAuthority knowledgebase Updates the run-time database by inserting or modifying the run-time tables with the compiled binaries
15
Functionality provided by the Siebel Deployment plug-in includes: Lists top level rule modules from HaleyAuthority. Lets you choose modules to deploy. Compiles chosen rule modules, then deploys them to the Siebel run-time environment. Provides you an option not to deploy the semantic role model. A rule module is deployed without having to recompile the Siebel Repository File, or to restart the Siebel Server.
Note that, in this book, in general deployment means taking rules from the HaleyAuthority authoring environment and pushing or deploying them as modules to the Siebel run-time environment. For information about: Deployment across multiple Siebel Servers, see Migrating Run-Time Data with Application Deployment Manager on page 42. Tables provided for rules data in the Siebel run-time database, see Business Rule Tables in a Siebel Run-Time Database on page 178.
Importer and Deployment Plug-In Log Files

Logging on the Siebel side is available for the Siebel Object Importer plug-in and the Siebel Deployment plug-in. To turn on logging, you set the environment variable BZR_PLUGINS_LOG to 1 on the machine on which you are running HaleyAuthority. Using the Siebel Object Importer plug-in and Siebel Deployment plug-in after you set the BZR_PLUGINS_LOG environment variable generates log files in your HaleyAuthority installation folder. These log files include: Objectimporter_plugin.log Deployment_plugin.log
You can use the information in these log files to troubleshoot problems you encounter when using the Siebel Object Importer plug-in or Siebel Deployment plug-in. For more information, see Business Rule Service Run-Time Log Files on page 195.
16
Siebel Client and Server Run-Time Environment

The Siebel client and server run-time environment provides the communication mechanism between HaleyAuthority run-time and the Application Object Manager. Work performed by the Siebel run-time environment includes: Run-time administration:

Provides configuration, activation, and inactivation of a deployed rule module Provides functionality for importing and exporting a rule module
Integration of the Haley Inference Engine with the Application Object Manager:

Passes Siebel run-time data to the Haley Inference Engine Manages the HaleyAuthority run-time knowledgebase, which is an Application Object Manager instance, which it loads with the rule modules Manages working memory, which loads the run-time data the rule module logic assesses Handles invocations to the Haley Inference Engine Handles rule execution results from the Haley Inference Engine in the Siebel application Provides tracing and logging
Extension of Haley Inference Engine:

Extends Haley Inference Engine to pass back the results to the Siebel application Performs callbacks for a currency amount comparison operation Performs callbacks for a Siebel extended action, predicate, or function Provides capabilities for tracing and logging
Siebel Master Repository Database

When you run the Siebel Object Importer, you import Siebel objects from the Siebel master repository database into HaleyAuthority. The Master Repository database in a development environment is the database to which you check in repository changes made with Siebel Tools. The Master Repository database must contain the most current Siebel object model for your business. The Master Repository database might or might not contain transaction data.
Rules Administration Screen

A deployed rule module is activated, deactivated, and configured by using the rules run-time administration screen in the Siebel client.
Haley Inference Engine

The Haley Inference Engine executes the rules created in HaleyAuthority.
17
Proxy Service
The Siebel Business Rule Service is the proxy service. It is a proxy to functionality for the Siebel Rules Engine at run time. Functions performed by the proxy service include:

Manages the HaleyAuthority run-time objects Manages deployed rule modules Interfaces with the Application Object Manager for data Interfaces with the Haley Inference Engine for rule execution Manages the rule execution results from the Haley Inference Engine
For information on the data that is exchanged between the HaleyAuthority knowledgebase, the Siebel master repository database, and the Siebel run-time database, see Process of Setting Up the Knowledgebase on page 34.
Siebel Run-Time Database

A Siebel run-time database is a database that contains transaction data and seed data, such as lists of values, price lists, and so forth. It must include the same repository data as your Siebel master repository database. A Siebel run-time database and the corresponding Siebel master repository database might or might not be the same database. For security and performance reasons, they are likely separate databases in a development environment .
Business Rule Loading and Caching

You can implement a rule module to execute in various situations. For example, in a run-time event or in a business service within a workflow process. Regardless of how a rule module is invoked, the object model and rule module binaries that exist in the run-time database are loaded into the HaleyAuthority run-time knowledgebase for execution. The HaleyAuthority run-time knowledgebase is instantiated in the Application Object Manager when the object manager process starts, and persists until the object manager process stops. A rule module is loaded in the HaleyAuthority run-time knowledgebase for execution when the rule module is first invoked. The knowledgebase is loaded with rule modules on demand and is shared among different user sessions. When a rule module is loaded to the knowledgebase, it is ready to be used until it must be deleted. When a rule module is redeployed or deactivated, the loaded rule module is deleted from the HaleyAuthority run-time knowledgebase. The next time the rule module is invoked, the newly deployed or reactivated rule module is loaded into the knowledgebase.
Business Rule Maintenance

This topic describes how business rules are administered within the business rules architecture. For more information, see Administering Business Rules on page 63.
18
HaleyAuthority Knowledgebase and Siebel Repository Consistency The representation of Siebel objects as HaleyAuthority concepts and relations must be kept consistent with the Siebel object model. Changes to the Siebel object model require that you synchronize the HaleyAuthority knowledgebase with the Siebel Repository File. Example changes that necessitate synchronization include: The definition for a Siebel object that is used in a rule is changed in the Siebel Repository File. The Type for an imported field is changed in the Siebel Repository File, such as from DTYPE_TEXT to DTYPE_BOOL. An imported field is inactivated in the Siebel Repository File. A new field is created to access the same underlying table column. An imported object is affected by a schema change in the Siebel database, such as might occur after an upgrade. Your business process or your business process requirements change, such as business process performance metrics. Parameters for your business logic change. For example, thresholds that generate actions. Rule statements in the business rules are modified. Your business rule implementation must be deactivated, either temporarily or permanently. Personnel change, and so forth.
19
20
Designing Siebel Business Rules
This chapter provides an overview of designing an implementation of Siebel Business Rules. It includes the following topics: Roadmap for Developing Business Rules on page 21 Process of Designing Business Rules on page 25
Roadmap for Developing Business Rules

Figure 2 illustrates the lifecycle for developing business rules.
Figure 2.
Illustration of Development Lifecycle for Business Rules
21
Designing Siebel Business Rules Roadmap for Developing Business Rules
The steps for developing business rules include:
Design. Define the business process in which business rules are used, specify logic requirements, identify the mechanism to invoke the business process, identify UI elements involved, and identify the development tool. Setup Knowledgebase. Create a database to store the knowledgebase, then define connectivity to the knowledgebase. Import, Create and Test. Import Siebel objects to HaleyAuthority, then create and test a rule module in HaleyAuthority. Deploy and Activate. Deploy a rule module from HaleyAuthority to the Siebel run-time environment, then activate it. Implement and Verify. Implement business rules through a Siebel development tool, such as a workflow process, then verify the business rules achieve the required functionality. Migrate and Administer. Migrate the business rules from the development environment to the production environment, then administer the business rules periodically to reflect changes in the business environment.
2 3 4 5 6
Note that while the lifecycle illustrated is linear, the typical development cycle for business rules is iterative.
Processes Involved in Developing Business Rules

To develop business rules, perform the following processes:
1 2 3
Process of Designing Business Rules on page 25 Process of Setting Up the Knowledgebase on page 34 Process of Developing Business Rules on page 47 Developing business rules includes importing, creating, testing, deploying, activating, implementing, verifying, migrating, and administering.
Example Business Rule Implementations

Examples in this book that ground the concepts and procedures used when developing business rules include: Chapter 6, Implementing Rules Through a Script on a Business Component Chapter 7, Implementing Rules Through Declarative Configuration in a Workflow Process Chapter 8, Implementing Rules Through a Run-Time Event Chapter 9, Implementing Rules Through a Script in a Task UI
22
Prerequisites to Developing Business Rules

Prior to developing business rules, you must make sure the Business Rules Developer is installed correctly. You might be required to perform installation steps that are in addition to a typical installation for Siebel Tools. For more information, see Siebel Installation Guide for the operating system you are using. NOTE: The Siebel Bookshelf is available on Oracle Technology Network (OTN) and Oracle E-Delivery. It might also be installed locally on your intranet or on a network location.
HaleyAuthority Directories and Program Groups

By default, HaleyAuthority is installed in the \RULE subdirectory of the Siebel Tools root directory. CAUTION: Do not change the name of the \RULE subdirectory during installation or after installation. You can opt to change the root directory for Siebel Tools during installation, but not after installation. Program groups created for HaleyAuthority in the Programs group on the Start menu include: Haley Systems at the top level of the hierarchy Siebel Business Rules Developer at the same level as Siebel Tools
Both program groups point to the same HaleyAuthority authoring environment, and are not separate programs. The names and locations are different, but they are the same program no matter which icon is clicked to launch HaleyAuthority. The \RULE\Documents subdirectory includes HaleyAuthority documentation for using HaleyAuthority. Consult this documentation for HaleyAuthority usage instructions. You can also access the user guide from the Help menu in HaleyAuthority.
Avoiding Errors When Removing HaleyAuthority

If you remove HaleyAuthority and then install HaleyAuthority as part of removing and installing Siebel Tools, and if you open an existing knowledgebase and attempt to deploy or test a rule module, then an error is generated.
To avoid errors when removing HaleyAuthority

First run Siebel Object Importer to recreate the siebel.dat file, which stores information about the knowledgebase and run-time database. For more information, see About the Siebel Business Rules Architecture on page 12.
23
Documentation for Business Rules

When you develop business rules you can consult various documentation sources. Documentation for implementing and using HaleyAuthority with Siebel objects include: Siebel Business Rules Administration Guide. The primary source for information on using HaleyAuthority rules with Siebel objects. For more information, see Contents on page 3. HaleyAuthority Help. The primary source for information on building rules in HaleyAuthority. Available through the Help menu in HaleyAuthority, it includes inks to the Haley System Inc. Web site and documentation on the local machine. Information in HaleyAuthority Help includes:

Information about HaleyAuthority entities Procedures for building rules Rules for testing and debugging Examples of rules
Siebel Master Data Applications Reference. Provides information about predefined rules for Oracles Siebel Master Data Applications.
24
Designing Siebel Business Rules Process of Designing Business Rules
Process of Designing Business Rules

This process is a step in Roadmap for Developing Business Rules on page 21. To design business rules, perform the following tasks:
1 2 3 4 5
Defining the Business Process on page 25 Specifying Business Process Logic Requirements on page 26 Identifying the Mechanism that Invokes the Business Process on page 26 Specifying UI Elements for the Business Process on page 28 Identifying the Tool to Develop the Business Process on page 28
Defining the Business Process

This task is a step in Process of Designing Business Rules on page 25. In this topic, you define the business process you must develop.
To define the business process 1 2 3 4 5 6 7

Identify process goals, objectives, and metrics. State actions to be performed. State requirements for actions. State conditions that support the requirements. Plan the steps of the process. Identify dependencies. Answer questions about the nature of the process:

Does the process require interactivity with the end user? Does the process validate input from the end user? Does the process modify data? Does the process make decisions based on the values of the data? Is the process multistep? Are the steps in the process dependent on each other? Is this process a batch process?
25
Specifying Business Process Logic Requirements

This task is a step in Process of Designing Business Rules on page 25. In this topic you refine the definition of the business process by specifying business process logic requirements.
To specify business process logic requirements 1

Work backward to more clearly define the business process:
If necessary, refine the actions to be performed. For each action, state the conditions that must be satisfied for the action to be performed:

Identify only conditions that must be satisfied individually for the action to be performed. Identify conditions that must be satisfied in combination with other conditions in order for the action to be performed. Identify exceptions to other conditions.
b c 2 a b c
If necessary, refine conditions and exceptions that support higher level conditions. Identify assumptions.
Refine the business process: Clearly state individual conditions that make up compound conditions. Minimize negative logic when possible. Define limits and ranges of acceptable process output.
Identifying the Mechanism that Invokes the Business Process

This task is a step in Process of Designing Business Rules on page 25. In this topic, you identify the mechanism that invokes the business process.
26
To identify the mechanism that invokes the business process

Identify the mechanism that invokes the business process, as described in the following table. How the Business Process is Invoked Manually by the user. Mechanism to Use Mechanisms to use include: Automatically by a run-time event. A task UI or workflow process allows the user to invoke the business process A script can underlie UI buttons A script can use rules
Mechanisms to use include: A run-time event can use rules, a script, or both A workflow process can be invoked in response to a run-time event
Automatically by a preset schedule.
A workflow process, such as a periodic batch workflow process, can be invoked on a preset schedule.
27
Specifying UI Elements for the Business Process

This task is a step in Process of Designing Business Rules on page 25. In this topic, you specify UI elements for the business process by specifying the messages and dialog boxes required to support interaction with the end user, and you design input fields, labels, and buttons.
To specify UI elements for the business process 1

Plan the text for static messages. Messages defined in a rule module typically do not require design work.
Design the layout, including text boxes, buttons, other controls, and the control labels:

Decide how user interaction populates record fields. Provide controls that gather the end user input that is required as criteria for process decisions.
If the text in the UI elements must be localized, then use Language Independent Code (LIC) in your Siebel environment.
For an example, see Chapter 9, Implementing Rules Through a Script in a Task UI.
Identifying the Tool to Develop the Business Process

This task is a step in Process of Designing Business Rules on page 25. Many business processes developed by using the Siebel Rules Engine can also be developed using a script. However, Siebel Business Rules allows much of the logic of the process to be maintained declaratively and external to your Siebel application. Changing logic in the business rules does not require you to recompile the Siebel Repository File.
28
To identify the tool to develop the business process

Use guidelines to help identify the appropriate Siebel development tool to use to develop the business process, as described in the following table. How the Business Process is Used Interactively by an end user
Description of Development Tool Development tools and how the Siebel Rules Engine is used with the tool include: A Siebel run-time event to react to a specific event:
Siebel Rules Engine can implement more complex tests on field values and on calculations, and can display messages for different conditions Siebel Rules Engine can set multiple field values dependent on more complex criteria
A Siebel Task UI to support the end user in completing a multiple step task:

Siebel Rules Engine supports complex decision making and branching that occurs in a task UI Siebel Rules Engine supports validation that occurs in a task UI on the client based on UI events, such as entering a text field to be embedded in a task UI
A Siebel Workflow to implement a multiple step workflow that is initiated in response to an event. Siebel Rules Engine supports complex decision making and branching in a workflow process that depends on output from rules.
To validate data
Development tools to consider include: Business component user properties or field user properties to perform fundamental data validation Siebel run-time events, such as PreWriteRecord, or a workflow process to validate data entry by the user A run-time event such as WriteRecord, or a workflow process, for multistep processing, such as batch processing, to validate data in an environment that is not interactive
29
If an implementation uses a run-time event, a workflow process, or a task UI, then the Siebel Rules Engine can perform more complex decision making and set field values that depend on more complex criteria. For example, with a task UI, output from the business rules can provide criteria for conditional branching, taking one branch when the rule determines lead quality of an opportunity is excellent, and another branch when the rule determines lead quality of an opportunity is good. Other noninteractive workflow processes, such as batch processing, can also be implemented through a workflow process.
Example Business Rule Implementations That Use Siebel Development Tools

For examples that use various Siebel development tools to implement business rules, see: Process of Validating an Account Through a Script on page 70 Process of Qualifying an Opportunity Through a Workflow Process on page 80 Process of Validating a Service Request Through a Run-Time Event on page 102 Process of Creating an Opportunity Through a Siebel Task UI on page 122
30
Configuring the Development Environment
This chapter provides information on configuring and maintaining your rules development environment. It includes the following topics: Overview of the Business Rules Development Environment on page 31 Process of Setting Up the Knowledgebase on page 34 Migrating Rules Between Environments on page 39 Guidelines for Configuring the Rules Development Environment on page 46
For background information about the development environment, see About the Siebel Business Rules Architecture on page 12.
Overview of the Business Rules Development Environment

It is recommended that you maintain one knowledgebase for deploying rules to a single run-time database: The production knowledgebase must update only the production run-time database, and the production database must be updated by only one knowledgebase. A development knowledgebase must update only one development run-time database, and the development database must be updated by only one knowledgebase. Individual developer must replicate changes to the development knowledgebase that is tested in the development run-time database before migrating to production. Individual developers can use a local knowledgebase for prototyping only. As in the production and primary development environments, the local knowledgebase must update only one runtime database and the run-time database must be updated by only one knowledgebase. Development on the local knowledgebases must be replicated on the development knowledgebase. The run-time database is likely a local database. In a development environment, multiple developers on the same team working on the same implementation must use the same knowledgebase. If there are multiple teams, or if an individual is working on multiple implementations, then multiple knowledgebases are appropriate. For example, one knowledgebase for Call Center, and another knowledgebase for Sales.
31
Configuring the Development Environment Overview of the Business Rules Development Environment
User and Group Management in HaleyAuthority

HaleyAuthority creates versions for statements so changes are tracked. However, HaleyAuthority and Siebel plug-ins do not include a check out and check in system that maintains cumulative changes by multiple developers. By default, HaleyAuthority includes three user groups: administrator, everyone, and owners. You can control access by individual developers in a group by assigning privileges and permissions to the group. Each group includes a set of privileges that define high level access control. By default, a member of these groups possesses privileges. The privileges include: Take ownership Change privileges Generate logic Change default permissions Administer users and groups Rollback or commit Change states for a workflow process Change custom fields
In addition, permissions are assigned to each group to define access control at the object level. A permission restricts or allows each member of a group to perform a certain action on a particular object type or on an individual object. For example, a developer in the Everyone group is restricted from deleting an object type, or a relationship between object types. For an object that is a child of another object, the permissions on the parent object are inherited by the child. Principles that apply to the user of a knowledgebase include: If a network user launches HaleyAuthority and defines the new knowledgebase, then the user is automatically a member of the Administrators group in the new knowledgebase. In this case, the network user is identified through the Windows network login. If a user logs in through the Windows network login which opens the knowledgebase automatically, then the user is a member of the Everyone group. If a user runs the Siebel Object Importer and, as a result, creates a new HaleyAuthority entity, value, or relation, then the user becomes the owner of the created objects. Privileges assigned to owners of objects are administered in the Owners group.
32
Configuring the Development Environment Overview of the Business Rules Development Environment
By default, a member of a group can create a new group and can change the privileges of a group.
TIP: It is recommended that an appropriate administrator change the privileges of the groups to limit capabilities of individuals according to the requirements in your organization. For example, because it is not advisable that every user be able to redefine privileges for other users, you might be required to change the default behavior by deleting the administrator users and groups, to change privileges from the Everyone and Owners groups, and to leave those privileges to administrators only. For more information about: Restrictions on HaleyAuthority knowledgebase modifications required for Oracle support, see Technical Support for Business Rules on page 218 HaleyAuthority security topics, see HaleyAuthority Help
Data Migration Between Environments

Migrating is the act of moving business rules from one environment to another environment. During a business rules development effort, it is necessary to migrate knowledgebase and run-time data. For example, from your development environment to your production environment. In some cases, you might be required to migrate knowledgebases and run-time data from more than one source environment to the target environment. For example, from the local prototyping environment for multiple individual developers to the common development environment. Migration for a run-time event, a workflow process, a task UI, and a script does not vary because the Siebel development tool calls the Siebel Rules Engine. However, migration of rules run-time data and your HaleyAuthority knowledgebase between environments does require you to perform work specific to business rules development. For more information, see Migrating Rules Between Environments on page 39.
33
Configuring the Development Environment Process of Setting Up the Knowledgebase
Process of Setting Up the Knowledgebase

This process is a step in Roadmap for Developing Business Rules on page 21. To set up your knowledgebase, perform the following tasks:
1 2 3 4 5
Installing the Business Rules Developer on page 34 Creating a Database to Store the Knowledgebase on page 34 Defining Connectivity to the Knowledgebase on page 35 (Optional) Defining Multiple Knowledgebases on page 37 (Optional) Deleting a Knowledgebase on page 38
Installing the Business Rules Developer

You must make sure the Business Rules Developer is installed. For more information, see Prerequisites to Developing Business Rules on page 23.
Creating a Database to Store the Knowledgebase

This task is a step in Process of Setting Up the Knowledgebase on page 34. You begin by creating a database to store the knowledgebase.
To create a database to store the knowledgebase 1

For a production or development environment, or for testing an implementation, create a separate database with an enterprise relational database management system, such as Oracle, MSSQL, or IBM DB2. Configure an ODBC datasource to this database.
Guidelines for creating a database include: You can create a knowledgebase in an existing database or as a new database. You must only use an Access Knowledgebase (AKB) for local prototyping. An AKB is not intended to be the knowledgebase in a production, development, or test environment. It is strongly recommended that you provide a dedicated database for a production, development, or testing knowledgebase. CAUTION: Do not allow a knowledgebase to share a Siebel run-time database or a Siebel master repository database. Neither of these configurations is supported.
34
Defining Connectivity to the Knowledgebase

This task is a step in Process of Setting Up the Knowledgebase on page 34. To define connectivity, you can perform one of the following tasks described in this topic: Establishing Connectivity for a Production or Development Environment on page 35 Establishing Connectivity for a Local Prototyping Environment on page 36 Establishing Connectivity for an Oracle Database on page 37
If no knowledgebase is associated with the target repository and the Siebel database, then you can use an existing knowledgebase or create a new knowledgebase. You can create a new knowledgebase in an existing ODBC datasource or as a new Microsoft Access database. You must only use a Microsoft Access knowledge (AKB) base for local prototyping. For the examples in this book, you create a new Microsoft Access knowledgebase that is associated with a Siebel sample database. The new Microsoft Access knowledgebase must be the only knowledgebase associated with the target repository and database. This work is performed only one time for each environment. When you launch HaleyAuthority, you must specify the knowledgebase to use for the session. If you create a new knowledgebase, then you must define connectivity to the datasource for the new knowledgebase.
Establishing Connectivity for a Production or Development Environment

You can establish connectivity for a new knowledgebase for use in a production or development environment, or for testing an implementation.
To establish connectivity for a production or development environment 1 2

Make sure that the target environment possesses the appropriate Microsoft Access licensing. Make sure that your client possesses the required ODBC drivers. The ODBC for the Siebel Repository File is configured as part of the Siebel Tools installation process. If your HaleyAuthority knowledgebase uses an RDBMS that is different from the repository , then you must provide the required ODBC driver for the client.
3 4 5
If necessary, create the ODBC datasource for the HaleyAuthority knowledgebase. Launch HaleyAuthority. For more information, see Launching HaleyAuthority on page 36. Under Create a new knowledgebase using, click the Existing ODBC Data Source radio button, then click OK. Note that although a local Microsoft Access knowledgebase is used for the prototyping environment for a single developer, the developer can also choose to set up another knowledgebase, other than Microsoft Access, for the same purpose.
In the New Knowledgebase dialog box, in the ODBC Data Sources and Drivers tab, choose the ODBC datasource for the new database that you created to store the knowledgebase, then click OK.
35
In the subsequent dialog box, enter the login credentials for the datasource, then click OK. HaleyAuthority creates the HaleyAuthority tables and initializes the knowledgebase. For the first developer who creates the HaleyAuthority knowledgebase in the existing datasource, the login must include the create table privilege. Otherwise, HaleyAuthority cannot create the new knowledgebase. This situation is the only time that the create table privilege is required of a developer who is using this knowledgebase.
After a knowledgebase in an ODBC datasource is created, a developer who launches HaleyAuthority can open the knowledgebase by using the Open an Existing Knowledgebase option in the HaleyAuthority dialog box. If the ODBC datasource is not in the list, then choose More Data Sources, and choose the ODBC datasource from the resulting list. The developer must provide the ODBC login credentials to use the knowledgebase.
Launching HaleyAuthority You can launch HaleyAuthority.
To launch HaleyAuthority
Launch HaleyAuthority in either of the following ways:

From the Start menu, choose Program Files, [program group that includes Siebel Tools], then the Siebel Business Rules Developer menu item. From the Start menu, choose Program Files, Haley Systems, then the HaleyAuthority Enterprise menu item.
After launching HaleyAuthority, the HaleyAuthority dialog box displays. For more information, see HaleyAuthority Directories and Program Groups on page 23.
Establishing Connectivity for a Local Prototyping Environment

You can establish connectivity for a new Microsoft Access knowledgebase for a local prototyping environment.
To establish connectivity for a local prototyping environment 1 2 3

Launch HaleyAuthority. Under Create A New Knowledgebase Using in the HaleyAuthority dialog box, click the New Knowledgebase File (*.akb) radio button, then click OK. Name the knowledgebase. For example, TestCallBack, then click Save. HaleyAuthority creates the HaleyAuthority tables and initializes the knowledgebase. The ODBC datasource for HaleyAuthority must be defined to connect to an Oracle database. For more information, see the Siebel Installation Guide for the operating system you are using.
36
Establishing Connectivity for an Oracle Database

You can establish connectivity for an Oracle database.
To establish connectivity for an Oracle database 1 2

Choose an uppercase name for your knowledgebase, such as KB1. In the Oracle database that you connect to, perform the following steps:
a b c 3
Define a user named THE$AUTHORETE$KB1. Grant the user permission to create and delete tables and indices. For a user who accesses KB1, grant read and write permission to tables in THE$AUTHORETE$KB1.
In the ODBC dialog box in HaleyAuthority, define an ODBC datasource with the name KB1 that accesses the Oracle database.
Defining Multiple Knowledgebases

This task is a step in Process of Setting Up the Knowledgebase on page 34. You can define multiple knowledgebases to meet the distinct requirements for individual implementations in your business. This configuration allows groups of developers, each with distinct requirements, to define a knowledgebase that meets their specific requirements, thus decreasing the requirement to coordinate knowledgebase design and usage among different developers and teams. For example: You include both a call center and a sales implementation where these applications are implemented in different locations, and the business logic is not shared. You can develop standalone knowledgebases for each independent project, then run them within a single business, because the business shares the same database and application servers. You include multiple projects developing business logic using rules independently of one another. You require the capability to develop, test, then roll out these separate knowledgebases independently.
Separate knowledgebases are defined with varying concepts and relations that can then be imported and used by different teams, simplifying readability and manageability as these knowledgebases evolve over time. Support for multiple knowledgebases also mitigates the potential problem of developers from disparate groups who are using the same run-time database from inadvertently overwriting the rules for another developer.
37
To define multiple knowledgebases 1

Create an additional knowledgebase. Alternatively, if HaleyAuthority is already open, then from the application-level File menu, choose New, enter the name for your new database in the Filename window, and then click OK.
Import objects to the additional database. For more information, see Importing Siebel Objects into HaleyAuthority on page 48
In the Siebel client in which you deployed the knowledgebase, navigate to the AdministrationBusiness Rules screen, then the Business Rule Knowledgebase view. The list of knowledgebases that are deployed to the run-time environment are displayed.
Deleting a Knowledgebase
This task is a step in Process of Setting Up the Knowledgebase on page 34. You can delete a HaleyAuthority knowledgebase that is deployed to the run-time environment.
To delete a knowledgebase 1 2 3
In the Siebel client in which you deployed the knowledgebase, navigate to the AdministrationBusiness Rules screen, then the Business Rule Knowledgebase view. In the Business Rule Knowledge Base tree, choose the knowledgebase you must delete. Deactivate modules in the Rule Modules list. To deactivate a rule module, right-click the rule module name, then choose Deactivate Module.
4 5
In the Business Rule Knowledgebase form, click the Menu button, then choose Delete Record. Click OK in the confirmation dialog box. The knowledgebase is removed from the tree and the run-time environment.
Log out of the Siebel client then restart it.
38
Configuring the Development Environment Migrating Rules Between Environments
Migrating Rules Between Environments

To migrate rules between environments, you can perform the tasks described in this topic: Migrating Knowledgebase Data Between Environments on page 39 Migrating Run-Time Data Between Environments on page 40 Migrating Run-Time Data with Application Deployment Manager on page 42
TIP: It is recommended that you migrate a knowledgebase and run-time data from one source environment to the target environment to minimize the chance of errors. This topic emphasizes the one-to-one migration, but provides requirements and guidelines for migrating data from more than one source environment. For more information about: When to perform the work described in this topic, see Data Migration Between Environments on page 33 The context in which migration is performed during a typical development effort, see Migrating a Rule Module on page 63
Migrating Knowledgebase Data Between Environments

You can migrate the concepts and relations in a knowledgebase to a new knowledgebase or to an existing datasource by using the Backup utility in HaleyAuthority. You cannot use the Backup utility to migrate a knowledgebase to a datasource that contains existing knowledgebase tables. Thus two developers cannot both back up their local knowledgebases to the same target environment. Only one can do so. Subsequent objects must be imported manually to the target knowledgebase. TIP: To better control backups, it is recommended to restrict access to systems on which the development environment resides in a way that negates the possibility of multiple developers backing up to the same target environment. Note that you can also use the Backup utility to roll back a knowledgebase to an earlier state.
To migrate knowledgebase data between environments 1 2 3

Open the source knowledgebase in HaleyAuthority. From the application-level menu, choose the Tools menu, then the Backup menu item. Choose one of the following options:

Into New HaleyAuthority knowledgebase. Choose this option to make a local copy of the knowledgebase as a new Microsoft Access knowledgebase. Into existing ODBC Data Source. Choose this option to migrate the knowledgebase data to a new target environment on a database server.
39
Save the knowledgebase to the target environment:

If you are backing up to a new knowledgebase, then specify that knowledgebase file and location in the Specify HaleyAuthority knowledgebase dialog box. If you are backing up to an existing ODBC datasource, then choose the target datasource in the Knowledgebase selection dialog box.
Note that you cannot back up to a datasource that includes existing knowledgebase tables, with or without data. An alternate method of migrating knowledgebases from multiple sources is to manually import the objects in serial sessions instead of backing up the first knowledgebase. For more information, see Importing Siebel Objects into HaleyAuthority on page 48.
Data Migration for Multiple Developers

After a developer migrates data the first time for a knowledgebase, subsequent developers who must migrate their HaleyAuthority knowledgebase objects to the target HaleyAuthority knowledgebase must manually import those same Siebel objects to the target HaleyAuthority knowledgebase. Multiple developers cannot concurrently import objects to a knowledgebase. If a developer attempts to import objects while an import is in progress, then a message displays.
Migrating Run-Time Data Between Environments

This topic describes techniques to migrate run-time data from one environment to another. Use one of the following techniques: Migrating Run-Time Data with Export and Import Utilities on page 40 Migrating Run-Time Data with Application Deployment Manager on page 42
Data migrated includes Object Importer metadata and run-time data, such as rule modules and rule statements.
Migrating Run-Time Data with Export and Import Utilities

You can use the Export and Import utilities in your Siebel application to migrate run-time data and other Object Importer metadata to a target environment. This data is used at run time. This technique is intended for migrating small numbers of rules to a single target environment. Run-time data is exported to XML files from a source run-time datasource. The XML file is imported to the target run-time datasource.
40
Guidelines for migrating rule modules include: If you must migrate rule modules from multiple environments, then make sure the name of each module is unique within the entire collection of modules that is migrated to the target environment. CAUTION: Modules overwrite current data. A migrated module overwrites a module that was written earlier when these two modules possess the same name. Only the state of the earlier module in the target environment is preserved. This state information can include inactive or active, and the administrative settings in the Siebel Rule Module Administration views. To promote consistency, make sure the repository for the source datasource is identical to the repository for the target datasource. The semantic role model on which imported rule modules are based must be consistent with the Siebel Repository for the target datasource.
Migrating Run-Time Data with the Export Utility You can use the export utility to migrate run-time data.
To migrate run-time data with the export utility 1 2 3

In your Siebel application, navigate to the Administration-Business Rules screen, then the Business Rule Knowledgebase view. In the Business Rule Knowledge Base tree, choose the knowledgebase from which you must export run-time data. In the menu for the Rule Modules list, choose Export Selected Modules. An XML file with the exported rule modules is created.
4 5
Save the file. Repeat Step 1 through Step 4 in each run-time environment from which you must export a rule module.
Migrating Run-Time Data with the Import Utility You can use the import utility to migrate run-time data.
To migrate run-time data with the import utility 1 2 3 4 5

In the Siebel client, navigate to the Administration-Business Rules screen, then the Business Rule Knowledgebase view. In the Business Rule Knowledge Base tree, choose the knowledgebase to which you must import run-time data. In the menu for the Rule Modules list, choose Import Selected Modules. In the Import Modules dialog box, browse to choose an XML file that was exported from the source run-time datasource. Repeat Step 3 and Step 4 for each XML file that was exported from the source run-time datasource.
41
If the rule module is already deployed to the target environment, then an import preserves the rule module state in the target environment. In other words, if the existing rule module of the same name in the target environment is in an active state, then the imported rule module is in an active state. If an imported rule module does not include a rule module of the same name already deployed in the target environment, then the imported rule module assumes the state it had when it was exported from the source environment. In other words, if the rule module was in active state when it was exported, then it assumes active state when it is imported. If you are using the Siebel Developer Web Client, and if a new rule module in a knowledgebase is deployed, then you can use Reload All Modules to delete the rule module from the knowledgebase cache. For more information, see Activating a Rule Module on page 57.
Migrating Run-Time Data with Application Deployment Manager

This topic provides information for using Application Deployment Manager (ADM) to migrate business rules. For more information, see Siebel Application Deployment Manager Guide.
Overview of Migrating with Application Deployment Manager

ADM is the framework that automates the migration of enterprise customization data from one Siebel environment to another. Situations in which you typically use ADM to migrate data include: Large amounts of data must be migrated Rules and other Siebel data must be migrated concurrently Data to multiple servers must be migrated
For migrating a small number of rules, the Import and Export features in HaleyAuthority is sufficient. However, Import and Export are not practical for migrating every component of a particular customization that includes rules and other Siebel data. Such customizations can include migrating rules, as well as objects, such as business components, views, and Lists Of Values (LOVs). In this scenario, you can use ADM to create packages and deploy customizations efficiently. Note that when the term deployment is used in the context of ADM, deployment is not referring to the act of moving rule statements and modules from HaleyAuthority to the Siebel run-time environment. For more information, see Siebel Deployment Plug-In on page 15. The business rule is a predefined ADM data type that is intended for use in migrating business rules run-time data.
42
Guidelines for Migrating with ADM

Guidelines to follow when you use ADM to migrate rule modules include: Make sure the source and target environments include identical knowledgebases. Make sure that most, if not all, existing rule modules in the target environment also exist in the source environment, whether modified or not modified. It is assumed that the source and target environments for the migration are derived from a common environment. Exporting the semantic role model from the source to the target environment replaces the model in the target environment. Thus, after migration, the model required in the target environment is essentially updated with no deficiencies for rule modules that existed in the target environment, but not in the source environment, before migration. If the semantic role model is replaced in the target environment during migration, then the Inconsistent flag might be set to Y for a rule module that existed in the target environment but not in the source environment. This flag is displayed in the Rule Modules list in the Administration-Business Rules screen in the Siebel client. You must resolve inconsistencies in the rule module with the new model in HaleyAuthority and redeploy the rule module from HaleyAuthority to the Siebel run-time environment. For more information, see Activating a Rule Module on page 57. If the status of a module must not be Active, then deactivate the module. After migration, the Active status for a module is displayed in the Rule Modules list in the Administration-Business Rules screen. For more information, see Rule Module Reconfiguration and Deactivation on page 206.
Migrating Run-Time Data with ADM

You can use ADM to migrate run-time data.
To migrate run-time data with ADM 1 2

In the Siebel Client, navigate to the Application Deployment Manager screen, then the Deployment Projects view. Create a new deployment project.
Your entry in the Deployment Filter field, as described in Step 3, determines which rule modules are exported in this project. There are two options:

To override the Deployment Filter for a particular deployment session, check the Session Configurable field. To prevent a session level override of the filter, leave Session Configurable unchecked.
No entries are necessary for the Target System and Target User Name fields.
In the lower applet, create a deployment filter to filter for the subset of rule modules to export.

For the Data Type Name field, enter Business Rule. For the Deployment Filter field, see Guidelines for Setting the Deployment Filter Field on page 44.
Back up rule modules in the target environment.
43
Import the rule modules, activate, then restore the rule modules in the same way as with other ADM data types. NOTE: If restoring a rule module, then new rules that are inserted during the import are deleted. To change this behavior, modify the ADM registry by changing the value of the DeleteNewObjects property to N.
Check the states of the updated modules, and activate or deactivate the modules, as required. Depending on the parameters you set in ADM, the Active or Inactive state of an imported module cannot be the same state as the module that the imported module updates. A migrated module is in the Active state provided the Activate step of the ADM migration process is invoked. If the Activate step is not invoked, then the states for the modules before migration are preserved after the migration. For more information, see Activating a Rule Module on page 57.
Guidelines for Setting the Deployment Filter Field

You can specify a search specification for the Deployment Filter field. You must enter the search specification manually. The syntax supported by the Business Rule ADM data type to implement a field level search specification on the Rule Module business component includes: [Field Name] operator 'Filter_Criterion' -model Setting the Model Flag The optional -model flag specifies to export the chosen rule modules without exporting the semantic role model for the source environment. Guidelines for setting the model flag include: If the semantic role model exists in the run-time data for the target environment, and if it is identical to the semantic role model in the run-time data for the source environment, then you should append the specification with the -model flag. For this example, it is not necessary to replace the run-time semantic role model for the target environment, so setting -model increases migration performance. For example, to export only rule modules whose Name field begins with Pharma, without the model, enter: [Name] like 'Pharma*' -model If the semantic role model in the target environment differs from the semantic role model in the source environment, such as when no rule modules are yet deployed in the target, then you must export rule modules from the source with the model. To do so, leave the Deployment Filter field empty, or enter: [*] NOTE: You must not export a subset of rule modules with the model. In other words, a filter specification, such as the following example, is not valid: [Name] like 'Pharma*'
44
Deployment Filter Examples Table 2 provides example configurations for deployment filter usage.
Table 2. Scenario
Example Configurations for the ADM Deployment Filter Example Filter to Use [Knowledgebase name] = 'Pharma_KB'
To export rule modules that belong to the 'Pharma_KB' knowledgebase including the Pharma_KB model. To export only the rule modules, excluding the model, that belong to the 'Pharma_KB' knowledgebase. To export a field of the Rule Module business component.
[Knowledgebase name] = 'Pharma_KB' -model
[Data Assertion Mode] = 'For Each' and [Knowledgebase Name] = 'Pharma_KB' -model
45
Configuring the Development Environment Guidelines for Configuring the Rules Development Environment
Guidelines for Configuring the Rules Development Environment

Table 3 describes guidelines for configuring and maintaining your rules development environment. Table 3. Guidelines for Configuring and Maintaining Your Rules Development Environment Explanation Your edited or added relations might not be consistent with the Siebel object model. Deleting a knowledgebase deletes the knowledgebase tables in the run-time database to which the knowledgebase points. If you import objects for the new knowledgebase, then the run-time data created for the original knowledgebase is deleted, making the original knowledgebase useless. This guideline is an extra precaution to protect against data corruption. If the concepts, relations, or phrasing for the imported Siebel objects are modified or deleted, then the knowledgebase is not supported. For more information, see Technical Support for Business Rules on page 218.
Guideline Do not use a knowledgebase to update more than one run-time database. Do not delete a knowledgebase.
Run only one knowledgebase on a run-time database. In other words, do not create a new knowledgebase on a run-time database to which another knowledgebase points. Back up run-time tables nightly using an SQL tool. Never modify or delete HaleyAuthority concepts, relations, or phrasing manually, especially objects created by the Siebel Object Importer.
46
Developing Siebel Business Rules
This chapter provides information on creating, testing, and deploying business rules in HaleyAuthority. It includes the following topics: Process of Developing Business Rules on page 47 Guidelines for Creating a Rule Module and a Rule Statement on page 66
Process of Developing Business Rules

This process is a step in Roadmap for Developing Business Rules on page 21. To develop business rules, perform the following tasks:
1 2 3 4 5 6 7 8 9
Importing Siebel Objects into HaleyAuthority on page 48 Creating a Rule Module on page 50 Creating a Rule Statement on page 51 Testing a Rule Module on page 52 Deploying a Rule Module on page 56 Activating a Rule Module on page 57 Implementing Business Rules on page 59 Verifying Business Rule Functionality on page 62 Migrating a Rule Module on page 63
10 Administering Business Rules on page 63

In some situations, the order in which this work is performed can vary from project to project, and can be performed interchangeably for a project. For example, creating rules in HaleyAuthority and creating a workflow process in Siebel Tools are independent and might be performed in either order.
47
Developing Siebel Business Rules Process of Developing Business Rules
Importing Siebel Objects into HaleyAuthority

This task is a step in Process of Developing Business Rules on page 47. You import Siebel object definitions from the Siebel Repository to create a rule module that reflects the business logic. Example object definitions include definitions for business objects, business components, and fields. When you import specific definitions on which to build business rules, Siebel Object Importer automatically creates HaleyAuthority concepts and relations to represent those objects. The first time you perform an import of Siebel objects for a new HaleyAuthority knowledgebase, the minimal set of HaleyAuthority objects required to implement business rules in a Siebel application are implicitly defined. If this is your first import of Siebel Objects to the knowledgebase, then you must provide connectivity parameters to the Siebel Repository and run-time database before you import Siebel objects. For more information, see Defining Connectivity to the Knowledgebase on page 35. For more information about: Mapping between objects, see Mapping Between Siebel and HaleyAuthority on page 159 Maintaining mapping, see HaleyAuthority Knowledgebase and Siebel Repository Consistency on page 19 Tables that store rules data, see Business Rule Tables in a Siebel Run-Time Database on page 178
To import Siebel objects into HaleyAuthority 1

Launch HaleyAuthority. For more information, see Launching HaleyAuthority on page 36.
In HaleyAuthority, from the application-level menu, choose the File menu, Import, then the Siebel Object menu item. The Wizard for the Siebel Object Importer launches.
3 4
From the Wizard Welcome screen for the Siebel Object Importer, click Next. In the Wizard-Master Repository dialog box for the Siebel Object Importer, enter connection parameters for the repository and the run-time database for the repository, then click Next. This repository is typically the database where the developer checks in and checks out objects that are defined in Siebel Tools.
Provide connection information for the Siebel Repository database and run-time datasource:
Specify or browse to the Siebel application cfg file that points to the appropriate database. For more information, see Locating the Application Configuration File on page 50.
b c d
Enter the login credentials for the appropriate database. Choose the datasource: ServerDataSrc, GatewayDataSrc, Sample, or Local. In the Runtime Connection-Option dialog box, choose Server or Local mode.
48
If the Runtime Knowledgebase dialog box is displayed, then enter a unique Runtime Knowledgebase Name for this HaleyAuthority knowledgebase, then click Next. If this is the first import of Siebel objects to this knowledgebase, then the Runtime Knowledgebase Name dialog box is displayed. This dialog box displays the knowledgebase names that already exist in the run-time database. You must enter a name that is different from the knowledgebase names displayed in the list. When you specify this name, you are providing a knowledgebase context in which subsequent object import actions are performed. Note that this dialog box provides the mechanism for defining multiple knowledgebases.
7 8
In the Pick Task screen, click the Import Siebel Objects radio button, then click Next. From the Pick Business Object screen, choose one business object from the picklist, then click Next. The Pick Business Components screen displays, which lists the hierarchy of business components of the business object you chose. If you import a business component or field that is already imported, then Siebel Object Importer does not create duplicate concepts.
Click the check box for each business component of this business object that you must import. Click the expansion icons, choose the child business components, then click Next. The Pick Business Component Fields screen displays and lists the fields of the first business component that you chose in this step. If you expand a business component to choose a child business component, then the parent business component for the child is automatically chosen. You can import different fields for a business component by importing the business component more than one time, adding new fields in subsequent imports.
10 In the Available Fields list, click each field you must import, then click Next.
Click the right arrow to move the chosen fields to the Selected Fields list, or click the double right arrow to move every available field. The fields for the next business component you chose in Step 9 display in the Available Fields list.
11 Repeat step Step 10 to choose fields for each business component you chose in Step 9. 12 Click Finish to import the hierarchy.
The Finish screen illustrates the hierarchy of the business object, business component, and fields to be imported. For more information, see Phrasings Generated During Import on page 50. If data is found, then a message warns you that the run-time tables will be cleared. For more information, see Knowledgebase Overwrite on page 50.
13 To import more objects, click Yes. Otherwise, click No.

The Output screen displays a log file of the concepts, relations, and dictionary objects automatically created in HaleyAuthority. Note that, for Multi Value Fields (MVFs), concepts are created for the target business component of the MVF and for the primary of the MVF. For more information, see Concepts and Relations Created for a Multi Value Field on page 165.
14 In HaleyAuthority, click the Concepts tab, then click Entity.

A new entry near the end of the list is displayed with the form [kb_name], that includes the name of the knowledgebase you created.
49
Locating the Application Configuration File You can locate the configuration file used for the Siebel application.
To locate the application configuration file 1

Log into the machine where the Siebel Server is installed. If you are using a local database, instead of logging into the server machine, log into the machine where the application, such as Call Center, is installed.
2 3
Open Windows explorer. Navigate to the language directory.
a b 4
If on the server machine, then navigate to the \BIN\[language] directory in your Siebel Server root directory, where language is the language code. For example, ENU. If on the client machine, then navigate to the Siebel client root directory. For example, D:\Siebel\81\21031\MWC\BIN\ENU.
Locate the configuration file. For example, uagent.cfg or siebel.cfg.
Phrasings Generated During Import

After performing the procedure in Importing Siebel Objects into HaleyAuthority on page 48, if you expand the concepts hierarchy, then phrasings are displayed that you can use with the natural English language editor for HaleyAuthority to reference the imported business components and their fields with your rule statements. These phrasings are generated automatically by the Siebel Object Importer and represent the relations between the business components imported and their business component fields. The phrasings are of the form a business component name has a field name. For example, an opportunity has a revenue.
Knowledgebase Overwrite
When you import objects the first time to a knowledgebase, Siebel Object Importer verifies that the run-time tables do not contain preexisting data, such as data that might exist from another knowledgebase. If data is found, then a message warns you that the run-time tables will be cleared. If you affirm, then the run-time tables are cleared. Do not affirm unless you must abort an existing knowledgebase that accesses the run-time knowledgebase.
Creating a Rule Module

This task is a step in Process of Developing Business Rules on page 47. You implement business rules to make decisions and, if appropriate, execute logic. To build business rules from business logic, you first identify the actions or decisions that constitute the final product of the business logic, then work backward to build the conditions to evaluate and entities and relations on which the conditions are built.
50
To develop the business logic, you translate logic requirements identified in Specifying Business Process Logic Requirements on page 26 into modules that consist of rule statements, using the natural language conventions of the HaleyAuthority authoring environment. For important information about creating a rule module, see Rule Modules and Rule Statements on page 204.
To create a rule module 1

In HaleyAuthority, navigate to the Modules and Statements View. If the Modules and Statements tab is not available, then from the application-level menu, choose the View menu, Tabs, then the Modules and Statements menu item.
2 3
Choose the Modules and Statements folder in the explorer, choose Object, then choose Add a module. Enter a name for the module. Naming restrictions include:

The module name cannot include special characters, such as an asterisk (*), question mark (?), slash mark (/), exclamation point (!), at sign (@), or quotes ( or ). The module name cannot include a Windows reserved word, such as CON, COM1, LPT1, AUX, or NUL. However, the module name can include a reserved word as a substring in the name. For example, Consulting SRs is acceptable, but Con alone is not acceptable. The entire module name must consist of fewer than 100 characters.
(Optional) Add a submodule:
a b c
Choose a module. From the application-level menu, choose the Object menu, then the Add a Submodule menu item. Name the submodule.
You can repeat this procedure to add more modules and submodules, as required.
Creating a Rule Statement

This task is a step in Process of Developing Business Rules on page 47. A rule statement is added to an existing rule module in HaleyAuthority by using the Modules and Statements view. For important information about creating a rule statement, see Rule Statements on page 207.
To create a rule statement 1 2

In the Modules and Statements view, choose the module or submodule. From the application-level menu, choose the Object menu, then the Add a statement menu item.
51
In the Edit statement dialog box, type in a statement. For more information, see Guidelines for Writing a Rule Statement on page 210.
Edit the syntax until the entire statement is bold and the not understood message changes to understood. A rule module that includes a rule statement that is not understood cannot be deployed. For more information, see Draft Statement on page 208.
Click OK. Alternatively, you can click OK, then return later to correct the statement.
(Optional) Add applicability statements:
a b c
Right-click the statement. Choose Is Applicable > If. In the Edit Statement dialog box, type in the statement or pick the components for the statement, then click OK.
The IF applicability statement establishes conditional logic for the rule. If the IF applicability condition is true, then the statement executes. If you use a quoted string in the applicability statement to identify a field value, then the string must be identical to the field value to which it is compared. The comparison is case sensitive and space sensitive. For example applicability statement usage, see Creating the Rule Module on page 90. For a description of applicability statements, consult the HaleyAuthority documentation.
Testing a Rule Module

This task is a step in Process of Developing Business Rules on page 47. You can use the Siebel Test Harness in HaleyAuthority to test your rules in a simulation environment before deploying the rule module. For this topic, assume your knowledgebase includes the following statements defined as part of a rule module named SR Priority: if a service request does not have a priority then set Priority of the service request to 3-Medium if the priority of a service request is 1-ASAP then set Recommendation of the service request to Escalate You begin by configuring the Siebel test harness. For more information, see Siebel Test Harness on page 215.
Configuring the Siebel Test Harness

The first time you perform a test in HaleyAuthority you must configure the Siebel test harness. For subsequent tests, you are not required to configure the test harness again. Instead, you can use the configuration that is completed in this topic.
52
To configure the Siebel test harness 1 2 3 4

In HaleyAuthority, from the application-level menu, choose the Tools menu, then the Options menu item. Click the Tests & Cases tab. In the Test dll window, make sure Siebel Test Harness is chosen. Adjust output reporting. During Siebel Test Harness execution, a series of messages containing information about the current test displays in a separate test harness output window. You can adjust the level of output reporting by enabling or disabling the components listed in the output window.
Make sure connectivity with the run-time environment is established. Siebel Test Harness acquires connectivity information, such as connect string, user name and datasource, from the information you provided when importing objects to HaleyAuthority. For details about establishing connectivity, see Importing Siebel Objects into HaleyAuthority on page 48.
Next, create a test case.
Creating a Test Case

This topic describes how to create a test case.
To create a test case 1

In HaleyAuthority, click the Tests & Cases tab at the bottom of the screen. The Tests & Cases window displays.
2 3
Right-click the Test Cases folder, then choose Add a Test Case. In the Edit Test Case dialog box, enter a name for the test case in the Description field, then click OK. SR Priority is an example of a test case name you can enter.
Next, create an example instance for the test case.
Creating an Example Instance for a Test Case

After creating a test case, you create instances of concepts that serve as simulated data on which the rules act.
53
To create an example instance for a test case 1

Click the Concepts tab at the bottom of the screen. The Concepts window displays.
2 3 4 5 6
Expand the entity concept. Locate, then right-click a concept for which you must create an instance. Choose Add, then choose An Instance Or Example. For this example, choose the service request entity. In the instance dialog box, enter the following entries, then click OK:

A label for the instance. For example, test_sr_1. Make sure the This is An Example For Testing Purposes Only check box includes a check mark, then click OK. Note that the Instances folder under service request now includes the test_sr_1 instance.
7 8 9
Expand the Instances folder under the service request entity. Note that test_sr_1 is added as an instance. Right-click test_sr_1, choose Properties, then click the Facts tab. To add a fact to your instance, click the New icon, then choose a phrasing for your fact. For example, test_sr_1 has a priority. For the priority value, type 1-ASAP in the priority field, then click OK. Click OK again to close the Properties dialog box. NOTE: If the associated property includes a value, then add a fact to the instance. For example, to test using a service request instance that does not include a priority value, do not add a has a priority fact to the instance. Note that the New icon is square and yellow.
10 Associate the applicable test cases with the instance.

For example, right-click the test_sr_1 instance, choose Test Cases, click the SR Priority check box, then click OK. TIP: Alternatively, you can add an example instance to a test case by right-clicking the test case in the Tests & Cases window, then choosing Examples.
11 (Optional) Repeat Step 3 through Step 10 for each additional concept.

You must create an example instance for each concept that the rules reference. Because this example is intended to act on one service request at a time, you must associate only one service request at a time with this test case. Next, run the test case.
54
Running the Test Case

This topic describes how to run the test case.
To run the test case 1

Click the Tests & Cases tab. The Tests & Cases window displays.
Locate, then right-click the applicable test case. For example, SR Priority.
3 4 5
Choose Test Case. In the HaleyAuthority Enterprise dialog box, click Yes to deploy your logic. In the Deploy Configuration dialog box, make the following entries, then click OK:
a b
Accept the default of the Deploy check boxes checked for all modules. TIP: To improve performance, you can uncheck other modules that are not part of your test. Enter or browse to a directory for the deployed module. For example, D:\temp. The Siebel Test Harness dialog is displayed with connection information you provided when importing objects. Note that the directory you specify possesses no persisting value, and does not affect the eventual run-time database to which the module is deployed.
6 7
Click Next. In the Siebel Test Harness dialog box, choose the module you must test from the List of Modules defined in HaleyAuthority. For example, SR Priority.
Make sure the Select All Rule Modules check box does not include a check mark, then click OK. This step logs you in to the run-time database so that the Siebel Test Harness can acquire metadata about the run-time environment. After you click OK, the test case executes.
Next, examine test results, then run more tests.
55
Examining Test Results

This topic describes how to examine test results.
To examine test results 1

Examine data displayed in the Output Window. For this example, only one statement displays because none of the other conditions for the statement are satisfied: 1 if the priority of a service request is 1-ASAP then set Recommendation of the service request to Escalate Note that only statements that are executed are displayed. For more information, see Test Harness Output Window on page 215.
Test other conditions of your rule module:

Modify other example instances, then rerun the test. You can create a new example instance, disassociate the existing instance from the test case, and associate a new instance with the case. For this example, associate only one service request instance at a time with the test case.
For this example, you could create subsequent service request example instances, then test them one at a time after disassociating the test_sr_1 instance from the SR Priority test case.
Deploying a Rule Module

This task is a step in Process of Developing Business Rules on page 47. In order for a rule module to be available in the Siebel application, the rule module must first be deployed from HaleyAuthority to the Siebel run-time environment. When a rule module is deployed, it is visible and available in the Rule Modules list of the Administration-Business Rules screen in the Siebel client. The Siebel Deployment plug-in points by default to the run-time datasource that was specified in the Siebel Object Importer session you ran for the HaleyAuthority knowledgebase. For more information, see Guidelines for Deploying a Rule Module on page 205.
56
To deploy a rule module 1 2 3

In HaleyAuthority, from the application-level menu, choose the Tools menu, then the Siebel Deployment menu item. In the Siebel Deployment dialog box, in the List of Modules, choose one or more modules to deploy. Specify whether or not to update the model by checking or removing the check mark in the Update Model check box. If you choose to update the model, then this step logs you in to the run-time database and deploys the rules definitions to the run-time tables. For more information, see Guidelines for Using Update Model on page 57.
4 5
Click OK. From the application-level menu, choose the File menu, then the Exit menu item to exit out of HaleyAuthority.
Guidelines for Using Update Model

Guidelines for checking or not checking the Update model check box include: If you changed your HaleyAuthority semantic role model since the last deployment of a rule module, then it is recommended that you check the Update model check box . For example, if you imported new fields or if you performed a synchronization with the Siebel Repository, then check the Update model check box. Choosing this option loads the updated, compiled semantic role model from HaleyAuthority to the run-time database. Note that the semantic role model includes the entire set of concepts and their relations. For more information, see HaleyAuthority Knowledgebase and Siebel Repository Consistency on page 19. If the semantic role model has not been updated since the last rule module deployment, then you can uncheck the Update model check box. However, for a little performance overhead, it is likely worth leaving Update model checked when you deploy.
Activating a Rule Module

This task is a step in Process of Developing Business Rules on page 47. You can activate a deployed rule module.
To activate a rule module 1 2 3

Log in to the Siebel client in the same run-time environment to which you deployed a rule module. Navigate to the Administration-Business Rules screen, then the Business Rule Knowledgebase view. In the Business Rule Knowledge Base tree, choose the knowledgebase to which you deployed the new rule module.
57
In the Rule Modules list, locate the rule module you must configure. If the module is not listed, then it might not yet be deployed from HaleyAuthority, or you might be logged in to a different datasource from the one that you ran when you configured the module in HaleyAuthority. TIP: To view run-time database connect information, from the application-level menu in HaleyAuthority, choose the Tools menu, then the Siebel Deployment menu item. Note the connect information, such as the Connect String, User Name, and Runtime Knowledgebase Name, then click Cancel to close the dialog box.
In the Business Object field, pick the business object to which this rule module applies. This is the same business object from which you imported objects for this module. NOTE: If the Inconsistent (read-only) field includes a value of Y, then you must abort this procedure, resolve the inconsistency for the rule module in HaleyAuthority, then redeploy the rule module from HaleyAuthority. For more information, see Rules Configuration and Activation Troubleshooting on page 219.
In the Data Assertion Mode field, pick one of the following values:

For All. Choose this option to assert every input data set at one time, which is the default choice. For Each. Choose this option to assert one input data set at a time. Because only one input data set is in working memory at a time, this option minimizes the footprint of the working memory of the Siebel Rules Engine.
For more information, see Performance and the Data Assertion Mode Field on page 206.
In the detail Rule Module Relations list, add a new rule module relation for each relation in the rule module that you are deploying. For each rule module relation, click the Business Component field, then pick a listed relation. For more information, see Guidelines for Adding a Rule Module Relation on page 59.
8 9
Step off the current rule module relation record to save it. In the Rule Modules list, with the appropriate rule module chosen, click the Activate button. After you activate the rule module, you cannot modify the rule module relations. Note that the rule module and the associated relations for the rule module are cached at run time. For more information, see Business Rule Loading and Caching on page 18.
10 Click the Menu button in the Rule Modules list, then choose Reload All Modules to delete the rule
module from the knowledgebase cache. If you are using the Siebel Developer Web Client, and if the rule module you deployed is part of a knowledgebase that includes other rule modules, then you must delete the knowledgebase cache.
58
Guidelines for Adding a Rule Module Relation

Guidelines for adding a rule module relation include: Make sure the rule module relations list includes the unary relation for each top level business component in the rule module. A unary relation is a relationship with no Parent Business Component entry. Make sure the rule module relations list includes the parent and child business component relations for the business components used in the rule module. You can provide more search specifications on the business components for each relation record you create.
Implementing Business Rules

This task is a step in Process of Developing Business Rules on page 47. In this topic, you use a Siebel development tool to implement the business rule logic.
To implement business rules 1

Use a development tool to implement the business rules. Depending on the tool you choose, perform one of the following tasks:

Creating a Script on page 60 Creating a Siebel Run-Time Event on page 60 Creating a Siebel Workflow Process on page 60 Creating a Siebel Task UI on page 61
(Conditional) Calling the Siebel Rules Engine on page 61 If you implement rules in a workflow process, a task UI, or a script, then you must call the Siebel Rules Engine.
Implementing your business rules includes work that varies depending on the Siebel development tool you use. These tools include a run-time event, a workflow process, a task UI, and a script. The work you perform for implementing business rules through a development tool does not vary from the typical work performed when using the tool because the tool you use calls the Siebel Rules Engine. The rules logic is developed in HaleyAuthority, not the development tool. For examples, see Example Business Rule Implementations on page 22.
59
Creating a Script
You can use business rules in a script.
To create a script
Create a script that calls the business rules logic. For more information, see Calling the Siebel Rules Engine on page 61., and Chapter 6, Implementing Rules Through a Script on a Business Component.
Creating a Siebel Run-Time Event

You can implement rules in a run-time event on a business component to accomplish certain outcomes, such as field validation or dynamic setting of field values in which it is not necessary to access the content in the output property set that results from calling the rule.
To create a Siebel run-time event 1 2

Configure an action set to invoke the Business Rule Service with the appropriate rule module. Associate the action set with a run-time event that is supported by the Siebel Rules Engine.
For information about: Configuring rules on a run-time event, see Chapter 8, Implementing Rules Through a Run-Time Event Tracking run-time events, see Siebel Personalization Administration Guide
Creating a Siebel Workflow Process

A workflow process allows you to define a multistep process that can run on a predefined schedule, in response to a run-time event, or when manually initiated. A workflow process might or might not be user interactive.
To create a Siebel workflow process 1 2

Create the workflow process in the Process Designer. Lay out the workflow process:

Set properties for the workflow process, the workflow process steps, and the step connectors. To implement business rules in the workflow process, you must include a business service step. For more information, see Calling the Siebel Rules Engine on page 61.
Create UI elements. For an interactive workflow process, you can add synthetic event controls to an existing view to enhance process navigation.
60
For information about: Configuring rules in a workflow process, see Chapter 7, Implementing Rules Through Declarative Configuration in a Workflow Process Creating a workflow process, see Siebel Business Process Framework: Workflow Guide
Creating a Siebel Task UI

A task UI allows you to define interactions that assist the end user with executing a business process.
To create a Siebel task UI 1

Create the object definition for the task UI:

Lay out the task steps in the Task Editor. Set properties for the task UI, the task steps, and the step connectors. To implement business rules in the task UI, you must include a business service step. For more information, see Calling the Siebel Rules Engine on page 61.
2 3
Create business component and task UI groups. Define the views in which the task UI will be available to the end user. Create UI elements. For a task UI, this step involves creating task views.
Bind the task views to task steps.
For information about: Configuring rules in a task UI, see Chapter 9, Implementing Rules Through a Script in a Task UI Creating a task UI, see Siebel Business Process Framework: Task UI Guide
Calling the Siebel Rules Engine

If you implement rules in a workflow process, a task UI, or a script, then you must call the Siebel Rules Engine. The Siebel Rules Engine is called declaratively. For example, through an input argument in a step for a workflow process. The Siebel Rules Engine can also be called programmatically. For example, through a script on a business service.
61
To call the Siebel rules engine 1

Create a custom business service based on the Business Rule Service. For more information, see Business Rule Service on page 181.
Create a business service step that invokes the custom business service:

If using declarative configuration, then use the input arguments for the step to specify the input hierarchy set. Use the output arguments for the step to process rules output. If using a script, then build the script on the business service that calls the Business Rule Service. If output from the rules is input to other steps, then the script must parse the output property set of the Business Rule Service. If you use a script in other contexts to implement business rules, such as a script on a business component, then the script must call the Business Rule Service.
To pass output from the business service step to other steps, translate the output property set into process properties for a workflow process or task properties for a task UI.
For information about: Calling the Siebel Rules Engine from a script, see Creating the Script on page 73 Calling the Siebel Rules Engine using declarative configuration on a workflow process, see Defining Calls to the Siebel Rules Engine on page 94 Calling the Siebel Rules Engine using a script on a custom business service, see Defining Calls to the Siebel Rules Engine on page 152
Verifying Business Rule Functionality

This task is a step in Process of Developing Business Rules on page 47 In this topic, you verify that the business rules implement the functionality specified in Chapter 3, Designing Siebel Business Rules. Verification is performed in a development run-time environment before rules are deployed to a production environment. With some Siebel development tools you can also perform simulation testing. Calls to the Siebel Rules Engine do not change the technique used to verify business rules functionality, whether implemented through a script, run-time event, workflow process, or task UI.
To verify business rule functionality

Use the Siebel client, Siebel Tools or the Business Service simulator to verify that the business rules implement the functionality specified in Chapter 3, Designing Siebel Business Rules.
62
For information about verifying rules implemented in: The Siebel application, see Verifying Business Rule Functionality on page 118 The Siebel application while in debug mode, seePublishing, Activating, and Verifying the Task UI on page 155 The Siebel application using the Business Service simulator, see Testing the Rule Module on page 143 A workflow process, see Verifying Business Rule Functionality on page 97
For information about: Verifying a workflow process, see Siebel Business Process Framework: Workflow Guide Verifying a task UI, see Siebel Business Process Framework: Task UI Guide Verifying a script, see Siebel eScript Language Reference
Migrating a Rule Module

This task is a step in Process of Developing Business Rules on page 47. After a rule module is activated in the client and functionality is verified, you can migrate it to the production environment. The procedure you perform varies depending on whether you are migrating a small number of rules or a larger set of rules. Because the process described in this chapter is focused on a small set of rules, you can use the Export and Import utilities. For more information, see Migrating Rules Between Environments on page 39.
To migrate a rule module

For examples presented in this book, use the export and import utility to migrate data. For more information, see Migrating Run-Time Data with Export and Import Utilities on page 40.
Administering Business Rules

This task is a step in Process of Developing Business Rules on page 47. To administer business rules, you can perform one or more of the tasks described in this topic: Implicitly Synchronizing the HaleyAuthority Knowledgebase on page 64 Explicitly Synchronizing the HaleyAuthority Knowledgebase on page 64 Reconfiguring or Deactivating a Rule Module on page 65
Administration work for business rules can include activities you normally performed for an implementation of a run-time event, workflow process, task UI, or a script. Work specific to rules can include synchronizing, reconfiguring and deactivating.
63
After synchronizing, a rule statement that was previously understood by HaleyAuthority might become a draft statement. You must edit this statement before redeploying. For more information, see Draft Statement on page 208. For information about situations that necessitate administration, see Business Rule Maintenance on page 18.
Implicitly Synchronizing the HaleyAuthority Knowledgebase

You can synchronize HaleyAuthority concepts with individual Siebel objects by importing the Siebel objects to HaleyAuthority. For example, assume the Type of the Marketing Sub Plans of the Actual Expenses field for the business component is changed from DTYPE_NUMBER to DTYPE_CURRENCY in the Siebel Repository, and you previously imported this business component and field to your HaleyAuthority knowledgebase. You can import the Actual Expenses field.
To implicitly synchronize the HaleyAuthority knowledgebase

Run the Siebel Object Importer. For more information, see Importing Siebel Objects into HaleyAuthority on page 48. In this example, running Siebel Object Importer causes the changes listed in this topic to be made in the HaleyAuthority knowledgebase. Changes that become visible in HaleyAuthority include: If viewed through the HaleyAuthority Concepts hierarchy by clicking the Concepts tab, then the Actual Expenses concept is deleted under quantity > number > decimal number > real number, and under value > number > decimal number > real number.
A new concept, actual expenses, is created in the HaleyAuthority concepts tree under entity: currency value: The relation, marketingsubplans_actualexpenses, is deleted A new relation, marketingsubplans_actualexpenses, is created
To view the added relations, from the application-level menu, choose the View menu, Tabs, then the Full View menu item. Examine the Relations and Procedures hierarchy.
Explicitly Synchronizing the HaleyAuthority Knowledgebase

Objects for which you can synchronize the HaleyAuthority knowledgebase with the Siebel Repository include: Imported Siebel objects Chosen imported Siebel objects
If an imported Siebel object is deleted or modified in the Siebel Repository, then the object is also deleted in the HaleyAuthority knowledgebase and, if appropriate, a new object is created.
64
To explicitly synchronize the HaleyAuthority knowledgebase 1

In HaleyAuthority, from the application-level menu, choose the File menu, Import, then the Siebel Object menu item. The Wizard for the Siebel Object Importer launches.
2 3 4
From the Wizard Welcome screen for the Siebel Object Importer, click Next. In the Login screen, enter database connection parameters, then click Next. Perform the following for each of the Siebel Repository databases and the run-time datasource:
Specify or browse to the Siebel application cfg file that points to the appropriate database. For more information, see Locating the Application Configuration File on page 50.
b c d 5
Enter the login credentials to the appropriate database. Choose the datasource: Server, Sample, or Local. For the run-time data connection, also choose Server or Local mode.
In the Pick Task screen, perform either of the following steps, then click Next:

Click the Synchronize Selected Siebel Objects radio button to synchronize a subset of your imported Siebel objects. Click the Synchronize Entire Model radio button to synchronize your imported Siebel objects.
6 7 8
If you chose to synchronize chosen objects in Step 5, then choose one or more business objects from the picklist on the Pick Business Objects screen, and then click Next. On the Finish screen, click Finish. To perform another import or synchronization on the same database, click Yes. Otherwise, click No. The Output screen displays a log file of the concepts and relations that were updated.
Reconfiguring or Deactivating a Rule Module

As a business process and logic changes in your organization, it might become necessary for you to modify your rules.
To reconfigure or deactivate a rule module

Use the Rule Modules list to reconfigure or deactivate a rule module. For more information, see Rule Module Reconfiguration and Deactivation on page 206.
65
Developing Siebel Business Rules Guidelines for Creating a Rule Module and a Rule Statement
Guidelines for Creating a Rule Module and a Rule Statement

Table 4 describes guidelines for creating a rule module and a rule statement. Table 4. Guidelines for Creating a Rule Module and a Rule Statement Explanation Your edited or added relations might not be consistent with the Siebel object model.
Guideline Do not edit or add relations between the concepts that represent imported Siebel objects in the Concepts tree. When you write a rule statement, consider how the search specification for the business component, if defined, could impact the outcome for the rule statement.
When a rule operates on a business component, it is not aware of the view, so it is not aware of the search specification on the business component in the view. Records displayed in the view are limited to the conditions defined in the search specification on the business component. For example, assume you create a rule statement that evaluates accounts whose revenue is greater than $50,000. Assume the rule is run against records in the account business component where a search specification is defined on the revenue field that limits record display to only those records whose revenue is less than $10,000. In this case, the rule never executes because the search specification excludes records that meet the $50,000 condition for the rule statement. If a field in an applicability statement uses a or an to reference a field, then the Siebel Rules Engine can look for satisfaction of the statement from another record. The following statement applies the applicability statement to the current record only: set "Description" of an opportunity to Active Applicability: if: the status of the opportunity is "Accepted"
To restrict the applicability to the current record, make sure applicability statements include context. In other words, the leading conclusion must use a or an to reference fields, and the applicability statements must use the to reference the fields.
66
Table 4.
Guidelines for Creating a Rule Module and a Rule Statement Explanation There might be multiple modules in your implementation. Structured naming makes identification more efficient. For example, if a rule module is called by a business component run-time event, then you could use the following for the module name: business object_business component_event A rule module that is called by the PreWriteRecord event for the Account business component of the Account business object is then named: Account_Account_PreWriteRecord
Guideline Name the rule module to reflect the context in which the module is implemented.
In a set statement, put double quotes around the name of the field whose value is set. When writing a rule that makes a comparison to a quoted string, be careful to duplicate the quoted string exactly. Before running a test case, add every example instance to the test case that is referenced by the test case.
For example, in the following statement, the Description field is set: if an account does not have a contact then set Description of the account to Needs a contact. A string comparison in a rule is case sensitive and space sensitive. NOTE: The validation that HaleyAuthority performs for a rule checks that the rule statement is understood. It does not verify a quoted string. If some example instances are not added to a test case, then you can receive an inconsistent test result. Some examples include: Example_expense is an example expense Example_expense_item is an expense item Example_expense has example_expense_item is a fact Example_expense is added as an example to sample_test_case, but example_expense_item is not added
Your test results might be inconsistent, because some statements recognize that example_expense_item exists, while others do not. Use log files to troubleshoot plug-in performance. You can use log files to troubleshoot problems encountered when using the Siebel Object Importer plug-in or Siebel Deployment plugin. For more information, see Importer and Deployment Plug-In Log Files on page 16.
67
68
Implementing Rules Through a Script on a Business Component
This chapter describes how to implement business rules through a script. It includes the following topics: Overview of Implementing Business Rules Through a Script on page 69 Process of Validating an Account Through a Script on page 70
Overview of Implementing Business Rules Through a Script

A typical situation to use a script is when you must process data from the output property set of the Business Rule Service to make further decisions, thus allowing a decision to be made programmatically based on the results of rules execution. This decision making technique is useful in Siebel applications, such as a workflow process or a task UI. For more information about: A general approach to designing and developing business rules that reinforces steps performed in this chapter, see Chapter 3, Designing Siebel Business Rules, and Chapter 5, Developing Siebel Business Rules General configuration guidelines, see Guidelines for Implementing Siebel Business Rules on page 216
69
Implementing Rules Through a Script on a Business Component Process of Validating an Account Through a Script
Process of Validating an Account Through a Script

This topic gives one example of how to use business rules to validate an account through a script. You might use business rules differently, depending on your business model. To use business rules to validate account data through a script, perform the following tasks:
1 2 3 4 5 6 7
Designing the Business Rules Implementation on page 70 Importing Siebel Objects on page 71 Creating the Rule Module on page 72 Deploying and Activating the Rule Module on page 72 Configuring the Run-Time Event on page 73 Creating the Script on page 73 Verifying Business Rule Functionality on page 78
Designing the Business Rules Implementation

This task is a step in Process of Validating an Account Through a Script on page 70. In the design phase, you specify business logic requirements.
To design the business rules implementation

Perform design activities. For more information, see Chapter 3, Designing Siebel Business Rules. For this example, assume the business analyst already finished the design work. Therefore, this topic describes the output of the work for the analyst rather than the procedures performed to generate that output.
Business Process Requirements

For this example, a customer support representative creates a new or modifies an existing account record. A rule module includes rules that validate the account name and location before the account record is written to the database. A script is configured to invoke the rule module to: Invoke the Business Rule Service with an appropriate rule module Process the output from the Business Rule Service
70
If a new account record is created or an existing account record is updated, then the validation that must occur before the record is written to the database includes: Disallow an account name that contains internal Require that the account location is entered
Importing Siebel Objects

This task is a step in Process of Validating an Account Through a Script on page 70. For this example, the business logic requirement is implemented in a server script associated with a PreWriteRecord event on the Account business component that makes a call to the Business Rule Service. You begin by importing Siebel objects.
To import Siebel objects 1 2

Create a new knowledgebase named script_test_KB. For more information, see Process of Setting Up the Knowledgebase on page 34. Use the Siebel Object Importer Wizard to import object definitions:
a b c d
In the Runtime Connection-Option dialog box, choose Local. In the Runtime Knowledgebase Name dialog box, enter script_test_run_time_KB for the name. In the Pick Business Object screen, choose the Account business object. In the Pick Business Components screen, pick the Account business component. The business logic for this example is based on the Account business object and the Account business component.
On subsequent screens of the Pick Business Component Fields dialog box, add the Name and Location fields of the Account business component by choosing them in the Available Fields list, then clicking the right arrow to move the chosen fields to the Selected Fields list.
For more information, see Importing Siebel Objects into HaleyAuthority on page 48.
71
Creating the Rule Module

This task is a step in Process of Validating an Account Through a Script on page 70. Next, create a rule module to represent your business logic.
To create the rule module 1

Create a rule module named Account Validation. For more information, see Creating a Rule Module on page 50.
Add the following rule statements to the Account Validation rule module: if an account's name contains "internal" then invalidate the account with "An account name cannot contain internal. Please reenter the account name." if an account's location is unknown then invalidate the account with "You must provide the location for the account." For more information, see Creating a Rule Statement on page 51.
Deploying and Activating the Rule Module

This task is a step in Process of Validating an Account Through a Script on page 70. You must deploy and activate the Account Validation module to the Siebel run-time environment.
To deploy and activate the rule module 1

Use the Siebel Deployment tool to deploy the rule module:
a b
In the Siebel Deployment dialog box, choose Account Validation from the List of Modules list. Make sure the Update model check box includes a check mark.
For more information, see Deploying a Rule Module on page 56.
In the Siebel client, use the Business Rule Knowledge Base screen to activate the rule module:
a b
Set the Business Object of the Account Validation module to Account. In the Rule Module Relations list, create one new record using values in the following table. Field Parent Business Component Business Component Value No entry Account
For more information, see Activating a Rule Module on page 57.
72
Configuring the Run-Time Event

This task is a step in Process of Validating an Account Through a Script on page 70. Because the script in this example is invoked by the PreWriteRecord run-time event, you must configure the PreWriteRecord run-time event on the Account business component in the Siebel client.
To configure the run-time event

In the Siebel client, use the Administration-Runtime Events screen to configure the run-time event, using values in the following table. Applet Action Set Action More Info Event Event Event Event Field Action Set Name Action Name Business Service Context Name Object Name Event Action Set Name Value Account Validation-Scripting Example Account Validation-Scripting Example Rules script_test_run_time_KB:Account Validation Account Validation-Scripting Example Account PreWriteRecord Account Validation-Scripting Example
For more information, see Configuring and Activating the Run-Time Event on page 115,
Creating the Script

This task is a step in Process of Validating an Account Through a Script on page 70. The business logic requirements for this example specifies that the validation must be performed before the record is written to the database. Based on this requirement, a script is associated with a BusComp_PreWriteRecord event. If you must revert to the original configuration after enabling the ST eScript engine and modifying the code to be strongly typed, then you must undo your strongly typed code changes. The ST eScript engine is the default scripting engine. You begin by configuring the ST eScript engine for Siebel Tools.
73
To configure the ST eScript engine for Siebel Tools 1 2 3 4

In Siebel Tools, from the application-level menu, choose the Screens menu, System Administration, then the System Preferences menu item. In the System Preferences window, in the System Preferences Name column, query for Enable ST Script Engine. Set System Preference Value to TRUE. Recompile the Siebel Repository File. For more information about the ST eScript engine, see Using Siebel Tools and Siebel eScript Language Reference. Next, add the script to the Account business component.
To add the script to the account business component 1 2 3 4 5 6

Launch Siebel Tools on the sample database to which you deployed the Account Validation rule module. In the Object Explorer, click the Business Component object type. In the Business Components OBLE, query the Name property for Account. Right-click the Account business component, then choose Lock Object. Right-click the Account business component again, then choose Edit Server Scripts. In the Scripting Language dialog box, choose eScript, then click OK.
74
Choose BusComp_PreWriteRecord in the tree hierarchy, then add the following eScript code to the BusComp_PreWriteRecord function: function BusComp_PreWriteRecord () { //Set up a file to write comments to. var fp = Clib.fopen("c:\\temp\\Scripting_RulesExample.txt", "a"); //Declare the variable that contains the Business Rule Service. var svc:Service = TheApplication().GetService(Business Rule Service"); //Declare the inputs property set variable for Business Rule Service. Declare //child and grandchild property sets used to create //the hierarchical structure of the BusCompList input property. var inputs:PropertySet = TheApplication().NewPropertySet(); var child:PropertySet = TheApplication().NewPropertySet(); var grandchild:PropertySet = TheApplication().NewPropertySet(); //Declare the outputs property set variable for Business Rule Service var outputs:PropertySet = TheApplication().NewPropertySet(); // Fill in data in the input propertyset // <PropertySet RuleModuleName="Account Validation" // GetMoreData="N" // PerformAction="N" // <BusCompList> // <BusComp Id="this buscomp's id" Name="Account"> inputs.SetProperty("KnowledgeBaseName", "script_test_run_time_KB"); inputs.SetProperty("RuleModuleName", "Account Validation"); inputs.SetProperty("PerformAction", "N"); inputs.SetProperty("GetMoreData", "N"); child.SetType("BusCompList"); //Note that this script is associated with PreWriteRecord for the Account business //component, so this is the Account business component. grandchild.SetType("BusComp"); grandchild.SetProperty("Id", this.GetFieldValue("Id")); grandchild.SetProperty("Name", this.Name()); // Add fields for Name and Location var nameField:PropertySet = TheApplication().NewPropertySet(); var locationField:PropertySet = TheApplication().NewPropertySet(); nameField.SetType("Field"); nameField.SetValue(this.GetFieldValue("Name")); nameField.SetProperty("Name", "Name"); nameField.SetProperty("Type", "DTYPE_TEXT"); //Add the Name field as a child of the Account business component. grandchild.AddChild(nameField); locationField.SetType("Field"); locationField.SetValue(this.GetFieldValue("Location")); locationField.SetProperty("Name", "Location");
75
locationField.SetProperty("Type", "DTYPE_TEXT"); //Add the Location field as a child of the Account business component grandchild.AddChild(locationField); //Add the Account business component as a child of the BusCompList property. child.AddChild(grandchild); //Finally, add the BusCompList property (now a complete hierarchy) as a child of //the inputs property set. inputs.AddChild(child); // invoke Business Rule Service svc.InvokeMethod("RunRules", inputs, outputs); // Examine the outputs propertyset which must contain the following var var var var var fp = Clib.fopen("c:\\temp\\Scripting_RulesExample.txt", "a"); nChild = outputs.GetChildCount(); i = 0; resultType; errorText;
// If no result, then the validation passed in this example. if (nChild == 0) { Clib.fputs("Account Validation Succeeded!\n", fp); return (ContinueOperation); } // Parse and process the output property set. In this example, you only look for // RaiseErrorText and ValidationList because you only used those actions in the // Account Validation rule module. for (i = 0; i < nChild; i++) { resultType = outputs.GetChild(i).GetType(); // Process RaiseErrorText result if (resultType == "RaiseErrorText") { errorText = outputs.GetChild(i).GetValue(); Clib.fprintf(fp, "%s\n", errorText); return(CancelOperation); } // Process ValidationList result if (resultType == "ValidationList") { Clib.fputs("Results include ValidationList back!\n", fp); var j = 0; var msg:PropertySet = TheApplication().NewPropertySet(); var valList:PropertySet = outputs.GetChild(i); var valCount = valList.GetChildCount(); var valResult;
76
// Look at each Validation result for (j = 0; j < valCount; j++) { valResult = valList.GetChild(j).GetProperty("Result"); if (valResult != "Valid") { var val:PropertySet = valList.GetChild(j); var msgCount = val.GetChildCount(); var k = 0; for (k = 0; k < msgCount; k++) { Clib.fprintf(fp, "%s\n", val.GetChild(k).GetValue()); } return (CancelOperation); } } } } return (ContinueOperation); }
From the application-level menu, choose the Debug menu, then the Check Syntax menu item. Make edits as necessary. If you paste the script from this guide into Siebel Tools, then it might be necessary to manually replace the opening quote on line four of the script, depending on how your development machine handles the character set.
Save the script, then close the script editing window.
10 Right-click the Account business component, then choose Compile Selected Objects. 11 Restart the Siebel client.
77

This task is a step in Process of Validating an Account Through a Script on page 70. You can verify that the business rules implement the functionality defined in Designing the Business Rules Implementation on page 70.
To verify business rule functionality 1 2

Launch the Siebel client that points to the same datasource that the Siebel Tools that was used to write the script. Make various edits to the Name and Site fields for an Account record. Note that Site is the display name for the Location field of the Account business component.
Review the statements you created in HaleyAuthority. Note that if you attempt to save a record with a name that contains internal, or a name that contains an empty Location field, then the script will write the appropriate text to a file.
78
Implementing Rules Through Declarative Configuration in a Workflow Process
This chapter describes how to implement business rules through declarative configuration. It includes the following topics: Overview of Implementing Business Rules Through Declarative Configuration on page 79 Process of Qualifying an Opportunity Through a Workflow Process on page 80
Overview of Implementing Business Rules Through Declarative Configuration

Beginning with Siebel CRM version 8.1, you can declaratively build the input property set and process the output hierarchical property set in a workflow process or a task UI. The strength of calling a rule module in a workflow process or a task UI is that branching logic is maintained in a declarative form and in a location external to the Siebel application. Siebel Business Rules also allows a workflow process or a task UI to execute more complex logic without requiring a script. The critical requirement for using a rule module in a workflow process or a task UI is that you must include a Business Service step that invokes the rule module. The business service step typically references a custom business service that calls the predefined Business Rule Service. You can use either a script in your custom business service or declarative techniques in your workflow process or task UI to provide input arguments to the Business Rule Service and to process output from Business Rule Service. These input and output arguments might require interpreting process properties or task properties of the business service step. If you must capture output from the Business Rule Service to use in a subsequent workflow process or task UI step, and if you are using a script on the business service, then your script must parse the Business Rule Service output property set, and assign that output to output arguments of the business service step. For more information about: A general approach to designing and developing business rules that reinforces procedures performed in this chapter, see Chapter 3, Designing Siebel Business Rules, and Chapter 5, Developing Siebel Business Rules General configuration guidelines, see Guidelines for Implementing Siebel Business Rules on page 216 Configuring a workflow process, see Siebel Business Process Framework: Workflow Guide
79
Implementing Rules Through Declarative Configuration in a Workflow Process Process of Qualifying an Opportunity Through a Workflow Process
Process of Qualifying an Opportunity Through a Workflow Process

This topic gives one example of how to use business rules to qualify an opportunity through a workflow process. You might use business rules differently, depending on your business model. To use business rules to qualify an opportunity through a workflow process, perform the following tasks:
1 2 3 4 5 6 7 8 9
Designing the Business Rules Implementation on page 80 Defining the Project on page 82 Creating the Child Business Component on page 82 Creating the Workflow Process on page 84 Importing Siebel Objects on page 89 Creating the Rule Module on page 90 Testing the Rule Module on page 91 Deploying and Activating the Rule Module on page 93 Defining Calls to the Siebel Rules Engine on page 94
10 Verifying Business Rule Functionality on page 97 11 Publishing and Activating the Workflow Process on page 99
About the Traversing a Record Set Technique

This example uses a technique known as traversing a record set. Details about the technique are not provided in this book, but can be found in Siebel Business Process Framework: Workflow Guide.

This task is a step in Process of Qualifying an Opportunity Through a Workflow Process on page 80.

Perform design activities. For more information, see Chapter 3, Designing Siebel Business Rules. For this example, assume the business analyst already finished the design work. Therefore, this topic describes the work output of the analyst rather than the procedures performed to generate that output.
80

For this example, a workflow process processes a batch of opportunity records. If the lead quality and probability of the opportunity meet an inconsistency threshold, then a comment is generated in the Sales Objective field. The workflow process is run with the Mobile Web Client running on the sample database. The business process in this example includes:
1 2
Query opportunities for Status set to Accepted. For each record in the result set:

If Quality is 1-Excellent, and Primary Revenue Win Probability is at less than 70%, then set Description to Reconcile lead quality and probability %. If Quality is 2-Very High, and Primary Revenue Win Probability is at less than 50%, then set Description to Reconcile lead quality and probability %.
This process is based on the Opportunity business object and the Opportunity business component.
Business Process Logic Requirements

This business process considers opportunities that include a Status set to Accepted. Expectations from sales management for each opportunity include: If the Lead Quality is excellent, then the Probability %of completing the sale must be at least 70% If the Lead Quality is very high, then the Probability % of completing the sale must be at least 50%
If either of these situations are violated, then either the Lead Quality or the Probability % of the opportunity record must be changed. In addition, a comment is generated in the Sales Objective text box that states that these fields must be reconciled. The business logic refers to fields that appear in opportunity based applets. These fields are Status, Lead Quality, Probability %, and Sales Objective. To implement this example, you apply the logic to fields on the Opportunity business component. Table 5 describes the applet captions and their underlying business component fields that you identify by using Siebel Tools.
Table 5.
Applet Captions and Their Underlying Business Component Fields Underlying Field on Opportunity Business Component Status Quality Primary Revenue Win Probability Description
Applet Field Caption Status Lead Quality Probability % Sales Objective
81
Invocation Requirements
This batch process is run manually or on a preset schedule determined by a sales manager.
Defining the Project

This task is a step in Process of Qualifying an Opportunity Through a Workflow Process on page 80. You can create a new project with which to associate the workflow process, or you can use a predefined project. If you use a predefined project, then you must lock the project before you create the workflow process.
To define the project 1

Make sure the EnableToolsConstrain parameter is set to FALSE. For more information, see Preparing Siebel Tools on page 128.
2 3 4 5 6
In Siebel Tools, in the Object Explorer, click the Project object type. In the Projects OBLE, right-click, then choose New Record. Set the Name property to Business Rule. Make sure the Locked property for the project contains a check mark. Step off the record to save it.
Creating the Child Business Component

This task is a step in Process of Qualifying an Opportunity Through a Workflow Process on page 80. This example uses a technique known as traversing a record set to search for and modify opportunity records for this business case. This technique requires the creation of a child business component that is based on the primary business component. For more information, see Siebel Business Process Framework: Workflow Guide. In this example, the Opportunity business component is the primary, and Opportunity No Link is the child business component. You create the child business component.
82
To create the child business component 1 2 3

In the Object Explorer, click the Business Component object type. In the Business Components OBLE, right-click, then choose New Record. Define properties for the new business component using values in the following table. Property Name Project Class Table Value Opportunity No Link Business Rule CSSBCBase S_OPTY
Accept default values for other properties.
4 5 6
Make sure Opportunity No Link is chosen in the Business Components OBLE. Expand the Business Component object type in the Object Explorer, then click the Field object type. In the Fields OBLE, right-click, then choose New Record to add fields to the Opportunity No Link business component. For each field you add, use values described in the following table. Name Status Quality Primary Revenue Win Probability Description Column STATUS_CD LEAD_QUALITY_CD SUM_WIN_PROB DESC_TEXT Text Length 30 30 Not applicable. 255 Data Type DTYPE_TEXT DTYPE_TEXT DTYPE_NUMBER DTYPE_TEXT
Note that fields in the child business component correspond to fields with the same name in the primary business component. Because fields on the child reference the same table and column as their counterparts on the primary business component, they modify the same records. Next, establish a relationship between the child and the business object for the primary.
83
To establish a relationship between the child and the business object for the primary 1 2 3 4 5 6 7 8 9
In the Object Explorer, click the Project object type. In the Projects OBLE, locate, then click the Oppty project. Make sure the Locked property for the Oppty project contains a check mark. In the Object Explorer, click the Business Object object type. In the Business Objects OBLE, query the Name property for the Opportunity business object. In the Object Explorer, expand the Business Object object type to display the Business Object Component object type. In the Object Explorer, click the Business Object Component object type. In the Business Object Components OBLE, right-click, then choose New Record. Set the BusComp property to Opportunity No Link. Do not specify a link. item.
10 From the Tools application-level menu, choose the Tools menu, then the Compile Projects menu 11 Choose Locked Projects, then compile to the Siebel Repository File that is used by your sample
database. The file is typically: [Siebel client root directory]\OBJECTS\[language]\siebel.srf
Creating the Workflow Process

This task is a step in Process of Qualifying an Opportunity Through a Workflow Process on page 80. This workflow process:
1 2 3
Accepts a record of the primary Opportunity business component, which is not processed. Queries the child Opportunity No Link business component for records whose Status is Accepted. Traverses records in the query result set, applying the business logic.
In this topic, you begin by creating the workflow process.
To create the workflow process 1 2

In the Object Explorer, click the Workflow Process object type. In the Workflow Processes OBLE, right-click, then choose New Record.
84
Define properties for the workflow process using values in the following table. Property Process Name Workflow Mode Business Object Project Value Opportunity Rules Batch Processing Service Flow Opportunity Business Rule
4 5
In the Workflow Processes OBLE, right-click the Opportunity Rules Batch Processing workflow process, then choose Edit Workflow Process. Click and drag steps and connectors from the palette to the canvas until your workflow process resembles the workflow illustrated in the following figure:
Enter names for steps and connectors using the labels displayed in figure in Step 5. Click each step and connector in succession, defining the Name property in the Properties window as you proceed through the workflow process.
Click anywhere on the canvas background to display the Multi Value Property Window (MVPW) for the entire workflow process.
85
Add a new process property record for each of the properties described in the following table.
.
Name Siebel Operation Object Id RuleOutput_Derivation RuleOuput_Validation Result noRecord numAcceptedRecords vRowId
In/Out In/Out In/Out In/Out In/Out None None None
Business Object Opportunity Opportunity Opportunity Opportunity Opportunity Opportunity Opportunity
Data Type String String String String String Number Number
To add a process property, make sure the Process Properties tab is chosen in the MVPW, rightclick anywhere below the Process Properties tab, then choose New Record. Accept default values for properties not described in the table. TIP: To simplify creating a process property, create one process property record then fully define it. Right-click this newly defined process property then choose Copy Record. A new process property record is created with the same values as the original process property. For the new record, modify only those properties that require modification from the original.
From the application-level menu, choose the File menu, then the Save menu item.
Next, define the workflow process steps and connectors.
To define the workflow process steps and connectors 1

Click the Query Primary step, then use the Properties window to define properties described in the following table. Property Business Component Operation Value Opportunity Query
Click the Query Child step, then use the Properties window to define properties described in the following table. Property Business Component Operation Value Opportunity No Link Query
Make sure the Query Child step is still chosen in the process designer.
86
In the MVPW, click the Search Spec Input Arguments tab, right-click, choose New Record, then define properties described in the following table. Property Expression Business Component Filter Business Component Search Specification Value Opportunity No Link Opportunity No Link "[Status] = 'Accepted'" (Enter the Search Specification exactly as shown. The entire specification must be enclosed within double quotes. The search string must be enclosed with single quotes. A space is required before and after the equal (=) sign.) Type Expression
In the MVPW, click the Output Arguments tab, right-click, choose New Record, then define properties described in the following table. Property Property Name Type Output Argument Value NumAcceptedRecords Output Argument NumAffRows
In the MVPW, right-click, choose New Record to add another output argument, then define properties described in the following table. Property Property Name Type Value Value noRecord Literal false
Click the connector labeled Yes, then use the Properties window to set the Type property to Condition.
87
Right-click the Yes connector, choose Edit Conditions, then define a condition using properties described in the following table. Property Compare To Operation Object Value Value Process Property Greater Than NumAcceptedRecords 0
This condition traps for the instance where no records were returned from the query. If this condition is met, then the workflow process follows the No branch. If Query Child returns at least one record whose status is Accepted, then the workflow follows the Yes branch.
Click Add.
10 Define another condition using properties described in the following table.

Property Compare To Operation Object Value Value Process Property All Must Match (Ignore Case) noRecord false
This condition determines when the workflow process reaches the end of the record set in cases where at least one record is Accepted.
11 Click Add, then click OK. 12 Click the Next Record step, then use the Properties window to define properties described in the
following table. Property Business Component Operation Value Opportunity No Link NextRecord
13 Make sure the Next Record step is still chosen in the process designer.
88
14 In the MVPW, click the Output Arguments tab, right-click, choose New Record, then define
properties using values in the following table. Property Property Name Type Output Argument Value NoRecord Output Argument NoMoreRecords
15 In the MVPW, right-click, choose New Record to add another output argument, then define
properties using values in the following table. Property Property Name Type Business Component Name Business Component Field Value vRowId Business Component Opportunity No Link Id
16 Click the connector labeled No, then use the Properties window to set the Type property to
Default.
17 From the application-level menu, choose the File menu, then the Save menu item.

This task is a step in Process of Qualifying an Opportunity Through a Workflow Process on page 80. The business logic requirement is implemented in a business service step that makes a call to the Business Rule Service, which calls a rule module that applies the logic described in Business Process Requirements on page 81.
To import Siebel objects 1 2

Create a new knowledgebase named declarative_test_KB. For more information, see Process of Setting Up the Knowledgebase on page 34. Use the Siebel Object Importer Wizard to import Siebel objects:
Enter the login credentials to the sample database, and choose Sample as the datasource. For this example, the sample database, sse_samp.dbf, is used for both the repository database and as the run-time database. For the run-time data connection, choose Local. In the Pick Business Object screen, choose the Opportunity business object.
b c
89
d e
In the Pick Business Components screen, click the check boxes for the Opportunity and Opportunity No Link business components. On subsequent screens of the Pick Business Component Fields dialog box, add fields using values in the following table. Business Component Opportunity Fields Add the following fields: Description Primary Revenue Win Probability Quality
It is not necessary to choose the Status field. The Status field is used in the query in the workflow process that establishes the record set, but it is not used in the rule module. Opportunity No Link Add the following fields: Description Primary Revenue Win Probability Quality
For more information, see Importing Siebel Objects into HaleyAuthority on page 48.

This task is a step in Process of Qualifying an Opportunity Through a Workflow Process on page 80.
To create the rule module

Create a rule module named Opportunity Batch Processing. For more information, see Creating a Rule Module on page 50. Next, add rule statements to the rule module.
To add rule statements to the rule modules 1

Add the following rule statement to the Opportunity Batch Processing rule module: set "Description" of an opportunity to Reconcile lead quality and probability %. For more information, see Creating a Rule Statement on page 51.
90
Add the following applicability statement to the rule statement you created in Step 1: the quality of the opportunity is "1-Excellent" and the primary revenue win probability of the opportunity is less than 70 1-Excellent must be identical to the field value to which it is compared. The comparison is case sensitive and space sensitive. For more information about applicability statements, see Creating a Rule Statement on page 51.
Add another applicability statement to the rule statement you created in Step 1: the quality of the opportunity is "2-Very High" and the primary revenue win probability of the opportunity is less than 50.
Add the following rule statement to the Opportunity Batch Processing rule module: set "Description" of an opportunity no link to Reconcile lead quality and probability %.
Add the following applicability statement to the rule statement you created in Step 4: if: the quality of the opportunity no link is "1-Excellent" and the primary revenue win probability of the opportunity no link is less than 70
Add another applicability statement to the rule statement you created in Step 4: if: the quality of the opportunity no link is "2-Very High" and the primary revenue win probability of the opportunity no link is less than 50 The applicability statements in Step 5 and Step 6 reference the Opportunity No Link business component rather than the Opportunity business component, thus ensuring only records in the queried recordset are considered.
Testing the Rule Module

This task is a step in Process of Qualifying an Opportunity Through a Workflow Process on page 80. You can use the Siebel Test Harness in HaleyAuthority to test your rules in a simulation environment before deploying the rule module. For more information, see Testing a Rule Module on page 52. To test the rule module in HaleyAuthority, you begin by creating a test case.
To create a test case

Create a test case named Opportunity Rules. For more information, see Creating a Test Case on page 53. Next, create an example instance for the test case.
91
To create an example instance for the test case

Use the Add > An Instance Or Example command to create an example instance for the test case:
a b
In the instance dialog box for the opportunity entity, add example_opportunity for the label. Right-click the example_opportunity instance, choose Test cases, then click the Opportunity Rules check box to associate the test case with an instance. Note that Opportunity Rules is the name of the test case you created earlier in this topic.
Add a fact to the example_opportunity instance by defining the following phrasing: Choose Example_opportunity Has A Quality, then enter 1-Excellent for the quality value.
Add another fact to the example_opportunity instance by defining the following phrasing: Choose example_opportunity has a primary revenue win probability, then enter 69 for the primary revenue win probability value.
e f g
Repeat Step a and Step b to create an instance for opportunity no link, named example_opptynolink. Add a fact to the example_opptynolink instance by defining the following phrasing: Choose example_opptynolink has a quality, then enter 2-Very High for the quality value. Add another fact to the example_opptynolink instance by defining the following phrasing: Choose example_opptynolink has a primary revenue win probability, then enter 49 for the primary revenue win probability value. Do not add example_opptynolink to the Opportunity Rules test case.
For more information, see Creating an Example Instance for a Test Case on page 53. This example is intended to act on one Opportunity or Opportunity No Link record at a time, so associate only one instance at a time with the Opportunity Rules test case. Next, run the test case.
To run the test case

Use the Test Case command to run the test case:
a b c
In the Tests & Cases window, right-click the test case named Opportunity Rules. In the Deploy Configuration dialog box, accept the default values and browse to D:\temp. In the Siebel Test Harness dialog box, choose Opportunity Batch Processing from the list of modules, and make a note of the value in the Runtime Knowledgebase Name field.
For more information, see Running the Test Case on page 55. You require this information later when you activate the rule module in the Siebel client. Next, examine test results and run more tests.
92
To examine test results and run more tests 1

Examine data displayed in the Output Window. An entry of the form Opportunity Rules On [Date And Time] is added to the Test Results folder under Opportunity Rules. Expand this folder to view statements that were executed: 1 if: the quality of the opportunity is "1-Excellent" and the primary revenue win probability of the opportunity is less than 70 1 set "Description" of an opportunity to Reconcile lead quality and probability %.
(Optional) Test other conditions of your rule module:

You can disassociate example_opportunity and associate example_opptynolink with the Opportunity Rules test case to test another aspect of the rule module. Create other instances to test other aspects.
For more information, see Examining Test Results on page 56.

This task is a step in Process of Qualifying an Opportunity Through a Workflow Process on page 80. You must deploy the Opportunity Batch Processing rule module to a Siebel run-time environment for testing. First, you deploy the rule module.
To deploy the rule module

a b
In the Siebel Deployment dialog box, choose Opportunity Batch Processing from the List of Modules. Make sure the Update model check box includes a check mark.
For more information, see Deploying a Rule Module on page 56. Next, activate the rule module.
93
To activate the rule module

a b c
In the Business Rule Knowledge Base tree, choose declarative_test_KB, which is the knowledgebase you created in Importing Siebel Objects on page 89. In the Rule Modules list, choose Opportunity Batch Processing, then set the Business Object to Opportunity. In the Rule Module Relations list, create two new records:

For one record, set the Business Component field to Opportunity. For the other record, set the Business Component field to Opportunity No Link. Make no entry in the Parent Business Component field for either record.
Do not add other records because no child business components of Opportunity are included in the Opportunity Batch Processing rule module.
Make sure you activate the Opportunity Batch Processing rule module.
Defining Calls to the Siebel Rules Engine

This task is a step in Process of Qualifying an Opportunity Through a Workflow Process on page 80. In this topic, you use input arguments and output arguments for the Business Rule Service. For more information, see Business Rule Service on page 181. CAUTION: Except where directed, it is important that you do not modify the predefined Business Rule Service. If your implementation requirements cannot be addressed by the predefined, unmodified Business Rule Service, then create a custom business service that calls the Business Rule Service. This way, a special configuration you define that varies from the Business Rule Service does not impact other objects or processes that also use the Business Rule Service. After the rule module passes the simulation test, you can define calls to the Siebel rules engine. You begin by creating a custom business service.
To create a custom business service 1

Prepare the RunRules method. For more information, see Preparing the RunRules Method on page 182.
Prepare the ProcessOutput method. For more information, see Preparing the ProcessOutput Method on page 183.
In Siebel Tools Object Explorer, choose the Business Service object type, then query the Name property of the Business Services OBLE for Business Rule Service.
94
Right-click Business Rule Service, choose Copy Record, then define properties using values in the following table. Property Name Project Cache Display Name-String Override External Use Value Rules-Opportunity Batch WF Business Rule TRUE Rules-Opportunity Batch WF TRUE
In the Business Services OBLE, right-click the Rules-Opportunity Batch WF business service, then choose Compile Selected Objects.
Next, configure the workflow process to call the Siebel Rules Engine.
To configure the workflow process to call the Siebel rules engine 1 2

In Siebel Tools, navigate to the Workflow Processes OBLE, then query the Process Name property for Opportunity Rules Batch Processing. Right-click the Opportunity Rules Batch Processing workflow process, then choose Edit Workflow Process. The status property of the Opportunity Rules Batch Processing workflow process is In Progress.
In the Process Designer, click the Call Rules Engine business service step, then use the Properties window to define values described in the following table. Property Business Service Method Business Service Name Value RunRules Rules-Opportunity Batch WF
Note that you must specify the Business Service Name first, then the Business Service Method.
4 5
Make sure the Call Rules Engine business service step is chosen. Click the Input Arguments tab in the Multi Value Property Window (MVPW).
95
In the MVPW, add a new record for each of the input arguments described in the following table. Input Argument KnowledgeBaseName RuleModuleName BusCompName GetMoreData PerformAction Type Literal Literal Literal Literal Literal Value declarative_test_KB Opportunity Batch Processing Opportunity No Link Y Y
In the MVPW, add a new record for the input argument described in the following table. Input Argument ID Type Process Property Property Name Siebel Operation Object Id
8 9
Make sure the Call Rules Engine business service is still chosen in the process designer. Click the Output Arguments tab in the MVPW, then add a new record for each of the output arguments described in the following table. Property Name RuleOutput_Derivation RuleOutput_Validation Type Output Argument Output Argument Output Argument DerivationList ValidationList
For more information about arguments defined in this procedure, see RunRules Business Service Method on page 185. Next, configure the workflow process to handle rules output.
To configure the workflow process to handle rules output 1

Click the Process Rules Output business service step, then use the Properties window to define values described in the following table. Property Business Service Method Business Service Name Value ProcessOutput Rules-Opportunity Batch WF
Make sure the Process Rules Output step is still chosen in the process designer.
96
Click the Input Arguments tab in the MVPW, then add a new record for each of the input arguments described in the following table. Input Argument BusCompId RulesEngineOutput Type Process Property Process Property Property Name Siebel Operation Object Id RuleOutput_Validation
In the MVPW, add a new record for the input argument described in the following table. Input Argument TypeOrAttrName Type Literal Value Result
5 6 7
Make sure the Process Rules Output business service step is chosen. Click the Output Arguments tab in the MVPW. In the MVPW, add a new record for the output argument described in the following table.
Property Name Result
Type Output Argument
Output Argument TypeOrAttrValue
For more information about arguments defined in this procedure, see ProcessOutput Method on page 192.

This task is a step in Process of Qualifying an Opportunity Through a Workflow Process on page 80. You can verify that the business rules implement the functionality defined in Designing the Business Rules Implementation on page 80 by simulating the workflow process in a debug instance of your run-time client. Work you might be required to perform includes: Make the Status, Quality, Description, and Primary Revenue Win Probability fields visible in the Opportunity list. Remember that the captions of these fields in the UI are Status, Lead Quality, Sales Objective, and Probability %. Edit or create some new opportunities with Status, Quality, and Primary Revenue Win Probability values that satisfy the rule conditions.
To verify the workflow process in the Siebel client, you begin by making columns visible in a list applet.
97
To make columns visible in a list applet 1 2 3

In the Siebel client, navigate to the Opportunities screen, then the List view. In the Opportunities list, right-click anywhere in the list then choose Columns Displayed. Move fields from the Available Columns list to the Selected Columns list, then click Save. Note that fields are listed by their captioned names: Status, Lead Quality, Sales Objective, and Probability %.
Log out of the Siebel client.
Before running the simulator, make sure your Debug options are accurate and that they point to the run-time client that you specified elsewhere in this example. For information on setting Debug options, see Siebel Business Process Framework: Workflow Guide. NOTE: The paths you enter as Debug options must be specific to your local installation. Note that the workflow process simulator modifies the target database. Next, simulate the workflow process.
To simulate the workflow process 1 2 3

In Siebel Tools, make sure the workflow process is saved. If the Simulate toolbar is not visible, then, from the application-level menu, choose the View menu, Toolbars, then the Simulate menu item. Right-click Opportunity Rules Batch Processing in the Workflow Processes OBLE, then choose Simulate. The workflow process displays with the Start step highlighted.
Click the Start button on the Simulate toolbar, which is the leftmost right arrow. A debug run-time instance of your run-time client starts.
If the Watch window is not visible, then, from the application-level menu, choose the View menu, Debug Windows, then the Watch menu item. The Watch window displays data, such as output argument values as you step through a workflow process. If the Watch window is not already visible, then you cannot open it until you execute the Start step.
6 7
Click the Simulate Next button to step through the process or click the Complete Simulation button to execute the rest of the process. Click the Stop Simulation button to stop the simulation.
For more information on running the workflow process simulator in Siebel Tools, see Siebel Business Process Framework: Workflow Guide.
98
Publishing and Activating the Workflow Process

This task is a step in Process of Qualifying an Opportunity Through a Workflow Process on page 80. Before you can use the Opportunity Rules Batch Processing workflow process, you must publish, then activate it.
To publish then activate the workflow process 1 2

Publish the workflow process from within Siebel Tools. Activate the workflow process in the Administration-Business Process screen of your Siebel application. After the workflow process is activated, you can invoke it manually or set it up to run on a preset schedule. You can also start, stop, and monitor the workflow process in the Administration-Business Process screen for your Siebel application. For more information, see Siebel Business Process Framework: Workflow Guide.
99
100
Implementing Rules Through a Run-Time Event
This chapter describes how to implement business rules through a Siebel run-time event. It includes the following topics: Overview of Implementing Business Rules Through a Siebel Run-Time Event on page 101 Process of Validating a Service Request Through a Run-Time Event on page 102
Overview of Implementing Business Rules Through a Siebel Run-Time Event

You can configure a rule module to execute in response to a run-time event on a business component. This technique is useful for situations in which it is not necessary to access content in the output property set that results from calling the rule. Example situations where a run-time event is used includes performing field validation or setting field values. In general, a business component run-time event is categorized as pre or post. If a business rule is executed in a pre run-time event instead of the corresponding post event, then performance is usually improved. For example, invoke a rule through PreWriteRecord instead of WriteRecord, when possible. For more information about: A general approach to designing and developing business rules that reinforces steps performed in this process, see Chapter 3, Designing Siebel Business Rules, and Chapter 5, Developing Siebel Business Rules A list of Siebel run-time events for which rules integration is supported, see Run-Time Events Supported by Business Rules on page 180 General configuration guidelines, see Guidelines for Implementing Siebel Business Rules on page 216
10 1
Implementing Rules Through a Run-Time Event Process of Validating a Service Request Through a Run-Time Event
Process of Validating a Service Request Through a Run-Time Event

This topic gives one example of how to validate a service request through a run-time event. You might use business rules differently, depending on your business model. To use business rules to validate a service request through a run-time event, perform the following tasks:
1 2 3 4 5 6 7 8 9
Designing the Business Rules Implementation on page 102 Configuring the Action Set on page 104 Associating the Action Set with an Event on page 107 Importing Siebel Objects on page 108 Creating the Rule Modules on page 109 Testing the Rule Module on page 111 Deploying the Rule Modules on page 114 Activating the Rule Modules on page 114 Configuring and Activating the Run-Time Event on page 115
10 Verifying Business Rule Functionality on page 118

This task is a step in Process of Validating a Service Request Through a Run-Time Event on page 102.


For this example, a customer support representative creates a new or modifies an existing service request. A run-time event is configured to invoke the rule module to validate the service request before it is written to the database, ensuring the record includes appropriate data about the description, account, contact, area, activity plan, organization, commit time, reproduce, and activity.
102
Design Logic for the PreWriteRecord Run-Time Event

When invoked by the PreWriteRecord run-time event, the validation for a new or modified service request in this example includes: Disallow a service request that does not include a description and provide an explanation to the end user Disallow a service request that does not include an account and provide an explanation to the end user Disallow a service request that does not include a contact and provide an explanation to the end user If a service request does not include an area, then display a message that requests the end user to enter an area If a service request includes an activity plan that does not include a name, then display a message This validation might also be invoked through a PreWriteRecord event on the Activity Plan business component, so that if an end user creates or modifies an activity plan, then the user is warned to provide a name. If the rule applies to activity plans in every context, then implementing this rule on the Activity Plan business component is appropriate. That is, an activity plan that is associated with agreements, accounts, and so forth, as well as with service requests.
Design Logic for the WriteRecord Run-Time Event

If a WriteRecord run-time event detects a new or modified service request, then field values set for this example include: If a service request includes an organization whose name begins with PCS and the service request includes no primary organization, then set the organization of the service request to Default Organization If the commit time for a service request is not set, then set the commit time to the current time If the reproduce for a service request is set to Always, then set the priority of the service request to low The Reproducible field on a service request indicates whether the conditions leading to the request for service are reproduced as Always, Sometimes, or No. In this example, the business logic calls for setting the priority to low for a condition that can always be reproduced. If the reproduce for a service request is not set, then set the reproduce to Always
A PreWriteRecord event sets a field value for a new or modified activity that is associated with a service request. If an activity is associated with a service request, and if the status of the activity is Unscheduled, then change the status of the activity to Alerted. This rule executes correctly in both the Service Requests screen and in the Activities screen.
10 3
Comparison of Implementing a Business Rule on the Parent or the Child Business Component
The intent of the business rule statement in this example is to make sure that if an activity is associated with a service request that includes the status for the activity, and if the activity includes a status of Unscheduled, then the status for the activity is changed to Alerted. You could invoke this rule statement through a PreWriteRecord event on the Service Request business component instead of on the child Action business component. However, if you implement this rule on the Service Request business component, then an activity is assigned to a service request without subsequently saving the service request. In such a case, the Unscheduled status for the activity is not set to Alerted. Therefore, if the condition is satisfied, then this rule is written on the Action business component so that the Status field is set appropriately. For more information, see Guidelines for Writing Rules T hat Involve Parent and Child Business Components on page 210.
Configuring the Action Set

This task is a step in Process of Validating a Service Request Through a Run-Time Event on page 102. You can configure an action set to invoke the business rule service.
To configure the action set 1 2

In the Siebel Client, navigate to the Administration-Runtime Events screen, then the Action Sets view. In the Action Sets list, add a new action set using values in the following table. Field Name Description You might be required to give this field a name that includes the name of the rule module that it executes, such as Account Validation. Null by default. If set to null, and if the Active field is set to TRUE, then this action set is active. If a date is set in either of these fields, then this field restricts the dates for which the action set is active. Active Checked (TRUE) by default. If set to TRUE, then the action set is active, subject to restrictions in the Start Date and End Date fields. If not set to TRUE, then the action set is not active. Checked (TRUE) by default.
Start Date / End Date
Enable Export
104
In the Action list, add a new action using values in the following table. Field Name Action Type Description An arbitrary descriptive name is entered. Required. Choose BusService from the pick list.
In the More Info form, add more details using values in the following table. Field Sequence Description Required: If there is more than one action in this action set, then enter integer sequence numbers in the order that you intend the actions to execute If this action is the only action for this action set, then enter an integer, such as 1
Active
Checked (TRUE) by default. If set to TRUE, then the action is active, subject to restrictions in the Start Date and End Date fields. If not set to TRUE, then the action set is not active, even if the action set is active. Null by default. If set to null, and if the Active field is set to TRUE, then this action is active. If a date is set in either of these fields, then it restricts the dates for which the action is active, within the restrictions determined by the Start Date and End Date fields of the action set.
Start Date / End Date
Business Service Name
Enter Business Rule Service. Note that the value is case sensitive. This business service executes a rule module. It is seed data in the Siebel Repository.
10 5
Field Business Service Method Business Service Context
Description Enter RunRules. Note that the value is case sensitive, with no space. Enter the knowledgebase name followed by the name of the rule module that this action executes. Use a colon to delimit the knowledgebase name. To specify more than one rule module, separate their names with commas. The following example specifies a knowledgebase named runtime_test_KB, with rule modules SR ValidationPreWriteRecord and SR Validation-WriteRecord: runtime_test_kb:SR Validation-PreWriteRecord,SR Validation-WriteRecord NOTE: If you specify more than one rule module, then every specified rule module must include the same business object. Each specified rule module must be already configured and activated. For more information, see Activating a Rule Module on page 57.
106
Associating the Action Set with an Event

This task is a step in Process of Validating a Service Request Through a Run-Time Event on page 102. You associate an action set with a run-time event that you create in the Administration-Runtime Events screen in the Siebel client.
To associate the action set with an event 1 2

In the Siebel client, navigate to the Administration-Runtime Events screen, then the Events view. In the Events list, add a new event to create an association with the action set you created in Configuring the Action Set on page 104. Use values described in the following table. Field Name Sequence Value Not required. Required: If this event is not the only event that can invoke, then provide an integer sequence number for this and other such events in order to define the sequence you intend the events to be processed If this event is the only event that can invoke, then provide an integer, such as 1
Object Type
Required. Choose BusComp from the pick list. A HaleyAuthority rule module cannot apply to Application or Applet objects.
Object Name Event Subevent
Required. From the list of values, choose the business component on which this event is invoked. Required. Choose the appropriate event from the list of values. Required for some events. For example, the SetFieldValue event requires the name of the field. For more information, see Siebel Personalization Administration Guide. Adds more control. If the conditional expression evaluates to TRUE, then the action is invoked when the event occurs. Required. From the list of values, choose the action set that you defined in Step 2 on page 104.
Conditional Expression Action Set Name
10 7
Save the event record.
For more information about: Argument requirements for calling the Business Rule Service from a run-time event, see PerformAction Input Property on page 189 and Input and Output Property Usage With Siebel Development Tools on page 193 Using run-time events, see Siebel Personalization Administration Guide

This task is a step in Process of Validating a Service Request Through a Run-Time Event on page 102. For this example, the business logic requirement is invoked though a PreWriteRecord run-time event and a WriteRecord run-time event, each of which makes a call to the Business Rule Service.
To import Siebel objects 1

Create a new knowledgebase named runtime_test_KB. For more information, see Process of Setting Up the Knowledgebase on page 34.
Use the Siebel Object Importer wizard to import Siebel object definitions:
a b c d e
Enter the login credentials to the sample database, and choose Sample as the datasource. For this example, a local database is used for both the repository database and as the run-time database. You might be required to use the Siebel sample database, sse_samp.dbf, instead. For the run-time data connection, choose Local. In the Pick Business Object screen, choose the Service Request business object. In the Pick Business Components screen, pick the business components used during the import:

Click the check box for the Service Request business component. Click the check boxes for the Action and Activity Plan business components that appear as child components in the tree under Service Request.
108
On subsequent screens of the Pick Business Component Fields dialog box, add fields using values in the following table. Business Component Service Request Fields Add the following fields: Action Account Area Commit Time Contact Last Name Description Organization Priority Reproduce
Add the following fields: Activity SR Id Status
NOTE: Activity SR Id is the foreign key to the parent service request in the Service Request and Action link. Activity Plan Name
For more information, see Importing Siebel Objects into HaleyAuthority on page 48. The business logic for this example is based on the Service Request business object and the Service Request business component. Child business components and fields in the various child business components must be imported in order to implement the business logic.
Creating the Rule Modules

This task is a step in Process of Validating a Service Request Through a Run-Time Event on page 102. For this example, a PreWriteRecord run-time event and a WriteRecord run-time event each make a call to the Business Rule Service. There are two rule modules, one for the PreWriteRecord event and one for the WriteRecord event. First, create the rule modules.
10 9
To create the rule modules

Create three new rule modules with the following names:

SR Validation-PreWriteRecord SR Activity-PreWriteRecord SR Validation-WriteRecord
For more information, see Creating a Rule Module on page 50. Next, add rule statements to the rule modules.
To add rule statements to the rule modules 1

Add the following statements to the SR Validation-PreWriteRecord rule module: if a service request does not have an account then invalidate the service request with "A service request must have an account." if a service request does not have a contact last name then invalidate the service request with "A service request must have a contacts Last Name." 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." For more information, see Creating a Rule Statement on page 51.
Add the following statements to the SR Validation-WriteRecord rule module: 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" TIP: If you are working with an electronic version of this book, then you can copy the statement in the book to the clipboard, and then paste it into HaleyAuthority.
Add the following statements to the SR Activity-PreWriteRecord module: if the status of an action is "Unscheduled" then set "Status" of the action to "Alerted"
110
Add the following applicability statement to the statement you created in Step 3: an action has an activity sr id that is not unknown Note that the phrase not unknown tests the field to determine if it is not null. That is, this statement determines whether or not the field includes a value. For more information about applicability, see Creating a Rule Statement on page 51.

This task is a step in Process of Validating a Service Request Through a Run-Time Event on page 102. You can use the Siebel Test Harness in HaleyAuthority to test your rule statements before deploying the rule modules. For more information, see Testing a Rule Module on page 52. To test the rule module in HaleyAuthority, begin by creating a test case.
To create a test case

Create a test case named SR Validation-PreWriteRecord. For more information, see Creating a Test Case on page 53. Next, create an example instance for the test case.
To create an example instance for the test case

Use the Add > An Instance Or Example command to create an example instance:
a b c
In the instance dialog box for the service request entity, add example_service_request_1 for the label. Do not add a fact for the test case. Right-click the example_service_request_1 instance, choose Test cases, then click the SR Validation-PreWriteRecord check box to associate the test case with an instance. Note that the example_service_request_1 instance includes no service request items and has no field values associated with it.
For more information, see Creating an Example Instance for a Test Case on page 53. Next, run the test case.
11 1
To run the test case

Use the Test Case command to run the test case:
a b
In the Tests & Cases window, right-click the test case named SR Validation-PreWriteRecord. In the Deploy Configuration dialog box, make sure the following check boxes are checked:

deployment model measures unauthoredRules unauthoredDiagnostics
c d
In the Deploy Configuration dialog box, check the check box for SR Validation-PreWriteRecord. Leave the check boxes for other modules unchecked. In the Siebel Test Harness dialog box, choose SR Validation-PreWriteRecord.
For more information, see Running the Test Case on page 55. Next, examine test results, then run more tests.
To examine test results then run more tests 1

Examine data displayed in the Output Window. An entry of the form SR Validation-PreWriteRecord on [date and time] is added to the Test Results folder under SR Validation-PreWriteRecord. Expand this folder to view the statements that were executed: 1 if a service request does not have a contact last name then invalidate the service request with "A service request must have a contact." 1 if a service request does not have an account then invalidate the service request with "A service request must have an account." 1 if a service request does not have a description then invalidate the service request with "A service request must have a description." 1 if a service request does not have an area then raise an error as "Enter the area for the service request." The condition for the only other statement in the module, that a service request includes an activity plan without a name, is not satisfied by the example instance. The instance does not include an activity plan.
112
Test other conditions of your rule module:

Modify your example instances and rerun your test case. Alternatively, you can create separate example instances, separate test cases, or both. For this example, modify example_service_request_1 to include an activity plan and some field values to test. You must set properties for an instance of your service request and for an instance of an activity plan.
For more information, see Examining Test Results on page 56. Next, rerun the test to check for other examples and properties.
To rerun the test to check other examples and properties 1 2 3 4 5

Click the Concepts tab. Right-click example_service_request_1, choose Properties, then click the Facts tab. Click the New icon, choose example_service_request_1 has an account, then click OK. In the Account field, enter ABC Company, then click OK. Repeat this procedure to define more properties, using values in the following table. Property has an activity plan has a contact last name Value example_activity_plan Lee
Rerun SR Validation-PreWriteRecord to test the simulation. Test results must list the following statements as having executed: 1 if a service request does not have a description then invalidate the service request with "A service request must have a description." 1 if a service request does not have an area then raise an error as "Enter the area for the service request." 1 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."
7 8
Vary your instance properties and rerun the test case to test other aspects of your rule module. Create example instances and test cases similarly to test the SR Validation-WriteRecord and SR Activity-PreWriteRecord modules.
11 3
Deploying the Rule Modules

This task is a step in Process of Validating a Service Request Through a Run-Time Event on page 102. You must deploy the SR Validation-PreWriteRecord and SR Validation-WriteRecord modules to a runtime environment.
To deploy the rule modules

Use the Siebel Deployment tool to deploy the rule modules:
In the Siebel Deployment dialog box, choose the following modules from List of Modules:

SR Activity-PreWriteRecord. SR Validation-PreWriteRecord. SR Validation-WriteRecord.
Note the value in the Runtime Knowledgebase Name window. You use this value in a subsequent procedure when activating the rule module in the Siebel client.
Make sure the Update model check box includes a check mark.
For more information, see Deploying a Rule Module on page 56.
Activating the Rule Modules

This task is a step in Process of Validating a Service Request Through a Run-Time Event on page 102. Next, you can activate the rule modules.
To activate the rule modules

In the Siebel client, use the Business Rule Knowledge Base screen to activate the rule modules:
a b
In the Business Rule Knowledge Base tree, choose the Knowledgebase name you noted in Deploying the Rule Modules on page 114. Choose the SR Activity-PreWriteRecord module in the Rule Modules list, then set the Business Object to Service Request.
114
In the Rule Module Relations list, create new records by picking items from the Business Components field picklist, using values in the following table. Parent Business Component No entry Service Request Business Component Service Request Action
Note that when you define the Business Component then step off the record, the Parent Business component field automatically populates.
d e
After activating the SR Activity-PreWriteRecord rule module, choose the SR ValidationPreWriteRecord module then set the Business Object to Service Request. In the Rule Module Relations list, create new records by picking items from the Business Components field picklist, using values in the following table. Parent Business Component No entry Service Request Business Component Service Request Activity Plan
f g
After activating the SR Validation-PreWriteRecord rule module, choose the SR ValidationWriteRecord module then set the Business Object to Service Request. In the Rule Module Relations list, create new records by picking items from the Business Components field picklist, using values in the following table. Parent Business Component No entry Service Request Service Request Service Request Business Component Service Request Action Organization Primary Organization
Activate the SR Validation-WriteRecord rule module.
Configuring and Activating the Run-Time Event

This task is a step in Process of Validating a Service Request Through a Run-Time Event on page 102. To associate the SR Validation-PreWriteRecord, SR Validation-WriteRecord, and SR ActivityPreWriteRecord rule modules with a run-time event, you must configure a run-time event to invoke rules.
11 5
To configure and activate the run-time event 1 2

In the Siebel Client, navigate to the Administration-Runtime Events screen, then the Action Sets view. In the Action Sets list, add a new action set using values in the following table. Field Name Start Date / End Date Active Enable Export Value SR Validation-PreWriteRecord (Accept the default value null.) (Checked by default. Checked indicates TRUE.) (Checked by default. Checked indicates TRUE.)
3 4
In the Actions list, add a new action named SR Validation-PreWriteRecord Rules. In the More Info form, define fields using values in the following table. Field Action Type Sequence Active Business Service Name Value BusService 1 [Checked] Business Rule Service Description Required. Choose BusService from the pick list. Required. Required. Checked (TRUE) by default. Enter the value as shown. It is case sensitive. This business service executes a rule module. It is seed data in your Siebel Repository. Enter the value as shown. It is case sensitive, and does not include spaces. Enter the knowledgebase name followed by the module name. The syntax is [knowledgebase name]:[rule module name]. The format is precise. Use a colon to delimit the knowledgebase name from the rule module name. Do not insert spaces on either side of the colon. The rule module name must match the rule module name in HaleyAuthority exactly. The comparison is case sensitive and space sensitive.
Business Service Method Business Service Context
RunRules Runtime_test_kb: SR ValidationPreWriteRecord
5 6
Make sure the Administration-Runtime Events screen tab is chosen. Click Events in the link bar.
116
In the Events list, add a new event record using values in the following table. Field Name Sequence Object Type Object Name Event Action Set Name Value SR ValidationPreWriteRecord 1 BusComp Service Request PreWriteRecord SR ValidationPreWriteRecord Description Optional. Required. Required. Choose BusComp from the pick list Required. From the list of values, choose Service Request, the top-level business component. Required. Choose PreWriteRecord. Required. From the list of values, choose SR Validation-PreWriteRecord.
This event is associated with the action set you created earlier in this procedure. For more information about using run-time events, see Siebel Personalization Administration Guide.
8 9
Save the event. Create an Action set for SR Activity-PreWriteRecord:
a b c d e
Click the Action Sets link to navigate back to the Action Sets list. Query the Name column for SR Validation-PreWriteRecord. Right-click the record, then choose Copy. Name the new record Set SR Activity-PreWriteRecord. Repeat Step 3 through Step 7 using modifications described in the following table. Field Name Business Service Context Name Object Name Event Action Set Name Value SR Activity-PreWriteRecord Rules Test_kb:SR Activity-PreWriteRecord SR Activity-PreWriteRecord Action PreWriteRecord SR Activity-PreWriteRecord
Applet Actions More Info Events Events Events Events
11 7
10 Create an Action set for SR Validation-WriteRecord: a b c d e

Click the Action Sets link to navigate back to the Action Sets list. Query the Name column for SR Validation-PreWriteRecord. Right-click the record, then choose Copy. Name the new record SR Validation-WriteRecord. Repeat Step 3 through Step 7 using modifications described in the following table. Field Name Business Service Context Name Object Name Event Action Set Name Value SR Validation-WriteRecord Rules Runtime_test_kb:SR Validation-WriteRecord SR Validation-WriteRecord Service Request WriteRecord SR Validation-WriteRecord
Applet Actions More Info Events Events Events Events

This task is a step in Process of Validating a Service Request Through a Run-Time Event on page 102. You can verify that the business rules implement the functionality that is defined in Designing the Business Rules Implementation on page 102.
To verify business rule functionality 1

Log in to the Siebel application in the same run-time environment to which you deployed the rule module. If the application is open, then first log out, and then log in.
2 3
Navigate to the Service Requests screen, then the Service Requests List view. Create new service request records or edit existing records. In this step, create and associate activity and activity plans with service requests in order to meet the criteria of the various rules written to the Service Request business component, then check to verify that:
Appropriate messages display. If you try to save the record with disallowed data, then the correct message displays and the record is not saved until criteria for validation are met.
Fields are automatically populated as designed.
While in the Service Requests list, click a service request number in the SR# column to drill down on the service request.
118
5 6 7 8
Click the Activities view tab. In the Activities list, create a new activity or edit an existing activity. Set the status for the activity to Unscheduled then save the record. Make sure that the status changes to Alerted after saving. Test the run-time event similarly in the Activities list of the Activities screen. Test activities with and without an entry in the SR # column.
11 9
120
Implementing Rules Through a Script in a Task UI
This chapter describes how to implement business rules through a script on a custom business service. It includes the following topics: Overview of Implementing Business Rules Through a Script on a Custom Business Service on page 121 Process of Creating an Opportunity Through a Siebel Task UI on page 122
Overview of Implementing Business Rules Through a Script on a Custom Business Service

This chapter uses a task UI to implement business rules through a script on a custom business service. A task UI assist the end user with executing a business process. The requirements for implementing business rules in a task UI are similar to the requirements for implementing business rules in a workflow process. For more information, see Overview of Implementing Business Rules Through Declarative Configuration on page 79. Creating and implementing an entire task UI requires that you perform several work items, such as diagramming the task UI, defining task groups, creating task views, binding the views to task UI steps, defining visibility of the task UI, testing, and so forth. This work is described in this chapter. For more information about: A general approach to designing and developing business rules that reinforces steps performed in this process, see Chapter 3, Designing Siebel Business Rules, and Chapter 5, Developing Siebel Business Rules Scripting calls to the Business Rule Service, see Chapter 6, Implementing Rules Through a Script on a Business Component General configuration guidelines, see Guidelines for Implementing Siebel Business Rules on page 216 Creating and implementing a task UI, see Siebel Business Process Framework: Task UI Guide
12 1
Implementing Rules Through a Script in a Task UI Process of Creating an Opportunity Through a Siebel Task UI
Process of Creating an Opportunity Through a Siebel Task UI

This topic gives one example of how to use business rules to create an opportunity through a Siebel task UI. You might use business rules differently, depending on your business model. To use business rules to create an opportunity through a task UI, perform the following tasks:
1 2 3 4 5 6 7 8 9
Designing the Business Rules Implementation on page 122 Defining a New Siebel Task UI on page 127 Defining UI Elements for the Opportunity Info View on page 129 Defining UI Elements for the Excellent Lead Info View on page 133 Defining UI Elements for the Good Lead Info View on page 135 Binding Views to Task UI Steps on page 137 Defining the Task UI Groups on page 139 Creating the Rule Module on page 141 Deploying and Activating the Rule Module on page 142
10 Testing the Rule Module on page 143 11 Creating a Custom Business Service on page 145 12 Defining Calls to the Siebel Rules Engine on page 152 13 Publishing, Activating, and Verifying the Task UI on page 155

This task is a step in Process of Creating an Opportunity Through a Siebel Task UI on page 122.

122

For this example, a task UI uses business rules to assist a customer support representative to perform the following work: Create a new opportunity Categorize the quality of the lead based on the potential revenue for the lead Populate other fields on the opportunity
Output from the Siebel Rules Engine provides the criteria for branching. The business process requirement is:
1 2 3 4
Create a new opportunity. Enter fields, including Revenue. Populate the Quality field of the opportunity depending on the amount of potential revenue. Depending on the quality of the lead, branch to a view that requests the end user to enter a particular comment field.
This task UI is based on the Opportunity business object and the Opportunity business component. Figure 3 illustrates a chart that represents the business process that the task UI supports. This design work is performed in an application that supports the use of charts or other representations of the business process.
Figure 3.
Chart for the Business Process That Is Named New Lead
View Mock-Up Requirements

It is recommended to create a mock-up of the task UI. In this topic, the mock-up is already created for you. Views required for this task UI include: Opportunity Info view. End user enters data for the new opportunity. Excellent Lead Info view. End user enters data for an excellent lead. Good Lead Info view. End user enters data for a good lead.
12 3
Opportunity Info View Requirements Figure 4 illustrates a mock-up of the Opportunity Info View which displays the first screen in the task UI that you implement in this example.
Figure 4.
Mock-up of the Opportunity Info View
UI element requirements to consider for the view include: Required fields. Required fields are described in the following table. Field Name Name Sales Stage Close Date Revenue Type String String Date Currency
Messages. The message substitutes the login name of the end user, and asks the user to update the fields displayed. Buttons. The Previous button is disabled because this view is the first view that is displayed. Other buttons are active.
124
Excellent Lead Info View Requirements Figure 5 illustrates a mock-up of the Excellent Lead Info View.
Figure 5.
Mock-up of the Excellent Lead Info View
UI element requirements to consider for the view include: Required fields. Required fields are described in the following table. Field Name Opportunity Profile Type String
Buttons. Other buttons are active. The Finish Button is exposed.
12 5
Good Lead Info View Requirements Figure 6 illustrates a mock-up of the Good Lead Info View.
Figure 6.
Mock-Up of the Good Lead Info View
UI element requirements to consider for the view include: Required fields. Required fields are described in the following table. Field Name Goal Type String
Buttons. Other buttons are active. The Finish Button is exposed.
126
Business Logic Requirements

After the end user enters opportunity information, the quality of the lead must be evaluated based on revenue amount. The lead quality then determines which view is subsequently displayed to the user. The quality of the lead is described in the following table. Lead Quality Excellent Good Revenue $2,000,000 and greater At least $1 and less than $2,000,000
The Siebel Rules Engine looks at the revenue entered and determines the lead quality. Based on the lead quality, one of the following branches is followed: Excellent. The value of the Quality field on the opportunity is set to 1-Excellent, and the end user is routed to the Excellent Lead Info view to finish the Opportunity Profile field. Good. The value of the Quality field on the opportunity is set to 2-Very High, and the end user is routed to the Good Lead Info view to finish the Goal field.
Invocation Requirements
Views from which an end user must be able to invoke this task UI include: Opportunity List View Manager's Opportunity List View All Opportunity List View All Opportunities across My Organizations All Opportunities across Organizations
The end user can drill down on the Create a Lead Task UI in the Task pane to invoke the task UI. No subtasks are required. For more information, see Siebel Business Process Framework: Task UI Guide.
Defining a New Siebel Task UI

This task is a step in Process of Creating an Opportunity Through a Siebel Task UI on page 122. In order to implement this example, you first prepare Siebel Tools.
12 7
Preparing Siebel Tools

You must prepare Siebel Tools.
To prepare Siebel Tools 1

Make sure the following parameter is set in the [Siebel] section of \TOOLS_ROOT\bin\[language]\tools.cfg: EnableToolsConstrain = FALSE If the parameter is not present, then add it. This setting allows you to assign display names of objects for a workflow process.
2 3 4 5 6 7 8 9
In Siebel Tools, from the application-level menu, choose the View menu, then the Options menu item. Click the Object Explorer tab. Scroll down through the Object Explorer Hierarchy window to locate the Task object. Make sure the Task object and child objects for the Task object include a checkmark, then click OK. Repeat Step 4 and Step 5 for the Task Group object. In the Object Explorer Hierarchy window, locate the View object, then make sure the child View Task Group object in the View hierarchy includes a checkmark. In the Object Explorer Hierarchy window, locate the Applet object, then make sure the child Applet Message object in the Applet hierarchy includes a checkmark. Click OK.
Next, define the Create a Lead Task UI.
To define the create a lead task UI 1 2 3 4

In Siebel Tools, navigate to the Projects OBLE. Create a new project named Rules Call Back, then lock the project. In the Tasks OBLE, right-click, then choose New Task Wizard. In the New Task dialog box, enter values described in the following table. Field Project Task Name Display Name Business Object Default Transient Business Component Create as a subtask Value Rules Call Back Create a Lead Create a Lead Opportunity (Leave empty.) Unchecked
128
5 6
Click Finish. In the Task Designer, drag and drop task steps and connectors from the Palette to the canvas to create a task UI that is similar to the task UI illustrated in the following figure:
Define a name for each step and connector, as illustrated in the figure in Step 6:
Click a step then enter the name for the step in the Name property of the Properties window. For the Task View steps, note that the name for the step does not appear in the Task Designer until you bind the task step, which you perform later in this example.
b 8 9
For the connectors that include labels, Excellent and Good, click the connector, then enter the label for the connector in the Label property of the Properties window.
From the application-level menu, choose the File menu, then the Save menu item. Close the Task Designer.
Next, define UI elements for the Opportunity Info view.
Defining UI Elements for the Opportunity Info View

This task is a step in Process of Creating an Opportunity Through a Siebel Task UI on page 122. In this topic, you begin by creating the applet for the Opportunity Info view.
To create the applet for the opportunity info view 1 2 3 4

If the Task Designer is open, then close it. In Siebel Tools, from the application-level menu, choose the File menu, then the New Object menu item. Click the Applets tab. Click Form Applet, then click OK to launch the Form Applet Wizard.
12 9
In the General dialog box, create a form applet using values in the following table. Property Project Applet name Applet display title Business Component Upgrade behavior Use grid layout Value Rules Call Back Opportunity Info Opportunity Info Opportunity Admin Checked
6 7 8
Click Next. In the Web Layout-Form dialog box, choose Edit Mode, then click Next. In the Web Layout - Fields dialog box, move the following fields to the Selected Fields window, then click Next:

Name Sales Stage Close Date Revenue
Choose Next to accept the default controls chosen for your applet, then click Finish. The Web Template Layout Editor opens.
130
10 Lay out the Opportunity Info applet: a

To add the Opportunity Info title that is displayed immediately above the Name field, drag, then drop a FormSection control from the Web Controls Palette to the canvas. To set the caption, use the Caption-String Override property for the control. Position individual controls and control labels so that they resemble the following figure:
From the application-level menu, choose File - Save. For information about using the Web Layout Editor, see Using Siebel Tools.
11 In the Object Explorer, click the Applet object type, then query for Opportunity Info in the Name
property of the Applets OBLE.
12 In the Object Explorer, expand the Applet object type, then click the Applet Message object type. 13 In the Applet Messages OBLE, add a salutation message to the Opportunity Info applet by adding
a new Applet Message using values in the following table. Property Name Text Message-String Override Value Salutation Message %1, Please enter the Name, Sales Stage, Close Date, and Revenue
14 In the Object Explorer, expand the Applet Message object type, then click the Applet Message
Variable object type.
13 1
15 In the Applet Message Variables OBLE, define the variable used in your applet message by adding
a new Applet Message Variable using values in the following table. Property Field Value Value Login Id 1
16 Return to the Web Layout Editor, then add the new Salutation Message to the applet by dragging
a Text control from the Web Controls Palette to the canvas.
17 Use the Properties window to define properties for the control you added in Step 16, using values
in the following table. Property Field Type Field HTML Type HTML Only Name Value Message Salutation Message Plain text FALSE Salutation Message
For the Name property, you manually type in the value. Leave other properties at their default values.
18 From the application-level menu, choose the File menu, then the Save menu item. 19 Close the Web Layout Editor.
Next, create the task view that uses the Opportunity Info applet.
To create the task view that uses the opportunity info applet 1 2 3
In Siebel Tools, from the application-level menu, choose the File menu, then choose the New Object menu item. Click the Task tab. Click the Task View icon, then click OK to launch the Task View Wizard.
132
In the New View dialog box, create a task view using values in the following table. Property Project View name View title Business Object Upgrade behavior Value Rules Call Back Opportunity Info Opportunity Info Opportunity Admin
5 6 7
Click Next. In the View Web Layout-Select Template dialog box, choose View Detail 2 (Parent With Pointer), then click Next. In the Web Layout - Applets dialog box, click Next. The Web Layout - Applets dialog box allows you to add a standard applet to the view. Because you are adding a task applet, do not add applets in this dialog box.
In the Task View-Select Task dialog box, choose Create a Lead, then click Next. Because you did not choose an applet in Step 7, the wizard requires you to add a task UI. If you choose an applet in Step 7, then adding a task UI is optional, and you are prompted to add a task UI.
In the Task View-Task Applets dialog box, choose Opportunity Info, then click Next. appropriate right arrow to populate the bottom playbar applet text box, then click Next.
10 In the Task View-Select Playbar Applet dialog box, choose Task Playbar Applet-Bottom, click the 11 In the Finish dialog box, review your definitions, then click Finish.
The Web Template Layout Editor opens, displaying the visual layout for this task view.
12 Close the Web Template Layout Editor.
Defining UI Elements for the Excellent Lead Info View

This task is a step in Process of Creating an Opportunity Through a Siebel Task UI on page 122. In this topic, you define UI elements for the Excellent Lead Info view. You begin by creating the applet for the Excellent Lead Info view.
13 3
To create the applet for the excellent lead info view 1

Create the applet for the Excellent Lead Info View. To create this applet, repeat the procedure you performed earlier in this example, starting with Step 2 on page 129. Use values described in the following table. Dialog Box Form Applet Wizard General Property Project Applet name Applet display title Business component on which the applet is based Applet upgrade behavior Use Grid Layout Web Layout - Form Web Layout - Fields Mode Add field Value Rules Call Back Opportunity Excellent Lead Opportunity Excellent Lead Opportunity
Admin Checked Edit Mode Profile
After the applet is created and displayed in the Web Template Layout Editor, add the Excellent Lead Info title, then position individual controls and control labels so that they resemble the following figure:
3 4
From the application-level menu, choose the File menu, then the Save menu item. Close the Web Template Layout Editor.
Next, create the task view that uses the Excellent Lead Info applet.
134
To create the task view that displays the excellent lead info applet 1
Create the Task View that displays the Excellent Lead Info applet. To create this view, repeat the procedure you performed earlier in this example, starting with Step 1 on page 132, using values in the following table. Dialog Box Task View Wizard-New View Property Project View name View title View business object View upgrade behavior View Web Layout - Select Template Web Layout - Applets Task View - Pick Task Task View - Select Playbar Applet View template Applet Task applet Task Playbar Applet - Bottom Value Rules Call Back Excellent Lead Info Excellent Lead Info Opportunity Admin View Detail 2 (Parent With Pointer) Opportunity Excellent Lead No (Place at bottom position.)
Close the Web Template Layout Editor.
Defining UI Elements for the Good Lead Info View

This task is a step in Process of Creating an Opportunity Through a Siebel Task UI on page 122. In this topic, you define UI elements for the Good Lead Info view. You begin by creating the applet for the Good Lead Info view.
13 5
To create the applet for the good lead info view 1

Create the applet for the Good Lead Info View. To create this applet, repeat the procedure you performed earlier in this example, starting with Step 2 on page 129, using values described in the following table. Dialog Box Form Applet WizardGeneral Property Project Applet name Applet display title Applet business component Applet upgrade behavior Use grid layout Web Layout - Form Web Layout - Fields Mode Add field Value Rules Call Back Opportunity Good Lead Opportunity Good Lead Opportunity Admin Checked Edit Mode Goal
After the applet is created and displayed in the Web Template Layout Editor, add the Good Lead Info title, then position individual controls and control labels so that they resemble the following figure:
3 4
From the application-level menu, choose the File menu, then the Save menu item. Close the Web Template Layout Editor.
Next, create the task view that uses the Good Lead Info applet.
136
To create the task view that displays the good lead info applet 1
Create the Task View that displays the Good Lead Info view. To create this view, repeat the procedure you performed earlier in this example, starting with Step 1 on page 132, using values described in the following table. Dialog Box New View Property Project View name View title View business object View upgrade behavior View Web Layout - Select Template Web Layout - Applets View template Applet Value Rules Call Back Good Lead Info Good Lead Info Opportunity Admin View Detail 2 (Parent With Pointer) Opportunity Good Lead applet Task View-Pick Tasks Task View - Select Playbar Applet Task applet Task Playbar Applet - Bottom No (Place at bottom position.)
Close the Web Template Layout Editor.
Binding Views to Task UI Steps

This task is a step in Process of Creating an Opportunity Through a Siebel Task UI on page 122. Next, you bind views to steps in the Create a Lead task UI.
To bind views to task UI steps 1 2 3

In the Tasks OBLE, query the Task Name property for Create a Lead. Right-click the Create a Lead task UI, then choose Edit Task Flow. In the Task Designer, right-click the Create New Opportunity Siebel operation.
13 7
In the Properties window, define properties using values in the following table. Property Business Component Defer Write Record Value TBC for Big Opportunity TRUE (If a required business component field is empty, then setting this property to TRUE prevents the Object Manager from rejecting a record.) Operation Repeatable Retain Task Search Spec Insert TRUE TRUE
5 6
Right-click the Task View step that is immediately downstream of the Create New Opportunity step, then choose Bind Task View. Choose Opportunity Info, then click OK. Note that the name of the view referenced by the task view step is displayed in the Task Designer.
7 8
Make sure the Opportunity Info step is chosen. In the Properties window, define properties using values in the following table. Property Display Name-String Override Forward Button Type Disable Previous Value Opportunity Information Next TRUE
For information on configuration options, see Forward Button Configuration for this Example on page 139.
Right-click the Task View step that is on the Excellent branch, then choose Bind Task View.
10 Choose the Excellent Lead Info view, then click OK. 11 Make sure the Excellent Lead Info step is chosen. 12 In the Properties window, define properties described in the following table.
Property Display Name-String Override Forward Button Type Disable Previous Value Excellent Lead Information Submit FALSE
13 Right-click the Task View step that is on the Good branch, then choose Bind Task View.
138 Siebel Business Rules Administration Guide Version 8.1
14 Choose the Good Lead Info view, then click OK. 15 Make sure the Good Lead Info step is chosen. 16 In the Properties window, define properties described in the following table.
Property Display Name-String Override Forward Button Type Disable Previous Value Good Lead Information Submit FALSE
17 From the application-level menu, choose the File menu, then the Save menu item.
Forward Button Configuration for this Example

In certain steps in the procedure starting on Step 1 on page 137, you can choose Submit for the Forward Button Type instead of Next. Submit commits the record for the opportunity to the database before the subsequent call to Business Rule Service. Because the Business Rule Service is then assured of acting on the existing data only, the GetMoreData and PerformAction input properties of the Business Rule Service are set to Y. For more information, see: PerformAction Input Property on page 189 Input and Output Properties with a Script, Workflow Process or Task UI on page 194
Defining the Task UI Groups

In this topic, you create a task group to define the views in which the Create a Lead Task UI is available.
To define the task UI group 1 2

In the Object Explorer, click the Task Group object type. In the Task Groups OBLE, create a new Task Group using values in the following table. Property Name Project Display Name String Override Value Lead Tasks Rules Call Back Lead Tasks
Expand the Task Group object type in the Object Explorer, then click Task Group Item.
13 9
In the Task Group Items OBLE, create a new Task Group Item using values in the following table. Property Action Invoked Type Sequence Value Create a Lead Task 1
5 6 7 8 9
Navigate to the Projects OBLE, then lock the Oppty (SSE) project. Click the View object type in the Object Explorer, then query for Opportunity List View in the Name property of the Views OBLE. Expand the View object type in the Object Explorer, then click the View Task Group object type. In the View Task Groups OBLE, create a new view task group with the Task Group property set to Lead Tasks, and with the Sequence property set to 1. Repeat Step 6 and Step 8 for each of the following views:

Manager's Opportunity List View All Opportunity List View All Opportunities across My Organizations All Opportunities across Organizations
10 From the application-level menu, choose the Tools menu, then the Compile Projects menu item. 11 Compile all locked projects.

This task is a step in Process of Creating an Opportunity Through a Siebel Task UI on page 122. Because the business logic for this example is based on the Opportunity business object and Opportunity business component, you import the object definitions that are associated with an opportunity.
To import Siebel objects 1

Create a new knowledgebase named taskUI_test_KB. For more information, see Process of Setting Up the Knowledgebase on page 34.
Use the Siebel Object Importer wizard to import Siebel object definitions. For more information, see Importing Siebel Objects into HaleyAuthority on page 48.
Enter the login credentials to the sample database, and choose Sample as the datasource. For this example the sample database, sse_samp.dbf, is used for both the repository database and as the run-time database.
140
b c d e
For the run-time data connection, choose Local. In the Pick Business Object screen, choose the Opportunity business object. In the Pick Business Components screen, click the check box for the Opportunity business component. On subsequent screens of the Pick Business Component Fields dialog box, add fields using values in the following table. Business Component Opportunity Fields Add the following fields: Name Revenue Quality
For more information about how the Revenue field is imported for this example, see Concepts and Relations Created for a Multi Value Field on page 165.

This task is a step in Process of Creating an Opportunity Through a Siebel Task UI on page 122. Your business logic might include natural groupings of rules that can organize your logic sequentially, by applicability, or for some other purpose. For this example, the business logic is naturally grouped by the two qualities a lead might qualify for. The business logic to implement as a rule module is the evaluation of the quality of a lead. A rule module is a grouping of rule statements. A rule submodule is a grouping of statements within a module. The rule statements you create implement the logic described in the following table. Lead Quality Excellent Good Revenue $2,000,000 and greater At least $1 and less than $2,000,000
Next, create the rule module and rule submodules.
14 1
To create the rule module 1 2 3

Create a rule module named New Lead. Add a submodule named Excellent to the New Lead module. Add a submodule named Good to the New Lead module.
For more information, see Creating a Rule Module on page 50. Next, add rule statements to rule submodules.
To add rule statements to rule submodules 1

Add the following rule statement to the Excellent submodule: if an opportunity's primary revenue's revenue is at least 2000000 in "USD" then set "Quality" of the opportunity to "1-Excellent" and add "Excellent" for the opportunity For more information about creating a rule statement, see Creating a Rule Statement on page 51. For more information about the rule statement described in this step, see Rule Statement Components on page 208.
Add the following rule statement to the Good submodule: if an opportunity's primary revenue's revenue is at least 1 in "USD" and an opportunity's primary revenue's revenue is less than 2000000 in "USD" then set "Quality" of the opportunity to "2-Good" and add "Good" for the opportunity

This task is a step in Process of Creating an Opportunity Through a Siebel Task UI on page 122. You must deploy the New Lead module to the Siebel run-time environment.
To deploy the rule module

a b
In the Siebel Deployment dialog box, choose New Lead from the List of Modules. Make sure the Update model check box includes a check mark.
For more information, see Deploying a Rule Module on page 56. Next, activate the rule module.
142
To activate the rule module

a b c
In the Business Rule Knowledge Base tree, choose taskUI_test_KB, which is the knowledgebase you created in Importing Siebel Objects on page 140. In the Rule Modules list, choose New Lead, then set the Business Object to Opportunity. In the Rule Module Relations list, create three new records, using values in the following table. Parent Business Component (leave empty) Opportunity Opportunity Business Component Opportunity Primary Revenue Revenue
Use the MVG check box in the Business Component field. The Parent Business Component field automatically populates after a choice is made using the MVG. For the Opportunity business component, no parent business component is specified.
Activate the New Lead module.

This task is a step in Process of Creating an Opportunity Through a Siebel Task UI on page 122. The Business Service Administration view tests data in an existing opportunity. To make sure the rule module assigns the correct type of quality to the opportunity, the test uses input arguments for a business service to supply the opportunity with different revenue amounts to the Business Rule Service, which is the predefined business service for making calls to the Siebel Rules Engine. For more information, see Testing a Rule Module on page 52.
To test the rule module 1

Prepare the RunRules method. For more information, see Preparing the RunRules Method on page 182.
Prepare the ProcessOutput method. For more information, see Preparing the ProcessOutput Method on page 183.
3 4 5 6
Log in to the Siebel application in the same run-time environment to which you deployed the rule module. Navigate to the Opportunity list and locate an existing opportunity. From the application-level menu, choose the Help menu, then the About Record menu item. Make a note of the Row ID for the record and the value in the Revenue field for this opportunity.
14 3
7 8
Navigate to the Administration-Business Service screen, then the Simulator view. Create a new parent record, then define fields using values in the following table. Field Name Service Name Method Iterations Property Value Business Rule Service RunRules 1
In the Input Arguments list, create a separate record for each argument described in the following table. Property Name BusCompName ID RuleModuleName GetMoreData PerformAction KnowledgeBaseName Property Value Opportunity (Row # from About Record. For example, 6-48ZVH.) New Lead Y Y taskUI_test_KB
To define an input argument, perform the following steps:
a b c d
Click the New button on the Input Arguments list. Choose the MVG check box in the Property Name field, then click New. Enter the Property Name and Property Value, then click OK. Click the Save to File button on the Input Arguments list to save these arguments for later use. Make sure you choose all records before saving. Chose only records you must save.
10 On the Simulator list, Click the Menu button, then choose Run on One Input.
An output argument record is created.
11 Choose the output argument record, then click the Save to File button.
144
12 When you are prompted to save the file, choose Open to display the results from the rule
invocation. An evaluation is made, depending on the revenue amount in your chosen opportunity. The opportunity must evaluate as Excellent or Good, and the Quality field must be set to 1-Excellent or 2-Good. Your output must include a structure that is similar to the following XML example: <?xml version="1.0" encoding="UTF-8" ?> <?Siebel-Property-Set EscapeNames="true"?> <PropertySet> <DerivationList> <Derivation BusCompId="6-48ZVH" BusCompName="Opportunity"> <Value>Excellent</Value> </Derivation> </DerivationList> <SetFieldValueList> <SetFieldValue BusCompId="6-48ZVH" BusCompName="Opportunity"> <Field Name="Quality">1-Excellent</Field> </SetFieldValue> </SetFieldValueList> </PropertySet>
13 If HaleyAuthority is still open, then exit HaleyAuthority.
Creating a Custom Business Service

This task is a step in Process of Creating an Opportunity Through a Siebel Task UI on page 122. After the rule module passes a simulation, you can create a business service to call the rule module. NOTE: Examples of script in this document are written for use with the ST eScript engine. To implement this example, make sure your system is configured to use the ST eScript engine in Siebel Tools. For more information about: Configuring Siebel Tools to use the ST eScript engine, see Process of Validating an Account Through a Script on page 70 Business services, see Business Rule Service on page 181
14 5
To create a custom business service 1 2

In the Object Explorer, choose the Business Service object type. Create a new business service using values in the following table. Property Name Project Cache Display Name-String Override External Use Value Rules Business Call-Task Opportunity Rules Call Back TRUE Rules Business Call-Task Opportunity TRUE
In the Object Explorer, expand the Business Service object type, click the Business Service Method object type, then define a new method in the Business Service Methods OBLE using values in the following table. Property Name Display Name-String Override Value Rules Rules
In the Object Explorer, expand the Business Service Method object type, click the Business Service Method Arg object type, then add a business service argument in the Business Service Method Arguments OBLE, using values in the following table. Property Name Data Type Type Storage Type Display Name-String Override Value vRowId String Input Property vRowId
146
Add another business service argument using values in the following table. Property Name Data Type Type Storage Type Display Name-String Override Value vQuality String Output Property vQuality
6 7 8
In the Business Services OBLE, right-click the Rules Business Call-Task Opportunity business service, choose Edit Server Scripts, then click OK. Choose Service_PreInvokeMethod, then delete the default script in the script editing window. Enter the following script in the script editing window: function Service_PreInvokeMethod (MethodName, Inputs:PropertySet, Outputs:PropertySet) { if (MethodName == "Rules") { var out:chars = Rules(Inputs, Outputs); Outputs.SetProperty("vQuality",out); return (CancelOperation); } return (ContinueOperation); } NOTE: This script references the MethodName named Rules on the custom business service that is used in this example. The Rules method on the custom business service must not be confused with the RunRules method on the predefined Business Rule Service.
In the left panel of the script editing window, expand the general folder, then click the declarations subfolder.
14 7
10 In the right panel of the script editing window, add the following custom method to the Rules
Business Call-Task Opportunity business service: function Rules(Inputs:PropertySet, Outputs:PropertySet) { try { //Declare a business service variable. var svc:Service = TheApplication().GetService("Business Rule Service");
//Declare the inputs property set variable for Business Rule Service. Declare //child and grandchild property sets that build the //hierarchical structure of the BusCompList input property. var inputs:PropertySet = TheApplication().NewPropertySet(); var child:PropertySet = TheApplication().NewPropertySet(); var grandchild:PropertySet = TheApplication().NewPropertySet();
//Declare the outputs property set variable for Business Rule Service. var outputs:PropertySet = TheApplication().NewPropertySet();
//Declare the variable that gets the row id of the new lead from the task. var RowIdInput:chars = Inputs.GetProperty("vRowId");
//Declare variables to store results. var valResult:chars; var TheResult:chars;
//Use methods to build input property set structure. //Setting RuleModuleName to module you need to call. inputs.SetProperty("KnowledgeBaseName", "taskUI_test_KB"); inputs.SetProperty("RuleModuleName", "New Lead");
148
//Setting PerformAction to "Y" because our rule statements include //setfieldvalue calls to process. inputs.SetProperty("PerformAction", "Y");
//Setting GetMoreData to "Y" because you want the rules engine to get all //the child business components and fields automatically, instead of passing //them all explicitly. inputs.SetProperty("GetMoreData", "Y");
//Build the BusCompList > BusComp > Field hierarchy. child.SetType("BusCompList"); grandchild.SetType("BusComp"); grandchild.SetProperty("Id", RowIdInput); grandchild.SetProperty("Name", "Opportunity"); child.AddChild(grandchild); inputs.AddChild(child);
// Invoke Business Rule Service. svc.InvokeMethod("RunRules", inputs, outputs);
// Examine the outputs property set.
var nChild = outputs.GetChildCount(); var i = 0; var resultType; var errorText;
// If no result, then the derivation passed in this example. if (nChild == 0)
14 9
{ return (ContinueOperation); }
// In this example, you only look for RaiseErrorText and DerivationList // because you only used those actions in the New Lead rule module. for (i = 0; i < nChild; i++) { resultType = outputs.GetChild(i).GetType();
//Process RaiseErrorText result if (resultType == "RaiseErrorText") { errorText = outputs.GetChild(i).GetValue(); return(CancelOperation); }
// Process DerivationList result. if (resultType == "DerivationList") { var j = 0; var msg:PropertySet = TheApplication().NewPropertySet(); var valList:PropertySet = outputs.GetChild(i); var valCount:float = valList.GetChildCount();
// Look at each Derivation result. for (j = 0; j < valCount; j++) { valResult = valList.GetChild(j).GetProperty("Result"); if (valResult != "Valid")
150
{ var val:PropertySet = valList.GetChild(j); var msgCount = val.GetChildCount(); var k = 0; for (k = 0; k < msgCount; k++) { TheResult = val.GetChild(k).GetValue(); } return (TheResult); } } } } }//end try catch(e) { TheApplication().RaiseErrorText("Error in the Rules function: " + e.toString()); } finally {
} } For more information, see Output Property Schema for the Business Rule Service on page 199.
11 Navigate back to the Business Services OBLE, then choose the Rules Business Call-Task
Opportunity business service.
12 From the application-level menu, choose the Tools menu, then the Compile Selected Objects
menu item.
13 Click the Compile button in the Object Compiler dialog box.
15 1
Defining Calls to the Siebel Rules Engine

This task is a step in Process of Creating an Opportunity Through a Siebel Task UI on page 122. In this topic, you define calls to the Siebel rules engine by configuring the task UI to provide inputs to the rule module and to capture the outputs for the rule module. You begin by defining process properties for the business service.
To define process properties for the business service 1 2 3 4 5

In the Tasks OBLE, query the Task Name property for Create a Lead. Make sure the Status property of the Create a Lead task UI is In Progress. Right-click the Create a Lead task UI, then choose Edit Task Flow. Click the canvas background, making sure no steps are chosen. In the MVPW, make sure the Task Properties tab is chosen, right-click anywhere below the column headers, then choose New Record to add a task UI property using values in the following table. Property Name Data Type Access Mode Value varRevenue Number R/W
Right-click, then choose New Record to add another task UI property using values in the following table. Property Name Data Type Access Mode Value varRowId String R/W
Right-click, then choose New Record to add another task UI property using values in the following table. Property Name Data Type Access Mode Value ReturnFromRulesEngine String R/W
Next, define input and output properties for the Opportunity Info step.
152
To define input and output properties for the opportunity info step 1 2
In the Task Designer, click the Opportunity Info step. In the Multi Value Property Window, click the Output Arguments tab, right-click, then choose New Record to add a new output argument using values in the following table. Property Property Name Type Business Component Business Component Field Value varRevenue Business Component Opportunity Revenue
In the MVPW, right-click, then choose New Record to add another output argument using values in the following table. Property Property Name Type Business Component Business Component Field Value varRowId Business Component Opportunity Id
Setting these output arguments allows information that is provided by the end user through the Opportunity Info task view to be assigned to task UI properties that are ultimately provided as inputs to the business service. Next, define properties for the business service step.
To define properties for the business service step 1 2

In the Task Designer, click the Call Rules Business Service step. In the Properties window, define properties using values in the following table. Property Business Service Method Business Service Name Value Rules Rules Business Call-Task Opportunity
Note that you must specify the Business Service Name, and then the Business Service Method.
3 4
Make sure the Call Rules Business Service step is chosen. Click the Input Arguments tab in the Multi Value Property Window.
15 3
In the MVPW, right-click, then choose New Record to add an input argument using values in the following table. Property Input Argument Type Property Name Value vRevenue Task Property varRevenue
In the MVPW, right-click, then choose New Record to add another input argument using values in the following table. Property Input Argument Type Property Name Value vRowId Task Property varRowId
Click the Output Arguments tab in the MVPW, right-click, then choose New Record to add an output argument using values in the following table. Property Property Name Type Output Argument Value ReturnFromRulesEngine Output Argument vQuality
In the Task Designer, right-click the connector labeled Excellent, choose Edit Conditions, add a condition using values in the following table. Compare To Task Property Operation All Must Match (Ignore Case) Object ReturnFromRulesEngine Value Excellent
Click Add, then click OK.
10 Choose the connector labeled Good. 11 In the Properties window, make sure the Type property is set to default. 12 From the application-level menu, choose the File menu, then the Save menu item. 13 Close the Task Designer.
154
Publishing, Activating, and Verifying the Task UI

This task is a step in Process of Creating an Opportunity Through a Siebel Task UI on page 122. You must publish the Create a Lead task UI, then administer it in the run-time environment. After publishing and administering, you can verify that the business rules implement the functionality defined in Designing the Business Rules Implementation on page 122.
To publish the task UI 1 2

From the application-level menu, choose the Tools menu, then the Compile Projects menu item. Compile the Rules Call Back project to the Siebel Repository File that is used by your sample database. This repository is typically located at [Siebel client root directory]\OBJECTS\[language, such as ENU]\siebel.srf
3 4 5
In the Tasks OBLE, query the Task Name property for Create a Lead. Right-click the Create a Lead task UI, then choose Validate from the pop-up menu. In the Validate dialog box, click Start to generate errors and warnings. Correct errors and revalidate the task UI until errors are resolved. The Validate tool in Siebel Tools is an error correction tool you can use before you deploy a task UI. Note that this validation enforces the semantic consistency of a task UI. It does not refer to the validation that occurs with business rules. For more information, see Siebel Business Process Framework: Task UI Guide.
6 7 8 9
Make sure the status property is In Progress. Make sure the Create a Lead task UI is chosen in the Tasks OBLE. On the WF/Task Editor toolbar, click Publish. Do not click not Publish/Activate. Click Yes in the Siebel dialog box to publish the task UI.
Next, activate the task UI.
To activate the task UI 1 2 3 4 5 6

In the Siebel client, navigate to the Administration-Business Process screen, then the Task Deployment view. In the Published Tasks list, query for the Create a Lead task UI. Click the Activate button. Navigate to the Administration- Application screen, then the Tasks view. In the Registered Tasks list, create a new record. From the Task Name picklist, choose the Create a Lead task UI.
15 5
In the Responsibilities list, add the responsibilities that are required in order to provide access to the Create a Lead task UI. Make sure you include a responsibility that is included in your position to allow you to run the task UI. For testing purposes in this example, Siebel Administrator is a responsibility you can enter.
In the Registered Tasks list, click the Clear Cache button.
Next, verify the task UI.
To verify the task UI 1 2

In the Siebel application in your run-time environment, navigate to the Opportunity screen, then click the Opportunities List link. In the Opportunity List view, click the Toggle Tasks button in the Application toolbar. The Tasks pane is displayed and includes the Create a Lead task UI.
Click the Create a Lead link. Components displayed in the first view in the task UI include:

Areas to enter the name, sales stage, close date, and revenue for a new opportunity. The red asterisks (*) indicate the required fields. The message that addresses you and requests you to populate fields exposed on the view. The playbar applet that provides navigation through the task UI.
Enter 5000000 as the revenue, then click Next. Because $5,000,000 qualifies as an Excellent opportunity, the task UI branches to the Excellent Lead Info view.
Click Previous, change the revenue to 500000, then click Next. Because $500,000 qualifies as a Good opportunity, the task UI branches to the Good Lead Info view.
6 7
Enter data and continue until the task UI finishes. Navigate to the Opportunity List view and make sure a new opportunity record is created with the expected field values, including the value for the Quality field that was generated by the task UI.
Next, verify the task UI in debug mode.
156
Verifying the Task UI in Debug Mode

To perform another level of verification, you can step through the task UI in debug mode. The procedure you perform depends on the type of web client you are using. This example assumes you are using the Mobile Web Client. For more information, see the topic about enabling the debug mode in Siebel Business Process Framework: Task UI Guide.
To verify the task UI in debug mode 1

Open the configuration file (.cfg) for the application in a text editor. For more information, see Locating the Application Configuration File on page 50.
In the [InfraUIFramework] section of the configuration file, set the EnableRestrictedMenu parameter to TRUE. For example: [InfraUIFramework] EnableRestrictedMenu = TRUE If EnableRestrictedMenu is not in the InfraUIFramework section, then add it.
3 4
Save your changes, then close the file. Use the debugger to verify that the task UI implements the desired functionality.
15 7
158
Reference Topics for Siebel Business Rules
This appendix provides reference information for Siebel Business Rules. It includes the following topics: Mapping Between Siebel and HaleyAuthority on page 159 Business Rule Tables in a Siebel Run-Time Database on page 178 Run-Time Events Supported by Business Rules on page 180 Business Rule Service on page 181 Rule Modules and Rule Statements on page 204 Siebel Test Harness on page 215 Guidelines for Implementing Siebel Business Rules on page 216 Troubleshooting Siebel Business Rules on page 218
Mapping Between Siebel and HaleyAuthority

This topic describes mapping between the Siebel object model and the HaleyAuthority semantic role model. It includes the following topics: Overview of Mapping Between Siebel and HaleyAuthority on page 159 Siebel Objects Mapped to HaleyAuthority Objects on page 161 Siebel Concepts, Relations, Actions, Functions, and Predicates on page 165
Overview of Mapping Between Siebel and HaleyAuthority

The Siebel Object Importer generates HaleyAuthority objects and relations in order to represent the Siebel objects imported and their inherent relationships. A HaleyAuthority concept is represented as the position for the concept in the concepts hierarchy, where a colon separates the levels in the hierarchy. For example, assume value: date, specific day is the HaleyAuthority Concept entry for a Siebel field type. Assume Value is a type, or child, of concept. Assume date, specific day is a type of value. Names of relations created automatically are of the form siebelparentobject_siebelchildobject. Object names are displayed in lower case with no spaces and are connected with an underscore (_).
15 9
Reference Topics for Siebel Business Rules Mapping Between Siebel and HaleyAuthority
Table 6 describes the fundamental relations and their phrasings that are automatically created in HaleyAuthority by Siebel Object Importer.
Table 6.
Relations Automatically Created in HaleyAuthority By Siebel Object Importer Name of Relation parentbusinesscomponent_ childbusinesscomponent Phrasing of Relation a parent business component has a child business component and equivalents
Siebel Objects Parent business component and child business component are both imported. NOTE: If a child business component is imported, then the parent business component for the child is automatically imported. Business component and a single valued child field are imported.
businesscomponent_field
a business component has a field and equivalents
Business component and a multi value child field are imported.
For details of multi value field imports, see Table 7 on page 161.
Not applicable.
Restrictions and Limitations with Siebel Object Importer

Restrictions and limitations with Siebel Object Importer include: You can only import one Business Object at a time. Fields that cannot be imported include:
Non UTC date and time fields
Fields of Type DTYPE_DATETIME
Calculated fields without Type Fields of Type DTYPE_CLOB
You must not manually modify concepts and relations that are built among Siebel objects in HaleyAuthority. Such changes must only be made if the relations change in the Siebel Repository, and if you then make those changes by using Siebel Object Importer to synchronize the HaleyAuthority knowledgebase with the Siebel Repository.
If a particular Siebel object is imported, then it can be used by anyone who possesses access to the HaleyAuthority authoring environment. For procedural information about using Object Importer, see Importing Siebel Objects into HaleyAuthority on page 48.
160
Siebel Objects Mapped to HaleyAuthority Objects

Table 7 describes Siebel objects and their relationships to HaleyAuthority objects.
Table 7.
Mapping of Siebel Objects to HaleyAuthority Objects HaleyAuthority Object entity value: boolean Not applicable. Explanation Not applicable. Not applicable. Not mapped, and not available to choose in the Siebel Object Importer. The length of the CLOB object can exceed the string limit for HaleyAuthority.
Siebel Object Business Component Field of Type DTYPE_BOOL Field of Type DTYPE_CLOB
Field of Type DTYPE_CURRENCY Field of Type DTYPE_DATE
entity: currency value time: period of time: specific period of time: date, specific day and value: date, specific day
Not applicable. Not applicable.
Field of Type DTYPE_DATETIME
Not available to choose in the Siebel Object Importer
Not mapped, and not available to choose in the Siebel Object Importer. DTYPE_DATETIME fields are not UTC time. Because HaleyAuthority stores time as UTC time, these fields cannot be used in predicates.
Field of Type DTYPE_ID Field of Type DTYPE_INTEGER
value: string quantity: number: decimal number: integer and value: number: decimal number: integer
Not applicable. Not applicable.
Field of Type DTYPE_NOTE
value: string
Not applicable.
16 1
Table 7.
Mapping of Siebel Objects to HaleyAuthority Objects HaleyAuthority Object quantity: number: decimal number: real number and value: number: decimal number: real number Explanation Not applicable.
Siebel Object Field of Type DTYPE_NUMBER
Field of Type DTYPE_PHONE Field of Type DTYPE_TEXT Field of Type DTYPE_TIME
value: string value: string time: point in time: recurrent point in time: time of day
Not applicable. Not applicable. A DTYPE_TIME field stores a point in time, such as the time for an activity to begin, or an interval of time, such as the duration of a phone call. Siebel Object Importer maps fields of this type to the time of day concept. Not applicable.
Field of Type DTYPE_UTCDATETIME
time: point in time: instant, specific point in time and value: instant, specific point in time
Calculated Field of Type NULL Currency
Not available to choose in the Siebel Object Importer unit of money
Siebel Object Importer imports the currencies currently in the Siebel Repository to HaleyAuthority. Not applicable.
162
Table 7.
Mapping of Siebel Objects to HaleyAuthority Objects HaleyAuthority Object Not applicable. Explanation An MVF is not modeled as a field of the parent business component for the MVF. Instead, an MVF is modeled as the destination business component and the corresponding field for the MVF. For example, in the case of the Primary Bill To Last Name field of Account, the Contact business component and the Last Name field of the business component for the Contact are automatically imported. Concepts are created for the Contact business component, primary contact, and the Last Name field. Relations are created between: contact and last name account and contact account and primary contact
Siebel Object Multi Value Field (MVF)
Link
one-to-many relation: parent business component, child business component
One-to-Many relation. A many-to-many relation between business components is represented through the Link object in Siebel. It is mapped to two relations in HaleyAuthority. Only if the Primary Id property is not null, then create a relationship, because the main purpose is to model the Primary field value. For example, for the Bill To Contact field of the Account business component, concepts created include: Concept primary bill to contact as a kind of contact entity Relation between account and primary bill to contact
Multi Value Group (MVG) link (Traditional multi value link with the Primary Id Field property specified.)
A concept is created for a kind of destination business component, which is the primary. A one-to-one relation is created: root business component, concept.
Rules run-time must determine the primary so that it can assert the data correctly.
16 3
Table 7.
Mapping of Siebel Objects to HaleyAuthority Objects HaleyAuthority Object No concepts or relations are created. Explanation Not applicable.
Siebel Object MVG link (Traditional multi value link with the Primary Id Field property unspecified.) MVG link (Indirect multi value link with the Primary Id Field property specified.)
Relation: parent business component, destination business component A concept is created for a kind of destination business component, which is the primary. One-to-one relation is created: root business component, concept described above.
In this case, you must treat the indirect multi value link as a link between this business component and the destination business component. For example, the Account Issue Action business component includes an indirect multi value link named Contact whose destination link is Action\Contact. The one-to-many relation between Account Issue Action and Contact is only kept in this indirect multi value link, and not in the destination link, as it is with a traditional multi value link. Not applicable.
MVG link (Indirect multi value link with the Primary Id Field unspecified.)
Relation: parent business component, destination business component
164
Siebel Concepts, Relations, Actions, Functions, and Predicates

Table 8 describes the concepts and relations that are created in HaleyAuthority when the Siebel Object Importer imports Siebel objects to a knowledgebase.
Table 8.
Siebel Concepts and Relations in HaleyAuthority Name Currency value Exchange date Currency code currencyvalue_currencycode currencyvalue_exchangedate currencyvalue_realnumber Explanation Required for currency operations. Required for currency operations. Required for currency operations. Phrasing: a currency value has a currency code Phrasing: a currency value has an exchange date Phrasing: a currency value has a real number
HaleyAuthority Object Type Entity Date, specific day String Relation Relation Relation
For more information about the following topics: Definitions of action, function, and predicate, see Rules Glossary on page 225 HaleyAuthority terminology, see HaleyAuthority Help
Currency Objects
Objects that are related to currency are provided because HaleyAuthority does not fully support currency with exchange date and currency code.
Concepts and Relations Created for a Multi Value Field

This topic provides an example of how concepts and relations are created when a multi value field is imported. This example is used in Importing Siebel Objects on page 140. Revenue is a Multi Value Field (MVF) on the Opportunity business component with a primary value. Revenue field values are derived from a link between the Opportunity and Revenue business components: The Revenue field for the opportunity derives revenue values from the Revenue field for the child Revenue business component for the records in the link. One of the values in the Revenue field for the opportunity is the primary revenue. It is defined by the Primary Revenue Id field on the Opportunity business component.
16 5
Table 9 describes the concepts and relations that the Siebel Object Importer creates for this example, which is similar to other multi value fields that include a primary. For this example, three of the Siebel objects involved in this import include the same name, which is not typical. Table 9 explains their roles. If you write a HaleyAuthority rule statement that refers to the value of a multi value field, in this example the revenue for an opportunity, then you use the following example instead, using the concepts and relations explained in Table 9. The example provides the path to the primary value: a business_components primary child_business_components
child_business_component_destination_field
For this example, you use the following phrase: an opportunitys primary revenues revenue
Table 9.
Concepts and Relations Created By Siebel Object Importer for an MVF With a Primary Concept or Relation Created in This Example opportunity revenue revenue
Concept or Relation Concept: business_component Concept: child_business_component Concept: child_business_component _destination_ field
Description he parent Opportunity business component. The Revenue child business component, and not the Revenue field on Opportunity. The Revenue field on the Revenue child business component, and not the Revenue field on the Opportunity business component. Note that there is only one revenue entity after the import, although it is created to represent two different objects. However, the entity includes the relations that apply to both contexts. Notice that the import log includes two lines stating that the revenue concept is created.
concept: primary child_business_component
primary revenue
This concept is created as a child concept of the concept that represents the child business component in the link. In other words, the primary child_business_component is a type of child_business_component. Again, note that revenue in this relation is the Revenue child business component in the link, not the Revenue field on Opportunity.
relation: a business_component has a child_business_component
an opportunity has a revenue
166
Table 9.
Concepts and Relations Created By Siebel Object Importer for an MVF With a Primary Concept or Relation Created in This Example a revenue has a revenue
Concept or Relation relation: a child_business_component has a child_business_component _destination_ field relation: a business_component has a primary child_business_component
Description The Revenue child business component includes a Revenue field.
an opportunity has a primary revenue
Note that revenue in this relation is the Revenue child business component in the link, not the Revenue field on Opportunity.
16 7
Siebel Actions, Functions and Predicates

Table 10 describes the actions, functions, and predicates that are created when the Siebel Object Importer imports Siebel objects to a knowledgebase.
Table 10.
Siebel Actions, Functions, and Predicates in HaleyAuthority Example Requires Importing These Objects Account BO Account BC Location
Action Type Action
Action add-currencyliteral
Purpose For a derivation type of rule, add a currency literal as a derived value from a rule
Phrasing Example if an account's location contains "CA" then add 50000 in "USD" for the account if an account's location contains "CA" then add 70000 in "USD" on today for the account if an account's location contains "Germany" then add 700000 in "DEM" on 2006/03/01 for the account
Action
add-currencyvalue
For a derivation type of rule, add a currency value as a derived value from a rule
If an account's name is not unknown then add the account's annual revenue for the account
Account BO Account BC Annual Revenue Name
Action
add-value
For a derivation type of rule, add a value as a derived value from a rule. The value is a supported noncurrency value type. For a list of types supported by Siebel Object Importer, see Table 7 on page 161.
If an account's annual revenue is more than 1000000 in "USD" then add "Gold Account" for the account
Account BO Account BC Annual Revenue
168
Table 10.
Siebel Actions, Functions, and Predicates in HaleyAuthority Example Requires Importing These Objects Account BO Account BC Name
Action Type Action
Action add-value-withtype
Purpose For a derivation type of rule, add a value for an entity with a type as string. If using add-value action for a derivation type of rule, then the type of the child property is not unique because a child has the type as Value. This is because the phrasing for addvalue is add a value for an entity.
Phrasing Example If an account's name contains "Red" then add the account's name for the account with type as "Account's Name"
Action
invalidate-withcode
For a validation type of rule, invalidate with reason represented as a code For a validation type of rule, invalidate with reason represented as text Raise an error with reason represented as code. Stop the execution for the rule.
If an account's location is unknown then invalidate the account with code as "USER_DEFINED_ERROR_ CODE" If an account's location is unknown then invalidate the account with "Please provide a location for the account" if an account's name is unknown then raise an error with code
(Does not depend on an object import.)
Action
invalidate-withreason
Account BO Account BC Location
Action
raise-error-code
Account BO Account BC Name
16 9
Table 10.
Siebel Actions, Functions, and Predicates in HaleyAuthority Example Requires Importing These Objects Account BO Account BC Name
Action Type Action
Action raise-error-text
Purpose Raise an error with reason represented as text. Stop the execution for the rule Set a Siebel business component field of type DTYPE_CURRENCY Set a Siebel business component field of type DTYPE_CURRENCY Set a Siebel business component field of types other than DTYPE_CURRENCY Set the position name for the current user
Phrasing Example If an account's name is unknown then raise an error as "Account should have a name"
Action
set-currencyfield-value
Set "Annual Revenue" of an account to the account's revenue
Account BO Account BC Revenue
Action
set-currencyfield-valueliteral
Set "Annual Revenue" of an account to 9000000 in "USD"
Account BO Account BC
Action
set-field-value
If an account's location contains "US" then set "Description" of the account to "This account is in the US" set position name to "Consultant 1" if application name is "Siebel Universal Agent" Set profile attribute of "hobby" to "fishing" set shared global of "hobby" to "pastime" If an account's name is not unknown and the account's location is not unknown then validate the account
Account BO Account BC Location (Does not depend on an object import.)
Action
set-positionname
Action
set-profileattribute set-sharedglobal validate
Set a profile attribute Set a shared global variable For a validation type of rule, validate an entity
(Does not depend on an object import.) (Does not depend on an object import.) Account BO Account BC Name Location
Action
Action
170
Table 10.
Siebel Actions, Functions, and Predicates in HaleyAuthority Example Requires Importing These Objects (Does not depend on an object import.)
Action Type Function
Action currency-literaldivided-byliteral
Purpose Arithmetic operation with currency values and currency literals Arithmetic operation with currency values and currency literals Arithmetic operation with currency values and currency literals Arithmetic operation with currency values and currency literals Arithmetic operation with currency values and currency literals Arithmetic operation with currency values and currency literals Arithmetic operation with currency values and currency literals
Phrasing Example if 100 in "USD" on 2005/ 03/01 divided by 100 in "USD" on 2006/03/01 is more than 1 then
Function
currency-literaldivided-bynumber
If 100 in "EUR" divided by 10 is equal to 10 in "EUR" then
Function
currency-literaldivided-byvalue
If 1000000 in "USD" divided by an account's annual revenue is more than 1 then
Account BO Account BC Annual Revenue Does not depend on an object import.
Function
currency-literalminus-literal
If 100 in "USD" on today minus 100 in "USD" on yesterday is equal to 0 in "USD" then If 1000000 in "USD" minus an account's annual revenue is less than 0 in "USD" then
Function
currency-literalminus-value
Account BO Account BC Annual Revenue (Does not depend on an object import.)
Function
currency-literalplus-literal
If 100 in "USD" plus 100 in "KRW" is more than 200 in "USD" then
Function
currency-literalplus-value
If 1000000 in "USD" plus an account's annual revenue is more than the account's revenue then
Account BO Account BC Annual Revenue Revenue
17 1
Table 10.
Siebel Actions, Functions, and Predicates in HaleyAuthority Example Requires Importing These Objects Account BO Account BC Annual Revenue Account BO Account BC Annual Revenue Account BO Account BC Total Potential Volume Account BO Account BC Current Volume Total Potential Volume
Action currency-literaltimes-number
Purpose Arithmetic operation with currency values and currency literals Arithmetic operation with currency values and currency literals Arithmetic operation with currency values and currency literals Arithmetic operation with currency values and currency literals
Phrasing Example If 100000 in "USD" times 12 is less than an account's annual revenue then
Function
currency-valuedivided-byliteral
If an account's annual revenue divided by 1000000 in "USD" is more than 1 then
Function
currency-valuedivided-bynumber
If an account's total potential volume divided by 12 is more than the account's revenue then
Function
currency-valuedivided-byvalue
Set "potential/current volume" of an account to the account's total potential volume divided by current volume
Function
currency-valueminus-literal
Arithmetic operation with currency values and currency literals
If an account's current volume minus 100000 in "USD" is at least the account's total potential volume then
Account BO Account BC Current Volume Total Potential Volume
172
Table 10.
Siebel Actions, Functions, and Predicates in HaleyAuthority Example Requires Importing These Objects Account BO Account BC Current Volume Total Potential Volume
Action currency-valueminus-value
Purpose Arithmetic operation with currency values and currency literals
Phrasing Example Add an account's total potential volume minus the account's current volume for the account
Function
currency-valueplus-literal
Set "Credit Auto Approval Limit" of an account to the account's credit auto approval limit plus 500000 in "USD"
Account BO Account BC Credit Auto Approval Limit Account BO Account BC Credit Used Credit Auto Approval Limit
Function
currency-valueplus-value
Add an account's credit used plus the account's credit available amount for the account
Function
currency-valuetimes-number
Arithmetic operation with currency values and currency literals Get the name of the current active view Get the name of the current Siebel client application Get the currency code for the current application
Set "Annual Revenue" of an account to the account's revenue times 12
Account BO Account BC Revenue (Does not depend on an object import.) (Does not depend on an object import.) (Does not depend on an object import.)
Function
get-active-viewname get-applicationname get-currencycode
If active view name is "Account List View" then if application name is "Siebel Universal Agent" then _ invalidate an account with "currency code should not be USD" if currency code is "USD"
Function
Function
17 3
Table 10.
Siebel Actions, Functions, and Predicates in HaleyAuthority Example Requires Importing These Objects (Does not depend on an object import.)
Action get-divisionname
Purpose Get the name of the division associated with the currently logged in user. Get the language code Get the login name of the currently logged in user Get the name of the organization associated with the currently logged in user Get the parent business component name of the current business component Get the name of the position for the currently logged in user Get a profile attribute Get a shared global variable. Get the name of the view mode
Phrasing Example if division name is "Siebel" then _
Function
get-language
if language is "ENU" then _ if login name is "SADMIN" then _ if organization name is "Default Organizaiton" then _
(Does not depend on an object import.) (Does not depend on an object import.) (Does not depend on an object import.)
Function
get-login-name
Function
getorganizationname
Function
get-parentbuscomp-name
invalidate an account with "parent BusComp should exist for Account" if parent business component name is "" if position name is "System Administrator" then _
Function
get-positionname
(Does not depend on an object import.) (Does not depend on an object import.) (Does not depend on an object import.) (Does not depend on an object import.)
Function
get-profileattribute get-sharedglobal get-view-mode
If profile attribute of "Hobby" is "Fishing" then if shared global of "hobby" is "fishing" then _ invalidate an account with "view mode should not be 5" if view mode is "5"
Function
Function
174
Table 10.
Action Type Predicate
Action currency-atleast
Purpose Comparison predicate that involves currency values and currency literals
Phrasing Example If an account's current volume is at least the account's total potential volume then
Predicate
currency-atleast-one-literal
Comparison predicate that involves currency values and currency literals Comparison predicate that involves currency values and currency literals Comparison predicate that involves currency values and currency literals
If an account's revenue is at least 3000000 in "USD" then
Predicate
currency-atleast-twoliterals
If 100 in "USD" is at least 100 in "EUR" then
Predicate
currency-atmost
If an account's current volume is at most the account's total potential volume then
Predicate
currency-atmost-one-literal
Comparison predicate that involves currency values and currency literals Comparison predicate that involves currency values and currency literals
If an account's revenue is at most 3000000 in "USD" then
Predicate
currency-atmost-twoliterals
If 100 in "USD" is at most 100 in "EUR" then
17 5
Table 10.
Action currency-equalto
Phrasing Example If an account's current volume is equal to the account's total potential volume then
Predicate
currency-equalto-one-literal
Comparison predicate that involves currency values and currency literals Comparison predicate that involves currency values and currency literals Comparison predicate that involves currency values and currency literals
If an account's revenue is equal to 3000000 in "USD" then
Predicate
currency-equalto-two-literals
If 100 in "USD" is equal to 100 in "EUR" then
Predicate
currency-lessthan
If an account's current volume is less than the account's total potential volume then
Predicate
currency-lessthan-one-literal
Comparison predicate that involves currency values and currency literals Comparison predicate that involves currency values and currency literals
If an account's revenue is less than 3000000 in "USD" then
Predicate
currency-lessthan-twoliterals
If 100 in "USD" is less than 100 in "EUR" then
176
Table 10.
Action currency-morethan
Phrasing Example If an account's current volume is more than the account's total potential volume then
Predicate
currency-morethan-one-literal
Comparison predicate that involves currency values and currency literals Comparison predicate that involves currency values and currency literals Test whether the user is in task mode
If an account's revenue is more than 3000000 in "USD" then
Predicate
currency-morethan-twoliterals
If 100 in "USD" is more than 100 in "EUR" then
Predicate
user-intaskmode
If user is in task mode then
17 7
Reference Topics for Siebel Business Rules Business Rule Tables in a Siebel Run-Time Database
Business Rule Tables in a Siebel RunTime Database

Table 11 describes tables in a Siebel run-time database that store rules metadata during run-time. Table 11. Table S_BR_MODULE Tables in the Run-Time Database Information Stored Stores rule module name and configuration data, including rule module name, business object name, data assertion mode, inconsistent flag, status, and comment. Stores information about the knowledgebase, including model dirty flag and ruleset name. Stores information about model files, including: model.bin unauthoredRules.bin unauthoredSiebelRules.bin unauthoredDiagnostics.bin measures.xml Description If a new rule module is deployed from the Siebel Deployment plug-in, then a record is created in this table. The configuration data is updated through the Administration-Business Rules screen in the Siebel client. This data is used internally only and is not visible to the user. These columns contain the semantic model data, such as concepts, relations, some basic rules, and so forth. If you deploy a rule module, and if you check Update model when deploying selected modules on the Siebel Deployment dialog box, then the records are created in this table by the Siebel Deployment plug-in. The data in this table is used internally and is not visible to the user. S_BR_MODULE_BIN Stores compiled rule modules. If you deploy a rule module, then the records are created in this table by the Siebel Deployment plug-in. The data in this table is used internally and is not visible to the user. S_BR_MOD_BC_REL Stores business component relations, including multi-value group relations, configured for each rule module. If you create or delete rows in the Rule Module Relations list on the Rule Module List View, then records are created or deleted. The data in this table queries runtime data for rule execution.
S_BR_GBL_PARM
S_BR_GBL_BINARY
178
Reference Topics for Siebel Business Rules Business Rule Tables in a Siebel Run-Time Database
Table 11. Table
Tables in the Run-Time Database Information Stored Stores business component relations imported for each business object. Description If you import a business component hierarchy for a business object, then the records are created by the Siebel Object Importer. The records are visible in the pick applet on the Business Component field of the Rule Module Relations list in the Rule Module List View.
S_BR_MDL_BC_REL
S_BR_MDL_BC_FLD
Stores imported fields for each imported business component.
If you import fields for a business component, then the records are created by the Siebel Object Importer. The records are not visible to the user and are used internally at run time when querying the run-time data for execution.
S_BR_CONCEPT
Stores the HaleyAuthority concept ID for each imported business component, field, and multi-value group. For Siebel and HaleyAuthority releases that support only one knowledgebase for each implementation, this table includes only one record for the single knowledgebase.
The records are created by the Siebel Object Importer, and used at run time, and not visible to the user. Provides support for multiple knowledgebases in future releases. The record is not visible to the user.
S_BR_KNWLDGBASE
17 9
Reference Topics for Siebel Business Rules Run-Time Events Supported by Business Rules
Run-Time Events Supported by Business Rules

The run-time events in which you can implement Siebel Business Rules include: Associate ChangeRecord CopyRecord InvokeMethod NewRecord PreAssociate PreCopyRecord PreDeleteRecord PreInvokeMethod PreNewRecord PreQuery PreSetFieldValue PreWriteRecord Query SetFieldValue WriteRecord WriteRecordNew WriteRecordUpdated
Situations for Using the PreNewRecord Run-Time Event

If using PreNewRecord, then it is important to make sure at least one record exists for the business component. If a rule is invoked and executed before a new empty row is created in the business component, then there is no row ID to validate, and a Siebel error occurs. To avoid this problem, use NewRecord instead of PreNewRecord.
180
Reference Topics for Siebel Business Rules Business Rule Service
Business Rule Service

This topic describes the Business Rule Service business service. It includes the following topics: Preparing the Business Rule Service on page 182 RunRules Business Service Method on page 185 ProcessOutput Method on page 192 Input and Output Property Usage With Siebel Development Tools on page 193 Business Rule Service Run-Time Log Files on page 195 Input Property Schema for the Business Rule Service on page 196 Output Property Schema for the Business Rule Service on page 199
The Business Rule Service business service is predefined in your Siebel Repository. Irrespective of the implementation strategy you choose, such as a workflow process or a run-time event, the Business Rule Service is the underlying service that provides the interface to the Siebel Rules Engine. The Business Rule Service, which is a wrapper around the Siebel Rules Engine, asserts Siebel data, performs actions, and provides input and output arguments. It includes two business service methods: RunRules ProcessOutput
For a specific implementation, these methods are typically used in conjunction with one another:
1 2
RunRules calls the rules engine, identifies objects involved in the business rule logic, provides instructions for rules execution, and provides the outcome of rules execution. ProcessOutput provides you a way to specify what actions to perform based on the outcome of the rules execution performed with RunRules.
Depending on the Siebel release you are using and your business process requirements, it might be necessary to prepare the Business Rule Service to use these methods. For more information, see Preparing the Business Rule Service on page 182. CAUTION: Except where directed, it is important not to modify the Business Rule Service. If your implementation requirements cannot be addressed by the predefined, unmodified Business Rule Service, then create a custom business service that calls the Business Rule Service. This way, a special configuration you define that varies from the definitions on the Business Rule Service does impact other objects or processes that also use the Business Rule Service. For implementation strategies that invoke the Business Rule Service, see Example Business Rule Implementations on page 22.
18 1
Preparing the Business Rule Service

Depending on the Siebel release you are using and your business process requirements, it might be necessary to prepare the Business Rule Service. As of Siebel CRM version 8.1, the BusCompName and ID arguments of the RunRules method, and the ProcessOutput method is not predefined. If your business rules implementation requires these objects, then you must prepare the business rule service. For a specific Tools installation, you can define objects that are referenced from multiple sources. It is not necessary to define them again. Depending on your requirements, you must perform procedures in the following topics: Preparing the RunRules Method on page 182 Preparing the ProcessOutput Method on page 183
Preparing the RunRules Method

If your implementation requires data from either the BusCompName or ID arguments of the RunRules method, then you must define these arguments on the RunRules method.
To prepare the RunRules method 1 2 3 4 5 6 7

Open Siebel Tools. In Siebel Tools Object Explorer, choose the Business Service object type. In the Business Services OBLE, query the Name property for Business Rule Service. In the Object Explorer, expand the Business Service object type, then click the Business Service Method object type. In the Business Service Methods OBLE, query the Name property for RunRules. In the Object Explorer, expand the Business Service Method object type, then click the Business Service Method Arg object type. In the Business Service Method Arguments OBLE, add a new input argument to the RunRules business service method using values in the following table. Property Name Data Type Type Storage Type Display Name-String Override Value BusCompName String Input Hierarchy Business Component Name
182
Add another input argument to the RunRules method using values in the following table. Property Name Data Type Type Storage Type Display Name-String Override Value ID String Input Hierarchy ID
In the Business Services OBLE, right-click the Business Rule Service business service, then choose Compile Selected Objects.
Preparing the ProcessOutput Method

If your implementation requires data from the ProcessOutput method, then you must define the ProcessOutput method on the Business Rule Service.
To prepare the ProcessOutput method 1 2 3

Open Siebel Tools. In Siebel Tools Object Explorer, choose the Business Service object type, then query the Name property of the Business Services OBLE for Business Rule Service. In the Business Service Methods OBLE, add a new business service method to the Business Rule Service. Use values described in the following table. Property Name Display Name-String Override Hidden Inactive Value ProcessOutput ProcessOutput FALSE FALSE
18 3
In the Business Service Method Arguments OBLE, add a new argument to the ProcessOutput method using values in the following table. Property Name Data Type Type Storage Type Display Name-String Override Value RulesEngineOutput Hierarchy Input Hierarchy RulesEngineOutput
Add another argument to the ProcessOutput method using values in the following table. Property Name Data Type Type Storage Type Display Name-String Override Value BuscompId String Input Value BuscompId
Add another argument to the ProcessOutput method using values in the following table. Property Name Data Type Type Storage Type Display Name-String Override Value TypeOrAttrName String Input Hierarchy TypeOrAttrName
Add another argument to the ProcessOutput method using values in the following table. Property Name Data Type Type Storage Type Display Name-String Override Value TypeOrAttrValue String Output Hierarchy TypeOrAttrValue
184
In the Business Services OBLE, right-click the Business Rule Service business service, then choose Compile Selected Objects.
RunRules Business Service Method

This topic describes the RunRules business service method of the Business Rule Service. It includes the following topics: Input Properties of the RunRules Business Service Method on page 185 GetMoreData Input Property on page 187 PerformAction Input Property on page 189 Output Properties of the RunRules Method on page 191
Input Properties of the RunRules Business Service Method

This topic describes input properties on the RunRules method.
18 5
Input Properties that Identify Objects Table 12 describes input properties on the RunRules method of the Business Rule Service. These properties identify objects involved with rules execution.
Table 12.
Input Properties on the RunRules Method that Identify Objects

Description Optional. This input property identifies and provides the hierarchy and data of the business components and fields that are required for the rule module that is run by the RunRules method. For each record on which to act, an element in this list includes: The name of the top-level business component in the business object hierarchy on which this rule module acts The Row_ID for the specific record of the top-level business component If appropriate, child elements that include names of required child and further descendent business components and field values required to evaluate the rule
Input Property BusCompList
BusCompName
Required. The name of the top-level business component in the business object hierarchy on which this rule module acts. To use the BusCompName property, you must explicitly add it as a method argument on the RunRules business service method with Type set to Literal. A graphic representation of this hierarchy is displayed in the Finish screen that is displayed near the end of the Object Import procedure. For more information, see Importing Siebel Objects into HaleyAuthority on page 48.
ID
Required. The record ID for the business component record currently processed by the business rule. To use the ID property, you must explicitly add it as a method argument on the RunRules business service method with Type set to Process Property.
KnowledgeBaseN ame
Required. The name of the knowledgebase that the rule module belongs to. The knowledgebase name must be specified, and it must match exactly the knowledgebase name defined in HaleyAuthority. Required. The name of the rule module to invoke. Multiple rule module names must be separated by commas. The rule module name must match exactly the rule module name defined in HaleyAuthority.
RuleModuleName
186
Input Properties that Provide Instructions During Rules Execution Table 13 describes input properties on the RunRules method of the Business Rule Service. These properties provide instructions to the rules engine on work to perform during rules execution.
Table 13.
Input Properties on the RunRules Method that Provide Instructions

Description Required. If GetMoreData is set to Y, then the logic that applies includes: Instructs the Siebel Rules Engine to get every field automatically. You must specify only the top-level business components in the BusCompList input property set . Descendent business components and imported fields are automatically included in BusCompList implicitly. In addition, specific input field values are also included implicitly.
Input Property GetMoreData
If GetMoreData is set to N, then the logic that applies includes: Instructs the Siebel Rules Engine that each field is defined explicitly. You must explicitly specify descendent business components, fields, and field values in the BusCompList property set. The input property set must contain the data to be asserted.
PerformAction
Optional. The default value of Y indicates that the action specified by the rule module, such as set-field-value or set-profile-attribute, is executed. A value of N indicates to not execute an action. Typically, the caller of the Business Rule Service then processes the output property set, which includes the results of executing rules.
GetMoreData Input Property

The Business Rule Service must be provided data, which it in turn asserts to the Siebel Rules Engine. Without data, rules cannot execute. Ways in which the Business Rule Service is provided data include: If GetMoreData is set to Y, then the Business Rule Service acquires data from an existing database record that is identified by the current business component row ID. If GetMoreData is set to N, then the Business Rule Service acquires data from the caller for the Business Rule Service. In other words, the caller must build the data that is provided to Business Rule Service.
18 7
Performance Considerations with the GetMoreData Input Property Performance considerations to weigh when setting GetMoreData include: If GetMoreData is set to Y,, then the amount of script required to define the BusCompList input property is minimized. However, the descendent business components for the top-level business component and fields imported to the knowledgebase are included in the input property set, instead of the minimal set required for the rule module to execute. Thus performance is not optimal. If GetMoreData is set to N, then performance is optimized by providing only the minimal set of the descendent business components and fields for the BusCompList input property that is required by the rule module to execute. However, you must provide the structure and data for this hierarchy explicitly, such as with a script or as XML. If GetMoreData is set to N, then the data passed in the Input Property Set is asserted into working memory without modification. It is not necessary to provide a comma-delimited list in the Value property. Data is provided by the caller for the Business Rule Service.
Direct Invocation by a Run-Time Event If you declaratively configure the run-time event in the Administration-Runtime Events screen, then the run-time event invokes the Business Rule Service directly. When the Business Rule Service is invoked directly by a run-time event, the GetMoreData input property is set to Y by default and cannot be modified. The Siebel run-time event functionality controls the provision of data to the Business Rule Service. Data is provided from the current record in the business component as required. In the case of a pre event, such as PreWriteRecord, new data that is not yet written to the database is also provided as required, and where it is appropriate. For example, if a field value is changed by a PreWriteRecord event, and if the new field value is tested when a rule is executed, then the rule evaluates the new, unwritten value instead of the existing value in the database. Using a rule with a pre run-time event in this way allows the event to execute on an existing record that is modified or on a new record.
Indirect Invocation by a Run-Time Event If a script attached to the run-time event calls the Business Rule Service, then the run-time event invokes the Business Rule Service indirectly.
Indirect Invocation by a Pre Run-Time Event If declarative configuration or a script acts on a pre run-time event, such as PreWriteRecord, then: If the rule module acts on a new record, then setting GetMoreData to N is mandatory. The declarative configuration or a script must build and provide the data for the new record. Setting GetMoreData to Y cannot be used because there is no existing record in the database from which to get the required data. If the rule module acts on an existing record, then setting GetMoreData to N is strongly recommended. If there is a possibility that the rule might act on new, unwritten data, then do not set GetMoreData to Y because a Y setting forces the Business Rule Service to act only on the existing data in the database. Thus, incorrect data might be evaluated.
188
Indirect Invocation by a Post Run-Time Event If the declarative configuration or a script is attached to a post run-time event, such as WriteRecord, then the declarative configuration or a script can set GetMoreData to Y. There is no danger that the wrong data is provided to the Business Rule Service because a post run-time event acts only on data that is already written to the database. Setting GetMoreData to N is also allowed in this situation.
Other Invocations With GetMoreData Information for other contexts in which the Business Rule Service are invoked, such as a scripted business service or a script that is attached to the step of a workflow process, include: If a workflow process or a script writes a record to the database before invoking the Business Rule Service to act on the record, then the declarative configuration or the script can set GetMoreData to Y. There is no danger that the wrong data is provided to the Business Rule Service because there is no choice to be made between written, and new, unwritten data. Setting GetMoreData to N is also allowed in this situation. If a workflow process or a script does not finish writing a record to the database before calling the Business Rule Service, then the declarative configuration or the script must set GetMoreData to N and provide the data to the Business Rule Service. If there is a possibility that the rule might act on new, unwritten data, then setting GetMoreData to Y cannot be used because the Y setting causes the Business Rule Service to act only on the existing data in the database. Thus, incorrect data might be evaluated.
PerformAction Input Property

The Perform Action input property determines the entity that is responsible for performing actions, such as setting a field value, when a rule is executed: If PerformAction is set to Y, then the Business Rule Service is responsible for performing an action If PerformAction is set to N, then the caller of the Business Rule Service, such as declarative configuration in a workflow process or a scripted run-time event, must take responsibility for performing an action
Direct Invocation by a Run-Time Event If you declaratively define the run-time event in the Administration-Runtime Events screen, then the run-time event invokes the Business Rule Service directly. If the Business Rule Service is invoked directly by a run-time event, then PerformAction is set to Y by default and cannot be modified.
Indirect Invocation by a Run-Time Event If declarative configuration in a workflow process or in a script that is attached to the run-time event calls the Business Rule Service, then the run-time event invokes the Business Rule Service indirectly.
18 9
Indirect Invocation by a Pre Run-Time Event If the declarative configuration in a workflow process or a script acts upon a pre run-time event, such as PreWriteRecord, then: If the rule module acts on a new record, then setting PerformAction to N is mandatory. The declarative configuration or a script must perform an action based on the output property set that is returned by the Business Rule Service. If PerformAction is set to Y, then an error message is generated. If the rule module acts on an existing record, then it is strongly recommended that you set PerformAction to N. If you set PerformAction to Y in this situation, then you must be careful that your rules do not result in an infinite loop. For more information, see the example described in Indirect Invocation by a Post Run-Time Event on page 189. In the example, replace WriteRecord with PreWriteRecord. The same situation applies.
Indirect Invocation by a Post Run-Time Event If declarative configuration or a script is attached to a post run-time event, such as WriteRecord, and if the event acts on an existing record, then it is strongly recommended that you set PerformAction to N. If you set PerformAction to Y in this situation, then you must be careful that your rules do not result in an infinite loop. For example, assume a WriteRecord event calls a script that invokes the Business Rule Service with PerformAction set to Y. An end user clicks to save a record, thereby invoking the WriteRecord event. The script calls the Business Rule Service, which sets a field value. The record is then saved, which invokes the WriteRecord event again, the Business Rule Service sets the field again, and so forth. The following statement provides an example that might result in an infinite loop: if an account's name contains "ABC Company" then set "Location" to "San Jose" Instead, write a statement that does not unconditionally set a field value, such as: if an account's name contains "ABC Company" and the accounts location is unknown then set "Location" to "San Jose" Other Invocations with PerformAction The Business Rule Service is invoked in other contexts, such as with declarative configuration on the step of a workflow process, as a scripted business service, or a script attached to a workflow process: If a workflow process or a script writes a record to the database before invoking the Business Rule Service to act on the record, then the script can set the PerformAction input property to Y or to N. If a workflow process or a script does not finish writing a record to the database before calling the Business Rule Service, then:

If there is a possibility that the rule might act on new, unwritten data, then you must set PerformAction to N If the rule always acts on an existing record, then you can set PerformAction to Y or N
190
Output Properties of the RunRules Method

Table 14 describes output properties on the RunRules method of the Business Rule Service. These properties perform an action in subsequent rules execution.
Table 14.
Output Properties of the RunRules Method

Description Required. Lists the string values for modifications made on the business component record by the following HaleyAuthority actions: add-value add-currency-value add-currency-literal
Output Property DerivationList
ValidationList
Required. Describes the outcome of a rule statement. ValidationList only contains valid or invalid as set by the HaleyAuthority validate and invalidate actions.
RaiseErrorText
Optional. Lists the error strings generated by the HaleyAuthority raise-error-text action.
SetFieldValueList
Optional. Lists the field values set on the business component record by the following HaleyAuthority actions: set-field-value set-currency-field-value set-currency-field-value-literal
SetProfileAttributeList
Optional. Lists the name-value pairs set by the HaleyAuthority action set-profilevalue for use globally during one invocation of the rule module. SetProfileAttribute programmatically accesses the output property set of the Business Rule Service. Usage differs in different contexts depending on whether output is captured with a run-time event, a script, a workflow process, or task UI.
19 1
ProcessOutput Method
This topic describes the ProcessOutput business service method of the Business Rule Service.
Input Properties of the ProcessOutput Method

Table 15 describes input properties of the ProcessOutput method on the Business Rule Service
.
Table 15.
Input Properties of the ProcessOutput Method

Description Required. Specifies whether to get the value of DerivationList or ValidationList. TypeOrAttrName works in conjunction with TypeOrAttrValue to return results of the rule invocation. Type is Literal. For more information, see TypeOrAttrName and TypeOrAttrValue Arguments on page 193.
Input Property TypeOrAttrName
RulesEngineOutput
Required. Specifies the type of output from the RunRules method that the rules engine must return, such as ValidationList or DerivationList.
BuscompId
Required. Stores the value of Siebel Operation Object Id. Type is Process Property.
Output Properties of the ProcessOutput Method

Table 16 describes output properties of the ProcessOutput method on the Business Rule Service.
Table 16.
Output Properties of the ProcessOutput Method

Description Required. TypeOrAttrValue works in conjunction with TypeOrAttrName to return results of the rule invocation. Situations in which TypeOrAttrValue returns an empty string include: The input is not in the expected format The business component Id is not found TypeOrAttrName is not found
Output Property TypeOrAttrValue
For more information, see TypeOrAttrName and TypeOrAttrValue Arguments on page 193.
192
TypeOrAttrName and TypeOrAttrValue Arguments

You use TypeOrAttrName to specify to the rules engine what type of information to return. The rules engine then stores the information you requested in TypeOrAttrValue.
TypeOrAttrName Set to Result If TypeOrAttrName is set to Result, then TypeOrAttrValue contains the possible results in ValidationList, whose value is either valid, invalid, or inconsistent. For example, consider this HaleyAuthority statement: if an account's name contains "internal" then invalidate the account with "An account name cannot contain internal. Please reenter the account name." In this example, if the name for the account is internal, then the rules engine returns invalid in TypeOrAttrValue. if the name for the account is not internal, then the rules engine returns valid in TypeOrAttrValue.
TypeOrAttrName Set to Value If TypeOrAttrName is set to Value, then TypeOrAttrValue contains the string value returned in DerivationList. For example, consider this HaleyAuthority statement: set Quality of the opportunity to 1-Excellent and add Excellent for the opportunity. In this example, TypeOrAttrValue contains 1-Excellent, which is a result of the HaleyAuthority action add-value.
Input and Output Property Usage With Siebel Development Tools

This topic describes situations that apply when defining an input or output property for use with various Siebel development tools. For more information about configuring GetMoreData and PerformAction with various development tools, see: GetMoreData Input Property on page 187 PerformAction Input Property on page 189
19 3
Input and Output Properties with a Run-Time Event

This topic describes situations that apply when defining input or output property on the Business Rule Service and if a run-time event is used. For information on configuring a rule module to run in a runtime event, see Chapter 8, Implementing Rules Through a Run-Time Event.
Input Properties with a Run-Time Event If you configure a run-time event to invoke a rule module, then the Siebel run-time framework implicitly generates the input property set, based on the values that you enter in the AdministrationRuntime Events screen. You cannot control the structure of the BusCompList input property or the values of the other input properties. The input property set that is implicitly provided to the Business Rule Service includes: BusCompList includes the top-level business components you specified in the AdministrationRuntime Events screen and the descendent business components and fields imported to HaleyAuthority. In addition, field values in the current record are provided. GetMoreData is set to Y to allow for implicitly building the entire BusCompList property set, given only the top-level business components. PerformAction is set to Y, making sure actions specified by the rule module are executed. RuleModuleName is one or more names of rule modules that you specify in the AdministrationRuntime Events screen.
A script, a workflow process and a task UI are configured explicitly, primarily by using Siebel Tools.
Output Properties with a Run-Time Event If you use a standard declarative configuration to integrate a rule module with a run-time event, then you cannot capture content from the output property set.
Input and Output Properties with a Script, Workflow Process or Task UI

This topic describes situations that apply when defining an input or output property on the Business Rule Service when a script, workflow process or task UI is used. For examples of generating the input and output property set when these tools are used, see: Chapter 6, Implementing Rules Through a Script on a Business Component Chapter 7, Implementing Rules Through Declarative Configuration in a Workflow Process Chapter 9, Implementing Rules Through a Script in a Task UI
194
Input Properties with a Script, Workflow Process or Task UI The RunRules input property set must be provided explicitly, such as with input arguments on the step for a workflow process, a script on a business service, or code in an XML file. Unlike the static structure of the input property set that is set implicitly for a run-time event, the actions that your rules execute, as well as performance considerations, determine your settings for GetMoreData, PerformAction, and the structure for BusCompList.
Output Properties with a Script, Workflow Process, or Task UI You can capture and parse the output property set with the same Siebel development tool you used to provide the input property set, typically as declarative configuration on a workflow process or task UI step, as standalone script, or as a scripted custom business service that calls the Business Rule Service.
Business Rule Service Run-Time Log Files

Execution of the Business Rule Service is tracked in the same run-time log files that track execution of other Siebel applications: If using the Business Rule Service in a server environment, then reference the object manager log files If using the Business Rule Service in a local environment, such as the Developer client or Mobile Web Client, then reference the Siebel.log files generated in [client root directory]\log\
The levels that log events are set on the SIEBEL_LOG_EVENTS environment variable include: 0-Fatal 1-Error 2-Warning 3-Information 4-Detail 5-Diagnostic
For more information on the log levels and their configuration, see Siebel System Monitoring and Diagnostics Guide.
19 5
Input Property Schema for the Business Rule Service

This topic describes the input property schema for the business rule service.
EAI XML Usage

If you use the Siebel EAI XML Write to File service to export a Business Rule Service input or output property set to XML, then the structure of that XML file matches the structure described in the XSD in this topic. For more information about the EAI XML Write to File service, see XML Reference: Siebel Enterprise Application Integration.
Input Property Schema

The XSD (XML Schema Definition) in this topic represents the structure of the input property set that is expected by the Business Rule Service. <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http:// www.siebel.com/xml/BizRule" targetNamespace="http://www.siebel.com/xml/BizRule" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="PropertySet" type="BizRuleInputPropertySetType"> <xs:annotation> <xs:documentation xml:lang="en"> This describes the format of Input PropertySet passed to the CSSBizRuleService. The following 3 properties can be passed. RuleModuleName-name of the rule module the caller wants to evaluate GetMoreData-whether to get more children business component data using search specifications defined with the rule module if necessary, or to evaluate the rule module with the data passed in. This is an optional property and the default is "N". PerformAction-whether to carry out the result, i.e., whether to perform setfieldvalue actions. This is an optional property and the default is "N". </xs:documentation> </xs:annotation>
196
</xs:element> <xs:complexType name="BizRuleInputPropertySetType"> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element name="BusCompList" type="BusCompListType"/> </xs:sequence> <xs:attribute name="RuleModuleName" type="xs:string" use="required"/> <xs:attribute name="GetMoreData" type="BooleanType" use="optional" default="N"/> <xs:attribute name="PerformAction" type="BooleanType" use="optional" default="N"/> </xs:complexType> <xs:complexType name="BusCompListType"> <xs:sequence maxOccurs="unbounded"> <xs:element name="BusComp" type="BusCompType"/> </xs:sequence> </xs:complexType> <xs:complexType name="BusCompType"> <xs:sequence> <xs:element name="Field" type="FieldType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="BusCompList" type="BusCompListType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="Name" type="xs:string" use="required"/> <xs:attribute name="Id" type="xs:string" use="required"/> <xs:attribute name="IsPrimary" type="BooleanType" use="optional"/> <xs:attribute name="MVLinkName" type="xs:string" use="optional"/> </xs:complexType> <xs:complexType name="FieldType" mixed="true"> <xs:attribute name="Name" type="xs:string" use="required"/>
19 7
<xs:attribute name="Type" type="FieldDataType" use="required"/> <xs:attribute name="CurrencyCode" type="xs:string" use="optional"/> <xs:attribute name="ExchangeRateDate" type="xs:string" use="optional"/> </xs:complexType> <xs:simpleType name="FieldDataType"> <xs:restriction base="xs:string"> <xs:enumeration value="DTYPE_BOOL"/> <xs:enumeration value="DTYPE_CURRENCY"/> <xs:enumeration value="DTYPE_ID"/> <xs:enumeration value="DTYPE_INTEGER"/> <xs:enumeration value="DTYPE_NOTE"/> <xs:enumeration value="DTYPE_NUMBER"/> <xs:enumeration value="DTYPE_PHONE"/> <xs:enumeration value="DTYPE_TEXT"/> <xs:enumeration value="DTYPE_UTCDATETIME"/> <xs:enumeration value="DTYPE_DATE"/> <xs:enumeration value="DTYPE_TIME"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="BooleanType"> <xs:restriction base="xs:string"> <xs:enumeration value="Y"/> <xs:enumeration value="N"/> </xs:restriction> </xs:simpleType> </xs:schema>
198
Output Property Schema for the Business Rule Service

The XSD (XML Schema Definition) in this topic represents the structure of the output property set that is generated by the Business Rule Service. For more information, see EAI XML Usage on page 196. <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http:// www.siebel.com/xml/BizRule" targetNamespace="http://www.siebel.com/xml/BizRule" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="PropertySet" type="BizRuleOnputPropertySetType"> <xs:annotation> <xs:documentation xml:lang="en"> There are predefined set of results returned from the Rules Engine. Validation-The result of evaluating rules is either valid, or invalid with reasons-validation messages. Derivation-The result of evaluating rules is one or more values whether it's derived or not. The following predefined methods. SetFieldValue RaiseErrorText SetProfileAttribute </xs:documentation> </xs:annotation> </xs:element> <xs:complexType name="BizRuleOnputPropertySetType"> <xs:sequence> <xs:element name="ValidationList" type="ValidationListType" minOccurs="0"/> <xs:element name="DerivationList" type="DerivationListType" minOccurs="0"/> <xs:element name="SetFieldValueList" type="SetFieldValueListType" minOccurs="0"/> <xs:element name="RaiseErrorText" type="xs:string" minOccurs="0"/>
19 9
<xs:element name="SetProfileAttributeList" type="SetProfileAttributeListType" minOccurs="0"/> </xs:sequence> </xs:complexType> <xs:complexType name="ValidationListType"> <xs:sequence> <xs:element name="Validation" type="ValidationType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="DerivationListType"> <xs:sequence> <xs:element name="Derivation" type="DerivationType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="SetFieldValueListType"> <xs:sequence> <xs:element name="SetFieldValue" type="SetFieldValueType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="SetProfileAttributeListType"> <xs:sequence> <xs:element name="SetProfileAttribute" type="SetProfileAttributeType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="ValidationType"> <xs:sequence maxOccurs="unbounded"> <xs:element name="Message" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
200
</xs:sequence> <xs:attribute name="Result" type="ValidationResultType" use="required"/> <xs:attribute name="BusCompName" type="xs:string" use="required"/> <xs:attribute name="BusCompId" type="xs:string" use="required"/> </xs:complexType> <xs:simpleType name="ValidationResultType"> <xs:restriction base="xs:string"> <xs:enumeration value="Valid"/> <xs:enumeration value="Invalid"/> <xs:enumeration value="Inconsistent"/> </xs:restriction> </xs:simpleType> <xs:complexType name="DerivationType"> <xs:sequence> <xs:element name="Value" type="DerivationValueType" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="BusCompName" type="xs:string" use="required"/> <xs:attribute name="BusCompId" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="DerivationValueType" mixed="true"> <xs:attribute name="CurrencyCode" use="optional"/> <xs:attribute name="ExchangeRateDate" use="optional"/> </xs:complexType> <xs:complexType name="SetFieldValueType"> <xs:sequence> <xs:element name="Field" type="FieldType" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="BusCompName" type="xs:string" use="required"/> <xs:attribute name="BusCompId" type="xs:string" use="required"/>
20 1
</xs:complexType> <xs:complexType name="FieldType" mixed="true"> <xs:attribute name="Name" type="xs:string" use="required"/> <xs:attribute name="CurrencyCode" type="xs:string" use="optional"/> <xs:attribute name="ExchangeRateDate" type="xs:string" use="optional"/> </xs:complexType> <xs:complexType name="SetProfileAttributeType"> <xs:attribute name="Name" type="xs:string" use="required"/> <xs:attribute name="Value" type="xs:string" use="required"/> </xs:complexType> </xs:schema> The following example is an output property set consisting of ValidationList only: <?xml version="1.0" encoding="UTF-8" ?> <?Siebel-Property-Set EscapeNames="true"?> <PropertySet> <ValidationList> <Validation BusCompId="6-4AH4A" Result="Valid" BusCompName="Expense" /> </ValidationList> </PropertySet> The following example is an output property set consisting of DerivationList and SetFieldValueList: <?xml version="1.0" encoding="UTF-8" ?> <?Siebel-Property-Set EscapeNames="true"?> <PropertySet> <DerivationList> <Derivation BusCompId="6-4AEEW" BusCompName="Opportunity"> <Value>Excellent</Value> </Derivation> </DerivationList> <SetFieldValueList> <SetFieldValue BusCompId="6-4AEEW" BusCompName="Opportunity">
202
<Field Name="Quality">1-Excellent</Field> </SetFieldValue> </SetFieldValueList> </PropertySet> The following example is an output property set consisting of SetProfileList only: <?xml version="1.0" encoding="UTF-8" ?> <?Siebel-Property-Set EscapeNames="true"?> <PropertySet> <SetProfileAttributeList> <SetProfileAttribute Value="eft" Name="abc" /> </SetProfileAttributeList> </PropertySet>
20 3
Reference Topics for Siebel Business Rules Rule Modules and Rule Statements
Rule Modules and Rule Statements

This topic describes reference information for rule modules and rule statements. It includes the following topics: Rule Modules on page 204 Rule Module Activation on page 206 Rule Statements on page 207
For procedural information on creating a rule module and rule statements, see Creating a Rule Module on page 50. For examples of creating a rule module and rule statements, see: Creating the Rule Module on page 72 Creating the Rule Module on page 90 Creating the Rule Modules on page 109 Creating the Rule Module on page 141
Note that this topic is not intended as the primary documentation. For more information about creating a rule module, see the HaleyAuthority documentation included in the help menu in HaleyAuthority.
Rule Modules
When Siebel objects are imported, you can create a rule module to develop business logic. A rule module is a group of rule statements you apply to imported objects. HaleyAuthority allows you to define rules as English statements that: Identify business outcomes and specify actions to perform Compose if-then, if-then-else, and unless conditions using rule statement definitions
You can add submodules to a rule module and rule statements to submodules to further organize your rules.
204
Developing Business Rules Logic

This topic describes a general approach you can apply to develop business rules logic.
To develop business rules logic 1

Write rule statements to implement the actions that constitute the end products of the logic. For example, set the value of a field, display a message, set an output property value, and so forth.
For each action statement, write conditions that invoke the action:

Write conditions that invoke the action individually as IF applicability statements. These conditions are evaluated as OR conditions. Write conditions that must be satisfied, regardless of other conditions, as ONLY IF applicability statements. These conditions are evaluated as AND conditions. Write conditions that negate the invoking action, regardless of other conditions, as EXCEPT applicability statements. These conditions are evaluated as AND NOT conditions. Similarly, if a rule module you created in HaleyAuthority is hierarchical, then state conditions and exceptions in subordinate rules statements in a way that is logically consistent with conditions in higher level rule statements. Write the statements for assumptions, if necessary.
Note that a condition is sometimes referred to as an applicability statement.
Refine the structure of the statements in each module:

Applicability statements supporting a higher level statement are typically easier to understand and debug than creating an entire IF-THEN condition as one statement. Avoid compound conditions in an individual statement by expressing the conditions as individual applicability statements.
Minimize negative logic.
Guidelines for Deploying a Rule Module

Guidelines for deploying a rule module include: Before deploying, run the Siebel Object Importer at least one time so that you can bring up the Siebel Deployment plug-in. When a rule module is deployed for the first time, make sure the status for the rule module is Inactive in your Siebel application. For more information, see Activating a Rule Module on page 57. Before deploying, make sure the module contains at least one statement that is understood. Make sure there are no draft statements in the module you must deploy. For more information, see Draft Statement on page 208. Use log files to troubleshoot problems. For more information, see Importer and Deployment PlugIn Log Files on page 16.
20 5
Rule Module Activation

Work you must perform to activate a rule module you deployed from HaleyAuthority to the Siebel run-time environment include: Make sure the rule module exists and is deployed from HaleyAuthority. For more information, see Deploying a Rule Module on page 56. Make sure the Siebel client is logged in to the same datasource that you specified as the runtime datasource to use with Siebel Object Importer and to which you deployed the rule module from HaleyAuthority.
Performance and the Data Assertion Mode Field

The value of the Data Assertion Mode field determines whether one input data set to the Business Rule Service is loaded into memory at a time, or whether every input data set is loaded into memory at the same time. An input data set at this point is a unit of transaction data consisting of the toplevel business component and the child business components for the top-level business component and fields, as defined by the BusCompList input property set. For each particular collection of data sets that are processed, performance might improve by choosing For Each instead of For All at a threshold number of data sets in the collection. At or above the threshold, performance improves. Because this threshold can differ depending upon the actual data, you might be required to test for the threshold number in your development or test environment before implementing in your production environment.
Rule Module Reconfiguration and Deactivation

When a rule module is deployed for the first time, the state for the rule module is Inactive. When the rule module is in an Inactive state, you can configure the business object for the rule module and assert mode, add rule module relations to the module, and activate it. If a rule module is activated, then the state for the rule module changes to Active. If a rule module is in Active state, then you cannot reconfigure properties for the rule module. As related to run-time, when an active rule module is invoked for the first time, it is loaded in memory and cached for future use. Options in the menu on the Rule Modules list allow the properties of an active rule module to be reconfigured or to permanently deactivate the rule module. These options include: Rule Module Reconfiguration on page 207 Rule Module Deactivation on page 207
206
Rule Module Reconfiguration If you choose Menu > Reconfigure Module in the Rule Modules list, then the state of an active rule module changes to Published. While in the Published state, you can modify the properties for the rule module and add new relations to it. If a rule module is reconfigured, or if it is in Published state, then the cached version of the module continues to run, assuming the module was already invoked at least one time while in the Active state. After the configuration is finished and you redeploy the rule module, reactivate the rule module by choosing it in the Rule Modules list, then clicking the Activate button. At this time the existing version of the module from the run-time cache is deleted. A new invocation of the rule module causes the new configuration of the module to be reloaded. The advantage of having the Published state is that the rule module can continue to run with the cached version, thus reducing downtime for the rule module.
Rule Module Deactivation You can deactivate a rule module that is in Active state by choosing Menu > Deactivate Module in the Rule Modules list. If a rule module is deactivated, then the state for the rule module changes to Inactive, and the cached version of the rule module is immediately deleted. The rule module cannot be run. You can reactivate a deactivated rule module by choosing the rule module in the Rule Modules list, then clicking the Activate button. A workflow process, a script, or a run-time event that calls a deactivated rule module immediately errors. If it is likely that the module will be called, then you must allow the module to be in the deactivated state for as short an amount of time as possible in order to avoid errors. You use the Deactivate Module option to stop running a rule module immediately for purposes of reconfiguring and reactivating the rule module, or to stop running the rule module permanently.
Rule Statements
This topic describes reference information for the rule statement. It includes the following topics: Rule Statement Components on page 208 Draft Statement on page 208 If-Then-Else Conditions on page 209 Guidelines for Writing a Rule Statement on page 210 Guidelines for Writing Rules T hat Involve Parent and Child Business Components on page 210 Common Incorrect Rule Statements on page 212 Writing Rules Using Language Independent Code on page 214
20 7
Rule Statement Components

A typical rule statement contains several components. For example: if an opportunitys primary revenue's revenue is at least 2000000 in "USD" then set "Quality" of the opportunity to "1-Excellent" and add "Excellent" for the opportunity Table 17 describes components used in this example rule statement.
Table 17.
Rule Statement Components in a Typical Rule Statement Purpose Provides conditional context. The current opportunity. The primary revenue amount. For more information, see Concepts and Relations Created for a Multi Value Field on page 165.
Statement Component if an opportunity's primary revenue's revenue
is at least 2000000 in "USD"
Operator evaluates the revenue as an integer literal and the currency code for the revenue. A currency amount must be entered in the form shown, with the currency type included in quotes. Establishes the consequence for the conditional statement. Sets the Quality field on the record for the Opportunity business component to the value 1-Excellent. The Quality field is based on a List Of Values (LOV), so the value must be an exact match to evaluate to TRUE.
then set "Quality" of the opportunity to "1-Excellent"
and add "Excellent" for the opportunity
Appends another action. If this rule applies and is executed, then adds Excellent as a Derivation value to the output property set that is returned from the rule call.
Draft Statement
A draft statement is a statement that is not understood by HaleyAuthority. If the statement is not understood, then a question mark is displayed at the beginning of the statement in the Module Explorer. You must edit a draft statement to make sure it is understood before deploying a rule module. NOTE: A rule module that includes a draft statement cannot be deployed. A rule module that includes a draft statement is not included in the list of rule modules available to deploy. After synchronizing, a rule statement that was previously understood by HaleyAuthority might become a draft statement. You must edit this draft statement before redeploying.
208
Making a Draft Statement Understood You can make a draft statement understood.
To make a draft statement understood 1 2 3

In the Edit statement dialog box, edit the rule statement syntax until the entire statement is bold and the not understood message changes to understood. From the application-level menu, choose the Object menu, then the Reparse Statement menu item. If the statement is still not understood:
a b
From the application-level menu, choose the Object menu, then the Edit menu item. Make changes so that the statement matches the directions described in Step 1.
If-Then-Else Conditions
Table 18 describes if-then-else conditions used with rule statements.
Table 18.
IF, Then and Else Conditions Used with Rule Statements Logic Represented OR AND NOT Description If at least one of the IF statements is true, then the conclusion associated with a set of IF conditions is true. If every ONLY IF statement is true, then the conclusion associated with a set of ONLY IF conditions is true. If at least one of the unless statements is true, then the conclusion associated with a set of UNLESS conditions is false.
Condition if only if unless
In cases where more than one of the condition types applies, the order of precedence is:
1 2 3
UNLESS ONLY IF IF
20 9
Guidelines for Writing a Rule Statement

Guidelines for writing a rule statement include: Instead of typing a statement, pick words from the Words list, which only provides words that are understood by HaleyAuthority at the insertion point in the statement. Use the keyboard to type quoted strings. Use double quotes to differentiate a string value, such as my cat, from words critical to the structure of the sentence. A string value is used in a location where a string value is allowed structurally. Do not capitalize words, except those in quoted strings. For a set statement, make sure the field name is quoted and not preceded by an article. Example articles include the or a.
NOTE: The period (.) in a rule statement can only be part of a quoted string. To be understood, a HaleyAuthority rule statement cannot end with a period.
Guidelines for Writing Rules That Involve Parent and Child Business Components
When you write a rule, consider the intent of your rule and the context in which it is executed. Possible errors that can occur include: An intended business process is enforced sometimes, but not all the time, because a rule is not executed in every context that applies. One or more rules create a logical paradox. That is, one or more rules incorrectly prevent the satisfaction of the conditions for a rule, thus preventing it from executing at appropriate times. A rule module executes in more contexts than intended, such as for every context of a business component instead of in a restricted context. For example, the Expense Item business component is a child business component of the Expense business component. Your business process requires that certain conditions be true of expense items before their parent expense is valid.
210
Common Incorrect Rule Statements with Parent and Child Business Components Table 19 describes some common incorrect rule statements that involve parent and child business components that require improvement.
Table 19.
Common Incorrect Rule Statements For Parent and Child Business Components Description If the record includes an expense item with no description, then the rule prevents the writing of an expense record , but the rule does not prevent an expense item from having no description. An end user might create an expense item without a description, then never return to the parent expense item on which the rule is called. This rule disallows saving an expense unless it includes an expense item. However, you cannot add an expense item to an expense while the focus is the Expense business component. You add an expense item to an existing expense in the Line Items applet, whose business component is Expense Item. Thus you can never add an expense item to an expense, because you cannot create an expense without an expense item. Correction Write the rule on a PreWriteRecord event for the expense item business component, instead of on the expense business component. Then every expense item must include a description.
Incorrect Rule Statement if an expense has any expense item which does not have a description then invalidate the expense with All expense items should have a description. This rule is called in a PreWriteRecord run-time event on the Expense business component.
if an expense has no expense item then invalidate the expense with This expense does not have any line items. This rule is called in a PreWriteRecord run-time event on the Expense business component.
If an expense report does not include contributing expense items, then the report includes a zero total, and this situation is not an issue. Instead of denying record creation with an invalidation, you can instead provide a reminder to the end user to add an expense item, such as adding the following rule to a WriteRecord event on the expense business component: if an expense has no expense item then raise an error as Remember to add expense items to this expense report.
Typically, the best practice is to attach a rule statement to the business component to which the rule most directly applies, and to appropriately restrict the context in which the rule applies.
21 1
How a Rule Is Executed Depending on Context Ways in which business components are imported include: As the primary business component of the business object that you are importing As a child business component within the business object that you are importing
Regardless of how you import a business component, a rule written on the business component executes in every context, not only when the business component is playing one or the other of the parent or child roles. For example, a rule defined on the Action business component, imported as a child business component within the Opportunity business object, also executes in the Activity screen where Action is the primary business component. For an example of choosing the appropriate business component on which to write rules, see Process of Validating a Service Request Through a Run-Time Event on page 102.
Common Incorrect Rule Statements

Table 20 describes some common incorrect rule statements and their corresponding corrections. In some of these examples, a rule statement might be syntactically correct, but semantically incorrect. In other words, HaleyAuthority might indicate that a rule statement is understood, but the rule statement might not implement the desired functionality.
Table 20.
Common Incorrect Rule Statements Description The field is not set by the rule because the correct semantic form for setting a field value must: Quote the name for the field Capitalize the field name as it is defined in the Siebel repository Not precede the field name with an article Correction set First Name of the contact to "Ricardo"
Incorrect Statement Setting a field value. You intend a rule to set a value in the First Name field for a contact. HaleyAuthority understands the following rule statement: set the first name of the contact to "Ricardo"
212
Table 20.
Common Incorrect Rule Statements Description Components required in the comparison amount for currency field comparisons include: Number of units Currency type Exchange date on which to compare Correction if an expense item has an amount that is more than 700 in "USD" on an exchange date today then raise an error as "This expense item exceeds the maximum limit."
Incorrect Statement Evaluating currency fields. If the amount on an expense item exceeds $700, then the rule must raise an error. HaleyAuthority understands the following rule statement: if an expense item has an amount that is more than 700 in "USD" then raise an error as "This expense item exceeds the maximum limit." Evaluating a multi value field. If an opportunity includes a revenue of more than $10,000, then the rule must raise an error. An opportunity can include more than one revenue. The following statement appears reasonable, but it is not understood by HaleyAuthority: if an opportunity has a revenue that is more than 10000 in "USD" on an exchange date today then raise an error as "Revenue is more than $10000."
For example, comparison with the Amount currency field.
For this example, assume you imported the Opportunity business component and the Revenue field. The Revenue field is of type currency and is a multi-value field. If you import a multi-value field, then the Siebel Object Importer imports the business component on which the multi-value link is based. In this example, the Revenue field on the Revenue business component is imported. The rule is not understood because it is comparing the Revenue business component with an amount, which is an invalid comparison. HaleyAuthority understands the statement up to the comparison, as indicated in the Edit Statement dialog with bold text representing that portion of the statement that is understood, and non bolded text representing that portion of the statement that is not understood. For more information, see Concepts and Relations Created for a Multi Value Field on page 165.
if an opportunity has a revenue and the revenue's revenue is more than 10000 in "USD" on an exchange date today then raise an error as "Revenue is more than $10000."
21 3
Writing Rules Using Language Independent Code

By default, you write rule statements that use language specific values. Alternatively, you can write rule statements that reference Siebel string values that are language independent. This technique is known as writing rules using Language Independent Code (LIC). Consider the following statement: if an account's name contains "ABC Company" then set "Account Status" of the account to "MOST_PRECIOUS" If you configure your implementation to interpret LIC, then the Siebel string value MOST_PRECIOUS is interpreted depending on the language that is used in your Siebel implementation. For EnglishAmerican, it is translated to gold. If your implementation is not configured to interpret LIC, then the literal MOST_PRECIOUS is written to the Account Status field, regardless of the language you are implementing. NOTE: HaleyAuthority only supports rules authoring in English. However, actions performed in your Siebel application can use LIC.
Setting Your Environment to Interpret LIC You can set your environment to interpret LIC when executing rules.
To set your environment to interpret LIC

In the cfg file for the application, set the following parameter:
In server mode, set BizRuleUseLIC = TRUE
For the Developer client or Mobile Web Client, create the following section: [BizRule] BizRuleUseLIC = TRUE
Note that the cfg file for Siebel Call Center is uagent.cfg. For more information, see Locating the Application Configuration File on page 50.
214
Reference Topics for Siebel Business Rules Siebel Test Harness
Siebel Test Harness

Siebel Test Harness uses a connection to the run-time database to acquire information about the metadata required to run the test. It does not perform write activity on the run-time database. Extended Siebel functions and predicates used with the Siebel Test Harness plug-in starting with Siebel CRM Version 8.1 include: currency-* functions get-active-view-name get-profile-attribute currency-* predicates user-in-taskmode
For more information about: Procedures for using the Test Harness, see Testing a Rule Module on page 52 Example usage of the test harness, see Testing the Rule Module on page 91 and Testing the Rule Module on page 111
Test Harness Output Window

The Test Harness output window provides a log file of the rule statements that are executed. These include: Unconditional action statements Conditional statements for which the if clause is true Applicability statements that are true
After running a test case, an entry of the form [test case name] on [date and time] is added to the Test Results folder under the Test Case Name folder. If you expand the concepts hierarchy in the output window, then new concepts and phrasings are displayed that you can use with the natural English language editor in HaleyAuthority in order to reference the imported business components and their fields with your rule statements. These phrasings are generated automatically by the Siebel Object Importer, and they represent the relations between the business components imported and between business components and fields imported. The phrasings are 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.
NOTE: Functions specific to Siebel, imported on your initial import with Siebel Object Importer, result in a Loaded undefined function function name line. However, the output indicates that the simulated test executes those functions.
21 5
Reference Topics for Siebel Business Rules Guidelines for Implementing Siebel Business Rules
Guidelines for Implementing Siebel Business Rules

Table 21 describes guidelines for implementing business rules. Table 21. Guidelines for Implementing Business Rules Explanation For a business component that is already imported to HaleyAuthority, various descendant business components and fields might also have been imported to HaleyAuthority. For a rule module that acts on the business component, it is likely that only a subset of the descendant for the business component and fields are used by the rule module. Setting GetMoreData to N requires you to explicitly provide the business component and field hierarchy to the BusCompList input property, but it avoids having to process the entire hierarchy of a business component when the rule module executes. To optimize performance, it is recommended to invoke the Business Rule Service fewer times by deploying a rule module that includes a large number of rule statements. This technique is preferable to invoking the Business Rule Service more often with multiple rule modules, each of which includes fewer rule statements. In general, frequent invocation of the Business Rule Service results in a higher impact on performance. It is better to create a rule module that includes more rule statements and, thus, invoking the Business Rule Service less frequently.
Guideline If you can build the necessary data required for the BusCompList input property, then it is recommended to set GetMoreData to N. If directly invoking the Business Rule Service, such as through a script or workflow process, then this technique optimizes performance .
216
Reference Topics for Siebel Business Rules Guidelines for Implementing Siebel Business Rules
Table 21.
Guidelines for Implementing Business Rules Explanation Writing for a pre event improves both database server performance and application server performance.
Guideline If invoking a rule on a run-time event, then it is recommended to write the rule for a pre event, such as PreWriteRecord, instead of the corresponding post event, thus optimizing performance. This guideline applies when the rule invokes an action, such as set field value. Where possible, it is recommended to implement business rules through declarative configuration rather than through a script. If you use a script, regardless of how you call the Business Rule Service to capture output data from the service, then you must provide a custom script that calls the service and parses the output property from the service.
Several Siebel development tools are available to implement business rules, including a run-time event, a workflow process, a task UI, and a script. Some of these tools use declarative configuration, such as a workflow process, to provide instructions to the Business Rule Service and the Siebel Rules Engine. However, if you are invoking business rules through a script, then the script must reference the Business Rule Service. The Business Rule Service is a wrapper around the Siebel Rules Engine, and it acts as an interface to the run-time environment. The custom script must provide the instructions and hierarchy set that the business service requires in order to gather data, assert data, and perform action according to Siebel Rules Engine output. If invoking business rules through a script, then there is no other way for the Business Rule Service to acquire these instructions and hierarchy set.
21 7
Reference Topics for Siebel Business Rules Troubleshooting Siebel Business Rules
Troubleshooting Siebel Business Rules

This topic provides technical support guidelines and troubleshooting information. It includes the following topics: Technical Support for Business Rules on page 218 Rules Configuration and Activation Troubleshooting on page 219 Rules Deployment Troubleshooting on page 221 Rules Output Troubleshooting on page 223
Technical Support for Business Rules

You receive Haley Systems Inc. authoring and run-time software as part of Oracles Siebel Tools installation. Besides creating and deploying HaleyAuthority rules for Siebel objects, you can also use HaleyAuthority to create and deploy rules for other applications. For help with business rules, create a service request (SR) on OracleMetaLink 3. Alternatively, you can phone Global Customer Support directly to create a service request or get a status update on your current SR. Support phone numbers are listed on OracleMetaLink 3. You can also contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle's Application Expert Services. The following guidelines must be observed on the HaleyAuthority knowledgebase in which rule statements for Siebel objects are written: The HaleyAuthority knowledgebase does not reside in the Siebel run-time database or in the Siebel Repository database The HaleyAuthority knowledgebase includes no custom concepts other than concepts that Siebel Object Importer creates The HaleyAuthority knowledgebase includes no custom relations or phrasings among concepts other than the relations and phrasings that Siebel Object Importer creates No concepts, relations, or phrasings that the Siebel Object Importer creates are deleted from the HaleyAuthority knowledgebase
218
Rules Configuration and Activation Troubleshooting

This topic provides information for resolving issues that occur when you configure and activate a rule module in the Rule Modules list of the Administration-Business Rules screen for your Siebel application. Table 22 describes symptoms and work you can perform to resolve rules configuration and activation problems.
Table 22.
Troubleshooting Tips for Rules Configuration and Activation Diagnostic Steps and Cause If the rule module is inconsistent with the currently deployed semantic role model, then this read only flag is set in the Rule Modules list. This state occurs if you deploy the rule module from HaleyAuthority, and if the semantic role model is then changed and redeployed. This situation might cause your rule module to be inconsistent with the model. Your rule then includes statements not understood by HaleyAuthority. For example, assume the module uses a field as a string in a rule statement, then a field in the Siebel Repository is changed from DTYPE_TEXT to DTYPE_BOOL. The field is imported or the knowledgebase is synchronized with the Siebel Repository. The model is redeployed with another rule module. Your rule module is then inconsistent with the currently deployed semantic role model. A rule statement using the field is inconsistent with the currently understood statements that use that field entity. Corrective Action For more information, see Correcting an Inconsistent Flag That Includes a Y Value on page 220.
Symptoms and Error Messages Inconsistent flag includes a Y value.
21 9
Correcting an Inconsistent Flag That Includes a Y Value

You can correct an inconsistent flag that includes a Y value.
To correct an inconsistent flag that includes a Y value 1 2

In your Siebel application, navigate to the Administration-Business Rules screen, then the Business Rule Knowledgebase view. In the Rule Modules list, deactivate the inconsistent rule module. For more information, see Rule Module Deactivation on page 207
3 4
In HaleyAuthority, edit rule statements to make them understood. Redeploy the rule module.
In the Rule Modules list for your Siebel application, make sure the Inconsistent flag for the rule module includes a value of N, then reconfigure and activate the rule module.
220
Rules Deployment Troubleshooting

This topic provides information for resolving issues with deploying a rule module. Table 23 describes symptoms and work you can perform to resolve rules configuration and activation problems. For procedures that support the corrective action to perform, see Configuring the Action Set on page 104.
Table 23. Context Run-time event
Troubleshooting Tips for Rules Deployment Symptoms and Error Messages At run time, you get an error message that the deployed rule does not exist. Diagnostic Steps and Cause The name of the rule module in the Business Service Context field for the Action for the run-time event must be identical to the name of the rule module in HaleyAuthority. The comparison is case sensitive and space sensitive. Corrective Action Correct the rule module name in the Business Service Context field for the Action for the runtime event.
22 1
Table 23. Context Run-time event
Troubleshooting Tips for Rules Deployment Symptoms and Error Messages At run time, you get an error message that the deployed rule does not exist. Diagnostic Steps and Cause Possible causes for this error include: The name of the rule module must not include special characters, such as an asterisk (*), question mark (?), slash mark (/ ), exclamation point (!), at sign (@) or quotes. The rule module must not be deactivated in the rules administration screen. Using the proper format, enter the knowledgebase name and module name in the Business Service Context field for the Action for the run-time event. Corrective Action For more information, see Correcting the Rule Does Not Exist Error on page 223.
Run-time event
At run time, you get an error message that the deployed rule does not exist.
If using a rule with a runtime event, then you must specify both the knowledgebase name and the module name in the Business Service Context field. Information in the Business Service Context Field uses a precise format: [knowledgebase name]:[rule module name]
222
Correcting the Rule Does Not Exist Error

You can correct the rule does not exist error.
To correct the rule does not exist error 1 2 3 4 5

Deactivate the rule module. In HaleyAuthority, rename the rule module. Redeploy the module. Activate the module, which is now displayed as a new module. Enter the corrected module name in the Business Service Context field for the Action for the runtime event.
Rules Output Troubleshooting

You can use the WritePropSet method of the Siebel EAI XML Write to File service to print the output property set returned from Business Rule Service. Use an XML viewer to examine the output. For more information, see XML Reference: Siebel Enterprise Application Integration.
22 3
224
Glossary for Siebel Business Rules
This appendix describes terms used with business rules. It includes the following topics: Rules Glossary on page 225
Rules Glossary
Table 24 describes common terms used with business rules. Table 24. Term Action Terms Used with Business Rules Definition A procedural relation that satisfies at least one of the following situations: Returns no value Produces output, consumes input, modifies data, or changes state
For example, the add-value action is phrased as add a value for an entity. BusCompName Deploy DerivationList Draft Statement Function An input argument on the Business Rule Service that specifies the name of the business component on which rule statements run. Taking rules from the HaleyAuthority authoring environment and pushing or deploying them as modules to the Siebel run-time environment. An output argument on the Business Rule Service that carries the string value assigned based on the rule definition in HaleyAuthority. A statement that is not understood by HaleyAuthority. A procedural relation that satisfies both of the following situations: Returns values Does not produce output, consume input, modify data, or change state
For example, the get-profile-attribute function is phrased as a first string is profile attribute of a second string. GetMoreData An input argument on the Business Rule Service that instructs the Siebel Rules Engine on how to get data. A value of Y indicates to get every field automatically. A value of N indicates that you explicitly define the fields to be passed.
22 5
Glossary for Siebel Business Rules Rules Glossary
Table 24. Term
Terms Used with Business Rules Definition There are two uses of this term, with significantly different definitions. For more information, see About the Siebel Business Rules Architecture on page 12. An input argument on the Business Rule Service that specifies the name of the Knowledgebase that contains the rule module invoked. Putting a specific technology into effect by performing a particular plan or procedure. A grouping of rule statements. A grouping of statements within a module. A function that returns one value, either TRUE or FALSE. An input argument on the Business Rule Service that specifies what actions to perform. The default Y indicates that actions specified by the rule module are to be executed. A value of N indicates to not execute actions. An output argument on the Business Rule Service that lists the error strings generated by the HaleyAuthority action raise-error-text. A top-level rule module is a unit of rule definition and execution. A rule module might contain submodules or rule statements. A sub module might contain rule statements. An input argument on the Business Rule Service that specifies the name of the Rule Module invoked. A logical statement built in HaleyAuthority that captures and implement business process logic in a Siebel application. In HaleyAuthority, the set of concepts and the relations among them. In order for rules to be written, the objects and relations on which the rules depend must exist as part of the semantic role model. An output argument on the Business Rule Service that identifies the field values that are set on the business component record by HaleyAuthority actions set-field-value, set-currency-field-value, and set-currency-fieldvalue-literal. An output argument on the Business Rule Service that lists the namevalue pairs set by the HaleyAuthority action set-profile-value. An input argument on the Business Rule Service that specifies whether to get the value of DerivationList or ValidationList.
Knowledgebase
KnowledgeBaseName Implement Rule Module Rule Submodule Predicate PerformAction
RaiseErrorText Rule Module
RuleModuleName Rule Statement Semantic role model
SetFieldValueList
SetProfileAttributeList TypeOrAttrName
226
Table 24. Term
Terms Used with Business Rules Definition An output argument on the Business Rule Service that works with TypeOrAttrName to return results of the rule invocation. An output argument on the Business Rule Service that returns valid or invalid depending on the results of the rule evaluation. If the rule is met, then the value is valid. If the rule is not met, then the value is invalid.
TypeOrAttrValue ValidationList
22 7
228
Index
A
actions, created by Object Importer 165 ADM, See Application Deployment Manager Application Deployment Manager, migrating run-time data 42 architecture, about 12
C
child and parent business components, writing rules for 210 concepts, created by Object Importer 165
D
data run-time, migrating 40 run-time, migrating with Application Deployment Manager 42 validation with a runtime event 102 validation with rules 70, 102 validation with script 70 database knowledge base stored in 34 runtime, rules tables in 178 Deactivate Module 207 deploying description of 15 draft statements 208 example of deploying a rule module 114 guidelines for 205 instructions with running a test case 55 procedure for deploying a rule module 56 role in procedure for activating a rule module 57 Deployment plug-in about 15 log files of the 16 design process defining business process in 25, 81, 123 determining development tools in 28 specifying business logic requirements in 26, 81, 127 specifying business process invocation requirements in 26, 82, 127 development environment guidelines for maintaining 46 HaleyAuthority 12 development process adding business logic in 71, 80, 108, 109 administering business process in 99, 155 deploying and activating rule modules in 72, 93, 142 deploying business process in 99, 155 overview of 47 providing calls to rules engine in 61, 94
B
batch processing using rules for 80 with a workflow process 80 benefits using business rules 9 business logic adding 71, 80, 108, 109 specifying requirements 26, 81, 127 business process administering 99, 155 defining 25, 81, 123 deploying 99, 155 specifying invocation requirements 26, 82, 127 testing 155 Business Rule Service about 181 about input property set 192 about the ProcessOutput method of 192 about the RunRules method of 185 creating a custom service based on the 62 description of usage in a workflow process 79 example of custom business service based on 94 example of invoking through script 74, 146 input property set schema 196 invoking through a run-time event 104 log files for 195 output property set schema 199 preparation of 182 procedure for calling of 62 role in architecture 18 setting GetMoreData 187 setting PerformAction 189 business rules, about 9 business service, about Business Rule Service 181
22 9
Index F
testing business process in 155 testing rule modules in 78, 91, 111, 118, 143 development tools, determining 28 documentation, about using 24
log files Deployment plug-in 16 Object Importer 16 runtime 195
F
functions, created by Object Importer 165
M
multi-value field, importing 165
G
GetMoreData, setting 187 groups, managing 32 guidelines creating rules 66 deploying rules 66 implementing rules with script 216 maintaining development environment 46
N
navigation dynamic, using a task 122 dynamic, using rules for 122
O
Object Importer about 13 actions created by 165 concepts created by 165 functions created by 165 predicates created by 165 relations created by 165 using 48 objects about importing with importer plug-in 13 importing 48 output property set for Business Rule Service, schema 199 troubleshooting 223
H
HaleyAuthority, about 12
I
input property set for Business Rule Service 192 for Business Rule Service, schema 196
K
knowledge base about 14 activation with 57 activation with a run-time event 116 defining connectivity 35 deleting 38 importing objects with 48 migrating between environments 39 migrating run-time data with 40 migration of 33, 39 presence requirements 15 principles for users 32 recommendations for usage 31 setting up 34 storage database 34 synchronizing 63 synchronizing with repository 19 usage with ADM 42 usage with an action set 106 using multiples of 15, 37
P
parent and child business components, writing rules for 210 PerformAction, setting 189 predicates, created by Object Importer 165
R
Reconfigure Module 207 relations, created by Object Importer rule modules activating 72, 93, 142 creating 50 deactivating 206 deploying 56, 72, 93, 142 reconfiguring 206 testing 78, 91, 111, 118, 143 rule statement as a draft statement 208 building in conditions of 209 components of 208 creating 51 definition of 9 description of grouping of 141 165
L
language independent code, writing rules in 212, 214 LIC, See language independent code
230
Index S
example of 72, 90, 110, 142, 166, 193 example of testing 112 general approach to developing 205 guidelines for creating 66 guidelines for grouping of 216 guidelines for writing of 210 including currency 215 non-examples 212 potential state of after synchronizing 64 testing of 93 versioning of 32 writing for language independence 214 rules about 9 about developing and deploying 21 about invocation 18 caching 18 creating 14 guidelines for creating 66 guidelines for deploying 66 implementing in a task 121 implementing with script 69 integrating with a run-time event 101, 102 loading 18 migrating 39 modifying 65 run-time events supported by 180 troubleshooting activation 219 troubleshooting configuration 219 troubleshooting implementation 221 troubleshooting output 223 rules engine, calling 61, 94 Rules Runtime, about 17 run-time data migrating 40 migrating with Application Deployment Manager 42 run-time events activating 115 configuring 115 integrating rules with 101, 102 rules support 180
about 13 guidelines of using with ADM 44 mapping to Siebel 159 representation in run-time knowledge base 14
T
tables, runtime database, for rules 178 task administering 155 binding views 137 creating 61, 127 deploying 155 implementing rules in 121 testing 155 technical support, about 218 test harness about 215 configuration of 52 example of using 91, 111 procedure for using 52 testing business process 97, 155 rule modules 78, 91, 111, 118, 143 task 155 workflow process 97 troubleshooting Business Rule Service output 223 rules activation 219 rules configuration 219 rules implementation 221 rules output 223
U
users, managing 32
V
views binding to task steps 137
W
workflow process activating 99 administering 99 creating 60, 80 deploying 99 testing 97
S
script creating 73 guidelines for implementing rules with 216 implementing rules with 69 semantic role model
23 1
Index W
232

Siebel Business Rules Administration Guide: November 2008

Uploaded by

Copyright:

Available Formats

Siebel Business Rules Administration Guide: November 2008

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Siebel Business Rules Administration Guide: November 2008

Uploaded by

Copyright:

Available Formats

Siebel Business Rules Administration Guide

Version 8.1 November 2008

Siebel Business Rules Administration Guide 1

Whats New in This Release Siebel Business Rules Overview

About Benefits for Siebel Business Rules

About the Siebel Business Rules Architecture

Designing Siebel Business Rules

Roadmap for Developing Business Rules Process of Designing Business Rules

Configuring the Development Environment

Overview of the Business Rules Development Environment

Process of Setting Up the Knowledgebase

Migrating Rules Between Environments

Guidelines for Configuring the Rules Development Environment

Siebel Business Rules Administration Guide Version 8.1

Developing Siebel Business Rules

Process of Developing Business Rules

Guidelines for Creating a Rule Module and a Rule Statement

Implementing Rules Through a Script on a Business Component

Implementing Rules Through Declarative Configuration in a Workflow Process

Siebel Business Rules Administration Guide Version 8.1

Publishing and Activating the Workflow Process

Implementing Rules Through a Run-Time Event

Implementing Rules Through a Script in a Task UI

Appendix A: Reference Topics for Siebel Business Rules

Siebel Business Rules Administration Guide Version 8.1

Siebel Concepts, Relations, Actions, Functions, and Predicates

Rule Modules and Rule Statements

Siebel Test Harness

Test Harness Output Window

Appendix B: Glossary for Siebel Business Rules

Siebel Business Rules Administration Guide Version 8.1

Whats New in This Release

Whats New in Siebel Business Rules Administration Guide, Version 8.1

HaleyAuthority Knowledgebase Presence Requirements on page 15

Siebel Business Rules Administration Guide Version 8.1

Whats New in This Release

Siebel Business Rules Administration Guide Version 8.1

Siebel Business Rules Overview

About Benefits for Siebel Business Rules

Benefits of Using Business Rules

Siebel Business Rules Administration Guide Version 8.1

Run-time event Siebel Workflow Siebel Task UI Business service

Siebel Business Rules Administration Guide Version 8.1

Siebel Business Rules can invoke methods, including:

Siebel business component methods Application methods

Siebel Business Rules Administration Guide Version 8.1

About the Siebel Business Rules Architecture

Figure 1 illustrates the architecture for Siebel Business Rules.

Siebel Business Rules Architecture

HaleyAuthority Development Environment

Siebel Business Rules Administration Guide Version 8.1

Siebel Object Importer

Siebel Business Rules Administration Guide Version 8.1

Siebel Business Rules Administration Guide Version 8.1

Siebel Deployment Plug-In

Siebel Business Rules Administration Guide Version 8.1

Importer and Deployment Plug-In Log Files

Siebel Business Rules Administration Guide Version 8.1

Siebel Client and Server Run-Time Environment