Low-Level Integrations using MuleSoft - Part 1

In the modern days that we live in it's almost impossible to think of any type of communication between disparate systems (either synchronous or asynchronous) that is not based on high-level protocols such as HTTP (as in RESTful APIs/SOAP Web Services), AMQP/Kafka (as in asynchronous messages/events based processing) and more structured formats (such as JSON, XML, Avro, CSV).

However at times architects and developers have to go “back to basics” because they are tasked to deal with integration with legacy applications and/or proprietary hardware which capabilities do not include any kind of modern communication model as the mentioned above, or for any other reasons, the only supported mean of communication with external systems requires use of more low-level communication model based on TCP and Sockets, file transfers and schedule-based processes for example and this is what this series of articles is about.

Each of these will be split in 2 parts, where the first part presents the readers a fictious scenario and the proposed design and components of the solution and the second part is all about implementation in Salesforce, MuleSoft and other technologies.

Integration based on TCP Sockets

In this first article we will go about integration based on more low-level communication and integration based on TCP sockets, both as a client and as a service, based on a fictious scenario. Let’s get started!

Scenario

In the scenario presented in this article, a company that manufactures white-label (unbranded) products needs to synchronize data between their industrial printers with their Salesforce CRM and Xero Accounting systems which is lastly monitored and tracked via dashboards in Tableau as illustrated by the high-level diagram below:

These specific printer models utilize a MOXA NPort device to convert serial data to ethernet and vice-versa, in 2 separate processes, one running as a server (inbound print data listener), receiving print job details and another running as a client (outbound print data sender) broadcasting updates of execution of print jobs.

All this communication uses TCP servers and clients on both the MOXA as well as the MuleSoft side, mainly based on (somewhat) structured message formats (COBOL Copybook) containing information regarding:

• New print batch
• Print Batch/Label Status Change

Solution Design

The approach taken to design this solution in an interesting mixture of event-driven architecture with a more traditional ESB style, leveraging a reliability pattern in conjunction with the low-level communication with the printers using TCP. The diagram below illustrates all the components and communications that comprise this scenario:

In a real-life scenario, additional integration points and features would be required and/or would be designed and implemented differently to what is being exposed in this article, but those will not be thoroughly covered in this series because that type of integrations have been widely covered by a number of articles and videos throughout the internet, hence our focus will be more on the integration between these systems and the industrial printers only, which happens to be based on a simple TCP server/client, leading us "back to basics".

New Print Batch

This process is comprised by a few sub-processes and starts when the operator triggers a print batch in Salesforce, creating a new print batch, including all products and quantities to be print. When the user submits a new print batch, Salesforce publishes a new event that triggers the whole process to notify one of the printers as to what to print as illustrated by the sequence diagrams below:

Salesforce to MuleSoft

MuleSoft to Printer & NPort

Print Batch Status Update

This process is comprised by a few sub-processes and starts when the operator executes a job (prints) using the printer’s UI, which triggers the printer’s TCP client to establish a connection to a TCP Server (MuleSoft) to start sending a series of messages indicating change of statuses of print batch and labels as they are print. These status changes are then sent across to Salesforce, Xero and Tableau, starting one or more different processes within these systems as illustrated by the sequence diagrams below:

Printer to MuleSoft

MuleSoft to Salesforce, Xero and Tableau

Next Steps

After having defined the high-level solution design, our next step is to dive down into the technical specifications and how to implement this solution, which will be complete and available in the next post of this series of two.

Stay tuned for the next post of this series where we will dive down into a more technical design and implementation of this solution.

Enjoy!