Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
frank_klingl
Active Participant


The last main functional improvements of the planning engine came with SAP Business Warehouse 7.40 SP8 (see SDN blog on ‘Further Improvements on SAP HANA-optimized planning with the Planning Applications Kit in 2014’). We now reached a good and functionally complete feature set for PAK and BPC embedded as explained also in older blogs on PAK article ‘Moving from BW-IP to SAP HANA-optimized planning with the new Planning Applications Kit (PAK)’) and BPC (blogs Unifying BPC-NW and BW-IP). Now with the new NetWeaver release 7.50 and the related shipment of SAP Business Warehouse 7.50, we have the opportunity to ship new functionality without impacting quality and stability on older releases. This does not mean that we don’t do anything for BW 7.40 or older release from development side. HANA enablement of 7.40 features like the improvements in FOX on internal tables will be available with revision 92 and note 2145611. Other enhancements are being developed and will be delivered soon. An examples for a new FOX feature is the further PAK enablement of reference data.  We will also support the more flexible scenarios in BPC embedded along the roadmap.

 

For classic BW-IP customers I see in general three main reasons moving to the BPC license:

• Using the additional features of BPC embedded model like BPF (Business Process Flow) and work status

• Using the acceleration for large data volumes with the HANA optimized planning through PAK

• Getting more flexibility for  the LOB/end user by leveraging the BW workspace technology for planning and combining it with the BPC embedded

 

Basic new features like planning on aDSO in connection with HANA optimized BW will only be done in the 7.50 code line onwards as well as further FOX enhancements on modularization. Of course, we continue our journey to make BPC embedded more flexible for LOB planning use cases by combining BPC standard features with the central IT governed BW models.

I am often asked if we only concentrate our development  now on BPC and PAK and don’t invest any longer in classic BW-IP. This is not true. A lot of functionality is shared. In some cases classic BW-IP will of course not reach the same performance and some features like the allowance of local objects in workspaces only makes sense  on HANA with PAK since a lot of prerequisites are only met with HANA. But for example, we still support also new objects of BW which run only on HANA like the aDSO in classic BW-IP. In some cases we even have functions which only run in ABAP and have no special PAK support like the BRF+ integration.

 

The topics we addressed lately from the planning engine in BW are categorized as follow


 

  • 7.40 round offs

  • FOX enhancements

  • aDSO Planning in BW7.50

  • BPC embedded features


 

Let us have a glimpse on each of the topics in detail. The features of the last feature pack of 7.50 are described in Planning Engine Improvements for BPC Embedded Model, PAK and BW-IP with BW 7.50 SP4

 

• 7.40 round offs


 

Already available with SAP BW 7.40 SP12 onwards is the classic BW-IP improvement to connect to the ABAP runtime of DSM-Decision Service Management / BRFplus as rules framework.  We here deliver the report RSPLS_BRFPLUS_TOOL which generates BRFplus functions from the signature of a planning function type exit and the rules can be maintained and called from the planning function exit. For details see the blog  DSM-Decision Service Management / BRFplus in BW-IP.  As mentioned above, this feature is intended only for classic BW-IP. It of course also works with PAK enabled, but this certain step will then be processed on the ABAP application server by first reading the data from the buffer, processing the function in the application server and pushing the result back to HANA. As long as no big data volumes are exchanged the performance should be in the same range as for classic BW-IP.

 

• FOX enhancements


The main intention for the FOX enhancements is still to make the need for customers to use SQL Scripts in planning exit obsolete or only necessary in special and advanced cases. In particular in most customer project you will only get a performance boost if direct SQL algebra expressions is used in the SQL Script instead of the sequential implementation as used in the  ABAP exit. The FOX functionality was first improved with support package 8 for the classic BW-IP runtime (see blog Further Improvements on SAP HANA-Optimized Planning with the Planning Applications Kit in 2014) . Now the HANA planning engine has also adopted those enhancements for PAK for internal table with revision 97.02 and for reference data in HANA SP10 revision 102.1.

In addition a performance improvement was done to allow an unordered FOREACH loop in FOX. This particulary saves a lot of time spent by sorting the data in HANA. See note 2084538 which is available with HANA Rev 74 and BW 7.50 SP 0 (or 7.40 SP9 or 7.31 SP15 or 7.30 SP13).

The new features are listed in the table below

 





















































Feature HANA Revision BW Release/SP SAP Notes
PAK enablement internal tables Rev. 97.02 7.40 SP8 2145611
Enable info objects as reference data (ATRV) planned in Rev. 102.1 7.40 SP8 tbd
Extend reference data selection tbd 7.50 SP0
Use not planning enabled DSOs as reference data tbd 7.50 SP0
Internal Modules tbd 7.50 SP0
External Modules tbd 7.50 SP0
FOREACH UNORDERED Rev. 72 7.40 SP10

 

I am often asked for examples and documentation on FOX. As always in FOX, the new features are also documented in the F1 help (info button) on the parameter section in the FOX planning function maintenance screen in transaction RSPLAN. Also you can have a look at the standard documentation on help.sap.com. The syntax highlighting requires a GUI update. We now describe in detail the main features related to enhanced reference data selection and modularization.


Enhance reference data selections


 

PAK improvement with HANA SP10


 

You might remember that with BW 7.40 SP8 (see Further Improvements on SAP HANA-Optimized Planning with the Planning Applications Kit in 2014) we introduced in FOX the ability to access data from a second aggregation level. At this time FOX scripts containing this feature did only run in the ABAP application layer and for PAK we had to pull the data from the planning buffer to the application layer process the FOX in the ABAP layer and push back the results. So it was running with PAK but not HANA optimized. With HANA SP10 (probably rev 102.4), we now pland also support the optimized execution in HANA. Currently we still have a limitation. When using a variable for a key figure name (TYPE KEYFIGURE_NAME) in a  FOREACH loop together wiht access of an external InfoProvider (INFOPROVIDER statement) the execution will be done in the ABAP runtime.

 

Here is a typical example for an external infoprovider access:

 

DATA PROD TYPE 0IP_PROD.

DATA SEGMNT TYPE 0IP_SEGMNT.

INFOPROVIDER ANY_ALVL.

SEGMNT = VARV( SEG ).

 

FOREACH PROD.

{ PRICE, PROD } = ANY_ALVL.{ PRICE, SEGMNT, PROD }.


ENDFOR.

 

Not input enabled DSO as reference data


 

With BW 7.40 we allow as external InfoProviders not only aggregation levels but also not input ready DSOs. For input ready DSOs we still require aggregation levels created on top to ensure that un-saved data in the planning buffers are also retrieved. As usual this feature will first be available in classic BW-IP and be adapted in a higher HANA support package level (revision 102.2). When this is available we will state this in note 1637199.

 

Influencing reference data selection


 

The new feature of explicit reference data selection is general available with BW 7.50 SP0. Before BW 7.50 only a implicite influencing of reference data was possible with statements like

  • { PRICE, 2015 } = { PRICE, 2014 }.  The value 2014 is included into the reference data selection

  • YEAR_PREV = TMVL( -1, YEAR ).


{ PRICE, YEAR } = { PRICE, YEAR_PREV }.


IF Functions like TMVL, ATRV are used => the selection for 0CALYEAR is cleared


 


If more reference data is necessary, you had to tell the system what you want with tricks. In our example the values for 0CALYEAR should come from the active filter and additional values. So we read the global variable PREVYEARS and assign one value to a local variable YEAR:

 

DATA YEAR TYPE 0CALYEAR.

YEAR = VARI( 1, PREVYEARS ).

FOREACH YEAR IN REFDATA

{ PRICE, 2015 } = { PRICE, YEAR }.




 

We then use a local variable for accessing additional reference data. The formula parser realizes, that a local variable (YEAR) holds a value of a global variable (PREVYEARS). Only together with the second information, the reference data selection will be enhanced.

 

Now with BW 7.50 we are introducing FOX statements for explicit reference selection. It is for example possible to avoid the deletion of selections which are needed for functions like ATRV or TMVL. One can now achieve this by the statements:

 

KEEP REFDATA SELECTION (FOR INFOPROVIDER xyz) FOR 0CALYEAR.

KEEP REFDATA SELECTION (FOR INFOPROVIDER xyz)  FOR 0CALYEAR, 0COSTCENTER.

 

Here the addition FOR INFOPROVIDER is only needed if explicit reference data is defined before by the INFOPROVIDER statement itself.

In order to add additional values to the selection one can now write:

 

ENHANCE REFDATA SELECTION (FOR INFOPROVIDER xx) FOR 0CALYEAR: #, 2015, VARIABLE GL

 

If you want to have all values in the reference selection for example for InfoObject 0material you simply write:

 

ENHANCE REFDATA SELECTION FOR 0MATERIAL:  *

 

As mentioned above all those statement are available in classic BW-IP and in PAK.

There is one statement which only available in classic BW-IP: I is possible to check whether new data is in the filer. For example you can now write:

 

IF YEAR IN SELECTION.

 

This addresses the problem that a newly created record is not included in the selection.

 

Modularization


 

 

What is also new in classic BW-IP FOX runtime and not yet supported by HANA is the new concept of modularization by defining FORM statements. Modules or forms as they are called in FOX can be defined similar to ABAP forms with IMPORTING and CHANGING parameters.

 

As an example you can define a FORM calculate the maximum of tow values like:

 

FORM MYMAX IMPORTING VAL1 TYPE F

VAL2 TYPE F


CHANGING  MAXVAL TYPE F


      YEART TYPE YEARTAB.


IF VAL1 > VAL2.


MAXVAL = {0VCPL_REVV,2015} .


ELSE.


MAXVAL = {0VCPL_REVV,2015} .


ENDIF.


YEART.{ CNT, 2014 } = 25.


ENDFORM.

 

 

This form can be consumed by :

 

TABLE YEARTAB2 TYPE YEARTAB.

DATA VAL1 TYPE F.

DATA VAL2 TYPE F.

VAL1 = {0VCPL_REVV,2014} .

VAL2 = {0VCPL_REVV,2013} .

MYMAX ( 2014, VAL2 ,VAL2, YEARTAB ).

 

The new reuse is a clear benefit when it comes to more complex cases. Those forms can also be included from other FOX planning functions by using the INCLUDE statement.

 

Example:

INCLUDE FOX1.

 

Included Parts are:

• Definition of internal tables as Types

• Infoproviders

• Forms

 

We define in the FOX formula in TEST_CUR

 

FORM TEST_CUR IMPORTING I_CURR TYPE 0CURRENCY

CHANGING C_INCLUDE TYPE I.


IF I_CURR IN SELECTION AND I_CURR <> #.

  C_INCLUDE = 1.


ELSE.

C_INCLUDE = 0.


  ENDIF.

ENDFORM.

 

DATA CUR TYPE 0CURRENCY.

DATA IS_VALID TYPE I.

TABLE CUR_TAB { CURR TYPE 0CURRENCY KEY,                    VALID  TYPE I } .

INCLUDE TEST_CUR.

 

ENHANCE REFDATA SELECTION FOR 0CURRENCY: ADP.

FOREACH CUR IN REFDATA.

TEST_CUR( CUR, IS_VALID ).


CUR_TAB.{ VALID, CUR } = IS_VALID.


ENDFOR.

 

Only the definition TEST_CUR (and table definitions using the TABLE statement) can be referenced by planning functions using the INCLUDE statements. Global DATA and the formula itself are disregarded. Using the INCLUDE statements without forms also makes sense if you want to structure your coding more efficient. This is also immediately supported in PAK. For forms as stated above however still work is needed in the HANA planning engine.

 


  • aDSO Planning




 

With BP 7.40 SP 9 a new basic inprovider aDSO was introduced combining the advanteas of InfoCube and DSO in one InfopPovider type in HANA. See SDN article on aDSO for more detail. Since planning is possible with real time cubes it was clear that we will also adapt this new basic InfoProvider in planning. The main differences to the InfoCube are often hidden to the end user and also to administrator at first glance. However, we find that for the aDSO there is, contrary to the InfoCube,

  • No yellow request

    • With the aDSO we have a new request handling using

      • Request TSN (Time Sequence Number)

      • Process/Request have n:m relationship






 


    • Every save operation creates a new request



 


 

  • No Navigational attributes are present at aDSO level

    • Introduced by the CompositeProviders on top

    • (Delta-/AfterImage-)Buffer and characteristic relationships however live on part provider => OLAP delta read requests may need navigational attributes




 

  • Flexibility: Enhanced InfoObject Support

    • InfoObjects and fields are possible

    • Per InfoObject: SID generation during reporting or writing can be chosen

    • Planning currently only supports SID generation during writing




 

  • In general transport (TLOGO) object type does not determine the behaviour of planning. In the past Infocube planning determined deltas while direct update DSO requires after images.


 

Beginning with 7.50 SP0 it will now be possible to use cube like aDSO for planning (flag ‘All Charachterisitcs are Key, Reporting on Union of Inbound and Active Table’ is marked).  As for real time cubes we have still limitations which are limited to planning only and not to general use cases in reporting and WhM. Therefore they are still allowed in the general modelling of an aDSO but not in context of planning. Those are

 

  • the flag ‘All Characteristics are Key, Reporting on Union of Inbound and Active Table’ is marked

  • all characteristics have to be mapped to BW info objects

  • InfoObjects cannot be of high cardinality

  • stockcover is not supported

  • constant target should not be filled


 

The rest of the modelling of the planning artifacts is also very similar to the cube.

For example in:

 

  • RSPLAN: You can also use aDSO flagged for planning like a cube as base provider to create aggregation levels on top or to assign CRs

  • In transaction RSA1 you switch ‘load behaviour’ between planning and staging

  • In process chains we adapted the existing variant for cubes to support also aDSOs


 

The rest is as usual. With 7.50 SP0 we do not yet support the HANA optimized runtime with PAK but this will come with 7.50 SP1. It is also planned to support direct update like aDSO in a following support package.

 


  • BPC Embedded Features




 

In BPC classic the Line of Business (LOB) administrator can define his own InfoCube and dimension and enable planning on LoB data himself. We started to enable the same in BPC embedded using local providers which are planning enabled. However the cube in theBPC classic model and the local provider in BPC embedded model lack the connection to central IT data in the data warehouse. The next natural step is to combine global IT data with planning enabled local providers using a local defined composite provider. Here we start again in BW with the BW workspace and explicitly model local composite providers in the workspace designer.

 




Picture BW 7.50 SP0:  Local planning enables provider and be combined with global data source like (real time) cube


 

The idea is to reference actual key figures of the global InfoCube and plan on key figures of the local provider. This can be easily achieved by creating an aggregation level and then an input read query on top. You can of course, use the features like restricted key figures in the query to connect input ready key figures only to the local provider. Also planning functions can be defined on those aggregation levels.

At the moment the global InfoCube and local planning cube must share the same characteristics. This due to an existing restriction we also have for global composite provider (HCPR) and is mentioned in note 2091885. In general we have the restriction that we do not allow aggregation levels on top of

  • Local CompositeProviders with joins where an input enable PartProvider is involved

  • Local CompositeProviders involving characteristic mapping with different basis characteristic names (if the partprovider is planning enabled). In particular if the local provider fields are mapped to local characteristic or are key fields.

  • CompositeProviders with a navigational attribute, which is not mapped from all input enable partial providers.

  • CompositeProviders with a constant target.


As mentioned at the moment it still can only be modeled in BW Workspaces with explicit modelling of local composite provider with following constraints like for central composite provider for planning. But of course with SP0 the roadmap only starts.

 

We did a closer integration of the BW Workspace Query Designer (WQD) in BW 7.50 SP1 and plan an integration with BPC embedded in the BPC admin for upcoming support packages. The local workspace designer is an UI5 based application which runs in the browser and can be started by transaction RSWQD. In the local query designer you can define your own initial drill state, include restricted and calculated key figures and you can define the global filters. All the complex modelling is done under the hood.  With SP1 the new planning features come and the end user just adds a local planning enabled key figure to the central provider in the Workspace Query Designer.

 

 



 

With SP1 the following planning related features are available to the end user




  • Create new local planning enabled base key figure

  • Set disaggregation mode of the key figure


 



On the query properties you can flag the local query to start in change mode

 



 

I suggest to check out the non planning related feature of WQD in BW 7.50 SP0 and then go to SP1 to use the planning features.

 

 

In addition local hierarchies have been developed in BW workspaces with 7.50 SP0  and are now also adopted by BPC embedded. They can be created on local as well as on global dimension (or in BW language characteristics). It is also possible to copy a global hierarchy to a local and change it locally.

 

On the first screen we copy a hierarchy

 



Then we add local values as local nodes in the hierarchy

 

 



 

 

We then see them only in our local hierarchy.

 



 

Those local hierarchies can be used for example in simulation reports to show how results would differ with a different hierarchy structure.

View the BPC embedded product information for details.

 

 

8 Comments