Using Decision Server

Decision Server provides development and runtime components for rule-based solutions that automate the implementation of the highly variable decisions that are used by client applications.

Decision Server components:
  • Rule Designer: An Eclipse-based development environment in which you design, author, test, and deploy decision services.
  • Rule Execution Server: Provides the runtime environment for running and monitoring decision services.

In a rule-based solution, a client application calls a decision from a decision service. The client application can require many decision points in a decision service. Each decision point has business rules that are packaged as rulesets, which express policies for making decisions. A decision service is deployed to Rule Execution Server as a RuleApp. Each RuleApp contains one or more rulesets, each corresponding to a decision.

The following diagram shows how the different components interact:

Diagram shows the Decision Server components.
Note: Decision Server also interacts with Decision Center, which includes a rule repository and a collaborative web console for business users to author, manage, validate, and deploy decision services (see Using Decision Center.)

The design and development phases of decision services take place in rule projects. The decision service supports complex decisions in which several rule projects are grouped into one entity. Synchronization, branching, and change management are applied to all the rule projects in the decision service hierarchy, allowing the behavior of the decision service to be governed and deployed consistently.

Feature Decision service
Project hierarchy Main and standard rule projects
Ruleset definition Decision operations
Branch management Project hierarchy
Release management Decision governance framework
Synchronization Rule artifacts and deployment configurations

Designing

In Rule Designer, you design the granularity of your decision service and the contract with the client application. You also design the model and vocabulary for authoring business rules.

Designing involves putting in place the necessary infrastructure for editing rules and producing one or several rulesets:
  • 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 by using a unique signature of input and output parameters. In decision services, you create decision operations, which define the content and signature of the ruleset. Because you can use the same rule projects and packages in different decision operations, a decision service can easily evolve 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) that 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 to allow 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 that are based on the ILOG® Rule Language (IRL) and require programming skills.

As part of authoring, you can also do the following actions:
  • Define vocabulary categories to filter the vocabulary elements that are available when you author business rules.
  • Create rule authoring 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

Authoring business rules

Debugging

You debug a ruleset in Rule Designer:
  • 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 the ruleset as a whole.
Category Topic
Learn more

Reviewing a rule project

Debugging rulesets

Testing

In Rule Designer, you prepare the capability for business users to run tests and simulations in Decision Center.

Category Topic
Learn more

Testing and simulating rulesets

Integrating

You integrate the client application from Rule Designer.

After the ruleset contract is set, you host the ruleset on Rule Execution Server and call the ruleset from the client application. Managed and monitored, Rule Execution Server is an execution environment for deployed business rules in rulesets. 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.

You call a ruleset from a client application through the hosted transparent decision service (HTDS) REST service.

Decision Server provides components for each option.

Category Topic
Learn more

Executing rules by using the REST service

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 is fully validated and approved, you can deploy it to Rule Execution Server for use in a production environment. You can deploy from Rule Designer or Decision Center. See also Connecting Rule Designer.

Business rules are deployed from a decision service by using a deployment configuration, which defines what to assemble into 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 an artifact that can be synchronized with Decision Center, and is subject to change management and governance in the Business console.

The following table lists deployment features:

Feature Decision service
Deployment definition Deployment configuration
Deployment version Defined in deployment configuration
Deployment targets Defined in deployment configuration
Deployment options Rule Designer and Decision Center Business console
Deployment history Audit trail in Decision Center
Category Topic
Learn more

Deploying rules

Deployment configurations

Connecting Rule Designer

To be able to connect Rule Designer to Decision Server, you need a Zen API key. For more information, see Using a Zen API key for authentication.

The Zen API key can be generated by a user with the following permissions:
  • ODM - Administer Decision Center
  • ODM - Administer Decision Server

You need to select the connection of the Zen API key provider, and then enter the generated Zen API key.

Administering and monitoring

Rule Execution Server provides tools to administer and monitor decision services:
  • You use the Rule Execution Server console or its REST API to manage rulesets and execution in the Decision Server.
  • You can 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.

Auditing

Ruleset execution trace data provides an audit trail of past decisions, which can required for regulatory requirements. This type of data provides a means to investigate a decision that is rendered in a past transaction by showing all associated rules.

By using Decision Warehouse with Rule Execution Server, you can manage, back up, and remove stored decisions. Decision Warehouse also stores and retrieves detailed reports on rulesets for which monitoring is enabled.