Scheduled Failover Message Forwarding Processor
The scheduled failover message forwarding processor is a message processor that ensures reliable message delivery. This message processor is useful when it comes to scenarios where a message store failure takes place and it is necessary to ensure guaranteed message delivery.
The only difference of the scheduled failover message forwarding processor from the scheduled message forwarding processor is that the scheduled message forwarding processor forwards messages to a defined endpoint, whereas the scheduled failover message forwarding processor forwards messages to a target message store.
For an example scenario where the scheduled failover message forwarding processor is used, see Guaranteed Delivery with Failover Message Store and Scheduled Failover Message Forwarding Processor .
Scheduled failover message forwarding processor parameters
Following are the parameters and the description for each of the parameters you need to specify when creating a scheduled failover message forwarding processor.
Parameter Name | Description | Required |
---|---|---|
Name | The name of the scheduled failover message forwarding processor. | Yes |
Source Message Store | The message store from which the scheduled failover message forwarding processor consumes messages. | Yes |
Target Message Store | The message store to which the scheduled failover message forwarding processor forwards messages. | Yes |
Processor state (is.active ) | Activate (true ) or Deactivate (false ) | Yes |
Forwarding interval (interval ) | Interval in milliseconds in which processor consumes messages. | No (The default value is 1000) |
Retry interval ( | Message retry interval in milliseconds. | No (The default is value is 1000) |
Maximum delivery attempts ( | Maximum redelivery attempts before deactivating the processor. This is used when the backend server is inactive and the ESB profile tries to resend the message. If you set the value of this property to -1, it deactivates the message processor without retrying, after the first attempt fails. | No (The default value is |
Drop message after maximum delivery attempts (max.delivery.drop ) | If this parameter is set to The Maximum Delivery Attempts parameter can be used when the backend is inactive and the message is resent. | No (The default value is Disabled) |
Fault sequence name ( | The name of the sequence where the fault message should be sent to in case of a SOAP fault. | No |
Deactivate sequence name ( | The deactivate sequence that will be executed when the processor is deactivated automatically. Automatic deactivation occurs when the maximum delivery attempts is exceeded and the Drop message after maximum delivery attempts parameter is disabled. | No |
Quartz configuration file path ( | The Quartz configuration file path. This properties file contains the Quartz configuration | No |
Cron Expression ( | The cron expression to be used to configure the retry pattern. | No |
Task Count (Cluster Mode) | The required number of worker nodes when you need to run the processor in more than 1 worker node. Specifying this will not guarantee that the processor will run on each worker node. There can be instances where the processor will not run in some workers nodes. | No (The default value is 1) |
In addition to specifying the required parameters, you can click Show Additional Parameters and set any of the additional parameters if necessary.