Decision Server
The following Decision Server components are in the cloud portal:
- Rule Designer: An Eclipse-based development component for designing, authoring, testing, and deploying decision services.
- Rule Execution Server: The execution component for running and monitoring rule applications deployed from decision services.
In a rule-based solution, a client application requests a decision from a rule application. The client application can contain many decision points that use the rule application. At each decision point, business rules in rulesets express policies for decisions. A rule application is deployed to Rule Execution Server as a RuleApp. Each RuleApp contains one or more rulesets, and each ruleset corresponds to a decision.
Decision Server also interacts with Decision Center, which includes a rule repository and collaborative web console for business and technical users to author, manage, validate, and deploy decision services.
Rule applications are designed and developed in decision services, which can implement complex decisions. Synchronization, branching, and change management are applied to all the rule projects in a decision service hierarchy, allowing the decision service behavior to be governed and deployed consistently.
Creating
In Rule Designer, you create the model and vocabulary for authoring business rules to put in place the infrastructure for editing rules and making rulesets:
- You define the business rules that make up an executable decision unit, or ruleset. The ruleset uses input and output parameters to pass data to and from the client application. You give each ruleset a unique signature of input and output parameters. In decision services, you create decision operations that define the contents and signatures of rulesets. Because you can use the same rule projects and packages in different decision operations, you can easily change a decision service to add new decision points that require different signatures.
- You define the vocabulary that is used in the 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. In a decision service, a main rule project serves as the top-level project so that the decision service behavior can be governed and deployed consistently.
- You organize rule packages in rule projects to store business rules and define a ruleflow to specify the order for executing rules.
- 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 a 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 following types of business rules:
- Action rules
- Decision tables
These business rules use the Business Action Language (BAL), which is designed to have a natural language syntax. You can also create technical rules, which are based on the ILOG® Rule Language (IRL) and require programming skills.
Authoring might require you to define vocabulary categories to filter the vocabulary elements that are available when you author business rules.
Machine Learning integration
IBM Watson Machine Learning extracts key characteristics, patterns, and anomalies from your historical data to create predictive models. These models then contain insights from your data that you can transform into actions and business decisions. Your company's historical data contains information that can improve your business decisions.
By integrating Machine Learning models into decision services, you can apply predictive insights from historical data and prescriptive business decisions based on company policies.
Debugging and testing
You can debug a ruleset in Rule Designer, and test that the decision service or a project implements the expected business logic:
- You debug the ruleset by using a 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.
- You run test scenarios on rules. You can run these tests locally in Rule Designer, without the entire Rule Execution Server component.
Integrating
After the ruleset connection is defined, you host the ruleset on Rule Execution Server and call it from the client application. Rule Execution Server is the execution component for deployed business rules. It handles the creation, pooling, and management of ruleset instances so that client applications can call the decisions as easily as possible.
To call the ruleset from the client application, you post the ruleset as a hosted transparent decision service (HTDS) that is called through web service protocols.
Deploying
A RuleApp holds a group of rulesets that are deployed together. The RuleApp also contains the input and output parameters that define the interaction 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 production. You deploy the decision service by using a deployment configuration that 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, including input and output parameters, main ruleflow, and any rule extraction. The deployment configuration can be synchronized with Decision Center, where it is subject to change management and governance.