Message sequence

Delivering messages in sequence is not guaranteed. Only delivery is guaranteed (at least once). In some cases the sequence of receiving is the same as the sequence of sending, but you cannot rely on this. Many factors can impact the sequence, such as:

  • Parallel processing (multi-threading).
  • Documents traffic.
  • Intermediate steps in the process, such as content-based routing, filtering or mapping.

Take these situations into account:

  1. Message Delivered with Delay or Out of Sequence sometimes due to network or BOD traffic BODs are not always delivered on time or in sequence. Especially in case they reference to each other. For example; a Sync.ItemMaster BOD reaches the application later than a Sync.PurchaseOrder. The application may well send out a Confirm BOD for the Sync.PurchaseOder BOD. Or is highly recommended to set a retry mechanism to have a few tempts based on intervals to sort out the message delay or out of sequence issue.
  2. Message Delivered Out of Sequence for Different Verbs of the Same Object. It happens sometimes when an application awaits the Acknowledge BOD from the SOR for the object via Process BOD. The Sync BOD of the same object from the SOR arrives prior to any Acknowledge BOD. This is similar to point 1, caused by BOD traffic or network, and can be solved by a few times retry in turn. Therefore applications are recommended to include this into IONAdoption consideration.
  3. Multiple updates from SOR on same document out of sequence Multiple changes on the same document may not arrive in the correct sequence. Use the Variation ID to check whether a Sync message is out of date. If the Variation ID of an incoming message is lower than a Variation ID you already processed for the same document type and document ID, then you must not overwrite the newer information you already have.
  4. Data with interdependency break down into a set of documents. This is the same as what is explained in "Sending messages in batch".