ERP-CRM middleware: handling retries and outages

Point-to-point interfaces can be sufficient for a small number of well-defined flows. As applications, business units and exceptions multiply, mapping and error handling become scattered. Middleware provides a shared place for these responsibilities. Its introduction should address concrete problems: inconsistent records, duplicate orders, difficult incident analysis or changes that require several systems to move together.

Starting point and project boundaries

• Identify the trigger, source and destination of each data flow.
• Assign business owners who can resolve conflicting customer, product or order information conclusively.
• Inventory existing direct connections and manual exports before adding middleware to the application landscape.

Middleware should identify messages, record business states and limit retries. Idempotent processing prevents a repeated request from causing an unintended second effect. Different failures require different responses: temporary unavailability is not the same as an invalid customer identifier. Exception queues need owners and controlled replay. Periodic reconciliation detects inconsistencies that can remain even when individual transfers appear successful.

• A queue decouples availability but does not itself guarantee one business execution.

Receiving systems must recognise repeated delivery.

• Define external identities, event versions and rules for late changes so that older messages do not overwrite newer states.
• Separate technical retry from business correction.

Unprocessable transactions need a visible exception backlog and an accountable owner.

The published GSWE reference GRÜN Itex describes a publishing metadata platform with around 40 connected interfaces. GSWE took on operations, stabilisation and further development, improving monitoring and error analysis. This demonstrates experience with a complex integration landscape. It is not a reference for any particular ERP-CRM product pairing, which must be assessed separately.

Practical acceptance scenarios for the first release

• The source sends the same order event twice. The destination creates one order and the repeated delivery remains traceable.
• An older customer update arrives after a newer one. Processing recognises the ordering or routes the conflict to controlled resolution.
• The ERP is unavailable for an hour. When it returns, the backlog is processed at a bounded rate without overloading the destination again.

A clear integration brief identifies source and target systems, data owners, volumes, acceptable delays and recovery procedures. It also covers versioning, secret management, permissions and personal information in logs. Relevant acceptance scenarios include a delayed message, a repeated event and a target system recovering after an outage.

Review the recovery strategy with the provider: which messages are reprocessed after an outage, which ordering constraints matter and which transactions require manual approval? Request a traceable test with deliberately duplicated and invalid messages. The scope should also define technical-log retention and a way for support staff to resolve exceptions without unrestricted access to business data.

Check failed-message handling as well as successful data transfer. Responsible teams need to see which transactions are waiting, which need correction and which can safely run again. Middleware should support these decisions without requiring manual changes directly in production databases. Define ownership of the recovery queue before accepting the service.

A checklist for commissioning the work

• Request documentation of message routes, retention, retry limits and the manual approval process for replaying failed transactions.
• Check that a correlation identifier follows the transaction across systems so support does not have to search unrelated logs independently.
• Require source-to-destination reconciliation: successful HTTP responses alone do not establish complete business-data transfer.

Middleware is useful when it makes processes easier to control. Adding a platform without ownership only relocates the problem. Start with a critical data flow and measure manual corrections or time needed to diagnose exceptions. These observations provide a grounded basis for expanding the integration landscape.

Assess the benefit and control further expansion

• Compare the number of persistently unresolved transactions and the time needed to restore an interrupted data flow.
• Assess whether another system can be connected through a clear contract or whether additional exceptions increase coupling.

Explore the scope and discuss your project

• List the ERP, CRM and business applications involved, including current transfer methods, volumes and frequency.
• Describe a common failure together with its current resolution process and the teams involved.
• Explain which data must be available promptly and which workflows can tolerate delayed processing.