Continuous Integration with webMethods 9.X

A subset of DevOps, Continuous Integration is a vital step towards better quality and faster innovation

Read about the benefits of the Continuous Integration (CI) and how it can be easily applied to webMethod solutions.

Issue 2, 2017

Download PDF

An introduction to CI

The aim of CI is to prevent integration problems, referred to as “integration hell,” when the code of a group of developers comes together. The idea is to have all sources put together and automatically tested on daily basis. Integrating and testing in such small iterations helps identify and fix problems early on instead of having long unpredictable testing phases before a release.

Key components of CI are:

Let’s look in detail how these components apply to webMethods products.

Version control for your Integration Server assets

The modern way to develop on the Integration Server is with the local development environment. This implies that every developer is self-sufficient and can develop assets on his own. She/he can share hers/his work via VCS. The most popular choices today are Git and Subversion®.

The Software AG Designer comes with a pre-installed Eclipse™ Git plugin, while the SVN plug-in has to be additionally installed.

1.1  Central repository

Software AG has created a template repository structure that can be found on its GitHub® organization 

The structure is self-explanatory and has placeholders for Integration Server packages, Integration Server unit tests, BPM processes and Business Rules. You can fork this GitHub repository or just clone the structure and use it in your VCS of choice.

We will focus on Integration Server Packages and Unit Test Framework tests.

1.2  Set up a developer workstation

Software AG recommends having a DevOps Edition installation for every webMethods developer in the organization. This installation type consists of Designer, Integration Server and Unit Test Framework with their respective licenses.

Connect all workstations to your copy of webmethods-sample-project-layout. Use the official template, as it works seamlessly in the CI scenario described later.

1.3  Unit Test Creation

The Unit Test Framework tests are hosted in Java® Eclipse Projects and their XML descriptors should always be placed in the resources/**/setup folder inside the test project. Following this convention will enable the CI script to find and execute the tests. Those tests will have to be placed in the respective location in the central repository. Please check the Readme.md of the Github template structure for more information.

CI infrastructure

When developers are using dedicated machines and a central repository for the projects source code, the foundations for your DevOps setup are laid. The next step is to create infrastructure that will regularly check out the repository content, deploy it on a test server and execute all developers’ defined tests. This is, in short, CI.

The infrastructure will consist of a CI Server/webMethods Build Server and a webMethods Test Server. Our recommendation is to always keep the CI/webMethods Build Server physically separated from the webMethods Test Server. For test purposes both can be combined, but this should not be your permanent set-up. A good idea is to have the webMethods Test Server running in a Docker® container, as it will be stateless and easily disposable after the deployment.

CI workflow

1.1 Set up a Test Server

The test server should be a webMethods installation with a set of components similar to your production environment with the only difference that the Unit Test Framework should be installed on the Integration Server to support call mocking during complex integration tests.

Set up a CI/webMethods Build Server

1.3.1 webMethods Installation

Install Asset Build Environment and webMethods Integration Server that contains only the Deployer package. There is no need to have a database connection, the Integration Server can run in “embedded” mode.

HTTP(S) connection between the build server and the test server should be allowed.

1.3.2   CI Scripts

Download the official Software AG CI scripts from the SoftwareAG GitHub organization - sagdevops-ci-assets

In the scripts directory, edit the file called System.properties. The provided data should reflect your infrastructure – addressed of test and build server and their credentials.

Note their location of the scripts on the filesystem as this will be set in Jenkins® as environment variable later.

1.3.3   OS Environment

Make sure the default Java in the path is the JDK shipped with your webMethods installation, e.g., add ${SAG_HOME}/jvm/ jvm/bin to the system Path variable. Make sure Java gets resolved when you call Java from the command line.

1.3.4   Jenkins

Download and install the latest version of Jenkins. Make sure your installation contains the pipeline plugin.

• Jenkins has to run with the same user as your webMethods Build Server so that the two can interact seamlessly.
• Provide Jenkins with two environment variables, in the server’s system configuration:

SAG_CI_HOME should be pointing to the location where you saved the CI scripts.

SAG_HOME should be pointing to the location where your build server is installed

Set up Jenkins environment variables

1.3.5   Set up the build job in Jenkins

Create a new job in Jenkins from type pipeline. Set up the pipeline definition to be obtained from SCM. Select your SCM and point to your own repository that is a copy of standard template project webmethods-sample-project-layout

For script path – select Jenkinsfile.unix of Jenkinsfile.win depending on what OS your build server is running.

Uncheck the “Lightweight checkout” box so that you always do a full checkout of your repo and not only of the Jenkinsfile.

Sample configuration of the Pipeline job

Build the pipeline job and what the results. The first run will take longer, as Jenkins will checkout your whole repository, parse the Jenkinsfile* and then execute the steps defined in it.

Sample Jenkins Pipeline results

Examine the job results and see a test trend of all Unit Test Framework executions. Notice that all packages present in the repository get automatically deployed on the test server. If new package(s) and new tests get uploaded to your repository, those will also get automatically deployed and executed via the job run.

Conclusion

The benefits achieved with this CI setup are:

1. Optimal development setup
2. Automated build, deploy and test execution of the repository content
3. Integration can be done step by step and can be scheduled arbitrarily
4. Visibility and prevention for code integration problems

More information about the DevOps Edition and the Unit Test Framework can be found in the official SoftwareAG documentation portal. The Unit Test Framework became an official webMethods product in version 9.10 and can be
provisioned via Software AG’s Installer and Command Central from version 9.12.