Relevant if Asynchronous messages feature is used. Introduced in OpenHub 2.1.

This feature is disabled by default. You can enable it by setting ohf.asynch.finalMessages.processingEnabled parameter to true.

Messages that are already processed should not be kept indefinitelly in OpenHub repository, for performance reasons. Therefore, mechanism called "final messages handling" is introduced.

Final message handling job

Messages that are considered final by workflow are periodically fetched by job (org.openhubframework.openhub.core.common.asynch.finalmessage.FinalMessagesProcessingJob) and processed.

Message is final if it's in one of the following state: OK, FAILED or CANCEL

Enabling message handling job

see configuration property ohf.asynch.finalMessages.processingEnabled in OpenHub configuration
interval & maximum limit of messages in one job loop can be configured, see parameters
- ohf.asynch.finalMessages.processingIntervalSec
- ohf.asynch.finalMessages.iterationMessageLimit

Message processing

Is realized by beans of FinalMessageProcessor type. Generally speaking it can be anything, typical scenario will be some kind of archiving before deleting.

Processing order is defined by Order interface implementation.

Note: duration for keeping messages in OpenHub database can be configured differently per each state, for example ohf.asynch.finalMessages.ok.saveTimeInSec. See OpenHub configuration for configuration properties.

DeleteFinalMessageProcessor

default implementation provided in OpenHub, does delete all the messages and other related records in the database
can be enabled/disabled by configuration property (ohf.asynch.finalMessages.deleteProcessor.enabled)
has defined Order, specified in static final variable.

How to add custom message processor?

register bean of type FinalMessageProcessor, preferrably class AbstractFinalMessageProcessor should be extended
define custom Order, relevant if multiple processors are registered
implement method to process message, FinalMessageProcessor is FunctionalInterface
method to process message is invoked in database transaction common for all message processors

Error handling

if exception is thrown during message processing, job will continue with another one. In next job iteration the message will be processed again
if multiple processors are registered then if one throws exception, processing stops and transaction is rolled back. This mechanism tries to ensure, that messages will be processed with all the processors or none