Hopefully you have already taken a look at our samples for C#, Java, Go, Python and Node.js and noticed that on execution they can be configured to make use of a CCDT. To explain how and why the samples do this we have an accompanying tutorial, which shows how to build connections strings and make use of CCDT in messaging applications.
In this tutorial we explore how an application connects to MQ queue managers and how to configure the MQ Client to benefit from a more sophisticated connection. In this way, your application is able to delegate the responsibility for checking for the discovery of and binding to available queue mangers to the IBM MQ Client. Adding scale and availability to existing applications without having to change application logic.
MQ Clusters: Living the dream
As part of our focus on Developer Experience, we love to drink our own champagne. We have created a demo to show just how easy it is to configure a MQ cluster on a set of Raspberry Pi zeros. In this demo the MQ clients are Flask Python applications. Why you may ask? Well, messaging applications are enterprise ready, but that doesn’t mean they have to be written in assembly language or machine code. We chose Python as it is the language of choice for many developers. IBM MQ supports a wide range of programming languages and API and we wanted to demonstrate this depth. Python is a popular language and there is an IBM MQ Client available on GitHub.
While coding disconnect / reconnect logic directly into our applications would have been achievable it would have resulted in brittle code and obfuscate your application logic. Fortunately, a core value of MQ is that developers shouldn’t have to do this to their code. So, we opted to make use of a Client Connection Definition Table (CCDT) and delegate the responsibility of detection and reconnection to the underlying IBM MQ Client. Administrators and Site Reliability Engineers (SREs) understand how the messaging infrastructure works. CCDTs promote a level of flexibility in applications allowing the infrastructure knowledge simply to be bolted on to the application code.
Our initial experiment revealed that all was not good. We discovered that the Python MQ library we were using, pymqi, wasn’t yet CCDT enabled. CCDTs are an elegant and simple addition to an application. In fact, just two things are needed:
- The location of the CCDT through environment variables.
- The application does not create a client definition.
The pymqi library API was insisting that the client definition be provided. So, the MQ Developer Experience team developed a fix and created a pull request to add this functionality in a developer friendly way.
We were now able to make use of CCDT configured automatic reconnects in our applications. We just needed a CCDT file. We opted for a JSON format so we could edit it. Working through sample CCDT files and the documentation we managed to create our CCDT. As ever, doing something for the first time is always difficult. So, we built this tutorial so that you can avoid making the same mistakes that we did.
We now had a sample CCDT, and a Python app that made use of it, that we are excited to share. We CCDT enabled all the samples across multiple programming languages, so you can just pick them up and get all the benefits.
The tutorial available at this link guides you through the process of creating a CCDT and explore how CCDT settings change the way your messaging applications behave.
Feel free to try out any of the samples available in our github repository.
The use of the CCDT to define connections and connection policies is a component of uniform clusters. You can find out more in the blogs JSON CCDT & Uniform Cluster features and Auto application rebalancing using the Uniform Cluster pattern