Messaging
This post is part of a 4-article series covering integration styles for Sage 500 ERP (formerly MAS 500). The purpose is to introduce the subject of Integration Architecture, provide an overview of common approaches found today, and discuss how each can be achieved with Sage 500.
If you haven’t read part 1, we suggest you take a quick peek as it provides an overview of the “Big 4 Integration Styles” at a high level. Other posts in this series cover Direct Database Data Exchange, File Based Data Exchange, and Remote Procedure Invocation.
In this article, we’re going to take a look at the 4th of 4 integration styles which is Messaging.
Messaging
Data Exchange by Messaging is an integration style that we don’t see very often in small and mid-sized ERP solutions, however it offers a number of distinct advantages for many integration stories and has found its way into widespread use in our integration projects.
Messaging refers to an approach whereby the caller sends a message through an intermediate system to the target system. They do not get an immediate response other than to note that the message was received by the messaging system. Delivery is assumed and in most cases guaranteed. The message is enqueued by the messaging system for later processing.
Processing of the queued messages takes place by a separate application or processor that can validate and transform the data in the message and then call the appropriate API in the target system to complete the transaction. Error handling is externalized in this pattern, with errors being recorded in the queued message, allowing the disposition of errors to occur in a time independent manner from the overall message workflow.
- Is it easy to implement? No, this is the more complex approach for integrating applications. It requires the definition and implementation of a messaging subsystem and the message processing service. The development team requires specific knowledge of messaging based solutions, in addition to at least some domain knowledge of the underlying ERP system.
However, if the messaging subsystem and processor are already defined, for third parties the implementation is greatly simplified. Here they only need knowledge of the message structure and the mechanism to send messages (most often web service based). Domain specific knowledge of the target ERP system (Sage 500 in this case) is limited to a much narrower set of parameters and rules.
- What tools are available within Sage 500? No messaging based solution is available from Sage for Sage 500 ERP. However RKL eSolutions does have an extensive messaging toolkit from which they have engineered a number of high volume, highly reliable integration solutions for clients.
- Is this a tightly coupled solution? No. The message structure is abstracted from the underlying requirements of the Sage 500 SQL API model, so that changes can be accommodated at the level of the message processor, not the message definition itself. This greatly simplifies isolating the consumer of the integration service from underlying changes in the ERP system.
- What are the error handling challenges? The error handling model for messaging based solutions is very different from more direct integration patterns. Here we log errors as part of the messaging stream. E-mail alerts or similar mechanisms are used to inform business process owners of messages that encounter errors, and they can then address those errors on a time-independent basis. Additionally, certain message types are ideal candidates for automatically retrying the transaction, helping overcome transient issues with no user interaction.
- Is it easy to maintain over time? The overall maintenance effort is about the same as other solutions, however the responsibility for change management is largely shifted to the owner of the message processor vs. the calling application. This shift in responsibility is ideal in most cases, and represents an overall simplification of managing change.
- Is it scalable? Yes, this is the most scalable integration style discussed here. Because the messaging subsystem queues incoming and outgoing transactions, they can be processed in a manner that reduces impact on Sage 500 or the outside system. From the caller’s perspective the process is asynchronous, as they do not have to wait for the underlying workflow to complete before submitting the next message. Additionally, the processing of message can be halted around windows of maintenance or unplanned downtime, and then restarted when Sage 500 is available. Messages will simply wait in the queue until such time as they are processed.
- Is it easy to secure? Yes, because we can offer multiple layers of security. Access to submit messages into the messaging subsystem can be secured. Most importantly, the outside callers have no direct access to Sage 500, making this an ideal approach for integrations that must extend across the public internet or in other open environments.
Sage 500 ERP itself offers no message based integration solution.
However, RKL eSolutions has built a rich toolkit for message-based integration projects that is ideally extensible, scalable, and reliable. Our RKL Integration Services toolkit provides a custom messaging system and a highly extensible message processing application.
Integration Styles Summary
In this 4-part series, we examined the Big Four Integration Styles commonly found with projects that integrate to Sage 500. The following chart summarizes our discovery of each of these integration styles:
RKL eSolutions has extensive experience with each of these integration styles, and uniquely offers a messaging based solution, our RKL Integration Services, that is engineered specifically around Sage 500.
Need Help with an Integration Project?
If you need help with an ERP integration project, then contact the integration experts at RKL eSolutions.
Our highly-skilled team of ERP system developers and consultants can help to make your project a success.
Related Posts
Sage 500 Integration Styles: File Based Data Exchange
Sage 500 Integration Styles: Direct Database Data Exchange
Sage 500 Integration Styles: Remote Procedure Invocation
