How to Move IBM App Connect Enterprise to Containers

This article is part of a series and follows the previous article, Deploying a Queue Manager from the OpenShift Web Console.

IBM App Connect Enterprise was initially created at a time when much integration was performed using messaging, and specifically IBM MQ. Indeed, despite the popularity of more recent protocols such as RESTful APIs, there are still many integration challenges that are better suited to messaging. Today, IBM App Connect Enterprise is used to mediate various protocols, but nearly all existing customers will have some MQ-based integration in their landscape.

Building Flows in IBM App Connect Using Connectors

This article illustrates three scenarios that demonstrate how you can use IBM App Connect to build flows that integrate with apps. The three connectors that we will use for these scenarios are;

  1. Microsoft Azure Active Directory - a cloud-based identity and access management (IAM) solution that provides single sign-on and multi-factor authentication that helps to protect from cybersecurity attacks.
  2. Oracle E-Business Suite  - a complete set of business applications for managing and automating processes within your organization.                                                                 
  3. Salesforce Marketing Cloud - a customer relationship management platform that provides digital marketing automation and analytics software and services.

1. Using Microsoft Azure AD With IBM App Connect

You can use App Connect to perform actions on the following objects:

POP and PUSH Testing Framework

The POP and PUSH (P&PT) testing framework's goal is to provide a platform for combining Six Sigma testing techniques with IBM App Connect microservices. In the same way that a recording reel of film records a snapshot of test case data, the P&PT will record a snapshot of test case data. It is digital proof captured throughout the lifecycle of an App Connect Enterprise application, from development to production (application lifecycle), using Git and Jenkins' workflow.

Introduction

In reaction to the business scenario, the project's test case count increases. As the test case repository grows like the General Sherman Tree grows: the goal is to reduce the amount of time spent on manual testing (operations).

From IBM Integration Bus to IBM App Connect Enterprise in Containers (Part 4b)

In Scenario 4a, we showed you how to deploy an IBM MQ queue manager in a container using the Kubernetes (OpenShift) command-line interface (CLI). That showed that it’s really just a couple of commands and all the detail is really in the definition files.  That’s certainly the approach you’ll want to move to for production so you can automate the deployment through pipelines. However, sometimes it’s useful to just be able to perform actions through a user interface without having to know the detail eg. command lines, and file formats, and that’s what we’re going to look at in this scenario.

Installing the IBM MQ Operator

IBM MQ Operator that we discussed in Scenario 4a will once again be used under the covers to perform the deployment. The operator also provides us with the user interface which, as you will discover, is neatly integrated with the OpenShift web console.

From IBM Integration Bus to IBM App Connect Enterprise in Containers (Part 3)

In Scenarios 2a and 2b, we showed different ways of deploying an App Connect flow onto containers on OpenShift – via the command line, and via the dashboard. We eventually saw a response from our deployed integration, but so what! We haven’t yet really seen what Kubernetes is bringing to the table. We will now explore some of the things that Kubernetes significantly simplifies and extends compared to traditional deployments. In this scenario, we’ll specifically look at load balancing and autoscaling.

If you feel you already understand basic load balancing and autoscaling in Kubernetes, perhaps take a look at the Advanced Scaling Topics section at the end of this post.

How to Move IBM App Connect Enterprise to Containers: Part 2(b)

Scenario 2b: Deploy a Simple Flow Onto Red Hat OpenShift Using the App Connect Dashboard

In Scenario 2a we introduced the App Connect 'operator'. This works as a sort of digital assistant to help us look after App Connect containers. In that scenario, we used the operator to deploy a container via the Kubernetes command line. In this scenario, we're going to do exactly the same deployment but instead through a user interface known as the App Connect Dashboard. 

What is the App Connect Dashboard?

The App Connect Dashboard is a user interface that provides a simplified way to deploy BAR files within App Connect containers and administer them once live. Some of the facilities it provides are:

How To Move IBM App Connect Enterprise to Containers – Part 2(a)

Scenario 2(a): Deploy a Simple Toolkit Message Flow Onto Red Hat OpenShift Using the Command Line Interface (CLI)

In Scenario 1 we took a simple flow from IBM Integration Bus and demonstrated we could get it running in IBM App Connect Enterprise on an isolated Docker container. This was a good start, but of course, in a real production environment, we would need more than just an isolated container. We would want to be able to create multiple copies of the container in order to provide high availability and to scale up when the incoming workload increases. We would also need to be able to automatically spread the workload across all those container replicas. 

This and much more is what is provided by a container orchestration platform, and the most commonly used platform today is of course Kubernetes. In this scenario, we’re going to take that same simple flow and deploy it onto Kubernetes and demonstrate some of these orchestration platform features

Automate Data Transformation Using IBM App Connect

IBM App Connect has introduced a new Artificial Intelligence (AI) feature that is capable of auto-generating data transformation expressions, and that helps accelerate your integration flow-building experience.

Data Mapping remains a fundamental part of integration development, but it takes time. An increasing number of applications, lack of naming standards, and nested field structures further compound the complexity for the integration developers. Once the mapping is done, data transformation is the next challenge for the users since each application expects data to be in a certain format.  Also, while building integration flow, developers need to understand the format of the source and target data field and come up with transformation expressions that can change data from source to target format. This exercise is done manually and it takes a lot of time and skills to build such transformation expression.