A typical Operational Decision Manager (ODM) Rules setup will contain three major components: Decision Server Rules, Decision Center, and Rule Designer. Each component has its own function, and interacts with the others as rules are developed, deployed, and executed. In this post, we will learn the functions and interactions of each ODM Rules component.
Decision Server Rules, also known as Rule Execution Server, is the runtime environment in which rule services are exposed to and called by client applications. Rules are typically executed through SOAP and REST calls, but can also be called through a Java API.
Decision Server Rules includes a tool called Decision Warehouse, which can log rule requests and responses along with other rule execution details, such as which rules fired and rule execution duration. This is especially useful for developers or auditors as they understand what decision was made and why.
It is common to have separate instances of Decision Server Rules for different environments, such as development or production. Production environments requiring high volume and continuous availability may consider clustering multiple instances of Decision Server Rules.
Decision Center (previously called Teamserver) provides a work space for business users and developers to view, collaboratively author, and deploy rules through their web browser. Decision Center is a distinguishing feature of ODM from other rule engines, and maximizes business agility.
Decision Center acts as a repository, similar to SVN or Git. This brings useful features to business users, such as automatically keeping a history of a rule, being able to compare previous revisions of a rule, and built-in documentation of changes. As a project grows, branches or releases are created to separate changes in progress from rules currently in use. Once an update been validated, it is integrated with the “live” rules.
A typical ODM setup will consist of a single Decision Center installation. Some architects may suggest a Decision Center installation for each environment (development, production, etc.) similar to Decision Server Rules, but that is generally not necessary or recommended. Decision Center is analogous to a code repository, which is generally a single entity. Instead of multiple Decision Centers, a project should use branches or releases to separate phases of development, which can be deployed to whichever Decision Server Rules environment(s) is appropriate. To save resources, a single enterprise may wish to have different projects and even different departments share a Decision Center installation, with governance to allow users visibility only to projects for which they are authorized.
Decision Center is made up of two web consoles: Decision Center Business Console, and Decision Center Enterprise Console. The Business Console is the newer, more user-friendly interface which is on its way to eventually replace the Enterprise Console. However, some administrative features for IT users are not yet implemented in the Business Console. If a feature exists in both consoles, the Business Console should be used.
While Decision Center provides an excellent environment for business users, developers will need something different for some of their tasks. Rule Designer is an Eclipse-based Integrated Development Environment for developers to create and modify rule applications. It is compatible with Eclipse plugins, and can be used for other development, such as Java programming. Rule Designer is necessary in the initial stages of rule development, for example when creating the data models. Rule Designer should be installed on each developer’s workstation; business users should have no need to use it.
Each of these components work with one another in different ways as rule applications are developed.
Decision Center and Decision Server Rules: After rules have been developed and validated, Decision Center can be used to deploy to one or more Decision Server Rules servers.
Decision Center and Rule Designer: Both components are capable of modifying rule artifacts, so it is essential to keep them synchronized. From Rule Designer, a developer can publish a local copy of rules to a Decision Center repository and/or update the local copy from Decision Center.
Decision Server Rules and Rule Designer: Like Decision Center, Rule Designer can be used to deploy to a Decision Server Rules environment. However, because changes can be made outside of Decision Center and its validation processes, this is best done for deployments to a development environment only.
To prevent deployments from Rule Designer to production systems, system administrators can give production deployment authorizations to a service account. This account would be the only one given authorizations to deploy to a production environment, and it credentials would not be distributed. Developers can be given monitor (read-only) access to the production Decision Server Rules console.
We can see the main components of ODM and how they function with each other. Decision Server Rules is the runtime environment, called by client applications. Rule Designer and Decision Center provide separate environments to author rules, tailored to the needs of developers and business users respectively. Rule Designer and Decision Center can synchronize their rule artifacts with each other, and each can deploy to Decision Server Rules server. With each type of user being given an environment tailored to them, IBM’s ODM can provide a powerful platform to manage business rules.