Saving Concept (SAP Library - BW Business Planning and Simulation)

Saving Concept

Saving Technique

During a planning session, SEM-BPS allows you to make various changes to the planning elements or to create new elements (for example, planning areas, planning functions, planning layouts, data selections, changed plan data) without having to immediately save each change. The program collects all the changes that you make within one planning session and saves these either when you want it to or following an appropriate message at the end of the planning session.

This way, you can navigate freely within the planning screen and you can decide whether to save changes permanently or not. This procedure also results in significantly improved response times.

This technique is based on a three-level saving concept:

Internal tables: In the context of each SEM-BPS subfunction (for example, layout design in manual planning, definition of a planning level), all changes are noted in internal tables in the relevant applications and, when you switch to another application, these changes are written to the cross-application buffer memory in SEM-BPS.
Buffer: If you switch between subfunctions within SEM-BPS (for example, if you carry out a planning function after modifying a planning package), the changes that are stored in the internal tables are stored temporarily in a buffer. This buffer holds all changes that are made during a planning session.
Database: When you end the planning session and want to exit SEM-BPS, you must decide whether to permanently save the changes you made during the session or not. The system notifies you that unsaved data may be lost. You can save permanently at any time during the session by using the function Save .

Note

With the Save function, all changes made to all objects are saved permanently to the database. It is not possible to exclude specific elements or the result of individual changes from this saving function. If you have made changes which you do not want to save to the database, then you must end the planning session without saving.

Note

When saving, there is another alternative: Choose Planning ® Save model to save the changes you have made in a planning session. However, the plan data is not saved. This way, you can test changes to the planning objects without permanently saving the plan data that is changed.

Locking Concept

The saving concept described has consequences for the way how data edited with SEM-BPS can be locked. The general rule applies:

Data is locked against access from other planning sessions within a planning session from the moment where it was accessed with write access. A lock generated once by the system lasts until the planning session is terminated.

The background for this behavior is that only in this way can an improvement in the response times be reached: Only when accessing the data for a certain characteristic combination for the first time, is the database is accessed. The data read from there is saved provisionally in the SEM-BPS buffer and stays there until the end of the planning session. Further access to this data is then directly served from the buffer without having to access the database. However, since the data in the buffer is saved with reference to a planning session, the same data cannot be changed simultaneously in other planning sessions because otherwise consistency problems would arise.

Saving data also does not normally remove the existing lock, since the planning session continues, and further accesses to the buffered data could take place. However, if you wish that the system releases locked data without you having to exit the planning session, you can do this in the following ways:

You add the user parameter SEM_BPS_SAVE_UNLOCK to the user master records of the employees who use SEM-BPS, and set the parameter to the value X. This has the effect that the system always releases the data which you are editing with SEM-BPS, when you save the data in the data basis with the Save function.

You call up the API_SEMBPS_REFRESH function using the SEM-BPS Application Programming Interface.

Saving Location

The section on saving technique provides information on how the planning objects are saved and the resulting benefits for the user. As far as the exact saving location is concerned, we must distinguish between the various object types:

Plan Data

To work with the SEM-BPS component, you usually begin by creating a Planning Area. The most important property of each planning area is the specification of an InfoCube in the SAP Business Information Warehouse that will serve as a data source for the planning area. This InfoCube is not only the source, but also the destination for any newly created or changed plan data that you save. If the system where you are running SEM-BPS contains its own Business Information Warehouse, and the InfoCube is defined there, then the data is saved in that same system; If the InfoCube is located in another system, and is addressed via RFC, then the data is saved in the remote system.

Planning Objects that are Processed Exclusively by SEM-BPS Functions

These include the planning architecture objects (planning areas, levels and packages; see Planning Environment) and also the user-defined planning functions with their parameter groups. Objects of this class are always saved in the application-specific tables defined by SEM-BPS. These are located in the same system as the application itself.

Planning Objects that are Processed by Embedded Applications

This class includes those objects that, although processed in the context of SEM-BPS, are processed using embedded applications that are not themselves components of the SAP System. These are the applications that are used as part of Predefined Planning Functions:

Microsoft Excel (manual planning)
Powersim Constructor (dynamic simulation)

These applications are called up within SEM-BPS by in-place-activation as OLE automation objects. This means that they do not have their own application windows and some functions are not available. However, these applications are still responsible for handling the files you provide (spreadsheet workbooks, simulation models). When you save these files, they are not written as normal files to the local file system or to the file system of a server. Instead, they are transferred as a binary data stream (BLOB) to the SAP Business Document Service component. The Business Document Service serves as a version management system for the various versions of data, that you process with any of the embedded applications. You can find out about the files that are stored there by using the Business Document Navigator.

Example

Here, as an example, we list those components of a planning screen that you build in manual planning using Microsoft Excel that are saved by the Business Document Service:

All spreadsheet worksheets, including those worksheets that you added to the layout using the function Change layout

All graphics, diagrams or other objects that you added to the worksheets
All macros

Note: Of the elements listed here, only those that you added with the function Change layout are saved. If, after the change protection was removed, you added elements using functions other than Change layout, then these elements are not saved.