I recently had the opportunity to work on a project where we were bringing in a vendor product that required data integration with a number of our client’s in house transaction applications. We needed to determine how the internal applications would integrate with the new product. I figured the timing was right to build on my prior blog on messaging, and provide some additional guidance.
A well designed integration is loosely coupled. Loosely coupled refers to a component relationship where each component makes no assumptions regarding the definition of the other opponents. Tight coupling could require wholesale changes to the in house application if we needed to upgrade or replace the vendor product in the future. Imagine if you have 5 applications writing directly to the vendors API and for some reason we needed to make a vendor change. All 5 applications would need to go through the full SDLC and change control process to integrate with the new vendor. We chose messaging as our integration pattern of choice as it results in loosely coupled integrations; if you read my previous blog on messaging you can see some of the additional benefits.
Once we decided on messaging there were other questions that needed answering about the channel, the data, and error handling.
What Type of Channel?
When we talk about channels, the two main options are “Publish Subscribe (Pub Sub)” and “Point to Point”.
Point to point is best when you want to send the data to one application. An example would be the processing of a financial transaction. This transaction should only be sent to the application in place to handle those transactions. Pub-sub on the other hand is when many applications or consumers may want the message. An example would be stock price notifications. Many people may want to be informed if the price of a stock reaches a certain level. For my integration, we needed to use point to point as transactions needed to be analyzed by the vendor product.
What Type of Data?
A message can contain different types of data depending on your requirements. These types include:
- Document. Information from the sending application is needed by the consuming application.
- Event. Something just happened that the consumer(s) want to know about.
- Command. The receiving application is being instructed to do something.
For my project we used a Document type message since we wanted the vendor product to analyze data from the in house applications.
How Will Errors Be Handled?
When I refer to error handling, I don’t mean infrastructure issues, but problems with the message itself. When the data within a message is not understandable by the receiving system, the receiving system should have the opportunity to place the message on a separate queue for messages it cannot process. This is called an Invalid Message Channel. Ideally there would be a process in place to handle those messages. For my project, we created a component that will be placing the data from the message onto a database used by the operations team to research issues such as invalid messages.
With all the information from above and from my previous messaging, you can see why messaging is a good fit for integration. Hopefully the ‘message’ is clear!