The Value of Table Change Logging For SAP Customizing Data
Why Table Change Logging?
SAP enables the functionality of change documents for business objects such as credit card data and bank account information. The tracking of changes to SAP customizing data can be enabled through activation of Table Change Logging. Starting with SAP S/4HANA 2021 it is enabled by default. The two main goals of Table Change Logging are:
- Identification of unauthorized changes
- Fulfillment of legal requirements and audit rules
Unlike using the concept of change documents that usually consist of a set of dependent hierarchical tables, Table Change Logging is activated on a per table level. The key advantage of Table Change Logging compared to the change document concept is that changes are recorded independent of how the tracked tables are accessed (for example, directly via transaction SM30 or via ABAP reports). The function modules for writing the change documents have to be implemented separately into every report that updates the corresponding business object.
What Should Be Logged?
The tracking of customizing data should at least be activated in:
- Production systems
- Systems where customizing data is created or changed
In general, all tables with delivery classes ‘C’, ‘E’, ‘G’, ‘S’ and ‘W’ are potential candidates for table logging. Table changes should only be logged, if the following criteria apply:
- The change frequency is low (fewer than 100 to 1000 changes per week)
- The data is structured simply and can be interpreted in its own context (Xstrings, binary data and so on are not suitable)
- No other change tracking (change documents, versions and so on) exists
- The table structure length is defined as fewer than 16,000 bytes (in a non-UNICODE system, < 8000 bytes)
- The total length of the key fields does not exceed 256 bytes
Application tables (delivery class ‘A’) should not be activated at all because:
- Transaction data is usually changed too frequently and logging would lead to serious performance and data volume issues
- Changes to master data should be covered by explicit change documents, due to their complexity and because they provide a better authorization concept for accessing, archiving and deleting tracked data changes
The tables that should be logged depend upon country and industry specific requirements. The detailed definition of the logging relevance of tables must take place in consultation with your audit organization. A good summary about tables requiring logging is SAP note #112388. This note contains valuable technical information and references some specific SAP notes that discuss logging requirements for individual tables.
How To Enable Table Change Logging in the SAP System
Before the Table Change Logging can be activated for individual tables, it must be enabled for a system in general. Changes to customizing tables can either be applied locally on the system or via transport requests from external systems. Table change Logging for both types of changes has to be enabled separately:
- Enable Table Change Logging for local changes
Table Change Logging for local changes is controlled by the profile parameter rec/client. The default value of that parameter is OFF (Table Change Logging is disabled). Starting with S/4HANA, SAP enforces Security by Default and sets the default value to ALL (Table Change Logging is enabled for all clients).
Make sure the profile parameter rec/client is set to ALL or provide at least a comma-separated list of your production and customizing clients, according to SAP recommendations. You can query the SAP table T000 in order to confirm which clients (MANDT column) are production clients (CCCATEGORY column equal to P) and which are customizing clients (CCCATEGORY column equal to C) as shown below:
The value should be set in the default profile and has to be deleted from all instance profiles using transaction RZ10.
- Enable Table Change Logging for changes applied via transports
Table Change Logging for changes applied via transports is controlled by the SAP TMS Transport Tool parameter RECCLIENT. The default value of that parameter is OFF (Table Change Logging is disabled). Starting with S/4HANA, SAP enforces Security by Default and sets the default value to ALL (Table Change Logging is enabled for all clients).
Make sure the profile parameter RECCLIENT is set to ALL or provide at least a comma-separated list of your production and customizing clients, according to SAP recommendations.
The parameter value can only be changed on the Transport Domain Controller via transaction STMS.
How To Activate Table Change Logging for a Table
The table change logging for an individual table can be activated (or deactivated) in the technical settings of the corresponding table (transaction SE13) by checking/unchecking the flag “Log (Data) Changes”. Mass changes on multiple tables can be applied via the audit report RDDPRCHK. The report provides several benefits. The header section of the report output displays the following:
- The value of the profile parameter rec/client on all instances
- The value of the SAP TMS parameter RECCLIENT
- The client role
- The change settings of the client
The result table lists all tables with their major attributes, including the current status of the “Log (Data) Changes” indicator. If SAP note #2579568 is applied to the system, the result table contains two additional columns “Classification Status” and “Log Flag Description” that help auditors classify and understand the current setting of the Log Indicator. After applying the SAP note, the technical settings of a table contain additional attributes that can be maintained by the author of the table:
If the Log (Data) Changes indicator is not checked, the developer should maintain a rating value (“Not required” or “May be required”) and a reason. The “Classification Status” in report RDDPRCHK is calculated based on these attributes and the effective value of the Log (Data) Changes indicator:
Technically, the rating and reason defined by the developer is stored in table CLS_ASSIGNMENT and both are automatically recorded in transport requests. The two attributes can be overwritten with report RDDPRCHK. Changes made here are tracked in table LOGGINGASSESSMNT which is also connected to the SAP transport system.
Note: The calculation of the classification status in the previous table is not dependent on the table class and is based on tests and code analysis on an SAP NetWeaver 7.56 system SP0. It does not match with the classification status information in SAP note #2579568. Furthermore, the wording used in RDDPRCHK is not consistent. The results might also be confusing as overwritten rating values are neither displayed in the report nor in transaction SE13 while they are taken into account in the displayed classification status.
The rating and reason values for SAP tables can be initialized with the report RDDPRCHK_UPLD (refer to SAP note #112388).
Table Log Evaluation
The logged records are stored in table DBTABLOG and can be read using transaction SCU3.
Data Volume Considerations
What can be done if a fast growth of table DBTABLOG is recognized?
- Determine the objects, which are logged most frequently as described in SAP Knowledge Base Article #2335086
As of patch SAPKB74019 of software component SAP_BASIS 740 and higher releases run report ZSLA_SCU3_CHECK_xx attached to SAP Knowledge Base Article #2724472. (SCU3 | Automatic checks and solution for most frequent issues in table logging) - Decide internally if logging for these objects can be switched off
- If you have decided to switch off logging, perform the procedure described in SAP Knowledge Base Article #1834803
- Decide if the logs should be deleted or archived
- If the logs should be deleted, use menu path Edit -> Logs -> Delete in transaction SCU3 or report RSTBPDEL
Before you start with the deletion, implement SAP Note #2755908 RSTBPDEL – Performance improvement
If you plan to delete logs periodically, read SAP Knowledge Base Article #2388295 - If the logs need to be archived, use menu path Edit -> Logs -> Archive in transaction SCU3, or transaction SARA with archiving object BC_DBLOGS
- Perform a Database reorganization. Further information can be found in SAP Note #53062
Table Change Logging in The Onapsis Platform
The Onapsis Platform provides several modules that check different aspects of Table Change Logging:
- Table change logging status
Checks the profile parameter rec/client
- Verify status of transport changes logging
Checks the SAP TMS parameter RECCLIENT
- Active logging for critical business tables
Checks the Log (Data) Changes Flag for a set of critical business tables
- Active logging for critical technical tables
Checks the Log (Data) Changes Flag for a set of critical technical tables
- Deactivation of Table-Change Logging
Checks if the table logging is explicitly deactivated in a source code object. This could be used to bypass active logging.
- Inadequate Table Logging
Checks a transport request for tables of class A with an activated Log (Data) Changes flag
- Table changes not logged in target system
Checks for tables with an activated Log (Data) Changes flag if the value of the SAP TMS parameter RECCLIENT matches with the value of the profile parameter rec/client in the target system
Conclusion
The continuously growing number of legal requirements and compliance regulations requires more and more data to be logged. The Table Change Logging feature in SAP provides options to track changes to individual tables and simple customized objects. It must be enabled globally for all customizing and production clients – for local changes and for changes applied via transport requests. Learn more about The Onapsis Platform for SAP security and how we’re supporting SAP customers in monitoring all important aspects of Table Change Logging.