Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
This article is part of a series. For the previous article, see Moving an App Connect Flow Using MQ onto Containers.
One of the most common integration points is a database, and App Connect is well suited to connecting to a significant variety of datastores. One of the most common protocols used to connect to databases is ODBC, so that is the example that we will work through in this post.
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.
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.
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.
This blog is part of a series, link back to Part 3 to explore the earlier articles.
In the following scenarios, integrations with IBM MQ are used. When we move IBM App Connect into containers, the recommendation is that wherever possible, we should move to working with MQ remotely. This is highly preferable to having a local MQ server residing alongside App Connect since it allows Kubernetes to fully take over the administration of scaling and high availability of the components. This is part of a broader common practice around containerization, noting that each container should have only one job.
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.
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.
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:
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.
Many enterprises have IBM Integration Bus environments running hundreds of integration flows in production. You have likely read about the benefits of moving to containers, perhaps even more generally of agile integration, and you’d like to explore that. You’d also like to move to a more recent version of the product (now named IBM App Connect Enterprise). However, it is likely you have no, or at least a very limited background in container technology. How do you take the first steps to explore these new platforms and product versions?
In this series, we are going to describe how you move to containers running IBM App Connect Enterprise. We’ll build up to more complex examples, but for this first one we’ll take the simplest possible flow, and we’ll use a Docker container environment that can easily be run on a laptop.
WebSphere Adapter for SAP Software provides multiple ways to interact with applications and data on SAP servers. The adapter uses the SAP Java™ Connector (SAP JCo) API to communicate with SAP applications supporting inbound and outbound interactions. The adapter has a property “Select assured once-only delivery”, which it uses as a data source to persist the event data received from the SAP server. Event recovery is provided to track and recover events in case a problem occurs when the adapter attempts to deliver the event to the endpoint. Any user looking into exploiting this feature will have to set up a remote queue manager for the persistence of message and recovery to work.
In this article, we describe the configuration and steps required for running an SAP Inbound Adapter based message flow in IBM App Connect Enterprise running in IBM Cloud Pak for Integration (CP4I). This particular scenario is focused on the SAP Inbound Adapter set with the Assured Once delivery option and the Integration Server configured to use a remote default QMGR option.