Quintiq Technical ThoughtWorthSharing ​​​​​​​Integration 

Planning and scheduling solutions such as DELMIA Quintiq almost always require integration with other systems such as ERP and MES systems. Because of the wide variety of the systems that Quintiq needs to integrate with, the Quintiq software offers a wide variety of options for integration such as ODBC, SOAP, JMS and others. Having those capabilities is of course excellent as this gives a lot of options to choose from. But choosing an option requires careful consideration.

In this post I would like to focus on one important design decision: to use direct integration or to use middle ware.

Direct integration

In direct integration a system connects directly to another system to send or retrieve data. An example of direct integration is a web service that is used to update an object in another system as shown in the picture below.

There are lot of advantages to using direct connections. One advantage is that they are relatively easy to develop due to the use of formalized API specifications such as WSDL for SOAP and YAML for REST web services. For example Quintiq supports the import of a WSDL file to generate the client interface in a Quintiq model. Another advantage is that they are relatively straightforward: the client sends a request to the server and the server sends an immediate response.

There are however also some disadvantages. A major disadvantage is that direct integration creates a dependency between two systems. If in the example System B is not available or busy, then System A needs to handle this situation and implement a retry mechanism.

Another disadvantage of direct connection is that it connects a client to single server. In scenarios where the same data must be pushed to multiple receivers, a direct connection cannot be used.

Integration using middleware

This is where integration middle ware comes into picture. Integration middle ware is designed to decouple systems and support more complex integration scenarios with multiple receivers. A good example of such middle ware are message queue solutions such as IBM MQSeries and Confluent Kafka. Also databases such as Oracle and SQLServer are often used as middle ware solution.

In the example above, System A publishes a message to a message queue and Systems B and C consume from this message queue. The major advantage of using message queues is that they take over the responsibility of the message delivery to the destination(s). After System A has published the message to the message queue, it can proceed with the next request regardless whether the target systems are available or not.

Another big advantage is that message queues support integration patterns with multiple destinations. Think about scenarios where you publish an order to a Company Planner and a Scheduler solution.

But the use of middle ware comes at a price. First disadvantage is that the use of middle ware makes integration much more complex. The source system does not know whether a message was processed or not and hence must take precautions for this. Also as receiving systems may refuse a message, an error handling mechanism such as retry and a "dead-letter-queue" must be implemented in the middle ware. The use of message queues therefore requires active monitoring and extensive error resolution procedures.

What to choose?

What technique to choose depends on the integration requirements. Direct integration is more suitable for request-reply interfaces as long as the requesting system implements an effective error handling mechanism and the receiving systems can be made highly available. For scenarios in which data is pushed from one system to another or when there are multiple receiving systems are involved, the use of middle ware is preferred.

I hope you enjoyed this post. Let me know your comments!