This article was originaly published in 2017.08.02
IBM Operational Decision Manager (ODM) with UrbanCode Deploy
IBM offers an Automation plug-in as well as a Source Configuration plug-in for integrating Operational Decision Manager (ODM) with UrbanCode Deploy (UCD). By combining these capabilities, users can schedule, regulate, and automate the deployment of their RuleApps from the Rule Designer to any number of Rule Execution Servers. ODM has the ability to deploy directly to a rule execution server, by generating the RuleApp from a Classic Rule Project, or Decision Services. The source configuration plug-in for UCD is designed to mimic this packaging and extraction capability, but rather than deploying it, stores it in the CodeStation repository. By storing and versioning these artifacts within UCD, users can enjoy the benefits of UrbanCode Deploy when deploying their Rule archives, including automated deployments, robust visibility, traceability and auditing capabilities. It is also important to note that not all users may find benefit from the source configuration plug-in. An example of where it is not necessary is when Rules are being exported to a separate host repository, such as Maven, Nexus, or a File System. In this case, UCD can still import these artifacts as component versions, but would require the use of other subsequent source configuration types, depending on the source repository. Additionally, if the artifacts are being built in Jenkins or another similar build tool (which is often the case with Data Models/XOMs), they can be pushed directly to UrbanCode Deploy using the Jenkins plug-in.
Contents
Getting Started
Compatibility
The following software products and versions are required for running the ODM integration on an IBM UrbanCode Deploy server:
- IBM UrbanCode Deploy 6.1.1.1 or later
Automation Plug-in:
- IBM Operational Decision Manager 8.0.1 or later
Source Configuration Plug-in:
- IBM Operational Decision Manager 8.6 or later
- For versions of ODM prior to version 8.6, Version 3 of the Source Configuration plug-in must be used alongside the Enterprise Console (/teamserver) rather the Business Console. (/decisioncenter)
The plugins can be downloaded from the following pages:
Using the Source Configuration Plug-in
Setup and Installation
Once you have downloaded the plug-in from the download page, it can be installed on UCD through Settings -> Source Configuration Plugins -> Load Plugin.
Source Configuration Plug-in Install Page
Once the plug-in is installed, it is important to locate and/or copy the required JAR files necessary for running the plug-in. Since ODM requires separate licenses, the source code JARs cannot be distributed alongside the plugin. This page provides details on the requirements for running the plug-in. The JARs can be found in the ODM install directory, at $ODM_SERVER_LOCATION$/teamserver/lib. If the UCD Agent for Version imports is installed on the same server as the ODM Server, this path can be referenced directly in the 'Jar Path' field of the plug-in. Alternatively, the folder can be copied to another location on the agent machine, or copied directly to the ODM plug-in lib directly, where they are added to the plugin classpath.
Configuration
To configure an ODM designated component in UCD, we can go to Components -> Create Component, and within 'Source Configuration Type', select IBM ODM in the dropdown list. This option is only available after the source configuration plug-in has been installed on the server.
Example ODM Component Configuration
The above configuration is showing an example configuration of how the following Decision Services branch would be configured in UCD. The following screenshot is showing the referenced Project, Branch, and configuration in the ODM Business Console. Using these settings, UCD is able to import the same version artifacts from ODM that are generated by hitting the 'Deploy' button on the top right of the Business Console screen.
Example Deployment Configuration for a Project Branch in ODM
Version Imports
Once we have created our component, we can import the artifacts as versions by selecting the Versions tab, and selecting 'Import New Versions'. The option to import an 'ODM Snapshot' will appear. This can be used if a snapshot has already been created on the ODM Business Console with certain configuration settings, and we would like to deploy this version.
However, leaving the field blank, UCD will generate its own incremental name for the version using the latest available configuration from ODM. As a result of this latter scenario, the following artifacts will appear. In the name '1.0-ibm-ucd-81', "1.0" refers to the version of the ruleApp within ODM itself, "ibm-ucd" refers to the 'Version Name Pattern' we specified in the component configuration, and "81" refers to the "Next Version Number", which we have incremented 81 times in this case.
Example ODM Component Version with Imported Artifacts
Once we have a component version located in UCD, regardless of whether it was pulled from a Maven repo, File System, or pushed from a build tool like Jenkins, we can now operate on and deploy the Artifacts using the Automation Plug-in.
Using the Automation Plug-in
Installation
Once you have downloaded the plug-in from the download page, it can be installed on UCD through Settings -> Automation Plugins -> Load Plugin.
Automation Plug-in Install Page
Since the Automation plug-in for ODM is designed around the Rule Execution Server REST API, it does not require any additional JARs or agent configuration. Subsequently, the agent can run on the same local server as UCD as long as we are using CodeStation to store the artifacts.
Steps
The ODM Automation Plug-in offers the following steps to be executed on the Rule Execution Server:
ODM Automation Plug-in Steps
For full details on the plug-in step configuration, see ODM steps documentation
Example Deployment
For a simple deployment to the Rule Execution Server, we can create a component process on our component, titled 'Deploy'. Within this process, the following steps are needed:
Example ODM Deployment Component Process
The default settings within Download Artifacts can be used to download our 'test_deployment.jar' from the component version we selected at deploy time:
Example Download Artifacts Step Configuration
The 'Deploy Rule Archive' step can then be configured with the following hard-coded settings to reference the file within the working directory, and deploy it directly to the Rule Execution Server:
Example Deploy Rule Archive Step Configuration
Scalability
These settings show the most basic configuration for deploying extracted Rules from Decision Center to a Rule Execution Server (RES). However, UCD offers extensive configurability to be able to deploy across many environments quickly and repeatedly.
Configuring multiple Rule Execution Servers on UCD:
- 1. Create an environment for each Rule Execution Server to deploy to.
- 2. Set a required property on the component environment to reference the hostname/ports of the RES environment.
- 3. Set the 'Hostname' and/or 'Port' field on the plugin Deploy step to reference this property (ex.
${p:environment/propertyName}).
Running a deployment application process with this configuration will now pass the location variables for the RES depending which environment is selected.
Configuring Rule Execution Server Deployments in Series UrbanCode Deploy offers the built-in ability to deploy artifacts in parallel across any environments directly from the CodeStation repository. Often in ODM, it is necessary to deploy Rule Archives directly from one RES to the next. The Automation plug-in for UCD provides this capability as well.
The key to this scenario is running the 'Fetch Rule Archive' step and 'Deploy Rule Archive' step in series. This can be done in a wide variety of ways, depending on the use case. One example would be to:
- 1. Create a component process for deploying from one RES to another.
- 2. Create a component process property for the retrieval RES hostname and port, and another property for the receiving RES hostname and port.
- 3. Add step 'Fetch Rule Archive', referencing the retrieval properties mentioned in step 2.
- 4. Add step 'Deploy Rule Archive', referencing the receiving properties mentioned in step 2.
Running this process will now download the Archive directly from RES1, store it in the UCD agent working directory, and deploy it to RES2 in a simple process.
#OperationalDecisionManager(ODM)
#UrbanCodeDeploy