Quintiq Technical ThoughtWorthSharing Integration
As any advanced planning and optimization solution requires master- and transactional data from external systems, integration design is part of almost every DELMIA Quintiq implementation. DELMIA Quintiq supports all mainstream integration technologies and protocols enabling it to meet any integration challenge. Having these capabilities however is no guarantee for success. The design of integration requires careful consideration in order to choose right solution for the right purpose. In this post I would like to share some of my experiences in my role as a Solution Architect and list five common pitfalls in integration design.
1. Not choosing the right pattern
There are various patterns in integration design. The four mostly used commonly used are
- Synchronous request-response: system A sends a request to System B and waits for system B responds with the requested data
- Asynchronous request-response: system A sends a request to system B but does not wait for system B to respond. System B sends response to system B as a later time.
- One-way Push: system A sends a message to system B without expecting a functional response
- Publish-subscribe: system A publishes a message to multiple systems using a message queue.
Which of those patterns is most suitable for a given interface depends on its purpose and non-functional requirements. It is important to understand the characteristics of these patterns in order to choose the right pattern for the right purpose. The table below provides some pointers to the suitability of a pattern.
Pattern | Most suitable for | Not suitable for |
Synchronous request-response | tasks with very limited scope. For example: plan order, return planning data, get planning for single order | Requesting large data volumes. For example request all orders. Business critical systems as the tight coupling may lead to delays. |
Asynchronous request-response | Jobs that have long runtime. For example start planning run. | Services that require a real-time response. |
Push | Notifications. For example to inform another system of a status change | Notifications that require confirmation from the receiving system. |
Publish-Subscribe | Scenarios in which a single message needs to be sent to multiple receiving systems | Scenarios where all receiving systems must have confirm processing of a message. |
2. Ignoring the team's experience
When designing an interface, it's important to take into account the experience of the teams that implements the interface. If a team has never implemented message based communication for example, it will be a tough ride as this often requires a different way of thinking. Even similar technologies as REST and SOAP require different expertise that must be acquired. Of course there can be strategic reasons to choose technologies that are out of the comfort zone of a team but this should then at least be taken into account in the estimation.
3. Forgetting error handling and recovery
In general we tend to focus on the implementing the happy case and forget about the situation in which things go wrong. What happens if a receiving system cannot process the information. Is a retry needed in case delivery fails? If so how many? How do I check whether the systems are all in sync? Or how to re-synchronize after two systems have run out of sync? These questions should be addressed already in the design stage of an interface as to avoid delays later on in the project.
4. Ignoring technical limitations
It is important to understand the limitations of integration technologies. Technologies to exchange messages typically have limitations in the size of the message that can be processed. These limits may even be specific to the technology used. It is therefore important to consider this in the design stage already instead of finding out during testing.
5. Ignoring non-functional requirements
Generally speaking for every functional requirement, there are always non-functional requirements and this is especially true for integration requirements. For integration there can be requirements related to the maximum delay in the delivery and processing of messages or the maximum response times for a request. It's important to consider this in the design of the integration as this may limit the technology to use. If a fast response is required, then the whole integration chain must be optimized for that. If there are doubts about whether the non-functional requirements are realistic, then a proof of concept should be considered.
I hope you enjoyed this post. Please reach out to me to share your thoughts and questions.
