Scheduled Failover Message Forwarding Processor

Introduction

The scheduled failover message forwarding processor ensures reliable message delivery. This helps ensure guaranteed message delivery even when there is a failure in the message store.

The only difference between the scheduled failover message forwarding processor and 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.

Properties

See the topics given below for the list of properties that can be configured for a Scheduled Failover Message Forwarding Processor.

Required Properties

Following are the required parameters you can set when adding a Scheduled Message Forwarding Processor:

Property Description
Message Processor Type Select Message Sampling Processor from the list of values.
Message Processor Name Give a name for the message processor artifact.
Message Store Select a pre-defined Message Store artifact from the available list.
Processor State ( is.active ) Activate (true) or Deactivate (false). Activated by default.

Optional Properties

Following are the additional parameters you can set when adding a Scheduled Failover Message Forwarding Processor:

Parameter Name

Description

Forwarding interval ( interval )

Interval in milliseconds in which processor consumes messages. The default value is 1000.

Retry interval ( client.retry.interval )

Message retry interval in milliseconds. The default is value is 1000

Maximum delivery attempts ( max.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. The default value is 4.

Drop message after maximum delivery attempts ( max.delivery.drop )

If this parameter is set to Enabled , the message will be dropped from the message store after the maximum number of delivery attempts are made, and the message processor will remain activated. This parameter would have no effect when no value is specified for the Maximum Delivery Attempts parameter.

The Maximum Delivery Attempts parameter can be used when the backend is inactive and the message is resent.

If this parameter is disabled, the undeliverable message will not be dropped and the message processor will be deactivated. The default value is Disabled.

Fault sequence name ( message.processor.fault.sequence )

The name of the sequence where the fault message should be sent to in case of a SOAP fault.

Deactivate sequence name ( message.processor.deactivate.sequence )

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.

Quartz configuration file path ( quartz.conf )

The Quartz configuration file path. This properties file contains the Quartz configuration
parameters for fine tuning the Quartz engine. More details of the configuration can be
found at http://quartz-scheduler.org/documentation/quartz-2.x/configuration/ConfigMain .

Cron Expression ( cronExpression )

The cron expression to be used to configure the retry pattern.

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. The default value is 1.
Top