SAP Workflow Reporting

Reporting on Workflow data is a skill in itself.
In addition to ABAP skills, Workflow reporting requires you to have Workflow skills, knowledge of Workflow technical architecture and tables. Here is an effort to quickly equip you with those skills.


FAQs on Workflow reporting

1. Which is the transaction table of ALL work items?

Answer: SWWWIHEAD is the transaction table of all work items.

This table contains one entry for every work item in the system.

This table also says if the WI is dialog or background, creator of the WI, creation time stamp, and current status of the WI, Parent WI and Top WI.

2. Where will I get Work Item completion date and time? (Complete / Logically deleted)

Answer: Table SWWWIRET. This table will also provide any errors occurred for the Work item. SWWVHEARET is a Joint view of SWWWIHEAD and SWWWIRET.

3. Where can I get different deadline date and time for each work item?

Answer: SWWWIDEADL will give all the deadline dates for each work item.

4. Which table can give me the dialog work items pending with a user?

Answer: SWWUSERWI or use the FM SWN_UWL_GET_WORKLIST

5. Which table can give me the dialog tasks executed by me?

Answer: SWW_OUTBOX or use the FM SWN_UWL_GET_OUTBOX

6. I have a Notification which triggers a workflow. (I use ISR framework). Where can I see the link between Notification number (QMEL) and the workflow?

Answer: Use table SWW_WI2OBJ

7. Where can I see the entire log for work item? I want to see how it was created? (Triggered by an event?), any one changed its container?  Any one changed the deadline? Etc.

Answer: Use table SWWLOGHIST.

8. Is there any table which will provide container of a work item?
 

SWW_CONT - Container Contents for Work Item Data Container
SWW_CONTOB- Container Cont. for Work Item Data Container (Only Business Objects

For the code refer
http://learnhrabap.blogspot.com/2010/09/workflow-how-to-read-multi-line.html

Here are other useful books on SAP Workflow topic.

 

Best Practices for SAP Workflow Development

Hi friends,

It is very important to follow few rules while developing new workflows. Once developed and moved into Production, it will be tough to alter the workflows, because of the efforts involved in regression testing all the scenarios.

Here are the Workflow development best practices I learnt from my experience.
If you have any more points or questions please reply in comment to this blog.

Agent determination

--> As far as possible do not declare tasks as generic tasks. This will ensure that unauthorized people will never get the work item.
--> If in any case you had to declare a task as generic, ensure that you check the option "Terminate workflow when no agent found"
--> Ensure that agent determination is through Position instead of using users.
--> Handling "Agent not found" scenarios. Better to have rules for redirecting work item when no action was taken by the primary agent for a specific period of time.

Emails
--> Email subject within 50 chars
Ensure that emails originating from workflow have only 50 characters in length. Exceeding characters will appear in workflow log, hence they would look fine if you are looking into workflow log.

But if you see in SOST, you see that characters are truncated after 50 characters

Dialog work items --> Title of dialog workitems are very important. An end user depends on this to identify the type of work item. It also becomes the subject line of extended notifications. Since this is used by the end-user, it has to be less technical and more user or business friendly.

When you create work item texts, you must take different aspects into account, such as multilingual capability or the user-specific formatting of dates and numbers. See SAP Note 1154835. This would also impact the performance while loading these items in UWL or SAP Inbox.

--> Extended notification content
As you know the dialog task description appears as the email content in extended notifications. At the time of developing the dialog task ensure that the task description meets the email (notification) content requirement.

Changing Workflow Template
Version is a beautiful concept SAP has for keeping track of Workflow Template changes. Always create a version before you change an existing template. This will help you to refer back to previous template and even switch to old template if the new changes fail.

Errors in Workflow
Error happens. Regardless of the care you have taken in designing workflows, error happens in workflow. So It is important to handle these errors and develop strategies to handle error scenarios.

--> It is also important to ensure that errors are noticed. To do this you need to ensure workflow is written inside try catch blocks, so that all errors are captured.
--> There should be a strategy at Organization level to handle such scenarios. Errors can be technical or application errors. It is wise to route application errors to Business Process team. Technical errors can be routed to Workflow administrator for resolving.

Workflow Administration
Workflow admins get many routine requests listed as below. It is important to establish business process for below mentioned actions, thus you are with better terms with auditing people.
--> forwarding a work item
--> adding approver to the workflows (to rules or approver tables)
--> killing a workflow ( might be required in case of a wrong WF template moving into prod)

Generic
--> It is mandatory to have a life time for a workflow. That means, if the workflow is pending for action at an agent, it should not be open/ 'live' for indefinite time. There should be time period after which workflow becomes obsolete, thus 'kills' the workflow. Thus you can reduce the load on the system from unnecessary workflows.

--> How the end user will know the current status / history of actions / actual submitted for of Workflow.. ? If you are using processes and forms and if you are in ECC6.0 Enh 2, then SAP provides this functionality.
If you happen to be ECC6.0 (without enh pack) or below, you need to have your own reports/custom applications built to read workflows. In this case it is important to have consistent container names and positions (task level? WF level?) across workflows. This ensures that your report program has less hard coding and thus reducing maintenance costs.

--> Develop a reusable utility class for the WF development : Some functionality in WF that are commonly used and that can be included as methods are listed below.
A method to read a distribution list,
Reading value from a particular customizing table,
Reading manager of an employee,
Reading a rule,
Read if employee is locked

That is it for now. Please let me know your thoughts about this article.

SAP Workflow: How to read Multi-Line container of a Work item

Here is a sample code for reading multi-line, BOR, Objects in a work item container

* For multi line class attribute of a container
  DATA: lv_wi_handle TYPE REF TO if_swf_run_wim_internal,
  cnt TYPE REF TO if_swf_cnt_container,
  l_req_wf_attribs TYPE REF TO cl_pt_req_wf_attribs.

* Get the instance of the workitem
  CALL METHOD cl_swf_run_wim_factory=>find_by_wiid
      EXPORTING
          im_wiid     = wa_wf_data-wi_id
      RECEIVING
            re_instance = lv_wi_handle.

* Get the container
  cnt = lv_wi_handle->get_wi_container( ).

* Get the required attribute from the container
  CALL METHOD cnt->if_swf_cnt_element_access_1~element_get_value
      EXPORTING
             name  = 'REQ' " Name of your object
      IMPORTING
             value = l_req_wf_attribs.

How to achieve Multiple levels of approval in CATS? SAP - Time Management

Hi Friends,

For Time sheets (CATS), SAP does not support multiple levels of approvals.

Custom solutions need to be designed for the same. This post explains one such custom design. This may not be an ideal design and if you have a better design please let me know.

Requirement: Once an ESS user releases his time sheet, a work item should go to his direct manager. Once the direct manager approves the time sheet, it should go to "HR approver" for approval. Once the HR approver approves the work item, work item should disappear, and in CATSDB the line should change to status '30' (Approved). The above requirement is valid only for Attendance type '0123'. For other attendance types the current single step task should get triggered.

Terminology
A “reports to” B “reports to” C ==> Employee “reports to” Direct Manager “reports to” One-up Manager

Solution Design: The solution can be broken down into three logical phases as below. Fourth one is a related and a required change based on your settings.

Part 1, Triggering of the multi-step workflow
SAP allows you to trigger a single step task at "Data Entry Profile" level. So before you set on this task you need to find out the "Data Entry Profile" the target ESS users are using. You can get this from Tcode SU01D

Let us see the single step task that is currently configured for the CATS. Our objective is to disable/stop this single step task and trigger our own multiple step workflow.

Go to SPRO--> Cross-Application Components --> Time Sheet --> Specific Settings for CATS regular --> CATS regular --> Record Working Time --> Set up Data entry Profiles. Select the Data Entry profile under consideration.


Data Entry Profile used by the user

Here you have to either remove "With SAP Business Workflow" or enter a dummy task for the field "Task" so that nothing happens with this task.

In this design we are going to trigger the CATS workflow from user exits.
Now you need to implement user exit CATS 0006-->FM EXIT_SAPLCATS_006-->Include ZXCATU05. Ensure that your workflow triggering code is at the end of this include program, so that all other time sheet validations are complete before you trigger the workflow.

Task to do in the above code: a) For “0123” call two level workflow. b) For ‘Others’ call the earlier single step task. You may use FM SWW_WI_START_SIMPLE to trigger workflow and single step task.

Other way to achieve the workflow triggering is to use the CATS business object and use the events in it to trigger the workflow.

Part 2, Custom screen for displaying the unapproved data once the work item is clicked upon.
A custom WebDynpro screen needs to be created for manager and one-up manager to see the time data to approve. In the UWL configuration XML file, you need to link that application with the workflow dialog task. You need to create an RFC that will populate the data for the above WebDynpro screen.

Pseudocode for the RFC

For the First Level approval (Direct manager)
Fetch all the records with AWART = ‘0123’ with status ‘20’ and work item id = balnk. Show these records for approval.

For the Second level approval (One-up manger)
Fetch all the records with AWART = ‘0123’ with status ‘20’ and work item id = top work item ID. Show these records for approval.

Part 3, Processing approvals and updating CATSDB
An RFC (to be called form portal application) needs to be created which will act according to the user decisions of direct manager and one-up manager. This will have two types of functions. One at the Direct manager level, other at the one-up manager level.

Pseudocode for the RFC

After First Level approval (Direct manager)
Update the CATSDB record with the Top Workitem ID of the workflow. If ‘Rejected’, update the CATSDB and workflow ends. If ‘Approved’, work item will be created for the second level approver.

After Second level approval (One-up manger)
If ‘Rejected’, update the CATSDB and workflow ends. If ‘Approved’, CATSDB record will be changed into ‘30’.

Part 4, Other related and important changes

Team --> Approval of working time (Standard application) will list all the attendance types which need approval, so that the manager can approve. Note that even after the first level of approval, out CATS record still has the status of ‘20’ hence will be available in “Approval of working time” application for the direct manager to approve (more-over he can approve the time as well). This is not right since the work item is now available at one-up manager.

To resolve this conflict I would suggest NOT to show the attendance type which needs two level approval in the Approval of working time application.

This can be easily achieved by a one line code at BADI HRCATS_APPR_CUST
IF_EX_HRCATS_APPR_CUST~EDIT_SELECTION

Sample code
DELETE XT_TIMESHEET_ITEMS where awart = ‘0123’.

Hope you find this blog useful. Enjoy!

How to debug a background task in workflow ?

Many a times we want to debug a workflow but find that the task is a background task.
Here is how you can debug such a task.

Put the following code in the beginning of the background task's FM. Note that htis is an infinite loop.

DO.
IF l = 'X'.
EXIT.
ENDIF.
ENDDO.

Start the workflow and reach till the background task. Now the above peice of code will be executed.

Now got to transaction code SM50 and you will see an entry there with user WF-BATCH. Select that Program/Session --> Program --> Debugging. You will reach to the above code in debugging screen. manually change the variable L to 'X' and you will be out of the infinite loop.