Auditing is an important feature for a planning solution.
In BPC NW standard model, auditing was supported since 7.0. The auditing data is stored in a system generated table with the prefix /1CPMB/.
In BPC NW embedded model, the feature is implemented differently. There are multiple different types of planning objects that can be used( InfoCube, Direct Update DSO, Planning type aDSO, Direct Update type aDSO ). Not all of them are supporting auditing today.
In this blog, I'm going to talk about auditing feature in Cube-like aDSO and InfoCube. The other two types of planning capable objects -- Direct Update type aDSO and Direct Update DSO so far still don't support auditing natively.
Before we start, make sure you're aware of below Note and it's successfully applied in your system.
2341545 - Support Auditing for aDSO
In BPC Embedded model, auditing is supported natively by BW. Once you switch on the flag in settings, BW is going to attache one dimension called "Audit Dimension" which includes 4 InfoObjects:
BW automatically updates the 4 InfoObjects when the cube is updated.
When the InfoCube is imported into BPC, the "Auditable" field is automatically marked.
In BPC, there is also a switch of the auditing feature. You can choose to switch on or off the audit.
The switch is not switching off the BW auditing flag. Actually the BW setting will remain on. What it does is to make the value of 0AUSER and 0AMODE a blank when you post new data, but the time stamp is still recorded.
So when you review the data in system report -> Data Change, you can will see entries like below.
To filter out the 0AMODE = OFF values in the audit report, you need to create BW query instead of using system report.
The Auditing will also impact the behavior of BW compression.
As the Auditing InfoObjects are just normal InfoObjects. BW compression will not be able to merge the delta records because even though all the other master data value are exactly the same, the 0ATIMSTMP will still be different . This actually also makes the "Zero Elimination" behave differently than a normal cube.
Without auditing, BW compression with zero elimination will delete this record completely from DB.
Now with auditing on, BW only clears the Request ID. You can see all 3 values remain in the DB. It'll no longer be possible to display a blank cell in the query or report. Instead, there will always be a zero. Unless you physically delete the record from DB or BW.
Before compression
This also means the number of the rows in active data table will always grow if there is no archive in place.
So far InfoCube-like aDSO is the only type of aDSO that supports auditing feature.
Other than the InfoCube, the behavior here is a bit different. There is no setting or flag for a InfoCube-like aDSO, as the auditing is always on and not possible to be switched off. You'll find that whenever you created an aDSO, regardless of the type, there will be a technical group named "__TECH_FIELDS__ " created and attached to it. The group contains only one InfoObject which is 0REQTSN. 0REQTSN contains two navigation attributes which are 0AUSER and 0ASOURCE.
When the aDSO is imported into BPC, the Audit is automatically on and cannot be switched off.
The audit data is stored in the Inbound table along with the request information, in my example, it's /BIC/AZADSOT1.
When you open the BPC Data Change system report, BPC will generate a composite provider under the name space of /1BW/, see below.
Below is what a Data Changes report looks like.
As audit information is part of the request, audit information will go away with activation. So to keep audit information one should never do data activation for the aDSO.
As the auto merge and auto optimize compression is off, and the auditing doesn't allow you to do data activation, you need to trigger it at DB level to ensure good performance on reporting.
Another potential side effect is, without data activation or compression, the size of the aDSO is going to grow quickly.
By far, Direct Update DSO and Direct Update aDSO don't support auditing. Good new is there is a BAdi named BADI_RSPLS_LOGGING_ON_SAVE which can be used to used. You can refer to the SAP Help Portal for more detail.
Hope you find the blog helpful.
In BPC NW standard model, auditing was supported since 7.0. The auditing data is stored in a system generated table with the prefix /1CPMB/.
In BPC NW embedded model, the feature is implemented differently. There are multiple different types of planning objects that can be used( InfoCube, Direct Update DSO, Planning type aDSO, Direct Update type aDSO ). Not all of them are supporting auditing today.
In this blog, I'm going to talk about auditing feature in Cube-like aDSO and InfoCube. The other two types of planning capable objects -- Direct Update type aDSO and Direct Update DSO so far still don't support auditing natively.
Before we start, make sure you're aware of below Note and it's successfully applied in your system.
2341545 - Support Auditing for aDSO
InfoCube
In BPC Embedded model, auditing is supported natively by BW. Once you switch on the flag in settings, BW is going to attache one dimension called "Audit Dimension" which includes 4 InfoObjects:
- 0ATIMSTMP
- 0AUSER
- 0AMODE
- 0ASOURCE
BW automatically updates the 4 InfoObjects when the cube is updated.
When the InfoCube is imported into BPC, the "Auditable" field is automatically marked.
In BPC, there is also a switch of the auditing feature. You can choose to switch on or off the audit.
The switch is not switching off the BW auditing flag. Actually the BW setting will remain on. What it does is to make the value of 0AUSER and 0AMODE a blank when you post new data, but the time stamp is still recorded.
So when you review the data in system report -> Data Change, you can will see entries like below.
To filter out the 0AMODE = OFF values in the audit report, you need to create BW query instead of using system report.
The Auditing will also impact the behavior of BW compression.
As the Auditing InfoObjects are just normal InfoObjects. BW compression will not be able to merge the delta records because even though all the other master data value are exactly the same, the 0ATIMSTMP will still be different . This actually also makes the "Zero Elimination" behave differently than a normal cube.
Without auditing, BW compression with zero elimination will delete this record completely from DB.
Now with auditing on, BW only clears the Request ID. You can see all 3 values remain in the DB. It'll no longer be possible to display a blank cell in the query or report. Instead, there will always be a zero. Unless you physically delete the record from DB or BW.
Before compression
This also means the number of the rows in active data table will always grow if there is no archive in place.
Cube-like aDSO
So far InfoCube-like aDSO is the only type of aDSO that supports auditing feature.
Other than the InfoCube, the behavior here is a bit different. There is no setting or flag for a InfoCube-like aDSO, as the auditing is always on and not possible to be switched off. You'll find that whenever you created an aDSO, regardless of the type, there will be a technical group named "__TECH_FIELDS__ " created and attached to it. The group contains only one InfoObject which is 0REQTSN. 0REQTSN contains two navigation attributes which are 0AUSER and 0ASOURCE.
When the aDSO is imported into BPC, the Audit is automatically on and cannot be switched off.
The audit data is stored in the Inbound table along with the request information, in my example, it's /BIC/AZADSOT1.
When you open the BPC Data Change system report, BPC will generate a composite provider under the name space of /1BW/, see below.
Below is what a Data Changes report looks like.
Activation is going to erase your auditing data
As audit information is part of the request, audit information will go away with activation. So to keep audit information one should never do data activation for the aDSO.
Side effect
As the auto merge and auto optimize compression is off, and the auditing doesn't allow you to do data activation, you need to trigger it at DB level to ensure good performance on reporting.
Another potential side effect is, without data activation or compression, the size of the aDSO is going to grow quickly.
Other objects
By far, Direct Update DSO and Direct Update aDSO don't support auditing. Good new is there is a BAdi named BADI_RSPLS_LOGGING_ON_SAVE which can be used to used. You can refer to the SAP Help Portal for more detail.
Hope you find the blog helpful.
- SAP Managed Tags:
9 Comments
