Message processors can be used to implement different messaging and integration patters along with message stores.
Message processors can consume the messages in message stores and perform some processing on them.
For example think of a scenario where we have a back-end service that can only accept messages at a given rate and incoming traffic to the ESB has a different message rate. So to serve that inbound traffic using the available back-end services we can have a message store that temporarily stores the messages and a message processor that will consume those messages and send to the back end service at a predefined rate.
Users can write their own message processor implementations and plug them using the Synapse configuration. WSO2 ESB ships two message processors implementations that can be used out of the box.
<messageProcessor name="string" class="classname" messageStore="classname" > <parameter name="string" > "string" </parameter>* </messageProcessor>
Message processor is a top level ESB configuration element where it should be given a unique name.
The 'class' attribute value is the fully qualified class name of the underlying message processor implementation.
There can be many message processor implementations. Users can write their own message processor implementations and use them too.
Parameters section is used to configure the parameters that is needed by underlying message processor implementation
Message Forwarding Processor consumes messages in a given message store and sends them to an predefined address endpoint.
If a message is successfully delivered to the endpoint, the processor will delete the message from the message store.
In case of a failure it will re-try after a configured interval.
Message processor can be activated or deactivated from the UI.
When its in the deactivated state users can manually delete/resend messages from the management console.
Message forwarding processor is useful when it comes to implementing reliable delivery channels, dead letter channels and store-and-forward channels.
Parameter Name | Value | Required |
interval | Message retry interval in milli seconds | No default is value is 1000ms |
max.deliver.attempts | Maximum re delivery attempts before deactivating the processor | NO |
axis2.repo | Axis2 Client repository to be use to send messages | NO |
axis2.config | Axis2 Configuration to be use to send messages | NO |
message.processor.reply.sequence | Name of the Sequence that reply of the message should be sent to | NO |
message.processor.fault.sequence | Name of the sequence that fault message should be sent to in case of a SOAP fault | NO |
quartz.conf | Quartz configuration file path | NO |
cronExpression | Cron Expression to be used to configure the re try pattern | NO |
Property Name | Value | Required |
target.endpoint | Name of the Address Endpoint which message should be delivered to | YES. |
OUT_ONLY | true if this is a out only message | Required for out only scenarios |
Message Sampling Processor consumes messages in message store and send it to a configured sequence.
This process happens in a pre-configured interval. Therefore this message processor implementation is useful in implementing delivery channels with fixed delivery rate.
Parameter Name | Value | Required |
sequence | SequenceID, which defines mediation flow | YES |
interval | Message retry interval in milli seconds | Default value is 1000ms |
quartz.conf | Quartz configuration file path | NO |
cronExpression | Cron Expression to be used to configure the re try pattern | NO |
Note: When using the "SamplingProcessor" as a Message processor implementation, we must provide the "sequence" parameter (which contains 'endpoint' URI).