Sorun Cevaplayalım

İşinizle ilgili öngörüler edinin, gerçek zamanlı bilgilere göre karar alın.

SAP Eğitim ve Sertifika Dönemleri

Uzmanlığınızı ve deneyiminizi SAP çözümleri kullanarak tasdik edin.

Çözüm Ekibi Başvurusu

Kullanıcılara hızlı ve pratik çözümler üreterek görev almak isteyenler.

SAP BLOG ADSO Remodeling: Cases after implementation of notes 3006437 and 3019867

SAP Blog

Kayıtlı Üye
Katılım
22 Ara 2017
Mesajlar
1,205
Tepki puanı
6
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


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:

2-39.png


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.

3-36.png




  • 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

4-27.png


5-24.png


6-25.png


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:

7-25.png


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

8-20.png


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

9-19.png


Observations:

  • No remodeling request is generated:

10-20.png


  • TRFN and DTP are getting inactive: you need to collect them in your transport

11-16.png




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:

12-18.png


Observation:

  • No remodeling request is generated:

13-18.png




Check 2: Add one more Group and move all the key figures:

14-15.png




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.

15-11.png




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.

16-12.png


17-11.png




SE11 structure of ADSO before import the change:

18-11.png


Changes imported to Target system without any errors, and the new groups are created:

19-13.png




SE11 structure of ADSO after the change is imported into the target system:

20-10.png




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.

21-8.png




Transport to target system:

22-7.png


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):

23-7.png




24-7.png




SE11: No changes in the data structure:

25-6.png


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.

26-5.png


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)

27-6.png




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!!)

28-5.png




In Target system:

  • RSADMIN parameter RSO_ADSO_ONLINE_CONV_THRESHOLD value set to 50,000.
  • Transport log of the target system:

29-4.png


30-4.png




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)

31-3.png


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.

32-4.png




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

33-5.png




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:

34-6.png


Add child compounding infoobect in Development system:

35-3.png


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;

36-3.png


37-3.png


  • 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...
 
Üst