Page Comparison

...

check for obsolete messages is solved by extcall component (only if keyType has value entity or custom)
the message that failed for the first time to process and changed existing data then it is necessary to check whether the data to be processed again. You can imagine that new incoming message for same operation and same entity is received but was processed before first one.
```
MSG1 setCustomer(externalCustomerId=5) OK
MSG2 setCustomer(externalCustomerId=5) PARTLY_FAILED
MSG3 setCustomer(externalCustomerId=5) OK
```
Message MSG2 doesn't have to be further processed because there is the message MSG3 which is newer (receiveTimestamp) and changes the same entity with same "object ID".

to make it possible to centrally check it then each entity has a specific unique identifier which we call "object ID". This identifier is mandatory and has to be set during processing inbound message via AsynchConstants.OBJECT_ID_HEADER header.
```
.setHeader(AsynchConstants.OBJECT_ID_HEADER, ns.xpath("/cus:setCustomerRequest/cus:customer/cus1:externalCustomerID", String.class))
```

for accurate entity identification OpenHub framework uses the name of operation and object ID by default. But sometimes it is not sufficient because for example customer's changes are contained in several different operations (messages). To change this behaviour then use header value AsynchConstants.ENTITY_TYPE_HEADER to change entity type that will be used instead of the name of the operation.
- Example: we have two operations setCustomerExt and createCustomerExtAll, which change customer. In this scenario the name of operation is not sufficient and therefore we use ENTITY_TYPE_HEADER.

if OpenHub decides the message is obsolete then message final status will be SKIPPED and hereafter already will not be processed

...

Versions Compared