Skip to Content
Author's profile photo Hans-Juergen Schwab

BW 7.30: Data Validations and Performance Improvements for Planning Applications

For all planning applications,it is vital that the planning data entered is consistent.Examples of this kind of consistency check are routines that prevent budgets from being exceeded or routines that convert amounts in local currencies (as entered by the planner) to the company currency. The routines are usually implemented as planning functions/sequences and offered to the planners in the form of buttons in the applications. For obligatory constraints, the application designer normally offers a dedicated ‘save’ button where the corresponding functions/sequences precedes the native ‘save’. This existing approach has some disadvantages:
– The application modeler has to make sure that planners cannot save data other than using this dedicated button. In particular, generic toolbars or context menu entries in BEx Analyzer that call the native ‘save’ directly have to be disabled in every planning Workbook.
– While the constraints are semantically linked to the data targets, i.e. the InfoCubes, the validity of the constraints is guaranteed in the application that manipulates the data. It is therefore necessary to ensure that no applications exist that allow a native save only.

It is clear that this gap needs to be filled. To do this, a planning sequence can be specified that is executed whenever data for a transactional InfoCube/write-enabled Virtual InfoProvider is supposed to be stored.
As of Release 7.30, you can maintain the settings in the new SAPGUI based planning modeler.
Because this feature was so interesting for customers, it has been downported to Release 7.01. Here, the customizing can be maintained with ABAP/V report RSPLS_PLSEQ_MAINTAIN.


One question remains open. How does the planning sequence know which data has to be processed? The answer is simple. The system itself finds which data has to be processed. It looks at the data that has already been processed.It doesn’t matter whether data has been changed manually or changed by planning functions.

The assumption is this: Only changed (or related) data has to be processed. Basically a filter is constructed from the changed data and intersected with the filter of the planning functions in the sequence. Now the planning function in the sequence is carried out with the result of this intersection. This guarantees that the planning functions process the minimal necessary amount of data only.This technique has two main advantages:

 -Minimal data means maximum performance for planning functions

 -Simple customizing of the consistency of the planning application at one central point.

Of course this technique is also interesting for a lot of planning functions, especially those that process a lot of data. It is therefore possible to define in a work book or a web application that a planning function (or sequence ) should only process changed data.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Very glad for IP. New features, Logging to DSO, abap-planner...
      IP is stil breathe. 🙂

      Next steps is a more features on front end side (Bex) and input-ready queries on DSO. 🙂

      Author's profile photo Gianfranco Vallese
      Gianfranco Vallese
      IP is still a "live" product!