The ODM and DevOps Series

Article 2 – Building ODM decision artifacts when they are stored in Source Code Control

This article in the second of the ODM and DevOps series, and will discuss how to compile decision artifacts when the choice has been made to store them in a source code control (SCC). If, however, as most people, you have made the choice to store your decision artifacts in Decision Center, you can skip directly to Article 3.

Build automation

Rules and other ODM artifacts can be extracted out of source code control, either by using the Team Collaboration feature of the Eclipse environment in which Rule Designer runs, or by using dedicated tooling such as a Command Line Interface, depending on your preference and of the underlying Source Code Control tool chosen.

Irrespective of the method chosen, let’s assume that you now have a directory location on your build machine which contains either a collection of Classic Rule Projects, or a Decision Service that you want to build. You also need to have extracted out the eXecutable Object Model that these rules depend on. This article assumes you’ve already defined the steps needed to extract and compile your XOM.

Using Rule Designer

At this point, you can use the Eclipse automation feature to invoke a headless Rule Designer environment, which will basically load your rule projects, compile the decision artifacts and generate a Rule Application. This process assumes that a copy of Rule Designer is available on the build machine. The steps are well documented in this section: https://www.ibm.com/support/knowledgecenter/SSQP76_8.10.x/com.ibm.odm.dserver.rules.designer.run/build_topics/con_build_rd.html .

Note: from the standpoint of Rule Designer, there is really no difference between a Decision Service or a collection of Classic Rule Projects which together constitute a decision service. It is simply up to you to ensure that you check out from your Source Code Control all the rule projects that are meant to be assembled together into a Rule Application.

However, keeping a Rule Designer environment around on the build machine can become an issue when you put in place a Continuous Integration tool such as Bamboo or Jenkins, since they distribute compilation workload across a set of build agents, which then all have to be setup with a Rule Designer installation.

Using the Build Command

Since ODM 8.9, an alternative is to use the new Build Command feature (documented here https://www.ibm.com/support/knowledgecenter/SSQP76_8.10.x/com.ibm.odm.dserver.rules.designer.run/build_topics/con_buildcmd_intro.html ), which provides the same capability to generate a Rule Application out of a Decision Service, but with a lighter package. This feature is provided as a Maven plugin (a MOJO), so the setup of the build agents is greatly simplified, since each build agent will download the necessary plugin binary from the artifact repository. You can then direct decision artifact compilation by writing your directives in a standard maven pom file, using the following syntax:

<artifactId>loan-validation-service</artifactId>

<packaging>decisionservice</packaging>

<build>

  <plugins>

    <plugin>

      <groupId>com.ibm.rules.buildcommand</groupId>

        <artifactId>rules-compiler-maven-plugin</artifactId>

          <configuration>

            <deployments>

              <deployment>

                <name>test deployment</name>

                  </deployment>

              <deployment>

              <!-- If you have several deployment configurations,

                   make sure that they have different names. -->

                <name>production deployment</name>

              <!-- You must specify a classifier for each

                   additional deployment configuration. -->

                <classifier>prod</classifier>

              </deployment>

          </deployments>

        </configuration>

    </plugin>

  </plugins>

</build>

One of the strength of using Maven is that you can leverage the built-in dependency mechanism for retrieving the eXecution Object Model binary that the rule compiler requires to generate the Rule App, with the same standard declarative approach that Maven uses to manage dependencies.

Note: the Build Command is only available for building Decision Services, set to use the Decision Engine, and cannot handle Classic Rule Engine.

Build Command initial setup

For the Build Command to work properly, you need to follow a one-time setup (as described here https://www.ibm.com/support/knowledgecenter/SSQP76_8.10.x/com.ibm.odm.dserver.rules.designer.run/build_topics/con_buildcmd_prep_env.html ) which uploads its jar file to your maven repository, so that each build agent is able to retrieve it from there.

Testing

Testing of the decision artifacts is a more challenging task. To be conducted effectively, it assumes a RuleApp has been created (such as described above) and deployed to a Rule Execution Server. Once done, then one needs some code to go over test data, build a query to the RES interface to exercise the deployed rules against this data, compare the returned result with the expected values, and build up a test report. In short, we need a dedicated test framework, and writing one from scratch goes well beyond what this article intends to explore.

However, the good news is that such a test framework already exists in the Business Console of Decision Center, and can be invoked there. This will then be covered in the third article of this series.

Continue to Article 3 - Building and testing ODM decision artifacts when they are stored in Decision Center
or
Skip to Article 4 - Deployment, promotion, traceability