Monday, December 19, 2011

WPS: Decription about Business Rules : Rule Set and Decision Table


Business rules

A business rule is a condition that must be satisfied when a business activity is being performed. A rule can enforce a business policy, make a decision, or infer new data from existing data.

An example of a business rule

A vendor establishes the preferred status of each customer and creates a business rule to determine how much each customer is charged for the same object. Here are some basic terms that define the building blocks of each and every business rule:
Conditions
A condition describes a situation or state that must be in place in order for a specific action to occur. In this example, the condition is the customer's status.
Actions
An action is the event that results from the evaluation of the condition. Each action is uniquely bound to the condition that precedes it. In this example, the action is the quotation of the price; it is different for each of the conditions that is encountered.

When to use business rules

A business rule is anything that captures and implements business policies and practices. A rule can enforce business policy, make a decision, or infer new data from existing data.
The WebSphere® Integration Developer tools have been designed so that users can easily compose integrative business solutions without programming skills. To this end, you can easily create and develop business rules in an intuitive graphical programming environment.
In general, you should use business rules to make a decision when any of the following conditions are met:
  • you want to change the results at runtime, on a running server instead of hard-coded logic in your solution.
  • the decision itself naturally takes on the form of a table
  • the decision itself naturally takes on the form of a series of textual if-then statements.
If you want to modify the business rule dynamically you must base your rule on a template. Basing rules on templates gives you more dynamicity at runtime and allows you to modify settings without involving an integration developer.
If your decision logic analyzes a collection of data or loops over a set of data, you should probably structure the decision in a sequential process, and call out to a rule set whenever there is configurable data.

Building business rules: task roadmap

A high-level view of the development of a business rule is presented.
You are in the process of planning your business process.
  1. Decide if a business rule is an appropriate solution for your business process. A business rule is an ideal solution when you want to have flexibility to change your business process at runtime.
  2. Create a rule group. The rule group is the primary element of a business rule, it provides the interface between the business process and the rule logic. The rule group also defines date ranges during which specific rule logic applies.
  3. Decide which rule logic to use. Some business rules are better suited to a decision table, some to a rule set.
  4. Create your chosen rule logic. The rule logic is either a rule set or a decision table.
  5. Create templates for your rule logic. By creating a template for your rule set or decision table you can build up a library of rule logics that you can reuse in the future. The template also allows you to stipulate which parameters of the rule logic can be modified by the business analyst using the Business Rule Manager. Additionally constraints can be applied to these parameters so that the changes made with the Business Rule Manager are within acceptable ranges.
  6. Assemble your rule group into a business process, test and deploy.

Choosing between a rule set and a decision table

You can capture business rule logic using either a rule set or a decision table. Here are some suggestions for how to decide which format to use.
Begin by sketching out a plan for your rules on a white board or a notepad. Use structure and terminology that is natural to the business environment in which these rules will be used. Then, look for the following trends in the finished product:
  1. If your rules seem to take the form of a large number of unstructured sentences, then you should probably use a rule set to capture their business logic. A rule set is more flexible than the more structured decision table.
  2. If you notice that every rule seems to use the same decision criteria, then it would be a good idea to use a decision table. In this case, the decision criteria that all the rules share in common can be captured once, and then you can define the parameters for each criteria.
  3. If your rules naturally take the form of a table, then you should probably use a decision table.
  4. However, if this table has a large number of holes, where some decision criteria are not applicable, or where the output values are undefined, then you should use a rule set. The structure of the decision table works well for regularity, but not for exception cases.

Creating a rule group

Create a rule group as a container for your business rules.
Create a new rule group by performing the following steps.
  1. In the workbench, switch to the business integration perspective.
  2. From the main menu, click File > New > Rule Group.
  3. In the New Rule Group window, specify a module (or create one if necessary by clicking New), a folder and a name for the new rule group, and click Next.
  4. In the select an interface window, browse to an existing interface or click New to create one. If you create a new interface here, you will have to create an operation using the interface editor before you can use it in the rule group.
This creates a rule group, and launches it in a new editor. Click any of the topics listed below to configure your new rule group.

Creating a rule set

This topic provides instructions on how to create a new rule set.
  1. In the workbench, switch to the business integration perspective.
  2. From the main menu, click File > New > Rule Set.
  3. In the New Rule Set window, specify a module (or create one if necessary by clicking New), a folder and a name for the new rule set, and click Next.
  4. In the select an interface and operation window, browse to an existing rule group, or click New to create one. If necessary, use the drop down lists to select a different interface and operation.
  5. Click Finish.
This creates a rule set, and launches it in a new editor. Click any of the topics listed below to configure your new rule set.

Creating a decision table

This topic provides instructions on how to create a new decision table.
  1. In the workbench, switch to the business integration perspective.
  2. From the main menu, click File > New > Decision Table.
  3. In the New Decision Table window, specify a module (or create one if necessary by clicking New), a folder and a name for the new decision table, and click Next.
  4. In the select an interface and operation window, browse to an existing rule group, or click New to create one. If necessary, use the drop down lists to select a different interface and operation.
  5. If you want to configure the layout of the decision table, click Next.
  6. In the Decision Table layout window, use the settings to determine how the decision table will appear in the editor. The preview shows what the table will look like.
  7. Click Finish.
This creates a decision table, and launches it in a new editor. Click any of the topics listed below to configure your new decision table.

Weak type support with business rules

Business object definitions can have XSD wildcards that can be used in business rules logic.
Such wildcards can represent a placeholder for any of the following:
  • an arbitrary simple type (xs:anySimpleType)
  • an arbitrary complexType (xs:anyComplexType)
  • an arbitrary type (simple or complex, called 'xs:anyType')
  • an arbitrary element (xs:any)
For more advanced mapping and expressions involving weak types or attributes use other components such as interfaces or business objects maps.
Restrictions:
  • No local variables in a rule set can be of weak type.
  • You cannot use weak types in computations or comparisons.

Choosing the correct template parameter values

To make sure that you don't have any syntax inconsistencies with template parameters in the runtime environment, please understand the following.
WebSphere® Integration Developer and WebSphere Process Server use a different syntax for template parameter values. This inconsistency does not affect rule set or decision table processing, but will make it more awkward to edit some business rules in the business rules manager.
In WebSphere Integration Developer, the value for a float template parameter must take the form '9.99f', where 9 is any number, and 'f' is a float delimiter. If the 'f' delimiter is not used in WebSphere Integration Developer, a validation error is added to the rule set. If the float value is syntactically correct, the rule can be deployed to the WebSphere Process Server server, and executed without error.
In the business rules manager, a value for a float template parameter must take the form '99.9'. If you view or edit the rule set or decision table in the Web client, a validation error will be added for any float value which includes the 'f' delimiter.
This inconsistency is only a problem if you want to modify the rules and save the new version to the WebSphere Process Server server. In this case, you must manually remove the 'f' delimiter from all float values in the Web client before you can save the new version

Refactoring business rules

When you refactor parts of your business rules, dependencies on those parts are automatically and universally updated throughout the product as a whole.
To refactor parts of your business rules, proceed as follows:
  1. In the Business Integration view, right-click the business rule.
  2. From the drop-down menu, hover over Refactor and then choose from one of the following three options:
Option
Description
Rename
Use this option to change the name assigned to the rule.
Move
Use this option to move your rule to a new folder or module.
Change Namespace
Use this option to assign a new namespace to your rule.

Generating documentation for your rules

If you need a high level synopsis of your business rules, including how they interact with other resources within the same project, you can create a customized report using the documentation generator.
A generated document can very quickly provide you with the following:
  • a quick understanding of a project or resource
  • an overview report about a complex project
  • the visualization of the relationships and cross references of resources within a project
  • a detailed report that can be printed out for certifications
To create a report for your business rules, proceed as follows:
  1. In the Business Integration view, right-click either your rule group, rule set, or decision table and select Generate Documentation.
  2. Configure the Documentation Generation wizard according to the instructions in the Generating documentation topic.

Launching the Business Rules Manager

The Business Rules Manager is a Web client that allows dynamic control of parameter values in template based rules that are deployed to the Websphere Process Server.

Before you begin
Make sure that both the server and client are configured correctly. See Considerations for installing the business rules manager for more information.
The default URLs for accessing the business rules manager are:
  • https://hostname:9443/br (if security is enabled)
  • http://hostname:9080/br (if security is not enabled)
where hostname is the name of the host.