Dear aBI : Notes on necessity for performing (attribute) change runs

[Former Member]

Scenario

In SAP BI 7.0, we often require a sub set of data to be accessed from Info cube. So, in this case we need to create smaller sets of data from the larger info cube. For Example: For a FY2009 with "Material A‟ data is only required from a set of 10 materials.

Introduction

Since the info cube is small, the required disk I/0 volumes during the query execution will be smaller too, and the query users will have an improved query performance. SAP implements this idea in Business Intelligence & calls the new Info cube an Aggregate.  An Info cube can have many aggregates, and all these aggregates are very transparent to users. That is, End users can comfortably create aggregates on Info cubes, and the BI OLAP processor does all the selection of the appropriate aggregate. In case of non-availability of aggregates, OLAP decides need to retrieve data directly from Info cube.

Attribute Change Run

A change run refers to the activating master data changes to attributes and hierarchies, realigning aggregates containing navigational attributes or defined on hierarchy levels. The main problem when the master data is changed (i.e. after data is loaded into the Info cube) is that the change on the attribute is not reflected at the cube side. We need to perform a PSA to DTP. We‟ll try an approach to solve this issue using Aggregate maintenance.



Fig 1.1 describes the changes affected to the availability of master data once a new record has been added.

Process Chains

Step by step analysis for the integration of attribute change runs in process chains

• 
  
  Start


• 
  
  Execute Info package ( Say if you are loading 2 Info Objects just have them all parallel )


• 
  
  You might want to load in sequence - Attributes to Texts to Hierarchies


• 
  
  And all connecting Info packages


• 
  
  Attribute Change Run ( Add all relevant Info Objects)

Fig 2.23 – This figure is a simple demonstration of further simplicity introduced by process chains for ACR. The above are the steps which are to be followed for effective data transfer.

Performing ACR

1. Case A : ACR Collisons
   
   
   
   1. Goto SE37 > Check RS*MOD*STATE*GET >
   
   
   2. Check CNSID Value for the IOBject > If no mods exists proceed to run RSATTR.
   
   
   
   


2. Case B : If there are entries, delete the collision locks using SE37 > RSD*MOD*CLOSE > Perform Step 3.


3. Case C : Goto SE38 > Run RSDS_AGGREGATES_MAINTAIN > Key in the Info object / Hierarchy Name.