Improvements of BPC 11.1 planning engine in Q1 2019

So far the last main set of new features of the planning engine was shipped with BPC 11 SP4 and BW/4HANA SP8 (see SDN blog on ‘Improvements of BPC 11 planning engine in Q1 2018′ for details). I just recall the improvements on new cell-based comments, file upload or the planning on master data queries. In addition, we supported most of planning objects in BW Modelling Tools. One of the most important object, the planning function, was so far missing in the BW Modelling Tools and this brings me to the set of new features coming with BPC 11.1 based on BW/4HANA 2.0:

• Support of Planning Functions in BW Modelling Tools
• Planning on Standard like aDSO
• Neglect Data Slices Setting for Planning Sequences
• Trigger Process Chain through new Planning Function Type and FOX with Zeros
• Improved PAK support for key figures of type INT8 and FLOAT
• Support ATRV on HANA view
• How To for Data Slice Exit based on BRF+
• Engine Preparation: Deletion of Data from the Query

The BPC 11.1 addon release is planned based  SP1 of BW/4HANA 2.0 in Mai 2019. Let us have a glimpse on each of the topics in detail.

Support of planning functions in BW Modelling Tools

We started the journey to integrate the planning objects from a separate modelling transaction to the BW Modelling Tools with NW BW 7.50 SP4 with the aggregation level as the first planning object (see Planning Engine Improvements for BPC Embedded Model, PAK and BW-IP with BW 7.50 SP4). We continued the journey in BPC 11 with the characteristic relationship editor (see First Steps from BW-IP and PAK towards SAP BPC 11.0, version SAP BW/4HANA planning with Embedded Model) and with BW/4HANA SP8 we added the data slices and planning sequences. However, the last and most important object, the planning functions was still missing. Now with BPC 11.1 based on BW/4HANA 2.0 we finished the journey by also adding planning function to the BW Modelling Tools. Consequently, the GUI transaction RSPLAN is not needed any longer. All planning function types are covered. This includes also more complex planning function types with special UIs like disaggregation and FOX. For FOX we included a script language editor including key word highlighting and auto complete and integrated search helps for all sort of objects like info objects, variables, and info provider.

 Planning on Standard like aDSO

Originally in BW-IP we only supported InfoCubes for planning. The handling of data was done in delta mode by just storing changes to the key figures. Then in BW 7.3 SP8 we introduced the planning on direct update DSOs. There we store the after image. See https://blogs.sap.com/2013/12/16/improvements-on-sap-hana-optimized-planning-with-the-planning-applications-kit-pak/ for details. It had some advantages like the support of NO2 and SID based key figures used for attribute planning. However, in particular the performance in most of the cases was better on InfoCubes due to the delta handling. When moving from InfoCube and DSO to the aDSO, the modes direct update and cube-like were kept. See for example note 2189829 or blogs https://blogs.sap.com/2015/10/21/planning-engine-improvements-for-bpc-embedded-model-pak-and-bw-ip-with-bw-750/  and https://blogs.sap.com/2016/07/21/planning-engine-improvements-for-bpc-embedded-model-pak-and-bw-ip-with-bw-750-sp4/ . The direct update (a)DSO has another disadvantage in the staging. When it is used as data source no deltas are available to be extracted and as workaround a full load into an InfoCube and from there a delta load to other sources had to be done. For audit logging only, the logging BADI RSPLS_LOGGING_ON_SAVE could be used. With the new development to include also standard aDSOs into planning those 2 disadvantages are gone. You can do planning on after images using the active table and the change log contains the deltas. From those change logs you can load to other InfoProvider or use the audit trail. However, the performance of cube like aDSO might still be better for large amounts of data.

The history or audit trail can be seen as usual for the standard aDSO in the manage UI (or old GUI transaction RSMNG)

Neglect Data Slices Setting for Planning Sequences

A new flag “No Data Slice Check” has been introduced for special cases where the execution of planning sequences should not take data slices into account. Such cases came up again and again in the SAP developer network as a requirement. One workaround for example is mentioned in blog Integrated Planning – how to activate/deactivate data slice at runtime, but has a lot of disadvantages on performance and stability since it is a basic setting in the user session with several caches relying on it. Those workarounds should now not be needed any longer when running planning sequences. The flag should be set when data slices should not be active. With note 2718886 it is also supported from NW BW 7.50 onwards and BW/4HANA 1.0.

Trigger Process Chain through new Planning Function Type

A new planning function type 0RSPL_START_PROCESS with description ‘Start a Process Chain was developed’ to trigger process chains from planning side. As a parameter, only the process chain must be filled. To get the result from the process chain the function type 0RSPL_GET_PC_LOG with text ‘Get Logs from Process Chains’ has been created. However, one should keep in mind that the process chain of course locks the data. For example, if you have open the query input ready in the UI and you trigger from there the process chain, the chain my try to set a lock on data which might be locked already by the query. Also, this was done to get rid of various workaround mention on SAP developer network. See for example How to trigger a process chain using a planning-function in sap design studio or thread 704623. This scenario should now be much easier to implement in projects.

In addition to 0RSPL_START_PROCESS, we deliver with SP1 a variant for FOX planning function type which also considers zero values. This new planning function type is called 0RSPL_FORMULA_ZERO. This will be also in NW BW 7.50 FP 16.

Improved PAK support for key figures of type INT8 and FLOAT

The new data type INT8 (integer of 8 byte) was introduced to BW with NetWeaver 7.50.  However, in Hana optimized planning (PAK) this was not supported. This limitation was documented in note 1637199. With HANA 2.0 SP4 we also support INT8 now in the HANA optimized runtime.

We got similar demands for float key figures. We pointed out the various problems mentioned in notes 2449817 and 460652 and referred to the general advice to avoid float in BW. But we had to admit in some situation where the sum is not needed to be precisely the sum of the items seen on the screen, it makes sense to use it. To get this working, the underlying aggregation level needs to contain the float key figure and you need at least implement note 2644984 or revision 13 on NW BW 7.50. In BPC11 it works from the beginning. The minimal HANA revisions are for HANA 1.0 is revision 1.00.122.17 or for HANA 2.0 it is revision 2.00.030.01.

We also will soon release modularization by forms on PAK soon once the underlying revision is released.

Support ATRV on HANA view

In BPC optimized usually HANA views are used for InfoProviders and master data. We also had an important limitation in FOX when using ATRV on HANA views. The limitation was lifted with the same note 2644984. Here the minimal requirement on HANA side is revision 2.00.030.01.

How-To for Data Slice Exit based on BRFplus

In NW BW 7.4 we published a How-To Guide and shipped a convenience report RSPLS_BRFPLUS_TOOL and utility class CL_RSPLFC_BRFPLUS_SRVTP to enable customers to build planning functions which are executed in BRFplus or also called DSM-Decision Service Management. While of course the performance expectations are much lower compared to functions executed in HANA, we saw an adoption in certain cases where performance is not critical and the function is purely rule bases. So, we decided to do the same for Variables (see blog Analytics) and Data Slice Exit. For this see note 2686429 – BW-IP: Data slices with BRFplus Exit. We created a new utility class CL_RSPLS_BRFPLUS_DATA_SLICE and one can reuse the convenience report RSPLS_BRFPLUS_TOOL to create the BRFplus functions. The note is also valid from NW BW 7.50 onwards and BW/4HANA 1.0.

Engine Preparation: Deletion of Data from the Query

Records in BW-IP, PAK or BPC embedded can be deleted using the corresponding planning function types like 0RSPL_DELETE_DSO. Here physical deletion is possible only in the case that the basic planning provider is a direct-update DataStore-Object(DSO) or a direct-update advanced DataStore-Object (aDSO) and became possible from NW BW 7.3 onwards. For all basic planning providers with insert-only logic (i.e. InfoCubes, virtual provider with write interface, cube-like aDSOs) it is only possible to write a new record with the reversed key figure values. We call it cancellation. With BPC 11.1 based on BW/4 2.0 we also allow to delete cells/records using input-ready queries on the backend side. The UI adoption could not yet be done but hopefully follow soon.

Server Pre-Processing

On the server side the deletion request is only known at cell level. Some simple checks are implemented before the deletion requests might trigger more complex disaggregation of the delete requests:

• A cell to be deleted in a new line is just removed from table
• A locked cell cannot be deleted, i.e. only unlocked cells can be deleted
• A cell to be deleted is set to the initial value
• If the cell to be deleted is an input-ready formula, the usual formula calculation is performed; the target of the inverse formula calculation inherits the DELETE flag. Using the ‘symmetrical calculation mode’ the deletion of a base key figure might trigger the deletion of another base key figure because of the above rule. Example: The base key figure ‘Costs fix’, ‘Cost variable’ might be used in the input-ready formula ‘Costs total’ := ‘Cost fix’ + ‘Costs variable’. Using the symmetrical calculation mode, a deletion of ‘Cost fix’ recalculates ‘Costs variable’ and thus ‘Cost variable’ also inherits the DELETE flag. As a result, ‘Cost fix’ and ‘Costs variable’ are initial after the server round trip.

Disaggregation of Delete Requests

After the server pre-processing of the inverse formula calculations, the table only contains base key figures (more precisely, structure elements based on base key figures). If one of these cells to be deleted is aggregated with respect to the aggregation level a disaggregation is triggered. The disaggregation of delete requests is processed as usual, the only additional step is to set the delete flag for all target cells of the disaggregation request; locked cells or manually changed cells will not be touched here. As a result, the disaggregation of deletion requests may fail if no untouched cells as a disaggregation targets are available. One might consider the disaggregation as a normal disaggregation using the initial value and a ‘disaggregation COPY’ of the delete flag.

Checks in the Planning Buffer

Delete requests for insert-only planning base providers are nothing special, these are just ‘reverse bookings’. For after-image planning base InfoProviders a delete request needs a special method to perform physical deletion. This is the same method used already to send the result of the ‘physical deletion’ planning function type to the buffer, thus the same checks apply here.

Deletion requests from input-ready queries are checked in the same way, the corresponding exception is handled and transformed to messages.