Dear SAP BW enthusiasts!
You all know, defining the data model of Advanced DataStore objects (ADSO) is not an easy task. Compared to the classic DataStore objects or InfoCubes, ADSOs provide plenty of new flavors and features in one object which require sound expertise to set it up properly. SAP does not only differentiate between ADSO flavors of “Standard”, “Staging”, “Data Mart” or “Direct Update”, but those all come with properties not available in the past. Some suitable examples are Fields instead of InfoObjects, renewed Partitioning and Indexing options, enhanced Master Data Checks or Integration into a new Data Tiering concept (DTO), just to name some popular ones.
If your ADSO already contains data, this change process becomes more complex and might result in remodeling tasks in addition to the standard Activation process. Then you are faced with a warning like this:
This blog post tries to explain why this remodeling exercise is required sometimes when you do changes to an existing ADSO. I will list some typical scenarios and provide two examples in the end as well.
My blog post applies to both SAP BW 7.x powered by SAP HANA and SAP BW/4HANA, but take into account that some of the listed scenarios refer to ADSO properties which exist only in SAP BW/4HANA.
In general, Remodeling is known since many years. In SAP BW 7.x there is a so-called Remodeling Toolbox (Tr. RSMRT), where the developer can define certain remodeling rules for classic data models to automate adaptions. See InfoCube example below:
In SAP BW/4HANA the above transaction is still available for InfoObjects, but ADSOs had never been integrated there. Finally, SAP BW/4HANA 2.0 introduced a similar function in the tab “Details“ of the ADSO UI in the BW Modeling Tools. Without any doubt these “Remodeling” functions need a Remodeling request in the same way as in the past to incorporate these changes.
However, you might come across situations, where a remodeling task is required although you did not use the “Remodeling” tool set displayed in the figure above. The reason for this is, that SAP has followed a slightly different approach in the change management process of ADSOs compared to the classic InfoProviders. SAP combines the well-known standard Activation process with the Remodeling tool set in order to operate ADSOs safely and guarantee consistency throughout the change process.
Dependent of the size of the data base tables, the changes managed by the remodeling tasks can result in long run-times. Decoupling those from the standard Activation process is an added value as these processes can be scheduled independently and they do not result in uncontrolled, long-lasting activation runs. In one word this means:
ADSO Activation = Standard Activation Process + Remodeling Task in justified cases
The standard Activation covers all changes on the metadata only and there is no impact on existing transactional or master data. Example: Changing an ADSO without data or adding an empty non-key field/InfoObject into an ADSO with data.
In addition to this, Remodeling is required for all changes which result in potentially long-running checks or changes on data in the ADSO or related master data. If the ADSO contains data a remodeling might be required to fully apply the desired changes. This consequence is very clearly mentioned in the Check result of the data model, in the Activation log and in the Transport protocol.
The remodeling request is created by the standard Activation and has to be started or scheduled manually afterwards. You can use Tr. RSMONITOR in general or the “Remodeling Requests” App in the SAP BW/4HANA Cockpit.
What does it mean “The ADSO contains data (or does not contain any data)” ?
An important decision factor for or against a remodeling requirement is whether the ADSO contains data or not. Let´s be clear what is meant by “ADSO does not contain any data”: All tables of the ADSO are empty and there is no active loading or activation request available. So TSN request with zero records are to be excluded as well. To be on the save side, use the option “Delete Data from all Tables” in the “Manage Data Store” App (SAP BW/4HANA) or “Delete Data” in Tr. RSA1 (SAP BW 7.x).
Typical ADSO Change Scenarios where ADSO contains Data and Remodeling is required:
Attention - this list is not exhaustive and might change in future.
- All changes provided by the “Remodeling” function in the BWMT UI for ADSOs
- Change of the ADSO flavor, e.g. Switch on “Unique Data Records” or switch from «Standard» to «Staging» (if possible at all, see release-dependent restrictions in help for SAP BW/4HANA or in help for SAP BW 7.5)
- Switch on special property “Inventory-Enabled”
- Change the Key definition
- Add/Change Time Characteristic if ADSO is Inventory-Enabled
- Add/Change InfoObject/Field "Criteria"
- Change Partitions and related settings
- Change Indices and related technical settings
- Change Field data types (some cases)
- Change Conversion routines (some cases)
- Change to Data Tiering properties which lead to different first level partition
(see SAP note 2985173 - DTO and Partitioning and case study 2 in appendix)
- Enable "Exceptional Updates on DTO Cold Store"
- Change Master Data Check to “During Load/Activation” from “No Reporting” or ”During Reporting”
- Change Master Data Check to “Persist SID in DataStore” (see also SAP note 3340421)
- Add compounding child while compounding parent is already in ADSO and contains data (see case study 1 in appendix)
Note 1: If the ADSO contains InfoObjects, the versioning feature is required to enable the system to validate the change(s). So it is recommended to make sure versioning is switched on for InfoObjects.
Note 2: Adding or removing a non-Key field/InfoObject does not require remodeling normally. SAP HANA performs this kind of activity very efficiently (Insert/Drop Column) and it is regarded as pure meta data adaption for the SAP BW application only.
Transport Management
In the past, the Remodeling rules you defined for InfoCubes or DSOs where TLOGO objects and an individual part of transports. After the import those rules could be executed manually. This is different for ADSOs: Here the standard Activation is processed during after-import and in addition a remodeling task is generated if the ADSO contains data and if the type of change belongs to the listed activities above.
In more detail this means, the import of a transport will result with a the following warning and return code 4 if you transport an ADSO which has been adapted and remodeling is required to apply the change:
Remodeling rule yyyymmdd <ADSO techn.name> has been created instead of activation
This warning is followed by a more detailed explanation. In this case, SID checks/generation are required as a new compounding InfoObject was added (see case study 2 in appendix).
At this point of time, the ADSO remains still in the old state until the Remodeling request is finished successfully. However, an updated M-version of the ADSO exists already. When the remodeling is done, the ADSO is activated and the M-version turns into the A-version.
Let´s be clear: This remodeling must be scheduled manually in each target system after the import of the transport. And this might result changes to current operational models in organizations which have separate teams only responsible for transport management.
What if other dependent objects like Transformations are transported in the same request? The import routine creates their updated M-version as well but of course cannot activate them (See third warning in the transport log above). The transport remains in return code 4. After successful remodeling, the system will include these dependent Transformations in the final activation step.You can manage this behavior manually. There is a corresponding property in the configuration of the remodeling request which is enabled by default:
If you face challenges with these dependent objects, then following SAP notes might provide the solution:
- 2319656 (Transformations and DTPs not active after successful Remodeling)
- 2793138 (Remodeling of Infoprovider doesn't reactivate dependent Transformations/DTPs)
- 3001284 (Remodeling of ADSO doesn't reactivate dependent Transformations)
- 3004020 (HCPR activation is not skipped in Transport if it has ADSO as a part provider with remodeling rule)
- 3340421 (Bad ADSO remodeling performance if there is at least one InfoObject with master data check = persist in DataStore)
Summary
When the ADSO was introduced in 2014 (SAP BW 7.4 SP09), SAP renovated the change management of this new modeling object and the standard Activation process was combined with the remodeling tool set. This makes sure that complex and potentially long-lasting checks and changes on ADSO data or related master data are taken care of properly. The ADSO remains in the old state and can still be used for loading and reporting, until the remodeling job has been executed successfully at a later point of time.
I hope, based on this blog you are not surprised any more when you get confronted with remodeling in the context of ADSOs and you will understand the reason and consequence of following warning:
UPDATE January 2021
The details of this blog post were collected during a customer project which transforms a legacy BI landscape to SAP BW/4HANA at a large international pharmaceutical organization. When the customer started using ADSOs in the new environment, BW architects were puzzled by these remodeling requirements. What followed was a constructive discussion with the SAP BW development team in WDF. SAP listened carefully to the feedback that the additional remodeling requirements added extra complexity and some unwanted risk for the change processes of existing customer applications.
This resulted in some good news: Since January 2021, SAP has relieved the conditions for additional remodeling tasks and some flexibility was provided to avoid them in some cases. Please refer to my follow-up blog post for more details: Role of Remodeling in ADSO Change Management – Part 2.
In addition, there is now a customer experience of the whole scenario documented by Emmanouil Kouvaritakis´ blog post ADSO Remodeling: Cases after implementation of notes 3006437 and 3019867.
UPDATE November 2023
Remodeling options have been enhanced with SAP BW/4HANA 2023. See more details here:
https://community.sap.com/t5/technology-blogs-by-sap/enhanced-remodeling-in-sap-bw-4hana-2023/ba-p/1...
Troubleshooting
There is a good summary in SAP note 2747594 (Composite Note: Remodeling ADSOs).
If you search for SAP notes or would like to open an incident then please use following components which refer to “Remodeling Toolbox” (RMT):
BW-WHM-DBA-RMT (SAP BW 7.x) and BW4-DM-RMT (SAP BW/4HANA)
Appendix:
Case Study 1 – Add a Compounding InfoObject
My ADSO is of type «Standard» and it contains data. It includes the InfoObject Controlling Area (0CO_AREA), which is constantly filled with value 1000. The compounding child InfoObject CostCenter (0COSTCENTER) is missing.
Now I add the InfoObject CostCenter (0COSTCENTER) which is compounded to InfoObject Controlling Area (0CO_AREA): The Check results in warning referring to remodeling requirements.
After activation there is a clear warning that ADSO must be remodeled.
The execution of Remodeling request is finish successfully after approx. 25 seconds.
The resulting InfoObject SID Table looks like this before and after remodeling:
The resulting ADSO table of active data looks like this before and after remodeling:
In this case study the generated remodeling task performed the following actions:
- Checked whether SID table of InfoObject 0COSTCENTER contains a corresponding value for
CO_AREA = 1000 / COSTCENTER = # . - As it was missing, the new SID was created.
- Finally, the column COSTCENTER was added during the ADSO activation.
Case Study 2 – Changing the Data Tiering Temperature from Hot to Hot+Warm
I use an ADSO of type «Standard», it contains data and the warm tier should be used now for some data, which means:
- Tab “General”: The default Data Tiering property “Hot, on Object Level” is changed to “Hot and Warm, on Partition Level”
- Tab “Settings”: Partition Field must be chosen and corresponding partitions have to be created (SAP BW/4HANA 2.0 SP04+: with free choice of static or dynamic partitioning type)
Remark: If we remained on the “Object level”, partitions would not be required, and remodeling would not apply. However, changing to a partition level is a more common use case. Typically, you would like to manage some data as hot and the remaining older data as warm and/or cold.
The Remodeling task is required because the first level partitioning is changed from HASH to RANGE on the user specified ADSO partitioning field and the existing data is moved into the corresponding partitions. In addition, existing 2nd level partitions are removed. See also SAP note 2985173 (DTO: Data Tiering Optimization and Partitioning).
Thanks to Markus, Dirk, Deniz, Manos and Arun for the idea and valuable input for this blog post.
- SAP Managed Tags:
21 Comments
