Page Comparison

Check obsolete messages in the queue

• control of obsolete messages is solved by extcall component
• the messages that failed the first time to process and amends existing data, it is necessary to check whether the data to be processed again. You can imagine that new message for same operation and same entity is received but was processed.

  MSG1 setCustomer(externalCustomerId=5) OK
  MSG2 setCustomer(externalCustomerId=5) PARTLY_FAILED
  MSG3 setCustomer(externalCustomerId=5) OK

  Message MSG2 must not be further processed because there exists the message MSG3, which is newer and changes the same entity with same "object ID".

• to make it possible to centrally check it so 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 (by default) the name of operation and object ID, but sometimes it is not sufficient because for example change of customer is contained in several operations. To change this behaviour is necessary to use header value AsynchConstants.ENTITY_TYPE_HEADER, which is then 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 CleverBus evaluates OpenHub evaluates that message is obsolete then will have new status SKIPPED and hereafter already will not be processed

• this is not necessary to check for messages where new objects are created

Confirmation the result of processing asynchronous messages

• when asynchronous message is processed (is in final status) then CleverBus can OpenHub can transmit information about result of processing - OK, FAILED or CANCEL final status.
• main interface is ConfirmationCallback, which has now two implementations:
• DefaultConfirmationCallback - default behaviour (rather suitable for tests), which only logs information about result
• DelegateConfirmationCallback - based upon source system it chooses properly implementation of ExternalSystemConfirmation interface, which as callback calls external system to confirm result.

Design of this functionality is so flexible because:

• not every system wants be informed about result of message processing
• every system can have specific requirements to confirmation (confirmation via web service, db call and so on)
• CleverBus OpenHub provides own defined WSDL asynchConfirmation-v1.0.wsdl with XSD asynchConfirmationOperations-v1.0.xsd to auto confirmation solution