TRIRIGA Integration Options

TRIRIGA provides multiple options for data exchange and the options range from very simple data dump using text file to a sophisticated real-time REST API.

The following diagram represents Integration options apt for the new world of interconnected systems. Although there are additional options for data exchange, we will focus mostly on the OSLC (REST API) and Integration Objects. A lot has already been talked about CBA (SOAP API) (erstwhile known as BusinessConnect).

Figure D1: Integration Options

TRIRIGA Integration Options

Figure D1: Integration Options walk through:

• The TRIRIGA Applications layer consists of configuration related to OSLC Manager and Resources. It also consist of configuration related to the Integration Object, although Integration Object in essence is really an extension to the platform.
• The TRIRIGA Application Platform layer consists of the underlying code base which enables interaction with the TRIRIGA applications. 
• The Systems Integration Layer consists of code base which provides interconnectivity options for the data exchange. 

Let’s have a quick introduction to these technologies starting with CBA.

1. Connector for Business Applications (CBA):

CBA is essentially an extension to the underlying TRIRIGA application platform and you can programmatically perform nearly any action using CBA which you could perform using the application itself. Catch is, to use CBA, you potentially need to be a Java rock star. You need to understand Java in depth to a level where you can create a client tool or code to consume the Web Services utilising SOAP construct and be able to write Java code to handle the request and response from CBA.

It requires continuous development and ongoing maintenance of the code to cater to the emerging demands.

This is also beyond the scope of many consultants as we would like to stop at certain level when our brain cells starts to feel the pain.

However, with all the complexities, it also brings enormous power and flexibility to perform wide variety of actions. You could further extend the use of CBA by utilising the Servlets technology to deploy custom applications.

2. Integration Objects:

Integration Object is a great initiative in trying to bridge the gap between the old and complex data exchange technology and the emerging requirements from customers who are looking for more simpler methods to exchange data.

Integration Object is built utilising the platform tools and a set of custom java code. It has a user-friendly field mapping tool and overall fairly easy to grasp. It allows you to look at the failures through the UI and potentially resubmit the transactions.

Integration Objects can be triggered either manually through the UI; through a workflow step; through a scheduler; or through web services call. Each trigger method has its own pros and cons, but important bit to understand is that if you are looking for a straightforward tool to import or export bulk data, Integration Object will help you get there.

We have started to utilise the Integration Objects in a project delivery quite early (Jan’ 2013)  during the first release and automated scheduling was one the challenges we have faced. We started with TRIRIGA scheduler and a bit of configurations, but eventually moved to a Windows Scheduler to better structure the Integration life-cycle. We have used scripted Web Services call to trigger the Integration Objects.

The Integration Objects provide options to utilise multiple different type of End points.

• Staging Tables
• Files
• File to DataConnect
• HTTP Post

I’ll further deep dive into the Integration Object in a separate post.

3. Open Services for Lifecycle Collaboration (OSLC):

OSLC is essentially a set of specifications which were developed (and being improved) to promote integration of software development life-cycle and to allow seamless integration between different software.

The OSLC specifications builds on various standard like REST and supports HTTP verbs through CRUD (Create, Read, Update, Delete) options and is essentially a step towards building a hypermedia (extended hypertext) system to enable machine to machine interaction (read IoT).

I’ll pause here and would direct more technically aligned readers to the following links:

• http://open-services.net/
• https://en.wikipedia.org/wiki/Open_Services_for_Lifecycle_Collaboration
• https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM%20TRIRIGA1/page/OSLC%20Getting%20Started%20Guide

I’ll be focusing more on the generic OSLC concept and implementation within TRIRIGA for the rest of the article. I’ll cover OSLC solution details in a separate article in future.

The OSLC implementation within TRIRIGA is being referred to as REST API as it works within the constraints of REST principles. The REST system contains a collection of resources identified through a unique identifier which can be used to perform standard actions using HTTP verbs (GET, POST, PUT, DELETE).  

Compared to other Integration options, OSLC Integration is more geared towards the emerging world of Internet of Things where we could easily connect the TRIRIGA system with other intelligent systems using “hypermedia” catalogue where the interconnected systems follow a series of pattern and steps to communicate between each other. There are many advances being made in this area and I’ll cover these topics separately elsewhere.

The OSLC Integration option is best suited for the real-time (or near real-time) data exchange scenarios. It works well in both synchronous and asynchronous scenarios while connecting with the external systems. An asynchronous scenario could be implemented by introducing a middleware in the middle (obviously).

We got sense of OSLC in early 2014 and based on the emerging information, we conducted some early research to understand the capabilities it might provide. Along with serving the mobile capabilities (which was one of the main reason the OSLC was being introduced across the IBM Smarter Infrastructure portfolio products), it became clear to us fairly quickly that this is the ideal technology and platform to create an Enterprise Integration framework for large-scale interconnected systems in scenarios where TRIRIGA is being deployed as part of a larger pool of systems.

We got hooked fairly early with OSLC and were developing architectural frameworks utilising OSLC and IBM ESB technology to provide a connectivity framework for multiple external systems. Once the OSLC was released within TRIRIGA, we started early pilots and were able to prove that the OSLC can form the basis of complex and automated interconnected solutions without the hassle of writing loads of custom code and will allow us to act (or react) quicker due to changing market needs.

We went live with first TRIRIGA OSLC and IBM Integration Bus Integration framework in April 2015 and since then we have been adding additional functions to the toolkit. The OSLC Integration Framework is now being deployed as part of various other TRIRIGA deliveries across the world and with additional adoptions, I’m sure this will become the preferred choice for Integration delivery in future.

One architectural note here regarding the Master Data Management and Service Oriented Architecture. It is important for any Integration project to reflect upon the data mastering requirements and approach and build a guiding principle around the “services” building blocks which will form the basis of creating a SOA enterprise. Any integration program runs the risk of failing to identify and build reusable pattern and potentially ending up as a point to point integration framework. It is therefore important to invest time in getting the architectural framework and data mastering strategy right and to build an Integration capabilities roadmap. Building an SOA enterprise is as much an art as it is a science and there is a fine balance between building loads of services upfront which will take additional time and investment and will provide slow rate of returns (but obviously doing the right thing in building the basic blocks); compared to potentially applying a more pragmatic approach where buildings blocks (base web services) are identified and aligned to an Integration roadmap but are only built “as you go” based on the emerging needs and inter dependencies.

There are other emerging trends in the market around API Management and potentially creating different level of IT within the IT teams and it is being referred to as “two-speed IT” –  one more traditional with measured response after due diligence and other responding quickly based on certain pre-defined guidelines aligned with changing customer needs.

Applying the same concept to the Integration area, you would want to think about two-speed Integration layers – one which is more traditional utilising the Service Bus and dealing with your master data movement and core transactions within your immediate organisation; and the other layer utilising the API Management toolkit providing a more agile approach (while still utilising the underlying services) towards providing Web Services for external consumption.

I’ve by now admittedly drifted too far towards architectural thinking around Integration solutions and would stop here. I’ll be dealing with all these concepts in the upcoming articles.

For now, I’ll leave you with a high level comparison of the three Integration Options:

Table D1: Integration Options comparison table:

Disclaimer: The items in the comparison table might mean different things to different people and I also anticipate that the table itself will be updated. Any suggestions / feedback is welcome.

— end —

Glossary:
REST – RESTful Web Services
API – Application Programming Interface
CBA – Connector for Business Applications
OSLC – Open Services for Lifecycle Collaboration