Building a Mapping Sheet Dynamically from TIBCO BW5 with a Generic Tool

28 Oct, 2020 | 5 minutes read

Overview

In the last couple of months, we have been working on a project that required migrating all TIBCO BW5 adapters from a certain group into BWCE one by one and another group into MuleSoft as the client’s goal was to switch on the cloud-based environment.

At that moment, we all knew that it would be an extremely exhausting and long process since it is completely impossible to manage such a load in a short period of time because we needed to check every process and review internally all of the overwhelming logic that every single developer has built since most of the codebase was not done by convention.

Likewise, if we added imported custom functions that are used in most of the message transformation, the codebase would have turned out to be a complete mess so it would take a lot of time to replicate into another integration platform.

Hence, we concluded that we needed something that would speed up and make this migration easier. That’s how we have come up with our newest generic tool for exporting XSLT expressions from BW5 processes into a Mapping sheet.

So far, as a team of TIBCO Integration developers, we have managed to produce a couple of supporting BW productivity tools, which significantly accelerate development and reduce time consumption for unit testing.

Ref: https://iwconnect.com/use-cases-of-supporting-tibco-bw-productivity-tools/

This specific tool, which we describe further in the article, has the purpose of accurately showing all XSLT expressions of a certain process passed as an argument, into an Excel file for mapping purposes.

Generic Mapping Tool

We decided that it is necessary to come up with a generic lightweight solution for exposing the XSLT transformation in a dedicated Mapping sheet which will significantly improve the development process and escape the tedious process of seeking and double-checking each activity.

We already knew about the BWCE support built-in migration feature, but we needed a kind of solution that would produce a clear picture of each granular part of the code for the MuleSoft developers, who struggled to reopen and replicate the functionality from every single activity of the process.

Implementation

After spending some time on the challenge, we have managed to accurately describe the XSLT expressions and distinguish XML standards for complex, simple elements and attributes along with the conditional/switch statements and XPath expressions.

The usage of this tool is simple and trivial. We are executing a traditional Java command for the jar and passing the process of our choice as an argument, after which the tool will do the rest of the work.

Let’s assume that we have simple mapped point-to-point values populated into visual XSD elements:

A simple mapped point to point values populated into visual XSD elements
(Image 1 – A simple mapped point-to-point values populated into visual XSD elements)

From this point of view, we are just executing a CLI command and we wait for the results:

java coding

According to the logging statement, we can conclude that an Excel file is created in the same location where the process resides which looks like this:

The created Excel file
(Image 2 – The created Excel file)

In the outlined picture above, we can notice that the sheet is named according to the activity where we pulled out the expression from, and the name of the process is the title of the Sheet.

The title columns are self-descriptive enough to indicate the values in subsequent rows.

We have also incorporated an additional Intro sheet where we are describing each of the colors and what they indicate.

If we look closely on the right side, we have the scope of the target fields to distinguish the elements with the same name but different parent nodes and we have plain values on the Source side since we have hardcoded the values for testing purposes.

Now, let’s assume that we have multiple activities in one process with complex transforming expressions to meet the requirements for the specific backend systems, internal consumers, or pulling certain data according to the passed expressions.

Multiple activities in one process
(Image 3 – Multiple activities in one process)

First, in this example, we can see that the same process contains multiple activities where XSLT transformations exist.

Other than that, in the outlined sheet are shown complex transformations with various expressions like choose, if-else, for-each statements, and built-in TIBCO functions.

Likewise, if we have a deeply nested structure of thousands of elements with various statements and filtration, our tool will seek recursively till the end of the scope and resolve the described fields in the Mapping rule column.

It is also worth mentioning the last sheet which is called Transition Expression, and clearly shows the expressions (if there are any) in transitions between activities.

Transition Expression
(Image 4 – Transition Expression)

The difference is shown on the right side, where, instead of source element we have decided to place target and source activities.

If we assume that there are multiple execution paths where certain messages should be distributed, this feature can be very helpful in order to indicate the logic of the content base routing or the message broker.

In the case where the desired process contains multiple transitions with XPath expressions, they will be outlined accordingly in the same sheet:

Multiple transitions with XPath expressions
(Image 5 – Multiple transitions with XPath expressions)

Outcome

After releasing the initial version of the tool, the development time has improved significantly meaning that the constant looking into the same BW5 processes has disappeared, and the building of the mapping transformation was a lot easier from each perspective.

The most important part is that each developer was dedicated to their own Integration platform without manually extracting wrapped XSLT from the desired process.

The second improvement was the communication between the project members which has exponentially sped up.

The third improvement is that we have satisfied clients since the migration was seamless and fast.

Summary

This generic tool has helped us a lot, not just with the client’s requirements to migrate the BW5 code into BWCE and MuleSoft Anypoint Platform, but also with an Integration Business Unit.

In addition, the tool can be used for migration to some other Integration platform or packaged software.

As a Tibco team in InterWorks, we always strive to automate each part of the Software Development Life Cycle by building various tools and bundle packages.

Although this generic tool is only for extracting XSLT expressions from BW5, in the next blog series we will describe another generic tool for exposing mapping expressions from BW6 and BWCE.

For further information regarding the tool, you can contact our TIBCO team at tibco@iwconnect.com