Workflow reporting with BW - how to extract information?

[Workflow99@aol.com]

Mikko,
 
Please see the following from Alan reg. the future of WIS.
_http://mailman.mit.edu/pipermail/sap-wug/2005-June/018025.html_ 
(http://mailman.mit.edu/pipermail/sap-wug/2005-June/018025.html) 
 
 
Regards,
Ramki Maley
Workflow Developer,  USCBP.
248-613-1287 (C)

 
In a message dated 8/16/2005 8:40:36 AM Eastern Standard Time,  
mikko.maki-rahkola at accenture.com writes:

Hi wug  members,

we're planning to do some more serious reporting on process  statistics and 
we have selected BW as the reporting engine & frontend. The  statistical 
information contains both workflow-specific container element info  such as company 
codes and general workflow header statistics such as  completion times. The 
backend system is R/3 4.6c.

My problem is how to  determine the best approach for extracting the 
information. The following are  my initial options and thoughts about them. Please let 
me know if you have had  a similar decision to make and which way did you go, 
if you have can tell  which is the most convenient option or if you can just 
comment on some of  them.

Thanks!
-Mikko

1. Direct extraction from standard  tables SWWIOBJCT, SWWWIHEAD and SWW_CONT
- either build a function module  which picks up the information from all the 
tables and works as a BW data  source or
- do the table joins in BW
- pros: no development needed in  R/3, data to be kept in a single location, 
easy use in BW if fm is built
-  cons: custom functionality build effort in R/3, problems with table joins  
(especially linking workflows to objects and workflows to container 
elements),  extraction performance, amount of future support (changing a container 
element  name results in fm changes)
- my preferred option currently if it's  possible

2. Extract first to WIS, then extract to BW
- with the user  exit and steps in help.sap.com, the stats can be extracted 
first to a new WIS  table/structure and
- BW can then be used to extract the information from  workflow-specific WIS 
structures/tables
- I have tested the WIS update  procedure with the user exit codings and all, 
but it felt a bit awkward and I  remember having some problems with it
- pros: less custom coding in R/3,  WIS quick to be filled
- cons: duplicate information in standard tables and  WIS, possible BW 
extraction problems, extra configuration for future  workflows
- not too keen about this, wis used just as a middleman

3.  Extract to BW from process-specific custom tables
- quick and dirty  approach, a custom log table to be created for all 
workflows
- a single  table line contains all the information needed for that process 
for a single  process instance
- pros: easy to build reports on, easy to extract to  BW,
- cons: duplicate information with standard tables, new tables for all  new 
future workflows
- not too eager to do this either, too much work in  the long run


This message is for the designated recipient only and  may contain 
privileged, proprietary, or otherwise private information.   If you have received it in 
error, please notify the sender immediately and  delete the original.  Any 
other use of the email by you is  prohibited.


_______________________________________________
SAP-WUG  mailing  list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20050816/71320a8e/attachment.htm