Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Manos
Participant
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:

  • 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!!
4 Comments
Labels in this area