h4. Motivation The new workload statistics collector shipped with NW2004s does not support the user exit Z_USEREXIT_WORKLOAD (note 143550 (http://service.sap.com/sap/support/notes/143550)) anymore, but requires to implement a so-called "BAdI" (Business Add-In, note 931446 (http://service.sap.com/sap/support/notes/931446)). As an additional challenge, the NW2004s workload collector does not only call this BAdI once per collector run, but - depending on the number of statistical records to be processed - multiple times in short time interval. So we have to face the fact that the BAdI implementation might run in parallel on the same application server, processing different sets of statistical records. In this blog, I want to outline how to cope with this challenge by providing sample coding for a quite simple task: When was a transaction or report used the last time? h4. What is a BAdI implementation? A BAdI implementation is simply an ABAP OO class which implements an interface defined by the BAdI definition. Nothing more, nothing less. Use transaction SE18 to create that ABAP OO class, the BAdI name is 'WORKLOAD_STATISTIC'. Note 931446 (http://service.sap.com/sap/support/notes/931446) provides more details. h4. Parallel execution Imagine the following situation: The NW2004s workload collector starts and has to process 7500 statistical records. After processing 7490 statistical records, the workload collector reaches the implemented limit for memory consumption, therefore interrupts its work, passes the collected statistical records to the BAdI implementation and restarts itself. The BAdI implementation now asynchronously starts to process the 7490 statistical records. In the meantime, the workload collector finishes processing the 10 statistical records left over from the previous run and again asynchronously starts the BAdI implementation. The numbers given are an approximation and not 100% correct, but quite close. This drawing illustrates the situation 
14 Comments