BPC Embedded Model Auditing Feature in aDSO and InfoCube
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.
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.
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.
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.
Thank you for such a excellent blog.
First of all i could like to thank you for this excellent blog, I have one question.
In development system have made the changes in the cube i.e i have "switch on the flag" but when i have transported that query to QAS system, The changes(Setting-->Auditable) are not not affected to the QAS cube and I don' t have write access to make changes in the QAS system.
So Can you please suggest me the how to achieve this requirement.
Please let me know if you require any more information from my end.
The Auditable flag should be able to be transported to downstream systems. Please check if there is anything wrong with your transport. In addition, please also read the KBA suggested by John.
Hi Mohammed, see if following this article helps:
Thanks for your kind reply.
I have transported query to QAS system, But some of the column not showing the data("#") As i have transported the same query. But in development its working fine.
I have checked the query and its same as the development query. Below is the screen shot.
Can you please help
Thank you for the blog. It is very informative.
Could you please tell if there is a possibility to use ADSO __TECH_FIELDS__ in the transformations like it is available in the standard InfoCube with auditing switched on?
I have been looking for 0REQTSN and it is not available as a source field anywhere. Moreover __TECH_FIELDS__ are only visible in the SGUI ADSO display and not in the Hana Studio.
Thanks in advance,
Thanks for the post, we are using Direct Update aDSO and linked it to a BPC Embedded Model but as you menntioned in Other Objects part, today is not available auditing Direct Update aDSO but according to your phrase is possible achieve this behaviour implementing BAdi BADI_RSPLS_LOGGING_ON_SAVE but I can not find more information or How to ... guide about this topic.
I found documentation in the next link about "Saving Changed Values" but is not clear if this Badi supports Direct Update aDSO objects and also does not show a clear example how to achieve this:
Thanks for your help.
The switch on flag in setting that you mentioned above is not available in my system.
Is there any another way to enable that settings ?
I have the same issue in my system, did you solve this issue?