SAP BW/4 HANA

Credits: blog.sap.com

     Gone are the days when RSA1 used to be the prime focus for BW modeling. BW/4 HANA is a solution which delivers BW solutions specifically for SAP HANA database. First question then, what is the difference between BW on HANA and BW/4 HANA. BW on HANA can be considered as the intermediary between native HANA implementations for BI and traditional SAP BW implementations. With BW on HANA, there is still support to some of the pure SAP BW metadata, whose support is withdrawn in BW/4 HANA.  As a memory jogger, metadata is used in the TREX search engine which searches for BW objects(just one of the usage).
   
     BW/4 HANA will now define SAP's future releases and hence its recommended that businesses gradually make a move from BW on HANA or BW to BW/4 HANA. BEx queries will no longer be active, reports will be based on BO tools such as SAP BO Design Studio, SAP Analysis for Office(BOA). Old infoproviers such as transient providers, Infocubes, Old- DSO's are no longer supported. The number of Data Sources reduced from 7 to just 3(ODP(for SAP source systems such as SRM), HANA source(for non-SAP) and Flat files).

My thoughts:
 All said and done, I however feel SAP was too quick to introduce BW/4 HANA as many were still upgrading to SAP BW on HANA or systems were being designed using native SAP HANA. Also, considering SAP ripping off support to SAP BW 7.3 in 2020, it is a bit too much of a push to first migrate to BW on HANA and then onto BW/4 HANA. BW/4 HANA is also not a successor of BW on HANA in that many of the objects are not supported(transient providers, for example). It is logically in series of the SAP product launches but not quite the upgrade we can think of.

It requires the system to be on BW on HANA 7.5 SP04(The transfer tool used for migration is available from SP02 itself), bare minimum pre-requisite. Although I do not doubt the efficiency and crispness of this system, when there is a migration as this, where most of the objects are not supported, companies implementing SAP systems using an older technology such as BW on HANA might really consider recharting their approaches. It is worth noting the consumers who are still on SAP BW 7.3 version and planning to upgrade gradually, the road appears to be long for them.

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.

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.