WebSphere Operational Decision Management introduces a native branching capability in the Decision Center (ex-RTS) that provides intuitive solutions to the various project versioning requirements.
Project branching in Decision Center
Branches are an integral part of working with the Decision Center. Before starting any work, you need to select the target rule project as well as the branch you want to use in that rule project. Below Figure shows the home page of the Decision Center where you make this selection.
Decision Center home page
By default, a rule project exists with a single branch, the “main” branch. At any time, you can create a sub-branch from the “branch in use” by selecting the Create subbranch action in the Current action menu, as shown in Figure
Create a subbranch
When you need to join concurrent project branches, the Merge Branches action provides a business user friendly way to perform the merging operation. After designating the branch to perform the merge with, Decision Center displays the set of differences to merge and proposes possible actions to be performed (replace in one branch or in the other, or do nothing), as shown in Figure . You can choose the desired direction for the merge in order to limit the set of differences that get displayed.
Merge branches actions
A detailed view of the differences, as shown in Figure is provided for each artifact to help with the merge task, and to allow fine grain difference management.
Detail of merge differences
This is about the extent of the operations on branch management in Decision Center. By deliberately limiting the set of operations, branch management is kept as non-technical as possible, so that it can be easily used and understood by business users.
The concept of baselines is still present in Decision Center, but baselines are now read-only snapshots of the project state (a baseline cannot be unfrozen anymore). The role of baselines is to represent:
A designated restore point for development baselines, similar to a tagged version for an SCCS.A reliable deployment state that can be used for clean promotion through the different rule environments, from testing to production.
Managing bug fixes
The branching capability of Decision Center makes bug fixes straightforward. Assume that the promotion of a new ruleset version was initiated from the main branch by creating a deployment baseline named loanvalidation-1.0.0.
If a defect is found in the rules while going through QA, the rule authors can simply clone the deployment baseline to a branch as shown in Figure, and start using this branch to fix the defect.
Figure Deployment baseline section from the Manage Subbranches and Baselines page
Once the fix is completed, you need to define a new RuleApp in order to deploy from the new branch instead of main. The definition of rulesets in Decision Management includes the specification of the project version from which the ruleset should be extracted. As shown below, the version can be either a baseline (such asloanvalidation-1.0.0) or a branch (such as loanvalidation-1.0-bugfix). For our example, we’ll select the latter.
Figure Select the project version
You can make additional fix iterations on the bug fix branch until the version is ready to be released in the production environment. At this point, the last task to complete is to merge the changes from the bug fix branch to the main branch. You can do this with the Merge Branches action, previously shown on . In this case, we’ll select the Only to ‘main’ Branch option for the direction.
Below Figure illustrates these three steps.
Managing bug fixes process
Managing concurrent rule service enhancements
Concurrent enhancements to a rule service are also made straightforward through project branches. When a change to the business policy is submitted, you can create a branch to implement and unit-test the change request. When you’re ready to deploy the change, you can merge the updated project elements back to the main branch, and a deployment baseline is created as a result of deploying the updated RuleApp.
Figure Concurrent rule service enhancement process
The concept of rule project security as proposed in RTS is now managed at the branch level. In large projects that include business policies coming from multiple LOBs or business groups, this allows for enforcement of fine-grain security by dedicating branches to certain groups (for example, pricing andeligibilit
Below Figure shows the new branch security options in Decision Center.
Branch security options in Decision Center
Managing rule project refactoring
Rule project refactoring, involving changes to the BOM for example, remains a task that is shared between Rule Designer (formerly Rule Studio) and the Decision Center
The merge operation in Decision Center does not include the BOM or the ruleset parameters. Updates to these artifacts on a given branch must therefore come from a synchronization operation with Rule Designer.
The refactoring process is accomplished as follows:
Create a branch to be the temporary production branch, to support ongoing maintenance.In Rule Designer, create a rule project from the Decision Center project’s main branch.Perform the rule project refactoring. Meanwhile, all project maintenance work will be handled through the temporary production branch. There should be no activity on the main branch until refactoring is completed.When the refactoring is complete, synchronize the Rule Designer project with the Decision Center project’s main branch, overriding the content of the main branch.Merge the temporary production branch back to the main branch.
The main benefit in this scenario is that the merging operation is using the rule specific diff instead of the generic textual diff based on the BRL format
