Overview: Decision Server Rules
- Rule Designer is an Eclipse-based development environment in which you design, author, test, and deploy rule applications.
- Rule Execution Server provides the runtime environment for running and monitoring rule applications.
At the core of a rule-based solution, you have a client application requesting a decision from a rule application. There can be many decision points required of the rule application by the client application. At each decision point, business rules packaged as rulesets are used to express policies for how decisions are made. A rule application is deployed to Rule Execution Server as a RuleApp. Each RuleApp contains one or more rulesets, each corresponding to a decision.
The following diagram illustrates how the different components interact:
The design and development phases of rule applications are managed through rule projects. A decision service is the recommended unit of rule management, since it allows for complex decisions that involve several rule projects to be grouped as one entity. Synchronization, branching, and change management are applied to all rule projects in the decision service hierarchy, allowing the decision service behavior to be governed and deployed consistently.
You can also manage your rules in classic rule projects. The two approaches share features but manage them in different ways. The following table lists features and how they are handled in the two approaches.
| Feature | Classic rule project | Decision service |
|---|---|---|
| Project hierarchy | Standard rule projects | Main and standard rule projects |
| Ruleset definition | Rule project properties | Decision operations |
| Branch management | Project | Project hierarchy |
| Release management | Through branches or customization | Decision governance framework |
| Synchronization | Rule artifacts only | Rule artifacts and deployment configurations |
Classic rule
projects are deprecated in V8.8.0. This feature will be removed in
a future release of the product. See Deprecated features for migration
details.
Designing
In Rule Designer, you design the granularity of your rule application and the contract with the client application. You also design the model and vocabulary for authoring business rules.
- You define the set of business rules that are put together as one executable decision unit called a ruleset. The ruleset uses input and output parameters to pass data to and from the client application. You define each ruleset and its parameters with a unique signature of input and output parameters. In decision services, you create decision operations, which defines the content and signature of the ruleset. Because you can use the same rule projects and packages for different decision operations, a decision service can easily change as new decision points requiring different signatures are added.
- You define the vocabulary that is used in business rules. In Rule Designer, you develop the business object model (BOM) which defines the elements and relationships in the vocabulary. You can define the vocabulary by mapping the BOM to the Execution Object Model (XOM). You can also create the vocabulary by generating the BOM from the XOM, and then configuring the business vocabulary from the BOM.
- You set up a rule project hierarchy. A rule project is a type of Eclipse project that is dedicated to the development of rule applications. With decision services, a main rule project is designed to be the top-level project, which allows the decision service behavior to be governed and deployed consistently.
- In the rule projects, you organize rule packages for storing business rules and define a ruleflow to specify their flow of execution.
- You define properties for managing and tracking business rules, by using rule model extensions.
- You set up business user validation tools, by configuring and customizing tests and simulations.
Authoring
If you are responsible for creating and managing the rules, you might author most of the business rules in the project. If business users are responsible for creating and managing the rules, you set up tools to facilitate rule authoring for them. You can create the different types of business rules, mainly action rules and decision tables. These business rules are all based on the Business Action Language (BAL), which is designed to look like natural language. In addition, you can create technical rules, which are based on the ILOG® Rule Language (IRL) and require programming skills.
- Define vocabulary categories to filter the vocabulary elements that are available when you author business rules.
- Create rule authoring extensions. You can use these extensions to integrate value editors for specific vocabulary elements, or to define dynamic domains that retrieve values from a data source.
| Category | Topic |
|---|---|
| Learn more | |
| Follow a tutorial | |
| View a sample |
Debugging
- You debug the ruleset by using an embedded rule engine to manage rule execution.
- You analyze rules by using constrained semantic queries, which check the consistency and completeness of individual rules and of the ruleset as a whole.
| Category | Topic |
|---|---|
| Learn more | |
| Follow a tutorial |
Testing
In Rule Designer you prepare the capability for business users to run tests and simulations in Decision Center.
| Category | Topic |
|---|---|
| Learn more | |
| Follow a tutorial |
Integrating
You integrate the client application from Rule Designer.
After the ruleset contract is established, you host the ruleset on Rule Execution Server and call the ruleset from the client application. Rule Execution Server is a managed, monitored execution environment for deployed business rules. Rule Execution Server handles the creation, pooling, and management of ruleset instances so that client applications can call the resulting decisions as easily as possible.
A plain Java™ interface.
Local EJBs.
A remote Java virtual machine (JVM) that uses remote EJBs.
Message-driven beans (asynchronously).
You can host the ruleset as a transparent decision service to be called through web service protocols.
Decision Server provides components for each option.
| Category | Topic |
|---|---|
| Learn more | |
| Follow a tutorial | |
| View a sample |
Deploying
A RuleApp defines a group of rulesets that are deployed together. The RuleApp also contains the input and output parameters that represent the contract with the client application, and the ruleset path needed by the client application to identify rulesets and their versions.
When a decision service or classic rule project is fully validated and approved, you can deploy to Rule Execution Server for use in a production environment. You can deploy from Rule Designer or Decision Center. If you are using classic rule projects, Decision Center does not apply versions to RuleApps, and there is no governance over who can change RuleApps.
The features that enable deployment are different depending on whether you use decision services or classic rule projects.
With decision services, you deploy by using a deployment configuration, which defines what to assemble in a RuleApp and where to deploy it. A deployment configuration can reference one or more decision operations. A decision operation includes all the settings needed to produce a ruleset: input and output parameters, main ruleflow, and any rule extraction. The deployment configuration is similar to the RuleApp definition for classic rule projects, but it is an artifact that can be synchronized with Decision Center and subject to change management and governance in the Business console.
The following table lists deployment features and how they are handled by the two approaches.
| Feature | Classic rule project | Decision service |
|---|---|---|
| Deployment definition | RuleApp | Deployment configuration |
| Deployment version | Managed by administrators in RuleApps | Defined in deployment configuration |
| Deployment targets | Selected at deployment time | Defined in deployment configuration |
| Deployment options | Rule Designer and Decision Center Enterprise console | Rule Designer and Decision Center Business console |
| Deployment history | Found in Rule Execution Server | Audit trail in Decision Center |
Classic rule
projects are deprecated in V8.8.0. This feature will be removed in
a future release of the product. See Deprecated features for migration
details.
| Category | Topic |
|---|---|
| Learn more | |
| Follow a tutorial | Tutorial: Creating a decision service with multiple projects |
Administering and monitoring
- You use the Rule Execution Server console, Ant scripts, or enterprise management tools (such as IBM® Tivoli® or HP OpenView) and JMX MBeans to monitor the execution of rulesets within Rule Execution Server.
- You can debug rules that are running in Rule Execution Server.
- You create backup versions of rulesets and revert to a previous version if necessary.
- You also monitor and archive execution results in decision warehouse. You can also gather statistics on performance.
| Category | Topic |
|---|---|
| Learn more | |
| Follow a tutorial | Tutorial: Debugging a remote Rule Execution Server application |
Auditing
- By using decision warehouse with Rule Execution Server you can manage, backup, and remove stored decisions. Decision warehouse also stores and retrieves detailed reports on rulesets for which monitoring is enabled.
- You create key performance indicators (KPIs). Business users often adjust policies to reflect changing business conditions and improve performance, by using these KPIs.
| Category | Topic |
|---|---|
| View a sample |