Search code examples
architectureintegrationdistributed-computing

Distributed Message Ordering


I have an architectural question on handling message ordering. For purposes of this question, the transport is irrelevant, so I'm not going to specify one.

Say we have three systems, a website, a CRM and an ERP. For this example, the ERP will be the "master" system in terms of data ownership. The website and the CRM can both send a new customer message to the ERP system. The ERP system then adds a customer and publishes the customer with the newly assigned account number so that the website and CRM can add the account number to their local customer records. This is a pretty straight forward process.

Next we move on to placing orders. The account number is required in order for the CRM or website to place an order with the ERP system. However the CRM will permit the user to place an order even if the customer lacks an account number. (For this example assume we can't modify the CRM behavior) This creates the possibility that a user could create a new customer, and place an order before the account number gets updated in the CRM.

What is the best way to handle this scenario? Would it be best to send the order message sans account number and let it go to an error queue? Would it be better to have the CRM endpoint hold the message and wait until the account number is updated in the CRM? Maybe something completely different that I haven't thought of?

Thanks in advance for any help.


Solution

  • I suppose CRM has its own unique customer id for the newly created customer. This CRM customer id is an external key for ERP and it should be present in the ERP->CRM update, otherwise CRM cannot correlate and update its own user record. If this assumption is right, you can put a middleman between CRM and ERP that keeps the orders without account numbers waiting in a queue, until it catches the account number update from ERP. The middleman would use the CRM customer id to correlate the waiting order request with the account number update, then enrich the order with the account id and forward the order to ERP.

    If an order is stuck in the middleman's queue for too long, it should be moved to an error/escalation queue.

    The middleman may be implemented within CRM or in ERP or in some integration platform.