www.biportal.

org

Address Performance Issues in

Change Document Log Reporting with BW 7.3

Contents
1. Why to report on a Change Document Log in BW .......................................................................... 1
2. Create a generic delta enabled extractor based on tables CDHDR and CDPOS ............................. 1
3. Create an acquisition layer DSO in BW to collect all document changes ....................................... 2
4. Create a BTL layer standard DSO for Each Reporting Area ............................................................. 2
5. Initialize for proper Object classes in Prod ..................................................................................... 3
6. Test performance and results in the reports .................................................................................. 4

1. Why to report on a Change Document Log in BW

When users change data in any SAP transaction the changes are recorded in several ECC log tables
(e.g. CDHDR, CDPOS). These can be changes to customer/vendor details, purchase orders, credit
limits, product prices, contract payment terms, etc. In certain BI reports we need to show the
change doc history in addition to the last value, e.g. who changed credit limit for a particular
customer during last two weeks, values from/to, on which dates, etc.

From a technical point of view displaying these changes in various contexts can be challenging due to
a huge number of records in the log (hundreds of millions or even billions of records in the table
CDPOS). By default entries in this cluster table are not marked with a timestamp that allows building
a delta enabled extractor. Therefore we need a smart approach for extracting and organizing these
logs in BW. However, if we have SAP HANA in place the approach will be different.

2. Create a generic delta enabled extractor based on tables CDHDR

and CDPOS
In the Transaction Code RSO2 create a generic delta enabled extractor based on the table CDHDR
this is the table for headers and it is rather small in size. In addition to that it has a Creation Date
field (Udate) that can be used as a delta field in the extractor. Enhance the extractor with the fields
from line items using Transaction Code RSA6.

In the extractor exit code we have to collect all the item records related to the header line. For this
purpose we will connect item records with header lines using full table key: objectclas, objectid,
changenr. As we expect multiple item lines for one header line in the ABAP code I suggest saving all
relevant item lines into a separate internal table. Then we should process the line items from the
internal table in the extractor data package and enhance it with header details by looking up records
from the header table.

1 by Sergei Peleshuk
 www.biportal.org

3. Create an acquisition layer DSO in BW to collect all document

changes
Create a write optimized DSO (ZCDHIWO) collecting all changes from the extractor. We have to
realise that we are not going to store here all records coming from the extractor as we do not need
all of them. As if we did so the data volumes would have been tremendous. Filtering will be done
with the Init infopackage using appropriate Objectclas values needed for the audit reports.

4. Create a BTL layer standard DSO for Each Reporting Area

In order to handle data volumes efficiently and address performance I suggest partitioning change
log data by reporting area. For example, one DSO should contain Credit Limit changes only
(ZCHDCRL), anther one Material master changes, etc. The split should be done in the corresponding
Start routines using the values in the fields: Objectclas, Tabname, Fname.

In case of proper partitioning data volumes in these DSOs should not exceed a few million records.
Key fields should match most common queries executed against this DSO. In case multiple query
types are expected/executed we should create secondary indexes in the DSO with relevant keys.

See example of filtering values for Credit Limit changes below:

2 by Sergei Peleshuk
 www.biportal.org

5. Initialize for proper Object classes in Prod

Please make sure in the Initialization for the extractor you extract only OBJECTCLASS IDs
required in your reporting. Use transaction code SCDO to see a complete list of object
classes with their descriptions and select those that are relevant for your reporting
requirements:

Later on you will be able to add more Object Classes by running additional Initializations if needed.

3 by Sergei Peleshuk
 www.biportal.org

6. Test performance and results in the reports

If we run delta on a daily basis for OBJECTCLASS = BUPA_UKM required for the credit limit update
log the extraction time will be just a few minutes or less. This is a pretty good performance taking
into account that we extract data from huge tables (over 1B records) connected to each other via a
key. Further processing in BW is not going to be an issue from a performance point of view as we will
be dealing with tens or hundreds of thousands records in a daily delta (in this case 350K records
were processed overall for credit limit changes log only).

Running reports or BEx queries on these DSOs is not an issue due to reasonable volumes and proper
indexes. At the same time we can easily use the change log data and the standard DSO (ZCHDCRL)
where it is stored for lookups in the business logic elsewhere.

4 by Sergei Peleshuk