GOLBA RETRY WITH AMQP.

 

Architecture Flow Diagram

Reprocessing Strategy for recoverable errors

 

---

Steps to be implemented:

1. First flow to have logic to move the message to main flow i.e second flow using process direct receiver channel

2. Second flow/main flow is created where the data from first flow is received here & few steps are mentioned on this flow. There are certain changes that needs to be updated on the exception sub process.

 

Main Flow - Exception Sub Process

• Set few headers for them to be passed to the next flow

 

• Use the Groovy script to check if it's a recoverable error

• Add a router palette to check if the flag for Retry_Status is set to ‘true’ or ‘false’

 

• Next step is to set Payload as body of the message to be sent to Global Retry flow

• Process call will invoke the Global Retry Flow#1 i.e Global_Retry_PublishMessage

Process Direct Address -> /RetryAMQP

3. The process direct will call the Global Retry FLow#1 i.e Global_Retry_PublishMessage flow

4. The data is published to Retry queue of the Private Event broker

5. The second Global flow Global_Retry_SubscribeMessage flow would be triggered as it is listening to the queue

Three steps are implemented on the Global Retry Subscribe flow

• Set the content modifier to add the custom Retry Count on the flow. This will specify the number of retries to be done for interface

• Groovy script to add the suffix at the end to specify the retry count of the message process for that message

• Groovy script to dynamically create a condition to be checked on AMQP Global Subscribe flow to check condition based on maxRetry count given on main flow

Changes implemented:

Step#1

Set MaxRetryCount in the content modifier in this flow

 

Step#2 -

Add a groovy script to enable custom logging to identify retry count in the Global flows.

The groovy script code can be seen below

Step#3 - Add a groovy script to create dynamic condition needed for routing to DMQ on Global_Retry_SubscribeMessage flow

The groovy script code can be viewed below

6. The message would be passed to the endpoint sent in the header of the message, which would invoke the main flow mentioned in step#2 if retry count is less than specified retry count on main flow

7. It will retry for RetryCount times (specified on step#1 on retryCount content modifier) & if not successful, the message would be moved from Queue to DMQ. This would be evaluated based on router logic in Global_Retry_SubscribeMessage flow

---

Please note all the Groovy scripts would be a part of Global Script collection shown below

Kindly note that please do not make any changes to the Global_Retry_PublishMessage & Global_Retry_SubscribeMessage flows. Only the changes are needed to specific main flows only.

NOTE: Please remove any unused long headers before hitting the Global Retry flows. This would help reduce load on the Global flows & ensuring best practices are followed.