Simply implement retry mechanism in SAP CPI without JMS(part 2)

Introduction

I have writen a blog on implementing a retry mechanism in SCPI with Data Store here the other day.
Though that solution is simple and straightforward, i found there are few disadvantages on it:

1. No Bulk Message Supported. Each time the process can only retrieve one message from the Data Store.
2. Scheduled Time is kind of fixed coded. Say I have 3601 error messages in the Data Store and the process has been configured to run for 1 hour with 1 second interval. Consequently, after the one hour window has finished, there will be , regardless of any delay, still one message left in the Data Store.

I have upgraded the Data Retry iFlow as below

The detail steps will be elaborated later. The iflow can be downloaded from here.

Detail Design Explain

To avoid using fixed runing windows, the loop local call has been used. The loop will end up if the maximum iteration number has reached or the Data Store is empty. By this means, the iflow can only be triggered once.

To be able to retrieve multiple messages per select from the Data Store, the message split has been used in the iFlow making sure the target message is consistent.

Here are the details:

Step1. Initialise the status. Since the local loop call has been used, the loop end up condition is mainly on whether the Data Store is empty or the retrieved message is blank. The custom status is initialised before the loop has been called.

Step 2. Retrieve Failed Messages in a loop call.

The maxinum number of recycle has been configured to 10,000 in my iflow. Assume this is a number that never be reached.

The running condition is flag IsEmpty is ‘false’, which means the message is not empty. When the Maximum iterations have reached, rather than raise an exception rolling everything back, just end up the process. Make adjustment according to your requirement.

Step 3. Inside the sub process, retrieve the failed messages from the Data Store.

change the Data Store name for your own requirement.

Adjust The number of Polled Messages if necessary. If multiple messages have been retrieved here, it will be split up later into single message into subsequential system.

Step 4. Splitter

General Splitter has been used here to retain the wrapper elements so that the xslt mapping later can be reused.

Step 5 is exactly the same as the mapping in the iflow v1.0. I am  not going to deep into it.

Step 6 is the call to the subsequential system. It depends on your particular requirement. No need to be elaborated here.

Step 7 and 8 are very similar to Step 1. Just to modify the flag for controlling the local loop call.

Conclusion

With the enhanced iflow, the schedule can be once per day rather than a fixed time window. The process will stop when all of the error messages have been retrieved automatically. The redundent calls have been greatly reduced.

On the other hand, it supports multiple messages retrieving which will be better for the performance, if the number of failed messages are huge.

Feel free to download it from here.