Compressing Infocubes

An InfoCube is loaded request by request, i.e request ids are created for each request, which is included in  ‘Data Package’ dimension in infocube.

Advantages of request ID’s are :

1) It makes  possible to pay particular attention to individual requests.

2) You can subsequently delete complete requests from the InfoCube.

Disadvantage of  Request Id is that same data record (where all characteristics are the same except the request ID)  appear more than once in the fact table. This unnecessarily increases the volume of data and affects system performance when you analyze data, since each time you execute a query, the system has to perform aggregation using the request ID.

What happens when we compress InfoCube? :

1) When the InfoCube is compressed the request Ids are deleted.

After compression the data cannot be deleted by request Id’s.

Data before compression :

Data after compression:

2) When infocube is compressed the data moves from F fact table to E fact table.

The F-table uses b-tree indexes the E-Table uses bitmap indexes. Index, Primary Index (The primary index is created automatically when the table is created in the database.).  Secondary Index (usually abap tables), Bitmap Index(Bitmap indexes are created by default on each dimension column of a fact table), and B-Tree Index.

When you load a data target, say a cube, the data is stored in the F fact table. If the cube is compressed, the data in the F fact table is transferred to the E fact table.

The data in the E fact table is compressed and occupies lesser space than F fact table.

3) During compression, the  records having everything same but different request Id’s are summarized.

 

4) Zero elimination :

Compression also does “Zero Elimination”. Zero Elimination means deleting the record from the cube after compression if and only if, the entire key figures of the particular record is zero. If there are two key figures A & B, A = 0, B = 10, then this record will not be deleted from the cube.

 

So in short Compression :

1) Removes redundant data by grouping on dimensions and aggregating key  figures, so helps in query performance.
2) Deletes request Id’s
3) Moves data from F fact table to E fact table which is smaller and has better performance                                                                                 4) Deletes t he record from the cubeif and only if, the entire key figures of the particular record is zero.

Event Based Process Chains

There may be a requirement where you may need to schedule a process chain after an event is being triggered.

In this Example I have a process chain A runs weekly, when completed should trigger an event which will result in execution of Process chain B.

Steps to be followed is as follows :

Step 1) Create an Event–>    Go to Transaction code SM62   –> Select  BckProcEvnts tab  –> Create an event.

In the snapshot  above  we can see I have created an Event ‘ZTEST’.

Step 2) Create variant for Program ”BTC_EVENT_RAISE”

    Go to se38 –> Enter Program name ‘BTC_EVENT_RAISE’—> Select Variant radio Button –> Click Display

Enter a name for Variant and click ‘Create’.

 

In the following screen, enter the event name which you have created in SM62 (in Step 1). In my case I had created ‘ZTEST’ Event.

Click on Attributes , enter description for variant  and click on ‘Save’

Step 3) Go to Process Chain A

At the end of your Process chain, insert process type ‘ABAP Program’.

In the next Screen insert  the ABAP Program ‘BTC_EVENT_RAISE’.

Enter the variant created in Step 2.

Your Process chain A will look like this

Schedule process chain A as per your requirement .Example I scheduled it weekly, (on Sunday, Morning 6 AM)

Step 4  ) Go to your RSPC and open Process chain B

Go to Start Variant –> Change selections –> After Event –> Enter the Event Name created in Step 1.

Check box ‘Periodic job’

Now , every Sunday 6 am Process chain A  gets executed. As soon as the ABAP Program is completed  in the last step of Process chain A, event ZTEST is gets triggered and as a result of that Process chain B starts.

So you get the desired result as per event based scenario.

Difference Between SAP BW 3.5 and 7x

The difference can be described as follows :

1) The Remodeling transaction helps you add new key figure and characteristics and handles historical data as well without much hassle. This is only available for infocubes in  SAP BW 7x.

2) The BI accelerator (for now only for infocubes) helps in reducing query run time by almost a factor of 10 – 100.

3) Search functionality has improved. You can search any object you want to, which was not possible in SAP BW 3.5

4) The transformation replaces the transfer and update rules.

5) Introduction of Write-optmized DataStore  Object in which does not have any change log and the requests do need any activation. The goal of such DSO is mainly to request its data with the Bex tools in order to provide queries at the raw data level..

6) One level of Transformation. This replaces the Transfer Rules and Update Rules.

7) Load in the PSA is a must in SAP BW 7x, which was optional in SAP BW 3.5 and data could be directly loaded to data targets.

8) In Infosets now you can include Infocubes as well.

9) Renamed ODS as DataStore Object (DSO).

10) Datawarehousing workbench replaces the administrator workbench.

11) New data flow capabilities such as Data Transfer Process (DTP), Real time data Acquisition