I came across an interesting scenario and the challenge was to build it with bare minimum complexity and little or no development effort and this lead to a approach I am talking about today. I have Web service that creates Service Request (SR) in the CRM system. If any error occurred because of CRM is down or any other reason (Master data issue in CRM etc) then the task should at least attempt for an hour and then if it is still not able to create SR then send the task to an appropriate agent with all the information of the task so that manual investigation can be done and after the issue is fixed and the agent can re-submit the SR creation task from Portal. This way you can design your workflow which required very minimal BAU support :smile: .
Scenarios:- In workflow we will come across many scenarios when you wish that your task/method should attempt/execute multiple numbers of times before terminating the task. For example:-
1) When you are trying to update a particular record (Say PO) and the PO is locked by other user. In this case you want the system to attempt to perform the action after an hour interval for at least some time and if still it is unsuccessful because of the same locking reason then throw error (or keep on trying N number of times till it succeeds in case you don’t want to generate an error ).
2) You want to modify Personnel Master data and it is locked due to Payroll lock/blackout period, you might want to try again and the record should get updated once that lock is removed.
3) You are calling RFC to execute functionality in remote system and remote system is down. You know that it will be up in an hour but you are lazy to do any extra effort to execute the same task again.
Pre requisite:- You have performed the basic customizing for workflow correctly (t-code SWU3) and make sure that you have scheduled background Job for work items with Errors as shown below.
Please note two parameters (Interval unit next rerun & Repeat counter for work items with errors) when you try to schedule this program as shown below.
PIC1 - Schedule Job - Diagram
The main purpose of the Job is to check if there is temporary error (as explained in detail below) then this schedule Job will try to execute that particular task again after 20 mins and It will try for at least 3 times (If that is configured differently in the task, explain later) before setting this temporary error task into permanent error which in turn will set the workflow into error.
Temporary Error:- I will keep this very short and providing you with the link worth reading.
If you have similar scenario as discussed then SAP has provided you with temporary error option. You can raise temporary error both from Class or BOR object for the Background Job to pick this up and reattempt later. Please read this Link on how to raise this exception in BOR.
The equivalent of Temporary, Application and system exception type of BOR is tabulated below.
| BOR Exception type | Equivalent Exception Class |
|---|---|
| Temporary | CX_BO_TEMPORARY |
| Application | CX_BO_ERROR |
| System | CX_BO_ABORT |
Please note that temporary error has two usages depending on the task type:-
Background Task:- In this case the schedule program (Workflow system) will retry for the particular number of time configured until it give up and set the workflow into error.
Dialog Task: - In this case it will remain in process status.
Step by Step demonstration of the temporary error in working
First I will walk you through some nice pictures of my development and then I will explain them in details. So here it goes:-
PIC 2 – Task - Diagram
PIC 3 – Task Outcomes Tab - Diagram
PIC 4 – Task binding with method - Diagram
PIC 5 – Latest End Tab - Diagram
PIC 6 – Class interface - Diagram
Please note I have created Temporary and Permanent exception class which has super class CX_BO_TEMPORARY & CX_BO_ERROR respectively as shown below.
PIC 7 – Temporary Exception raised - Diagram
Approach 1: Use of Counter Field
I am raising temporary exception if my Service request is not getting created in my CRM as shown in PIC 7. So that SAP can re-attempt to create the SR again after 20 mins. SAP tracks the number of attempt through a variable in the step container (object WORKINGWI) as you can see in PIC 4 and we will utilize the same. I have added a counter field in my method class I_RETRY_COUNT (PIC 6). As shown above PIC 1 right now my system is configured to execute the temporary error for 3 times (Initial + 3 more attempt) (PIC 1). Therefore SAP will put this task into permanent error on the 5th attempt (Little weird ha). Therefore before SAP throw the exception I will throw my permanent exception which I will be using as the outcomes of the task as shown in PIC 3 & PIC 2.
To achieve the same I am putting the task into permanent error in its 3rd attempt that is count > 2 (PIC 4). This Exception will then be handled and a notification will be sent to an agent as the outcomes step Route by permanent Error - Used in Approach 1 (as shown in PIC 3 and PIC 2).
Are you thinking that 3 attempts 20 min is restricting you as you don’t want to change the behavior for all other Workflow task, don’t worry see PIC 8 for your answer.
PIC 8 – Repeat attempt and Time Configuration - Diagram
Approach 2: Use Deadline monitoring
Here I am behaving little clever and using deadline monitoring “Latest End” as shown in PIC 2 and PIC 3. I am now raising only temporary error as shown and removed the permanent error code which was based on the count as in approach 1. Therefore it will keep on trying the task every 20 min for 3 times i.e you have an hour, so if you configure the “Latest End” such that it triggered after 45 min then you can avoid permanent error and divert the next course of direction as shown in the PIC 2. Please read this Link for detail on modeled deadline monitoring.
Step by step illustration for Approach 1
Step1. Execute the workflow and check the status
You can see that it has thrown an exception but the task is still not in error, it is in progress status. Let me show you the value of repeat counter. It is set to 00.
Step 2 Let us execute the program RSWWERRE manually so that we don’t have to wait for 20 min (demo purpose only). You can see that it has picked up our task and try to execute the method.
Step 3 Let us see the repeat counter now it is set to 01. Similarly it will try for second and third time when the permanent exception will be triggered.
Please have a look at the log it has attempted twice to execute the task
Step 4 Now I have executed the program RSWWERRE again so that it will exceed the counter and permanent error will be thrown which we want and the desire outcome step is executed as shown below.
The desire step outcome is triggered – Route by permanent Error – Used in Approach 1 , which we used to send the notification to the agent.
Step by step illustration for Approach 2
I have executed the workflow and you can see that temporary exception has been thrown as below
You can also see that background job as already executed and attempted to execute the step as shown below.
But before it get executed by the program after an hour i.e third attempt the modeled step for Latest end get triggered which is set for 45 min and the obsolete step is executed as shown below.
This way you can avoid the permanent error and can divert the notification to someone who can resolve the issue.
- SAP Managed Tags:
3 Comments
