Introduction:
In the SAP Cloud Platform Integration (CPI) or Integration Suite, ensuring that retry attempts are made under the right circumstances is essential for efficient error handling and message processing. While retries can be an effective way to deal with temporary issues, they can also lead to unnecessary load if applied to interface errors that are unlikely to resolve on their own.
In this blog, we will build upon the previous blog where we discussed sending email notifications after the final retry attempt. Now, we will focus on configuring SAP BTP Integration Suite to differentiate between connectivity errors and interface errors, ensuring that retries are only attempted for transient issues like connection failures. This selective retry approach helps in optimizing system performance, saving resources, and avoiding unnecessary retries for errors that require manual intervention or cannot be resolved through retries.
Note: This will only be applicable when using receiver adapters like HTTP, SOAP, IDOC, and OData, essentially any receiver adapters that returns the CamelHttpResponseCode in the header.
Use Case Overview:
In this use case, we will demonstrate how to configure an integration flow in SAP BTP Integration Suite to handle retries selectively, ensuring that only connectivity-related errors trigger retry attempts. The main objective is to fine-tune the retry logic so that retries are not applied to interface errors that require manual intervention, thereby optimizing the system’s performance. We will configure the integration flow to differentiate between connectivity and interface errors, ensuring retries are executed only for transient issues such as network or service-related problems. By doing so, the system will be more efficient, and resources will not be wasted on errors that cannot be automatically resolved.
Additionally, this configuration will ensure that an email alert is triggered in two specific scenarios:
For Non-Connectivity Errors: The flow will be ended without any retry attempts and an email will be sent once when a non-connectivity error occurs. For Connectivity Errors: The system will retry the operation up to a specified retry limit (e.g., 3 retries as set in AEM). Once the retry attempts are exhausted, an email notification will be triggered, alerting stakeholders of the final retry failure(explained in the previous blog).
This solution ensures that notifications are sent only when necessary, reducing notification overload while keeping stakeholders informed about critical issues based on the nature of the error.
Integration Flow:
Below is a sample Integration Flow created to handle retries selectively for connectivity and interface errors in SAP BTP Integration Suite.
The highlighted section in the iFlow screenshot shows the modification made to the integration flow from the previous blog. As shown, we have incorporated a Groovy script and a Router to manage retries specifically for connectivity-related errors.
In addition to the Groovy script and router, we need to create a value map that associates response codes with corresponding values, such as true or false. The Groovy script will extract the CamelHttpResponseCode from the header, look it up in the value map, and return the corresponding value (either true or false). If the response code is not found in the value map, the script will default to false.
Sample Value Map:
Note: As shown in the sample value map, I’ve assigned 408 a value of true because it’s a timeout issue, which justifies a retry. On the other hand, 401 is set to false since it indicates an authorization error, which cannot be resolved by a retry and would require manual intervention to provide the correct authorization. With this setup, we can now refine the retry logic further to focus only on the specific connectivity errors that should trigger retries.
Groovy Script:
import com.sap.gateway.ip.core.customdev.util.Message;
import com.sap.it.api.ITApiFactory
import com.sap.it.api.mapping.ValueMappingApi
def Message processData(Message message) {
def body = message.getBody();
def map = message.getHeaders();
def ResponseCodeValue = map.get(“CamelHttpResponseCode”) as String;
def valueMapApi = ITApiFactory.getApi(ValueMappingApi.class, null)
def value = valueMapApi.getMappedValue(‘Input’, ‘ResponseCode’, ResponseCodeValue, ‘Output’, ‘Value’)
if (value == null){
message.setProperty(“RetryFlow”, false);
}
message.setProperty(“RetryFlow”, value);
return message;
}
Router :
We use a router to define the routing condition as ${property.RetryFlow} = ‘true’ for Route 1, ensuring that only messages matching this condition will be retried. All other messages, which do not meet this condition, will follow the default Route 2. This route triggers an email alert to the relevant team and ends the flow, preventing further retries.
Conclusion:
In this blog, we explored how to configure selective retries in SAP BTP Integration Suite when using AEM by differentiating between connectivity errors and interface errors. By refining the retry logic, we ensure that only transient issues like network or service-related problems trigger retry attempts, while more persistent errors, such as authorization failures, are excluded from retries and flagged for manual intervention.
By implementing the solutions outlined in this and the previous blog, we can improve the efficiency of our integration flows, minimize unnecessary retries, and ensure that stakeholders are only notified when required. This approach also makes it easier for the support team to investigate issues, ultimately streamlining error handling and message processing in SAP BTP Integration Suite when using the AEM sender.
Introduction:In the SAP Cloud Platform Integration (CPI) or Integration Suite, ensuring that retry attempts are made under the right circumstances is essential for efficient error handling and message processing. While retries can be an effective way to deal with temporary issues, they can also lead to unnecessary load if applied to interface errors that are unlikely to resolve on their own.In this blog, we will build upon the previous blog where we discussed sending email notifications after the final retry attempt. Now, we will focus on configuring SAP BTP Integration Suite to differentiate between connectivity errors and interface errors, ensuring that retries are only attempted for transient issues like connection failures. This selective retry approach helps in optimizing system performance, saving resources, and avoiding unnecessary retries for errors that require manual intervention or cannot be resolved through retries.Note: This will only be applicable when using receiver adapters like HTTP, SOAP, IDOC, and OData, essentially any receiver adapters that returns the CamelHttpResponseCode in the header.Use Case Overview:In this use case, we will demonstrate how to configure an integration flow in SAP BTP Integration Suite to handle retries selectively, ensuring that only connectivity-related errors trigger retry attempts. The main objective is to fine-tune the retry logic so that retries are not applied to interface errors that require manual intervention, thereby optimizing the system’s performance. We will configure the integration flow to differentiate between connectivity and interface errors, ensuring retries are executed only for transient issues such as network or service-related problems. By doing so, the system will be more efficient, and resources will not be wasted on errors that cannot be automatically resolved.Additionally, this configuration will ensure that an email alert is triggered in two specific scenarios:For Non-Connectivity Errors: The flow will be ended without any retry attempts and an email will be sent once when a non-connectivity error occurs. For Connectivity Errors: The system will retry the operation up to a specified retry limit (e.g., 3 retries as set in AEM). Once the retry attempts are exhausted, an email notification will be triggered, alerting stakeholders of the final retry failure(explained in the previous blog).This solution ensures that notifications are sent only when necessary, reducing notification overload while keeping stakeholders informed about critical issues based on the nature of the error.Integration Flow:Below is a sample Integration Flow created to handle retries selectively for connectivity and interface errors in SAP BTP Integration Suite. The highlighted section in the iFlow screenshot shows the modification made to the integration flow from the previous blog. As shown, we have incorporated a Groovy script and a Router to manage retries specifically for connectivity-related errors.In addition to the Groovy script and router, we need to create a value map that associates response codes with corresponding values, such as true or false. The Groovy script will extract the CamelHttpResponseCode from the header, look it up in the value map, and return the corresponding value (either true or false). If the response code is not found in the value map, the script will default to false.Sample Value Map:Note: As shown in the sample value map, I’ve assigned 408 a value of true because it’s a timeout issue, which justifies a retry. On the other hand, 401 is set to false since it indicates an authorization error, which cannot be resolved by a retry and would require manual intervention to provide the correct authorization. With this setup, we can now refine the retry logic further to focus only on the specific connectivity errors that should trigger retries. Groovy Script: import com.sap.gateway.ip.core.customdev.util.Message;
import com.sap.it.api.ITApiFactory
import com.sap.it.api.mapping.ValueMappingApi
def Message processData(Message message) {
def body = message.getBody();
def map = message.getHeaders();
def ResponseCodeValue = map.get(“CamelHttpResponseCode”) as String;
def valueMapApi = ITApiFactory.getApi(ValueMappingApi.class, null)
def value = valueMapApi.getMappedValue(‘Input’, ‘ResponseCode’, ResponseCodeValue, ‘Output’, ‘Value’)
if (value == null){
message.setProperty(“RetryFlow”, false);
}
message.setProperty(“RetryFlow”, value);
return message;
} Router :We use a router to define the routing condition as ${property.RetryFlow} = ‘true’ for Route 1, ensuring that only messages matching this condition will be retried. All other messages, which do not meet this condition, will follow the default Route 2. This route triggers an email alert to the relevant team and ends the flow, preventing further retries.Conclusion:In this blog, we explored how to configure selective retries in SAP BTP Integration Suite when using AEM by differentiating between connectivity errors and interface errors. By refining the retry logic, we ensure that only transient issues like network or service-related problems trigger retry attempts, while more persistent errors, such as authorization failures, are excluded from retries and flagged for manual intervention.By implementing the solutions outlined in this and the previous blog, we can improve the efficiency of our integration flows, minimize unnecessary retries, and ensure that stakeholders are only notified when required. This approach also makes it easier for the support team to investigate issues, ultimately streamlining error handling and message processing in SAP BTP Integration Suite when using the AEM sender. Read More Technology Blogs by Members articles
#SAP
#SAPTechnologyblog
