Page Comparison

Exceptions

• if an external system is called unsuccessfully call to external system is unsuccessful - either some expected error is thrown (= exception declared in operation) or another exception is thrown as error during processing message. The type of error is "business" exception (e.g. value of invoice is negatively and it does not make sense or we want to create customer in external system which already exists), second type is internal technical error in external system, where it is necessary to try to call external system for some time. But if this error is expected "business" exception then process should remember these exceptions to confirm scenario it to the callee system (that invokes this process) at the end.
  • if some expected exception occurs then it has to be catched caught and stored into property with name that will end on the name with suffix AsynchConstants.BUSINESS_ERROR_PROP_SUFFIX (there may be more exceptions, and each of them will be saved as a separate value in property under name with appropriate suffix)

• during processing of asynchronous message it is possible to call more external systemssystems during processing of one asynchronous message. The order of calling calls doesn't have to be random therefore if any calling of call to external system fails , then an error is thrown and process processing of the message is stopped. After some time (configurable) OpenHub will pick the message by MessagePollExecutor from DB and the message is processed again.

• validation exceptions (=org.apache.camel.ValidationException) are resolved as business exceptions, so if this error occurs then processing of message ends immidiatelly with status FAILED.

• each call which defines route is extended from AbstractBasicRoute where there is implemented basic error handling mechanism, see Error handling
• exceptions can be caught and processed immediately in the route or can be propagated to superior route, i.e. route whence the route was called - it is solved by errorHandler(noErrorHandler()). More information you can find in Apache Camel documentation - Error handling in Camel

Transferring state among attempts

• sometimes is necessary to transfer stateful information of message information among individual attempts of processing - for example information, which IDs of customer collection were have been already processed
• for these purposes there is property AsynchConstants.CUSTOM_DATA_PROP for these purposes that can contain random string data (e.g. map of string and so on). The value of this property is at the end of message processing included in message entity: Message#getCustomData

Check obsolete messages in the queue

• check for obsolete messages is solved by extcall component
• the message that failed for the first time to process and amends 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 must not  doesn't have to be further processed because there exists is the message MSG3, which  which is newer (receiveTimestamp) and changes the same entity with same "object ID".

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

• this is not necessary to check for messages where when new objects are created then checking obsolote messages is useless