Pages

Saturday, September 30, 2017

Why LIS needs setup tables: A perspective

Ever wondered why LIS(Logistics) has setup tables for deltas? Why don't other modules such as HR/Finance have them? This is quite interesting to ponder on for a SAP BI consultant. SAP designers were quite quick in figuring out the need for a separate architecture for this for a fine reason.

Logistics has a slightly higher update rate. This makes it a bit difficult synchronize locks between BW requests and ECC update. An important point to note is that the setup tables come into play only when we do a init/full load(Full repair) on BW side. In other instances, the normal update methodology through delta queue is followed. Consider the following scenario:


The application tables are accessed nevertheless during the setup table is filled. This can, however be done during off business hours using selections as required. So this leads us to the question, why have setup tables when you are doing it off business hours anyway. The reason for this is some Logistics extractors are composed of many underlying base tables joined together. The application tables provide a unified structure which pulls data from all concerned tables based on the extractor.

Having explained the above, let me know your views on why other modules do not need setup tables.

NOTE: The basic nomenclature of the setup tables is MC*SETUP where * is the application component. For example, 02 is purchasing, 03 is inventory controlling, 05 is Quality Management, 11 is the SD Sales orders. An se11/se16 search would make the purpose and description of each of the objects clearer.


Saturday, February 25, 2017

Attribute Change Run: Purpose and Issues with BWA


                      The Attribute Change Run(ACR) is a prime process by which Master Data updates reflect in BW infoproviders. Once you load Master data in an infoobject via process chains it is loaded as D or M versions. These are intermediate and do not reflect in the final reports or linked to transactional data. Attribute change run exactly serves this purpose of making sure changes reflect in all relevant referenced targets and reports contain latest changes in MD.

                    Here, we have one more process which actually does something similar but not the same. The Master Data activation step(right click infoobject in RSA1-->Activate Master data) does change the version of the data from initial D/M to A. However, these changes are not reflected in the aggregates of the referenced cubes. So, it is always advisable to run ACR after MD loads.

            ACRs can be run manually by using the tcode SE38-->RSDDS_AGGREGATES_MAINTAIN click on infoobject list/hierarchy for which you have recently run the loads and then execute.
Once you run from here, you can monitor the ACR by tcode CHANGERUNMONI. Here the current ACRs are displayed along with the attributes which require an ACR to be run.

An important point here to note is that no two ACRs can run concurrently.WHY?
Lets consider two infoobject X and Y used as navigational attributes in Cube A. When ACR for X is going on, cube A is indirectly undergoing an update so at the same time, one cannot also work on infoobject Y. This is to adhere to the Isolation of the ACID properties of database.


ISSUES WITH ACR-BWA

When the cubes/infoobjects are indexed in BWA, ACR also adds/deletes modifies aggregates in BWA.ACR can clash with following processes:

1. Master Data Delta Daemon jobs
2. Rollup
3.Other running ACR

Master Data Delta Daemon jobs are periodic jobs which run every 3 minutes(this can be changed) and indexes any changes to MD in BWA. Rollup in BWA relates to the cubes aggregates indexed in BWA blades. However, the ACR does not immediately fail if these processes are on. We can set a WAITTIME parameter asking the ACR to wait before it fails due to lock issues. This can be found in tcode SPRO>>SAP Reference IMG. Follow the below hierarchy:


 Limit with Delta deals with ACR strategy. For instance, if the master data change is more than x(say 25) percent, reconstruction of aggregates is adopted. Otherwise alignment happens in existing aggregates. Block size is the default size of the data accessed as a block. This is to prevent temporary table overflow of data due to memory issues.Wait time has been described previously.

Now, ACR also fails when there is corrupt MD table indexes. For instance, if the YEMPLOYEE table is corrupt(information can be found in tcode RSDDBIAMON) in one of the blades and rebuilding also does not work. In this case, we need to restart the BWA, build Y table indexes and then re-run the ACR. This is a dangerous situation which if not taken into account can have the production hangng for hours/days.

It is also a good practice to have all BWA built before the ACR begins as the existing indexed records can be used as opposed to recreating the indexes in the ACR itself which might increase runtime.