Jitterbit into the Groove

Want to invoke custom Java classes from Jitterbit operations? Not a command line request, but to send and receive parameters, with no change to the Java class, then please read on! (I am unaware of this ever being been done so please lay claim)

With the imminent release Apache Groovy 3.0 (final Alpha released Jan 1) I thought it topical to shine a light on Jitterbit's Groovy support so that you can extend your private agents to "seamlessly and transparently integrate and interoperate with Java and any third-party libraries".

Utilizing Jitterbit's own Groovy Runner Plugin you can execute a Groovy script or run a local Groovy file.

But the proof is in the pudding:

Using CA Plex, the greatest CASE tool on the planet, I generated a simple Java application to highlight a modernization eiPaaS use case where my 'premium calculator' logic is compiled into a Java program over a backend database (IBM DB2 for i).

Business wants the 'premium calculator' exposed externally yesterday but don't want business as usual affected

We must call the premium calculator Java program from Jitterbit and not go direct to the database and duplicate the logic. Imperative we get the same premium amount calculated irrespective of what interface invokes the request.

Our Classic Client Server App

Oh you beautiful 1990's Java Swing GUI. On the right, we can see the simple premium calculator that takes the ProductKey and Amount and spits out an ErrorMessage or Premium. It is this GUI interface we want to replicate as a Jitterbit hosted RESTful API by calling the same Java program the GUI calls (here by referenced as premium_calculator).

GroovyConsole Script

Like discovering a new endpoint by Postman you are advised to build your groovy script in a native tool and NOT your middleware tool.

Using the Apache Groovy Console, I built and tested my script to call premium_calculator:

• I do not claim to be a groovy practitioner so go easy
• Note the hard coded parameters on [lines 1-2]
• Calling a CA Plex generated Java class involved calling it via a dedicated launcher class hence the two jar files
• I chose to add the jars to the classpath dynamically, so I used reflection to create the object [line9]
• Note highlighted in yellow was the expected result of an error as the supplied amount was greater than 100 (logic only contained in the premium_calculator class)

Next let us replicate the Groovy Script result in Jitterbit Script which will be sent to the Jitterbit Groovy Runner plugin at run-time.

Jitterbit Script

No Change, Cut and Pasted into the global variable $groovy.script. Please note the following:

• See the test hard coded parameters on [lines 3-4] and how we declare them as global variables in the Jitterbit world and are then referenced on [line 17] in the Groovy script
• Note I have run this in debug design time mode so I can view the result, which excitingly matches our Groovy Console result

Jitterbit Custom API

Please view Jitterbit Tech Talk for a great introduction to Custom API support

Using the right context menu option: Exclusive View in Design Studio we can see the 5 objects we need to expose this Java object as a custom API.

• Operation type Transformation to be assigned to our API definition in API Manager
• Transformation to parse the groovy return string of our premium_calculator
• Source Global Variable named groovy.return to instruct the transformation where it is to get groovy return string from
• File format detailing groovy return string schema
• Finally the Jitterbit Script to invoke the Groovy Runner plugin passing the API query parameters

• Note [lines 4-5] I have substituted out the hard coded test values with the run-time Get API query parameters using the built in API Jitterbit Variables

• Here you see the transformation being tested at design time which is such an important feature available to you to build your software step by step
• Note the simple target JSON API response which will be auto documented in our OpenAPI specifications

• Jitterbit's new engaging API Manger look and feel

• Finally we see the Developers Portal using OpenAPI 3.0 to document our published API ready for developers to discover and consume
• Note we get the same result marked yellow as we got in the Classic Client Server App

Conclusion

How can business not be happy! Leverage existing assets for more return on their original Java investment while maintaining business as usual. What a pleasure this little POC was !