Jenkins Pipeline for TIBCO BusinessWorks 6.x

or how to save time with TIBCO BW too

7 min readDec 8, 2020

In many IT projects DevOps is a well-known applied practice because of the advantage you have in automating tests, code quality checks, and automated deployment. In this story, I’ll try to help you adding tests and deploy automation to your TIBCO Business Works 6 application.

Shopping List

Here are the list of software you need to install before start working

Apache Maven (version 3.6.3)
Jenkins (version 2.249.2)
TIBCO Business Works 6 (version 6.6.0) + HF 2 or more
TIBCO Maven Plugin (version 2.6.0)
EGit (version 5.9.0)

All installation instructions lay on linked sites

Before downloading TIBCO Maven Plugin, please, check the compatibility page because version, 2.6.0 must be used for TIBCO BW 6.6.0 while 2.7.* for TIBCO BusinessWorks 6.6.1.

You must install a JDK on your system: if you try to install the plugin referencing TIBCO JRE it wouldn’t work, but Maven wouldn’t work too.

The Business Studio Project

The first step is to Mavenize your project. It’s a quite simple operation: right-click on your application project and choose Generate POM for Application.

It opens a dialog like this one

Picture 1 — Mavenize Project Screen 1 POM details and properties

Be hurry to populate Tibco Home and BW Home fields: if these parameters do not exist the plugin will skip tests; Tibco Home must be the absolute path of your current use TIBCO_HOME, while the BW Home is the relative path of your TIBCO Business Works 6.0 installation folder.

You can set Deploy Option different than None because the drop-down lists all application target deploy options. I chose AppSpace, and the Next button is activated:

Picture 2— Mavenize Project Screen 2 AppSpace deploy options

In this screen, you need to insert your TEA pointing:

Agent host
Agent Port
Domain
AppSpace
AppNode
HTTP AppNode port
The profile you would like to use for your deployment.

Flag the Re Deploy the Application if exists if you would like to overwrite an already deployed application.

Click Finish.

Configure GitHub and Jenkins Authentication

GitHub allows you to interact with your repository using technical credentials instead of your account ones. To enable technical credentials you must create a new GitHubApp.

Because I think it’s not useful reinventing the wheel I share with you the link I used to learn how to create a new GitHub app and let Jenkins use it.

Using GitHub App authentication | CloudBees Docs

There are several reasons for considering this authentication approach including: The rate limit for a GitHub App…

docs.cloudbees.com

The page asks you to convert the generated private key: you can use OpenSSL to achieve this goal.

My GitHub credentials were named 87887 in Jenkins.

Jenkins Maven Project

At the very beginning, I chose to start with a simple Maven Project.

Let’s talk about the configuration I set up.
The first step is to configure the source code management system:

Picture 3 — Source Code Management System

The URL (URL di Deposito box) is the one you use when you execute a git clone operation. The credential box (Credenziali) must be filled with the ones set up in the previous chapter.
Because GitHub calls main your master branch, this is what you read in the Branch(Ramo) box.

Next Step is defining Maven goals

Target tasks are all performed by Maven Plug-in for TIBCO Business Works:

clean: clean previous compilations
test: which executes compilation and unit tests
package: create the ear
install: release your archive to the AppSpece configured in the POM file.

You could go in deep about the tasks by reading the plugin documentation.
The most interesting parts of the configuration are the custom POM file and additional properties (Proprietà). The repository points to the TIBCO Business Studio workspace root folder, where Maven could find any pom.xml file.
You have to point your task to the .parent folder: here the all-encompassing pom lyes.

You point to the right EAR location adding the earLocation property to your project: in fact, the working directory is the *application.parent folder while the artifact lays into the *application/target folder.
You need to tell Maven it has to use the local repository where the plugin jar file is installed because Jenkins cannot download the plugin jar from Maven Central nor in its local repository as well.

In this type of pipeline, all steps are executed sequentially and reported at the end of the process. Here is the end report.

If something fails, for example, unit tests or deploy, you have to inspect the console output and understand where it fails and why.

Jenkins Pipeline

I transform my Maven project into a Jenkins classic Pipeline.

Be hurry you installed the Pipeline Maven Integration plugin.

This type of project uses a Groovy script as a source:

node{
    stage('Build')
    {
        git url:'https://github.com/SimoneMaletta83/tibcopipeline', credentialsId:'87887', branch:'main'
        withMaven(
            mavenLocalRepo: "C:/Users/Simone Maletta/.m2/repository")
        {
            bat "mvn clean compile -f it.maletta.pipeline.tea.sample.application.parent/pom.xml"
        }
    }
    stage('Test')
    {
        withMaven(mavenLocalRepo: "C:/Users/Simone Maletta/.m2/repository")
        {
            bat "mvn test -f it.maletta.pipeline.tea.sample.application.parent/pom.xml"
        }
    }
    stage('Deploy')
    {
        withMaven(mavenLocalRepo:"C:/Users/Simone Maletta/.m2/repository")
        {
            bat "mvn install -f it.maletta.pipeline.tea.sample.application.parent/pom.xml -DearLocation=../it.maletta.pipeline.tea.sample.application/target"
        }
    }
}

I choose to split the pipeline into three steps:

Build
Test
Deploy

The first stage executes the clean compile maven tasks; I would like you to observe the withMaven context which allows you to specify Maven custom configuration as well as the repository to use. You can specify the Maven config file settings.xml too. To learn something more here is the plugin main page.

The “Test” stage executes unit tests. There is nothing noticeable but you still need to force the pom.xml file to the one into *.parent folder.

The“Build” stage deploys the application on TEA invoking the install Maven goal. As seen before you need to force the earLocation for the same reason we talk about before.

At the very end here is the Jenkins Pipeline graphical report:

The picture below shows a screenshot from my TEA.

The deployment was executed using POM deploy information part: it allows you to insert only one node, but the install goal span the app all over the AppSpace nodes.

What’s next

I hope everything I talk about in this story was useful for you. You could consider this story as an entry point to TIBCO/Jenkins pipelines.
The first next step is to parameterize your pipeline to use it not only in a single environment: one of the parameters could be TIBCO BW profile, the script I wrote uses the one referred to by the pom.xml file.
You find the profile as a property allowing you to overwrite it at runtime.

Second step: push your pipeline to git and enable Jenkins to use your versioned file. The advantages of this approach are described in the Conclusions chapter.

At the end: define a WebHook. A WebHook automates the start of the pipeline: GitHub notifies Jenkins every time a push is executed over the branch your pipeline is listening on.

Conclusions

In this story, I showed you the benefits obtained by using a Jenkins pipeline to build, test, and deploy a TIBCO Business Works 6 application.

The first approach was using a Maven Project. It works quite good but for me has got some limitations: for example if something fails you need to go in deep with the console log to understand where it fails and why, you have no statistics to understand which goal is the most expansive in time too. From another hand, it’s very quick to configure, and using it for test and POC purposes or as a starting point gives you many advantages as a complete pipeline project.

The pipeline approach is more suitable for a large scale system: your pipeline script could be pushed into your favorite Source Code Management System and is more flexible in parameterization. This allows you to version your pipeline just as your code; you can define a branch for each environment while your Jenkins instance stores your environment configuration.