Role of Remodeling in the ADSO Change Management Process – Part 2
Hello again SAP BW enthusiasts!
Recently, I wrote about the activation process of ADSOs and highlighted that an additional remodeling task is often necessary if the ADSOs contains data (see my previous blog). Today I would like to share the good news that SAP has provided a framework which improves flexibility and offers a lever to avoid remodeling tasks for some cases.
In a nutshell, my previous blog elaborated on the cases when changes to an ADSO with data require additional remodeling tasks to be executed manually in order to activate the object properly. This also applies to the transport management when you provision these changes to the PROD-system finally. The separate remodeling job´s role is to keep the activation time to a minimum and thus to avoid terminations during the direct execution (e.g. time-outs). This safety belt is justified, because changes to ADSOs with a lot of data might result in a huge amount read and write operations to the existing transactional data in the ADSO.
The new framework differentiates between
- Read AND Write operations to the ADSO data, and
- Read ONLY operations on the ADSO data.
Let´s start with case 1: These operations remain unchanged. For instance, when you create a new column and you would like to fill it with a value at the same time, remodeling cannot be avoided (e.g. change the Master Data Check to “Persist SID in DataStore”). The same is true for modifications to the key fields or properties related to inventory key figures, data tiering, partitions, or indices as they usually require technical adaptions to the ADSO core tables on the SAP HANA database level.
The good news is that there is now more flexibility regarding operations related to case 2:
All ADSO changes which result in read-only operations on the ADSO data provide the option to avoid the separate remodeling task. Some common scenarios are:
- Add compounding child while compounding parent is already in ADSO and contains values: In this case the existing parent-child value combinations have to be identified in the ADSO and corresponding SID entries need to be created in the master data.
- Change Validity Characteristics if ADSO is Inventory-Enabled:
In this case the ADSO Validity table is recreated based on the ADSO data.
- Add InfoObject/Field “Criteria”:
In this case the ADSO data is validated whether it meets the new criteria and in the negative case an error message is generated and the activation of the object is denied.
Important! There is the precondition, that the largest ADSO table manages less records than a predefined threshold which is currently set to a default value of 100 million records. As stated above already, this upper limit is intended to prevent the execution from taking too long and terminations.
However, there is a new RSADMIN parameter RSO_ADSO_ONLINE_CONV_THRESHOLD available to change this predefined limit.
Option 1) Enhance the threshold to a larger value (> 100 million)
Precondition: SAP note 3019867 (ADSO: Change Threshold Value for Online Remodeling)
Why would you do this? Well, to avoid remodeling to be required at all for the scenarios listed above.
PLEASE NOTE: SAP does not recommend to do this, as a higher threshold values can cause terminations during import or activation due to timeouts. Changes like this are in customer´s responsibility and should be tested thoroughly as they highly depend on the resources and the performance of of the SAP BW/4HANA system and especially the related SAP HANA database.
Option 2) Reduce the threshold to a lower value (< 100 million):
Precondition: SAP note 3006437 (ADSO: Online Execution of Remodeling Operations)
Why would you do this? Well, let´s take following scenario:
- You modify an existing ADSO and the change refers to case 2
- Your ADSO contains no data in your DEV-system, 600’000 records in the QA-system
and 500 million records in Production.
Initially, there will be no remodeling request in DEV and QA, but when you import the transport to Production, manual remodeling will be unavoidable. The parameter mentioned above enables you to enforce the remodeling the QA-system as well for the purpose to be able to test this process before you set it live. In this little example, the parameter could be set to 500’000 to enable to test the manual remodeling in the QA-environment as well. After this setting, the transport to the QA-system will generate a remodeling request instead of activating the ADSO in the after-import directly.
The new framework is provided by the two SAP notes listed above which apply to both SAP BW 7.5 SP21, and SAP BW/4HANA 2.0 SP08.
You can find the customer experience of the whole scenario in Emmanouil Kouvaritakis´ blog post: ADSO Remodeling: Cases after implementation of notes 3006437 and 3019867.