With BW on HANA (BW 7.30 SP5 and up) we have introduced the Planning Application Kit – the BW on HANA based in memory enabled planning. Planning functions and disaggregations in queries can now be executed directly in HANA. Unfortunately there are some circumstances under which a planning function or a disaggregation can NOT be executed in HANA but will be executed in ABAP. The system behaves similar to BW-IP in this case.

Sometimes it is quite hard to decide whether a planning function/disaggregation has been executed in HANA or in ABAP. Here is a little collection of ideas how you can check this:

1. Planning Functions

1.1 Check the System Settings whether the Planning Function Can be Executed in HANA

Run report RSPLS_PLANNING_ON_HDB_ANALYSIS; it analyzes, whether a planning function can be executed in memory. The report shows some traffic lights for the InfoProvider and the single planning functions.

For an InfoProvider you will either get a red light (does not support HANA execution) or a green light (does support HANA execution). You will get more details on why HANA is not supported if you click on the traffic light.

For a planning function you will either get a red traffic light (cannot be executed in HANA) or a yellow traffic light (planning function could be executed in HANA). You will not obtain a green traffic light. The report only can check the static definition of the planning function. If you are execution the planning functions with certain filter criteria it might happen that AT RUNTIME the system decides that the planning function has to be executed in ABAP. We explain some of the situation s further below. Again you will get some additional information if you click on the traffic light.

The report does NOT check disaggregation in queries and whether it can be executed in HANA. The reason for this is that a query is a highly dynamical object and that most checks have to be done at runtime. As only relatively simple checks can be done at design time the report could not give enough valuable information.

If you get a red light for some or all of your InfoProviders please do the following checks:

• Is note 1637148 implemented?
• Is the system switched to PAK (see note 1637199)?
• Is the InfoCube HANA optimized?
• Is the InfoCube/DataStore Object entered in the list of HANA optimized InfoCubes?
• Is a characteristic relationship type exit or type hierarchy used in the InfoProvider?
• Is a data slice type Exit used in the InfoProvider?
• Is any virtual object used (virtual InfoCube, master data with own read class etc.)?
• Is a key figure type TIMS or DATS used (input enabled)?
• Is the user parameter RSPLS_HDB_SUPPORT set to ‘HDB_ON’ (if necessary, see note 1637199)?
• Have you used a DSO with a characteristic as key figure? If so you need to check note 2196138 to make this feature HANA enabled.

If a planning function gets a red light please check the underlying InfoProvider and the following conditions:

• Is the type of planning function available as optimized type (see list in note 1637199)?
• Has the planning function more than one condition?

As already mentioned above even if these conditions are met a planning function might still be executed in ABAP as the report cannot check all possible situations. This is for example the case if

• The planning function is a Fox formula and it calls an ABAP exit.
• The planning function has a condition and
  o the global filter contains selection on attributes, but the  condition contains selection on the basic characteristics or
  o the filter contains selections on hierarchy nodes and the condition has selections on the characteristic the hierarchy  is defined on or
  o the selection contains selections which are not single values restriction and those selection are not one by the same in the  global filter.

Please have a look at note 1637199 for the latest information on such cases.

For checking the general system settings you can also use our check tool described in SAP note 1729988.

1.2 Check the Execution of the Planning Function

By debugging:

Open transaction se80 (or se24), open class CL_RSPLFR_CONTROLLER and navigate to method EXECUTE_SERVICE. Set a break-point at about line 600:

*… checks for execution in TREX are done, now we know where we execute the algorithm;

IF l_trex_supported = rs_c_true.

If the coding after the if-statement is executed then the planning function runs in memory.

As an alternative you can also set a break-point in the class CL_RSPLS_HDB_SWITCH in method IF_RSPLS_HDB_SWITCH_RUNTIME~IS_IPIM_INFOPROV (checking the InfoProvider) and in method IF_RSPLS_HDB_SWITCH_RUNTIME~IS_IPIM_FUNCTION (checking the planning function). Here you can also get some information WHY a certain planning function is not executed in memory.

By checking the message number:

If the user parameter RS_DEBUGLEVEL is set to 0 or 1 then if a planning function is executed in ABAP then you will receive a message like:

&1 records read  &2 generated &3 changed &4 deleted

The message type and number are RSPLF 019.

If a planning function is executed in HANA then NO message regarding the information about used records will be shown (only a message stating that the planning function has been executed successfully).

If you set the parameter RS_DEBUGLEVELto 2 or higher you will get a message concerning the number of used records also in the case when the planning function is executed in HANA. The message will have the same text as in the ABAP case but it has a different message number.

The message type and number are RSPLF 091.

By using the statistics:

When a planning function is executed in HANA it writes different/less entries into the OLAP statistics. When you us transaction ST13, ‘BIIPTOOLS’, then you can view ‘BW Statistics Analysis’ (second button from the top) and then radio button ‘BW Object List’ (third from the top). In case of execution in HANA you do not see an entry for the planning function. When executed in ABAP you DO see the entries.

In both cases you see entries when choosing ‘Overview on Steps’ (first option).

Still PAK does write statistical event (just not visible in ST13). You can find those events in the view RSDDSTATEVENTS (PE stand for ‘planning engine’):

51000 PE: Open Session

51001 PE: Close Session

51002 PE: Copy

51003 PE: Lookup

51004 PE: Set Values

51005 PE: Restrict

51006 PE: Delta

51007 PE: Disaggregate

51008 PE: Delete

51009 PE: Get Current View

51010 PE: Set Current View

51011 PE: Describe

51012 PE: Snapshot

51013 PE: Combine

51014 PE: FOX

51015 PE: Cross Join

51016 PE: Copy Multiple

51050 PE: SQL DDL

51051 PE: SQL Query

51099 PE: Aggregate

2. Disaggregation in Query

2.1 Check the System Settings

Proceed in a similar way as above. Also some check some special requirement for the disaggregation:

The disaggregation in the query are executed not in HANA if

• the planning model uses multi-provider on top of aggregation level
• a formula is used as reference key figure for disaggregation
• the key figure is restricted to multiple values for a given characteristic except several single values (e.g. intervals or hierarchy nodes).

2.2 Check the Execution of the Disaggregation

By debugging:

There are cases when the disaggregation is executed in the ABAP runtime even if the query complies to the above restriction. This is the case for example when you disaggregate by 0FISCPER and the compounding father 0FISCVARNT is not restricted at all.

To check the execution open class CL_RSR_RRK0_PLAN and navigate to method DISAGGREGATE. Set a break-point at about line 138:

IF ( l_result_type EQ cl_rspls_plan_buffer=>n_c_result_type-index ) OR ( l_result_type EQ cl_rspls_plan_buffer=>n_c_result_type–femsn ).

    p_r_trex->disaggregate_s( EXPORTING i_setxx_type     = l_setxx_type…

If this coding is executed then the disaggregation is done in HANA. The method disaggregate_a is called when the disaggregation is
done in ABAP.

By using the statistics:

As noted above the system writes certain statistical events. In case a disaggregation was executed in HANA you will find the entry

51007 PE: Disaggregate