Skip to Content

Reading so many blogs on variety of topics in past few months and not contributing to the community is a weird feeling, so I felt its time to give my 2 cents to the community. Every new requirement triggers a research activity and as always there are more ways than one, the first choice or the instinct of any programmer now a days is to google it to get some ready baked/ or half baked stuff which can make life easier, and more often than not, most searches lead to SDN, it is like “All roads lead to Rome”, SDN has become such a huge repository that you get almost anything here, a one-stop shop. Though I am a fan of the old sdn, I am begining to like this new avatar the more I use it.

After a long hiatus a new requirement turned my attention towards SAP workflows. Some requirement sound simple but involve tricky solutions, and I believe any solution provided should have a less impact factor on the existing state of affairs. Here is what the customer had to say – Stop all the workflows after a particular date and restart all the workflows on hold after a certain date. It is an informal way of saying “hey all you folks! stop working, go on a vacation till I call you back. OK great!”, that is a crazy way of looking at things.

Now, we had a bunch of workflows which were designed to update HR master data after an approval processes and the update task of these workflows did not have any monitoring in place, and these unruly workflows would apparently try to update the data when the payroll is running and fail which leads to a manual task, though the problem was overcome by skipping update on a payroll run it still left us with a manual update later on. We needed some control in place to have all workflows stop when the red light is on, in other words, the update task process should stop when required, the timeframe should be configurable. To put it in more simpler words, we wanted a Stop, Watch, and Proceed arrangement in place. As always, there are more than one way to skin a cat, I could see few possibilites here, one way was to use the event creater and event watch activities in your workflow but then that would mean a lot of changes to existing workflow, and another way is to keep looping the task till conditions are satisfied, and you will do that if you have gone crazy, but the best way I thought was to do this way.

1. Create a Z-table which will hold the information as to when the workflows for a particular process should stop updating.

2. Create another Z-table to hold all the workflow ids which were stopped in this time period, this information will help us in restarting the workflows later on.

3. Create a workflow container element which can be used as a flag in worktiem conditions.

FLAG_WI.JPG

4. In the conditions tab of the the update task include the container element value as a check in the create work item, this will stop the work item execution till the condition is met, the work item will still be created.

wf_cond.JPG

5. Create a Z class which implements the IF_SWF_IFS_WORKITEM_EXIT interface, this will basically introduce a method EVENT_RAISED which can be used

to implement the business logic.

Class.JPG

6. Have the required logic in the method, incase the workflow should not be stopped then WF container should be updated in the BEFORE_CREATE event so that the flow execution goes on smoothly. Unfortunately the SAP_WAPI_WRITE_CONTAINER function module does not work in this method and you might need to write some custom logic to update the WF container, I have used private instance method update_container to have the container value updated. Incase the execution has to be stopped then the work item ids are moved to a Ztable.

method.JPG

7. The workitem which got created but not executed due the condition not met will remain in the checked status.

wiitem.JPG

8. To have all the workflows restarted at any time, I just developed a simple program which picks up the ids from the ztable and updates their container element COM_WI with X, you can use FM SAP_WAPI_WRITE_CONTAINER here. Once the container element gets updated the standard job SWWCOND which monitors the conditions on the workitems will kickstart the workflow from the stopped step.

Hope this blog finds some use to those who are novice to workflows and thanks for reading. Your comments and ratings are welcome.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Susan Keohan

    Hi Raghavendra,

    That is a really interesting problem – and a really interesting solution too.

    As you say, there are many ways to skin a cat.  Did you consider having the update process check for the payroll run (or a record lock, better yet) and then just re-try until it could get a lock on the record?   I don’t know how long that payroll run is, so I suppose it could get pretty ugly – to have a large number of background processes waiting around for a payroll run to finish…

    I like the innovation you have shown here!
    Thanks for sharing,
    Sue

    (0) 

Leave a Reply