RSMRT-Remodeling
Beginner’s Guide on Remodeling of Info Providers:
Remodeling, a term which so obviously states something is either reset or rearranged with terms of Info providers. What must be the ideal way to modify how data is displayed? Say, we have loaded a million records into our cube, but in a dire need to modify, do some changes to accommodate some more Info objects to the existing fact or delete some repeating data / no data columns etc at dimension level. In such cases what is the handy solution? The most trusted way to resolve hiccups of this sort is to identify & remodel your Info provider either at fact/dimensions level. In this article we’ll discuss some steps to change the metadata of our Info Cube and remodel our Info Provider. But first time users must be cautious enough to use the remodeled object, and transport the same object to different system landscapes sequentially. The drawback is that, we need to ensure no inconsistency with regards to definition of the Info provider exists between different systems in our entire landscape, else objects could become non-transportable at last.A simple example for re-modeling is as below.
There are some pre-activities to be performed too. Once a remodeling rule is scheduled, it is not allowed to modify in future; if not we must create a new remodeling rule. The best advantage is remodeling can be performed even when cube is filled with full data. The remodeling activity can be monitored also, and the requests can be either reset or restarted. Reset would be an exception, while Restart would potentially re-initiate the whole process.
Consider the data as in the cube. Here we plan to delete the unused field Z08_DTE.
Give the remodeling rule name & description.
Choose the required options as in the figure.
Save, Check & Schedule the rule.
Click the ‘Monitor’ hot key to check the status on a periodic basis.
Click Release Job. The job which had been scheduled has run successfully.
Remodeling, a term which so obviously states something is either reset or rearranged with terms of Info providers. What must be the ideal way to modify how data is displayed? Say, we have loaded a million records into our cube, but in a dire need to modify, do some changes to accommodate some more Info objects to the existing fact or delete some repeating data / no data columns etc at dimension level. In such cases what is the handy solution? The most trusted way to resolve hiccups of this sort is to identify & remodel your Info provider either at fact/dimensions level. In this article we’ll discuss some steps to change the metadata of our Info Cube and remodel our Info Provider. But first time users must be cautious enough to use the remodeled object, and transport the same object to different system landscapes sequentially. The drawback is that, we need to ensure no inconsistency with regards to definition of the Info provider exists between different systems in our entire landscape, else objects could become non-transportable at last.A simple example for re-modeling is as below.
So whatever the changes the DW architects make, care must be taken to do a full backup of all data, followed by stopping all respective process chains. After remodeling existing InfoCube, ensure to re-activate all your transformations & restart process chains (if applicable).
Remodeling in SAP NW-BI 7.0 is applicable only for InfoCubes; not Characteristic Info objects or DSOs. The following options can be performed during a remodeling.
- Add Characteristics / Key figure
- Replace Characteristics / Key figure
- Delete Characteristics / Key figure
There are some pre-activities to be performed too. Once a remodeling rule is scheduled, it is not allowed to modify in future; if not we must create a new remodeling rule. The best advantage is remodeling can be performed even when cube is filled with full data. The remodeling activity can be monitored also, and the requests can be either reset or restarted. Reset would be an exception, while Restart would potentially re-initiate the whole process.
So, to discuss on the early watches to be taken care, its best advised to never run remodeling for an InfoCube, while some process chains or SM37 jobs are running in parallel & take care of manually activating & restarts of the process chains once the remodelling is successful. Also, the InfoCube is locked for any loads or changes.
This activation must be performed for all objects upper & below the data flow (which would include transformation rules). Plus, data backups are a must. Aggregates existing on the cube, if any, will have to be recreated.
Deletion of Characteristics – Step by Step Example
Use T-Code: RSMRT or use ‘Re-Modeling’ in Administration tab on LHS of RSA1.
Consider the data as in the cube. Here we plan to delete the unused field Z08_DTE.
Give the remodeling rule name & description.
Choose the required options as in the figure.
Save, Check & Schedule the rule.
Click the ‘Monitor’ hot key to check the status on a periodic basis.
Click Release Job. The job which had been scheduled has run successfully.
After remodeling has been successful, we need to check & reactivate the transformations, DTPs etc. & other dependent objects associated with the InfoCube.
Addition of Characteristics
Provide the name & descriptions of new characteristics & dimension it must be included. Also, specify what mechanism the data is populated. In fact, there are 4 ways: Constant, Attribute (& of Characteristic), 1:1 Mapping with Characteristic or Customer Exit. Finally add the new characteristic to the BEx query and execute it.
Replacement of Characteristics is most similar to Addition.
Customer Exit for Remodeling Rules
Go to SE24 –or- Tools > ABAP Workbench > Development > Class Builder
Select Add characteristic, select new characteristic in which the dimension characteristic needs to be added. Select option Customer Exit, select Customer Exit and Transfer.
Use the last option to ‘Insert’ While the rule is being executed it can be monitored by clicking on the monitor button. Once the class builder is open, you can goto ‘Interface’ tab & use the Interface IF_RSCNV_EXIT. This is nothing but an structure which defines how one class behaves with other classes, also known as abstract class.
An interface can specify a set of methods, and classes that implement the interface will have to provide concrete implementations of those methods. IF_RSCNV_EXIT being the interface, we must implement the remodelling functionality via few methods (exits) Viz. IF_RSCNV_EXIT~EXIT. Once the class has been coded, we need to save & activate the method.
No comments:
Post a Comment