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, its 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 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 applies to both SAP BW 7.x on 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 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 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 functional scope 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” toolset 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 toolset 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 runtimes. 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:
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 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:
Note: This list is not exhaustive and might change in future.
On the other hand, 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 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 example 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 or 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:
Summary
When the ADSO was introduced in 2013 (BW 7.4 SP05), SAP renovated the change management of this new modeling object and the standard Activation process was combined with the remodeling toolset. 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 when you get confronted with remodeling in the context of ADSOs and you will understand the reason and consequence of following warning:
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 you should 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
ADSO type «Standard», 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:
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:
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 for following reasons:
Okumaya devam et...
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, its 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 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 applies to both SAP BW 7.x on 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 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 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 functional scope 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” toolset 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 toolset 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 runtimes. 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 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:
Note: 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 SAP help)
- Switch on special property “Inventory-Enabled”
- Change the Key definition
- Add Time Characteristic
- Add 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 from “No Reporting”/ ”During Reporting” to “During Load/Activation”
- Change Master Data Check to “Persist SID in DataStore”
- Add compounding child while compounding parent is already in ADSO and contains data (see case study 1 in appendix)
On the other hand, 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 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 example 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 or 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:
Summary
When the ADSO was introduced in 2013 (BW 7.4 SP05), SAP renovated the change management of this new modeling object and the standard Activation process was combined with the remodeling toolset. 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 when you get confronted with remodeling in the context of ADSOs and you will understand the reason and consequence of following warning:
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 you should 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
ADSO type «Standard», 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 initial Data Tiering setting “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 (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 for following reasons:
- First level partitioning is changed from HASH to RANGE on the user specified ADSO partitioning field.
- Second level partitioning had to be defined in the tab “Settings”. As a consequence, all records in the ADSO have to be moved into these partitions now.
Okumaya devam et...