Retry Message Processing in Case of an Error

1. Add a Content Modifier immediately after the Start Event:
   • Click on the design Palette.
   • Choose Message Transformers.
   • Click on Content Modifier.
   
   • Drag it to the message execution pipeline between the Message Start Event and the Content Enricher step.
   

   • Rename the Content Modifier - click on the Content Modifier step, go to the Properties Sheet –> General tab
     Set the Name to Park incoming message.

   • Go to Exchange Property tab, click on Add and enter the following details:

   Field	Value
   Action	Create
   Name	Input
   Type	Expression
   Datatype	java.lang.String
   Value	${in.body}
   Default

   

In this step, we assume that an exception has happened. We will now store the incoming message into a JMS queue. For this purpose, we cannot take the message on the pipeline as we can never be sure where an exception can occur. So we need to use the message that we parked in the previous step - this way we are always sure that we are working on the incoming message and can duplicate the entire processing while we retry.

1. Load the initial message from the property into the body when an exception occurs:

   • Click on the design Palette.
   • Choose Message Transformers.
   • Click on Content Modifier.
   

   • Drag it into the Exception Sub-process, just after the Error Start Event.

   • Click on the Content Modifier, go to the properties sheet and rename it to Retrieve incoming message into body.

   
   • Go to the Body tab and choose the following:

   Field	Value
   Type	Expression
   Body	${property.Input}

   

2. Add a JMS receiver in the Exception sub-process.

   • Click on the design Palette.
   • Choose Call.
   • Choose External Call.
   • Click on Send.
   
   • Drag it into the Exception Sub-process, just after the Content Modifier.
   
   • Click on the design Palette.
   • Choose Participant.
   • Choose Receiver.
   
   • Drag the receiver below the Request Reply step as shown below:
   
   • Click on the receiver, go to the properties sheet and rename the receiver to JMSQueue.
   
   • Hover over the Request Reply step use the Connector to connect it to the JMSQueue receiver. Choose JMS from the pop-up.
   

3. Configure the JMS connector:

   Add the following configuration to the JMS receiver in the Processing tab:

   Field	Value
   Queue Name	Input
   Retention Threshold for Alerting (in d)	2
   Expiration Period (in d)	90
   Encrypt Stored Message	Checked
   Transfer Exchange Properties	Unchecked

1. Save and deploy the integration flow:

   

   As soon as you deploy the flow, a queue shall be created and this can be see in the Queue Monitor:

   Go to the Operations view –> Manage Store section and click on Manage Queues:

   

   As you can see, a single queue is created. The name of the queue is Input - same as what was configured in the JMS receiver.

   

   There is currently no data in the queue.

   Let us now execute the flow to write a message into this queue.

2. Execute the integration flow and check the queue view again:

   

   We now see one entry in the queue.

3. Check the configured inbox. You should not have received any mails yet. This indicates that the flow did not complete processing.

   Now let us create a retry logic.

In this exercise, we shall copy the original flow and make the following changes in it:

• Replace the SOAP sender with the JMS sender: this is because, we now want the integration flow to poll the JMS queue, not expose a SOAP endpoint. This flow shall poll the queue after regular intervals as configured in the JMS channel in the next exercise. Every message entered into the queue through the exception sub-process of the original flow shall be retried as a result of the above process.

• The Exception sub-process shall be removed - this is because, when an entry is read from the queue, it is deleted. In case an exception occurs, the entry will be written back into the queue (or not deleted). This will make sure that it is retried and later put in the dead-letter queue in case the process fails to process successfully in the configured number of retries.

• The exception inducing script should be removed - this makes sure that when the message is retried, the exception is not simulated and hence we should be able to process the message successfully in the first retry.

1. Copy the integration flow:

   • Go to the Integration Package view:
   
   • Click on Edit. Go to Actions for the integration flow Manage Freight Logistics and choose Copy:
   
   • In the pop-up dialog, enter Manage Freight Logistics_retry as the name of the new integration flow:
   

   Click Copy.

   The corresponding integration flow gets added to the integration package:

   

2. Edit the retry flow:

   1. Open the retry flow and click Edit:

      

   2. Delete the sender SOAP channel:

      Click on the channel and click on the delete speed button:

      

   3. Hover on the e-CommerceVendor sender, use the speed button for Connector and connect the sender to the Message Start Event:

      

   4. Delete the script step - hover on the Script step and choose the speed button for delete:

      

   5. Remove the Exception Sub-process: delete the following:

      
      • Exception Subprocess 1
      • JMSQueue
      • Receiver 1

   The final integration flow looks like the picture below:

   

Configure the JMS sender as follows:

1. Save and deploy the retry integration flow:

   

   As soon as the flow is deployed, it starts polling the queue for messages. As a result, the message from the queue should now be picked by the retry integration flow and processed.

2. Check the queue view: since the message is now picked, we should not see any messages in the queue:

   

3. Since we do not raise an exception in the retry flow, this time, the flow will execute successfully and you should receive an email in the configured inbox.