srini jms retry logic:

 

https://community.sap.com/t5/technology-blogs-by-members/sap-cpi-retry-jms-and-open-incident-servicenow/ba-p/13453328

in SAP Integration suite ; for error case like message is not delivered to target with iflow; JMS sender ...can we schedule in such a way that it needs to be retry 3 times for every 1 hour and after 3 retires is it possible to retry again after 12 hours?

In the SAP Integration Suite, you can achieve the desired retry mechanism using JMS (Java Message Service) queues combined with specific retry strategies. Here's how you can set up the required retry mechanism:

1. Initial Setup:

   • Ensure that your iFlow has a JMS sender that reads messages from a JMS queue.

2. Configure Retry Logic:

   • Use the retry settings available in the JMS sender adapter configuration.
   • For the initial retries (3 times every 1 hour), configure the retry intervals and the maximum retries in the JMS adapter settings.

3. Implement Extended Retry Logic:

   • To retry after 12 hours if the initial retries fail, you need to use a combination of JMS queues and router/groovy scripts to handle the logic.

Here’s a step-by-step approach:

Step-by-Step Approach

1. JMS Sender Adapter Configuration:

   • Configure your JMS sender adapter with the basic retry mechanism.
   • Set the retry count to 3 and the retry interval to 3600 seconds (1 hour).

2. Router/Groovy Script Logic:

   • After the initial retries fail, you can route the message to a secondary JMS queue which holds the message for 12 hours before retrying.

3. Secondary JMS Queue:

   • Create a secondary JMS queue specifically for the 12-hour delayed retry.
   • Use a groovy script to set a property or header that indicates the number of retry attempts.

4. Message Routing and Scheduling:

   • Use a Router step to check the retry attempt count.
   • If the count is less than 3, allow the message to go through the initial retry mechanism.
   • If the count equals 3, route the message to the secondary JMS queue.

Sample Configuration Details

Initial JMS Sender Configuration

1. JMS Sender Adapter:

   • Maximum Retries: 3
   • Retry Interval: 3600 seconds (1 hour)

2. Router and Groovy Script Example:

   • Use a Groovy script to check and set the retry attempt count.

groovy
import com.sap.gateway.ip.core.customdev.util.Message

def Message processData(Message message) {
    def retryCount = message.getProperty("retryCount") ?: 0

    if (retryCount < 3) {
        retryCount += 1
        message.setProperty("retryCount", retryCount)
        message.setProperty("routeToSecondaryQueue", false)
    } else {
        message.setProperty("routeToSecondaryQueue", true)
    }
    
    return message
}

3. Router Step:
   • Route based on the property routeToSecondaryQueue.
   • If routeToSecondaryQueue is true, send the message to the secondary JMS queue.
   • If routeToSecondaryQueue is false, proceed with normal processing.

Secondary JMS Queue Configuration

1. JMS Queue Setup:

   • Configure a secondary JMS queue.
   • Set a scheduled retry for messages in this queue to be processed after 12 hours.

2. Secondary JMS Queue Retry Logic:

   • Ensure that messages routed to this queue will wait for 12 hours before being retried.
   • Use another Groovy script or Router step after the secondary retry to determine if further action is needed.

Handling the Secondary Retry

groovy
import com.sap.gateway.ip.core.customdev.util.Message

def Message processData(Message message) {
    def retryCount = message.getProperty("retryCount")

    // Logic to handle message after secondary retry
    if (retryCount == 3) {
        // Process after 12-hour delay
        // Reset retry count or take alternative action
    }

    return message
}

Summary

1. Initial Retry (3 times every 1 hour):

   • Configure JMS sender adapter for initial retries.

2. Routing After Initial Retries:

   • Use Router and Groovy script to manage routing based on retry count.

3. Extended Retry (12-hour delay):

   • Route to secondary JMS queue after 3 initial retries fail.
   • Configure the secondary JMS queue to handle 12-hour delayed retries.

By using a combination of JMS queues, Router, and Groovy scripts, you can implement a robust retry mechanism that meets your requirement of retrying messages initially 3 times every hour, and then once after 12 hours if the initial retries fail.

explain the above sequence of steps in iflow?

Certainly! Here's a detailed explanation of how you can set up an iFlow in SAP Integration Suite to achieve the retry mechanism where messages are retried 3 times every hour, and if those retries fail, they are retried again after 12 hours.

1. Initial Setup

Create Your iFlow

1. JMS Sender Adapter Configuration:
   • Start by configuring a JMS sender adapter in your iFlow that reads messages from a JMS queue.
   • In the adapter configuration, set the retry parameters:
     • Maximum Retries: 3
     • Retry Interval: 3600 seconds (1 hour)

2. Implement Retry Logic

Add Groovy Script for Retry Count

2. Groovy Script for Retry Count:
   • Add a Groovy script after the JMS sender to manage the retry count.
   • This script will check the current retry count, increment it, and set a property to determine whether the message should be routed to a secondary queue after 3 retries.

Example Groovy Script:

groovy
import com.sap.gateway.ip.core.customdev.util.Message

def Message processData(Message message) {
    def retryCount = message.getProperty("retryCount") ?: 0

    if (retryCount < 3) {
        retryCount += 1
        message.setProperty("retryCount", retryCount)
        message.setProperty("routeToSecondaryQueue", false)
    } else {
        message.setProperty("routeToSecondaryQueue", true)
    }
    
    return message
}

Add a Router

3. Router Step:
   • Add a Router step after the Groovy script.
   • The Router will use the routeToSecondaryQueue property to decide the next step:
     • If routeToSecondaryQueue is false, proceed with normal processing or another retry attempt.
     • If routeToSecondaryQueue is true, route the message to a secondary JMS queue for a 12-hour delayed retry.

Router Configuration:

• Condition for Normal Processing:
  • Expression: ${property.routeToSecondaryQueue} == false
• Condition for Secondary Queue:
  • Expression: ${property.routeToSecondaryQueue} == true

3. Configure Secondary JMS Queue

Secondary JMS Queue Configuration

4. Secondary JMS Queue:
   • Configure a secondary JMS queue in your SAP Integration Suite that will hold messages for 12 hours before processing them again.
   • Ensure that this queue is set up to delay message processing by 12 hours.

4. Handling Secondary Retries

Retrieve from Secondary JMS Queue

5. Secondary JMS Sender:
   • Set up another JMS sender to retrieve messages from the secondary queue after the 12-hour delay.
   • Ensure this JMS sender is configured to handle the messages correctly after the delay.

Add Groovy Script for Post-Delay Processing

6. Groovy Script After Secondary Delay:
   • Add another Groovy script to handle the logic after the 12-hour delay.
   • This script will reset the retry count or perform any necessary actions if the retries still fail.

Example Groovy Script:

groovy
import com.sap.gateway.ip.core.customdev.util.Message

def Message processData(Message message) {
    def retryCount = message.getProperty("retryCount")

    // Logic to handle message after secondary retry
    if (retryCount == 3) {
        // Reset retry count or take alternative action
        // For example, log the failure or send a notification
    }

    return message
}

5. Full iFlow Sequence

Here is the full sequence of steps in the iFlow:

1. JMS Sender Adapter:

   • Reads messages from the primary JMS queue.
   • Configured with 3 retries, 1-hour interval.

2. Groovy Script:

   • Manages the retry count.
   • Sets properties retryCount and routeToSecondaryQueue.

3. Router:

   • Routes based on routeToSecondaryQueue.
   • If false, proceeds with normal processing or retry.
   • If true, routes to the secondary JMS queue.

4. Secondary JMS Queue:

   • Holds messages for 12 hours.

5. Secondary JMS Sender:

   • Retrieves messages from the secondary queue after 12 hours.

6. Groovy Script:

   • Handles logic after the 12-hour delay.
   • Resets retry count or takes alternative action.

Summary

This iFlow setup ensures that:

• Messages are retried up to 3 times every hour using the primary JMS queue.
• If those retries fail, messages are routed to a secondary JMS queue.
• The secondary queue holds the messages for 12 hours before retrying.
• After the 12-hour delay, additional logic can be applied to handle the messages appropriately.

By following these steps, you can effectively manage retries with both short-term and long-term intervals in the SAP Integration Suite.