Checking status of cube behavior – BW4HANA

For overview on this topic and BW classic related specific information see following post: Checking status of cube behavior – BW classic.

In BW4/HANA based system there is no information about real-time behavior persistently stored in database like is in BW classic. Instead, the behavior (whether it is loading/staging or planning mode) is evaluated on the fly while user request the change of the behavior. For example if user triggers the behavior change system checks what real-time behavior is set currently and subsequently is changes it to opposite one.

Behavior change in t-code RSMNG:

Behavior change in BW Cockpit:

Information on aDSO behavior in RSMNG t-code is available by clicking on Information button in its toolbar.

The current mode is seems NOT stored persistently in database. Unlike of classic BW -> see: Checking status of cube behavior. Instead it is determined during runtime by ABAP class CL_RSD_RSAWBN_PLCUBE.

For an aDSO objects it is available in table called RSOADSO (Datastore Object) and field is PLANNING_MODE. Just give the aDSO tech name into ADSONM field and A value to OBJVERS field. This is a straightforward way to determine the real-time behavior of the aDSO. However, this table just stores the settings of the aDSO as can be setup in BW Modelling tools. See details here: Flavors of aDSO object

Below are other produceres how to determine the same:

1) Query table RSPMPROCESS with selection:

PROCESS_TYPE                = PLAN

PROCESS_ID                    = */CPMB/ARI* //your planning enabled aDSO object

 

Then sort a result set via field PROCESS_TSN and check value of PROCESS_STATUS field. If it is Y means PLANNIG request is active in the aDSO thus whole aDSO is in PLANNIG mode. If the PROCESS_STATUS field has value G (Finished) means there is no open yellow planning request in the aDSO thus it is in LOADING mode. Logic that handles flipping of aDSO mealtime behavior is coded in ABAP class: IF_RSPLS_ADSO_API~SET_PLANNING_MODE (CL_RSPLS_ADSO_API).

2) If above-mentioned procedure does not work, you may try this one. Enter the table  RSPMPROCESS with following selection

 

PROCESS_TYPE                    = PLAN

UNIQUE_TARGET_DATA        = */CPMB/ARI* //your planning enabled aDSO object

 

Then sort a result set via field PROCESS_TSN in descending way and check value of PROCESS_STATUS field. If the value is Y means the aDSO is in planning mode with active planning request.

Planning (e.g. APO) requests in BW InfoProviders

Planning application like APO, BPC, IP etc. are using special data load request type. Normally planning data is stored under one Request ID that starts with prefix 'APO_*' in real-time InfoProviders. One can observe it in Manage screen of a BW info provider in this way. I mentioned those APO_* request already my earlier post here.

Information about the APO_* requests are visible in tables RSREQDONE and RSSELDONE however not much information about them is available (no InfoSource, DataSource and so on). Most of information available in these tables is the same that can be found in Manage screen of a BW info provider. However

In administration of an InfoCube, the "Type Of Data Update" field is not filled in the request list if there is an APO request.

Since almost nothing exists for APO requests (no Source/InfoSource, DataSource, Source System and so on), the type of data update for the APO request is also unclear. Just a "Type of Data Update" field is populated with the "Full Update" value.

In addition, notice that a data, which was loaded into a real-time InfoProv via an InfoPackage/DTP (so-called BW load of BW request), cannot be changed with the Demand Planning. Thus if key figure not zero and it originates from BW request then the key figure becomes a read-only. Such KF needs to be copied to other if it needs to be changed in the planning app.

Checking status of cube behavior

Real-time cubes in SAP BW means that it is a planning cube where the planning functions can be implemented. This in short means a user’s can enter/modify data. It is possible then to copy, change and do a many different calculations with the data (e.g. distributions based on reference data or forecast functions).

The Real-time cubes can be therefore set into two modes (or called behaviors). Load behavior where the cube can be loaded via regular BW’s transformation or plan (or called real-time) behavior in which the cube can be saving planning data entered by users.

The change or the switch of the two modes can be done either manually:

Or same activity as done manually via RSA1 -> Modeling -> right click on cube -> Planning-Specific Properties -> Change Real-Time Load Behavior can be done programmatically.

Following FM can be used to check the real-time / load behavior and to set it:

RSM_LOADALWD_GET

RSM_LOADALWD_SET       

In addition, there is an ABAP report SAP_CONVERT_NORMAL_TRANS can be used for the same. Similarly, there is a process that can be put into process chain for that.

Table RSMDATASTATE (Status of the data in the Infocubes) and its field LOADALWD (Allow loading for real-time data targets) stores the information into which behavior the cube currently is set to. If the field LOADALWD is set to X it is in loading mode, if it is set to blank in planning mode.

For information on this topic relevant for BW4/HANA see this post: Checking status of cube behavior – BW4HANA