Dear BW community!
In this blog post, I would like to share with you my experience with the ADSO remodeling behavior, after the implementation of notes 3006437 and the most recent 3019867.
For details on ADSO remodeling behavior, kindly go through the blog posts of our SAP partner Frank Riesner, where he explains the details clearly:
Role of Remodeling in the ADSO Change Management Process | SAP Blogs
Role of Remodeling in the ADSO Change Management Process – Part 2 | SAP Blogs
Scope of this blog post will delve in to details of below use cases:
As explained in the blog posts from Frank Riesner, note 3006437 brings a new RSADMIN parameter RSO_ADSO_ONLINE_CONV_THRESHOLD, that allows us to control the threshold limit of the number of records, beyond which the system triggers a remodeling request. However, in large enterprises, the possibility of having ADSOs, with more than 100 million records is very common. Thanks to the note 3019867, this limitation has been addressed.
For the scope of this blog post, The following scenarios are tested. For space reasons, scenarios 1 – 4 and 7 are part of this blog. Scenarios 5 and 6 had the same results with all other regrouping scenarios. Scenarios are checked in both a SAP BW/4HANA 2.0 SP06 and in a SAP BW 7.5 SP15. Screenshots are from the SAP BW/4HANA system.
Let’s see the details now:
Conditions for scenario:
Observations:
ADSO is type “standard” and scope of the test case is to validate the system doesn’t generate any remodeling request once you change folders, or change the InfoObject sequence of “Data fields”.
Sub scenario 2.1:
Conditions for scenario:
Observations:
Sub scenario 2.2:
Condition for scenario:
Observations:
Sub-scenario 2.3:
Conditions for Scenario:
Check 1: Add a new group in the ADSO and regroup the infoobjects:
Observation:
Check 2: Add one more Group and move all the key figures:
Observations:
SE11: No changes in the table structure: however, the real picture of table can be taken from Hana only.
Check 3: Moving the changes to the target system, we see as per the transport log, no remodeling request is generated and all dependent objects are activated (1 Composite Provider, 2 ADSOs, 2 Transformations, 2DTPs): Target ADSO has 517.772 entries.
SE11 structure of ADSO before import the change:
Changes imported to Target system without any errors, and the new groups are created:
SE11 structure of ADSO after the change is imported into the target system:
Condition for scenario:
Development system:
ADSO: No data, RSO_ADSO_ONLINE_CONV_THRESHOLD is not maintained.
Create an additional Group and move the change to target system. No remodeling request is generated.
Transport to target system:
Observation in Dev System:
No remodeling request is generated, all objects are activated (1 Composite Provider, 2 ADSOs, 2 Transformations, 2 DTPs).
Target system:
RSADMIN parameter is maintained with value as 50,000 (less that the entries in target DSO, which is 517,772):
SE11: No changes in the data structure:
Please take a look into table structure through Hana Studio: the only change is happening due to the addition of child compounding infoobjects. All other changes (regrouping, infoobject sequence) are not affecting the table structure.
Observation in Target System:
Conditions for scenario:
In Development system:
Observation in Dev System:
ADSO is activated – no remodeling request is generated, however there are warning about potential remodeling: (Please do not be confused, It is just a warning!!)
In Target system:
Observations in Target System:
Is it very important to check the log; we are informed that a remodeling request is generated by ADSO and on top, all dependent objects are SKIPPED. All dependent objects should be taken care by remodeling request.
As we can understand, the remodeling request is hidden in the transport log. In most of the cases, developers or transport managers ignore the warning messages that generated during the transport.
As a result, developers recognize the issue only during their test and you can understand the risks its entails!!
Remodeling Request: (transaction RSMONITOR)
Execution of remodeling request was successful, ADSO is adjusted and all dependent objects are activated.
After the implementation of note 3019867, SAP removes the fixed 100 million limit and it is customer responsibility to define the limit through the RSADMIN parameter.
Responsible of the check is method IS_ONLINE_CONV_POSSIBLE of class CL_RSCNV_ADSO_HDB. Default value 100 million is still valid, however RSADMIN parameter value controls the process of ADSO activation.
So, for our scenario, I maintained RSADMIN parameter RSO_ADSO_ONLINE_CONV_THRESHOLD with a value of 2 billion in my target system and I enhanced an existing ADSO type “DataMart” with a child compounding infoobject
My ADSO keeps 1.7 billion records in the target system. Total number of columns (characteristics and key figures) = 90.
ADSO active table view from Hana Studio:
Add child compounding infoobect in Development system:
As expected, no remodeling request is generated, however there are warning messages for potential remodeling if ADSO is not empty.
Target system:
RSADMIN parameter is maintained as 2 billion.
Changes moved to the target system; here the transport log;
Conclusion:
Special thanks to my colleague Kalyan Kothinti who encourage me to publish this blog and share our experience on this topic !!
Enjoy!!
Okumaya devam et...
In this blog post, I would like to share with you my experience with the ADSO remodeling behavior, after the implementation of notes 3006437 and the most recent 3019867.
For details on ADSO remodeling behavior, kindly go through the blog posts of our SAP partner Frank Riesner, where he explains the details clearly:
Role of Remodeling in the ADSO Change Management Process | SAP Blogs
Role of Remodeling in the ADSO Change Management Process – Part 2 | SAP Blogs
Scope of this blog post will delve in to details of below use cases:
- Re-folder the InfoObject grouping
- Change the InfoObject sequence
- Insert a new compounding child InfoObject
- Insert a new compounding InfoObject (parent and child)
- Maintain RSADMIN parameter RSO_ADSO_ONLINE_CONV_THRESHOLD
As explained in the blog posts from Frank Riesner, note 3006437 brings a new RSADMIN parameter RSO_ADSO_ONLINE_CONV_THRESHOLD, that allows us to control the threshold limit of the number of records, beyond which the system triggers a remodeling request. However, in large enterprises, the possibility of having ADSOs, with more than 100 million records is very common. Thanks to the note 3019867, this limitation has been addressed.
For the scope of this blog post, The following scenarios are tested. For space reasons, scenarios 1 – 4 and 7 are part of this blog. Scenarios 5 and 6 had the same results with all other regrouping scenarios. Scenarios are checked in both a SAP BW/4HANA 2.0 SP06 and in a SAP BW 7.5 SP15. Screenshots are from the SAP BW/4HANA system.
Scenarios
Let’s see the details now:
Implement Note 3006437
Scenario 1:
Conditions for scenario:
- Add a compounding InfoObject into the dataflow
- No RSADMIN parameter is maintained in both source and target system.
- The ADSO is of type “Standard”
- ADSO contains less than 50,000 records in the Development system.
- The InfoObject is compounded with two parent InfoObjects, “Source Ssystem” and “Controlling Area”.
- Parent InfoObjects are already part of the ADSO model:
Observations:
- No remodeling request is generated.
- System is checking if RSADMIN parameter is maintained.
- If not, then the 100,000,000 takes care of the checks.
- New InfoObjects are added in the entire data Flow: Composite provider, source ADSO, target ADSO.
- Transport to target system does not generate a remodeling request and all objects are activated during the transport process.
- No of records of the ADSO in target system is less than 100 million
Scenario 2:
- Re-foldering of ADSO,
- Change the InfoObjects sequence,
- no maintenance of RSADMIN parameter RSO_ADSO_ONLINE_CONV_THRESHOLD in both source and target systems.
ADSO is type “standard” and scope of the test case is to validate the system doesn’t generate any remodeling request once you change folders, or change the InfoObject sequence of “Data fields”.
Sub scenario 2.1:
Conditions for scenario:
- In Development system: No of records in ADSO = 0
- Change InfoObjects sequence on “Data fields” area:
Observations:
- No remodeling request is generated
- No impact on dependent Composite Provider: it is still active, however Transformation and DTP are getting inactive: you need to activate and collect them in your transport.
- SE11 Table structure: As there are no data, it seems that the table structure is changed
Sub scenario 2.2:
Condition for scenario:
- We take the same ADSO as sud-scenario 2.1, but this time with data.
- In Development system: No of records in ADSO is appr. 3.5 million
- Change the sequence of 2 InfoObjects
Observations:
- No remodeling request is generated:
- TRFN and DTP are getting inactive: you need to collect them in your transport
Sub-scenario 2.3:
Conditions for Scenario:
- Continue with same ADSO as sub-scenario 2.2.
Check 1: Add a new group in the ADSO and regroup the infoobjects:
Observation:
- No remodeling request is generated:
Check 2: Add one more Group and move all the key figures:
Observations:
- No remodeling request is generated but the interesting part is that table structure as per SE11 is not adjusted as well!
SE11: No changes in the table structure: however, the real picture of table can be taken from Hana only.
Check 3: Moving the changes to the target system, we see as per the transport log, no remodeling request is generated and all dependent objects are activated (1 Composite Provider, 2 ADSOs, 2 Transformations, 2DTPs): Target ADSO has 517.772 entries.
SE11 structure of ADSO before import the change:
Changes imported to Target system without any errors, and the new groups are created:
SE11 structure of ADSO after the change is imported into the target system:
Scenario 3:
Condition for scenario:
- Re-foldering of ADSO
- Change the InfoObject sequence, regrouping,
- Maintenance of RSO_ADSO_ONLINE_CONV_THRESHOLD with a limit less than the ADSO no of records in target system only
Development system:
ADSO: No data, RSO_ADSO_ONLINE_CONV_THRESHOLD is not maintained.
Create an additional Group and move the change to target system. No remodeling request is generated.
Transport to target system:
Observation in Dev System:
No remodeling request is generated, all objects are activated (1 Composite Provider, 2 ADSOs, 2 Transformations, 2 DTPs).
Target system:
RSADMIN parameter is maintained with value as 50,000 (less that the entries in target DSO, which is 517,772):
SE11: No changes in the data structure:
Please take a look into table structure through Hana Studio: the only change is happening due to the addition of child compounding infoobjects. All other changes (regrouping, infoobject sequence) are not affecting the table structure.
Observation in Target System:
- No remodeling request is generated, all objects are activated
Scenario 4:
Conditions for scenario:
- Add a new compounding child infoobject in the ADSO.
- Maintenance of RSO_ADSO_ONLINE_CONV_THRESHOLD with a limit less than the no or records of my ADSO in target only
In Development system:
- ADSO: No data, RSO_ADSO_ONLINE_CONV_THRESHOLD is not maintained
- Add a new compounding IO (child only)
Observation in Dev System:
ADSO is activated – no remodeling request is generated, however there are warning about potential remodeling: (Please do not be confused, It is just a warning!!)
In Target system:
- RSADMIN parameter RSO_ADSO_ONLINE_CONV_THRESHOLD value set to 50,000.
- Transport log of the target system:
Observations in Target System:
- Remodeling request generated.
Is it very important to check the log; we are informed that a remodeling request is generated by ADSO and on top, all dependent objects are SKIPPED. All dependent objects should be taken care by remodeling request.
As we can understand, the remodeling request is hidden in the transport log. In most of the cases, developers or transport managers ignore the warning messages that generated during the transport.
As a result, developers recognize the issue only during their test and you can understand the risks its entails!!
Remodeling Request: (transaction RSMONITOR)
Execution of remodeling request was successful, ADSO is adjusted and all dependent objects are activated.
Scenario 7 – Implement note 3019867
After the implementation of note 3019867, SAP removes the fixed 100 million limit and it is customer responsibility to define the limit through the RSADMIN parameter.
Responsible of the check is method IS_ONLINE_CONV_POSSIBLE of class CL_RSCNV_ADSO_HDB. Default value 100 million is still valid, however RSADMIN parameter value controls the process of ADSO activation.
So, for our scenario, I maintained RSADMIN parameter RSO_ADSO_ONLINE_CONV_THRESHOLD with a value of 2 billion in my target system and I enhanced an existing ADSO type “DataMart” with a child compounding infoobject
My ADSO keeps 1.7 billion records in the target system. Total number of columns (characteristics and key figures) = 90.
ADSO active table view from Hana Studio:
Add child compounding infoobect in Development system:
As expected, no remodeling request is generated, however there are warning messages for potential remodeling if ADSO is not empty.
Target system:
RSADMIN parameter is maintained as 2 billion.
Changes moved to the target system; here the transport log;
- Transport takes approximately 10 mins
- All dependent objects are activated during the transport
- As expected, no remodeling request generated.
Conclusion:
- After implementation of notes 3006437 and 3019867 it is not required to run remodeling request for the scenario “Add compounding child while compounding parent is already in ADSO and contains data”.
- No remodeling request is generated for any regrouping / refoldering / change of
- Special attention must be taken in the transport log as remodeling request is hidden under the warnings
- SE11 is not a valid point to check ADSO table structures. Please use always Hana Studio.
Special thanks to my colleague Kalyan Kothinti who encourage me to publish this blog and share our experience on this topic !!
Enjoy!!
Okumaya devam et...