Workflow reporting in BW – extractor improvements

When starting to work with the BI team on creating workflow reports, you will usually find that although the standard extractors make a lot of data available, there are a few things missing that you will need in order to make the data useful.

The first missing part of the puzzle is the active workitems. ‘surprisingly’ most customers don’t accept a “not reserved by an agent” for almost all active workitems as a good display of the workflow status in the organization…   so you need to give the BI team a way to see the workitems agents and a SAP_WAPI_GET_WI_AGENTS needs to be added to the extractor, although reading from the SWWUSERWI table will work just the same, this is less recommended to read directly from the workitem tables  and as you see in the next paragraphs you will use more calls to function modules that will slow you down anyway.

Another missing part is the workitem result; some reports are made to see the amounts of rejected workitems. This has two problems you will have to deal with:

The first:  you will need to add the ‘_WI_RESULT’ container element by using the SAP_WAPI_READ_CONTAINER function module and SAP_WAPI_DECISION_READ to get the possible decisions.  Combine that with the actual result to see the decision text (although you would expect a WAPI called ‘decision read’ will give you the decision itself…).

The second problem is that result ‘0001’ is usually approve and ‘0002’ is usually reject but, you can’t depend on that since there are always exceptions to the rule, you will probably need a z-table telling the BW what is reject and approve in different workflows.

The last part of the puzzle is that customers want to see reports by the station on the way to approval and this is usually more detailed then the task number because the same task can be used by different approvers, for example in a release strategy based purchasing workflow the same task will be used by Buyers, FI, CEO etc. and reports are usually asked in this detail. The solution I use for this is to transfer the release code to the task container; even in tasks not based on release strategy I sometime transfer an approver code to the task container to help identify the approval station. Again you have to read the release code transferred to the workitem by the SAP_WAPI_CONTAINER_READ function module.

Even if the workflow task wasn’t built with a approver code in its container the data is usually in the workflow (top_wi_id) container but this will be less generic to extract. Another way to get the station is the location of the task in the workflow (the workflow node) if useable and the task. 

So you will end up with a table that is based on workflow-task-node-release code = approval code to determine the approval station. Pay attention that a buyer might be with a different approver code in different workflows. So this 5-th field is needed. Also because the workflow has version management, you might need more than one entry for an approver if the approval task was moved in the workflow structure.