Scheduling Planning Sequences in Process Chains 

Use

By integrating planning sequences into process chains, you can execute planning sequences in the background.

You can include a planning sequence in a process chain by including a process of process type Execute planning sequence in an existing process chain. In the detailed maintenance of the process, select the required planning sequence and possibly a suitable variable variant.

For planning sequences that are executed in the background, you can specify whether and how the planning sequences are to be divided into smaller packages. These packages can be executed in parallel as separate subjobs in multiple work processes.

You can monitor and analyze the parallel execution using the BI background management (transaction RSBATCH). More information: Setting Parallel Processing of BI Processes

Prerequisites

●      To schedule a planning sequence within a process chain, you must first create the planning sequence in the planning modeler. For more information, see Planning Sequences.

●      You created the required process chain in the process chain maintenance transaction (transaction RSPC) and defined the behavior of the process chain during execution, if necessary. More information: Process Chain Maintenance and Display/Maintenance of Process Chain Attributes.

●      If your planning sequence contains variables that can only be filled with user entries or if you want to overwrite variables with user entries, you can store a variable variant in the planning modeler. You can refer to this variable variant in the maintenance of the process with which you schedule the planning sequence.

You can store variable variants either locally for one user or as global variable variants. If you want to use a local variable variant, you must also use the user for which the variable variant was created for the definition of the process and as the user for background execution. More information: Variables and Display/Maintenance of Process Chain Attributes.

Note that changes that were made shortly before execution on an application server are not necessarily active immediately on all application servers. This depends on the settings for database buffering in your system and is true for many BI objects as well as for changes to the customer exits used. In production systems, you must make sure that at least the time that you selected for updating database buffering has elapsed between the last change to any objects and scheduling the process chain.

Procedure

...

       1.      In the process chain maintenance, create an application process of type Execute a planning sequence.

Note that some BI objects use the table buffer for read accesses. If you therefore want to schedule planning sequences distributed on more than one server, you must make sure that the default time that you defined for the table buffer has elapsed between the scheduled start and the last change (delivery default is 120s).

       2.      Select the required planning sequence and, if necessary, a variable variant.

       3.      Choose Apply.

       4.      In the screen area Activate or deactivate packaging, define whether the planning sequence should be executed in its entirety or if it should be processed by package.

Selection for Packaging

Option	Description
Process Without Packaging	The entire planning sequence is executed. The system only saves all the data on the database when all the contained functions have been executed without errors. No further settings are required for this option.
Process in Packages	The planning sequence is executed step by step. The system writes the modified data to the database after each step and deletes it from the buffer. For each step you can set whether and how it should be packaged. When a step is packaged, the system writes each individual package that was processed without errors to the database.

If you want to process the planning sequence by package, the system reads the steps of the planning sequence from the database and fills a table. Only those steps of the planning sequence that execute a planning function are displayed.

The step numbers are copied from the database. Since the steps for input masks are missing, the numbering is not sequential.

       5.      If you selected the option Process in packages, you can select which of the following packaging types should be used for each step.

Type of Packaging

Option	Description
No packaging	Exactly one subjob is scheduled with BI background management for such a step.  It executes the planning function for the entire filter of the step.
Automatic packaging	The characteristic with which the step is packaged is determined automatically when it is executed. You can define the number of packages into which the filter should be broken down in the last column of the table. You can also define if the values should be determined from the master data table or from the dimension table. (More information is available in section Determining Values for a Characteristic.)
Configured packaging	The characteristic with which the step is packaged must be selected. You can use two kinds of help in selecting the characteristic. 1. There is a value help for the InfoObject field that permits you to estimate the number of values for all the characteristics that are possible for the packaging. 2. You can select some steps and display a proposed characteristic for them.  You can first define how many packages should be created in the last column. You can also define if the values should be determined from the master data table or from the dimension table. (More information is available in section Determining Values for a Characteristic.) You can define how many individual values of the characteristic should be included in a package for the selected InfoObject. The system computes the number of packages from the number of all values divided by the number of values for each package. It rounds this number up in accordance with the formula: Number of packages = ceil (number of all values / number of values per package).

Determining Values for Characteristics

There are two ways to determine the values that are relevant for a characteristic. In both cases the characteristic restriction from the filter is used for the characteristic to be examined.

With this characteristic restriction, either the master data table or the dimension table is read. The master data table contains all the values for this characteristic. The dimension table contains all the values that are already stored in the relevant InfoProviders.

In both cases you can change the values in the tables by running a planning function.

Values can be written to dimension tables for all characteristics that were not yet contained in the InfoProvider.

The system accesses the SID table for the read type master data for characteristics that do not have a master data table. In this case new values can occur during execution of a planning function.

Function of the Master Lock

To prevent parts of a planning sequence from not being executed because other users are locking data, the master process passes a master lock ID to the subjobs.

At the beginning of execution, the master process locks all filters for the BI lock server. It sets a privilege lock, releases the normal locks again, and returns an ID for the master lock. From now on, only those work processes that can certificate themselves using this master lock ID may change the data within the filter. The subjobs certificate themselves using the master lock, and save the data using a normal lock. When the planning sequence has been completely processed, the master process releases the master lock.

You can monitor the master locks in the BI lock management (transaction RSPLSE). More information: Lock Concept and Lock Management

In rare cases (for example, if the administrator cancels the master process on purpose), the system might not release the master lock. In this case you can delete the master lock manually in the BI lock management transaction. This assumes, however, that you have authorization to execute the planning sequence. If subjobs are still open, the system cannot execute them any longer.

Determining the Characteristics in Question for Packaging

Some of the characteristics of an aggregation level on which a planning function is created cannot be packaged.

○       You can only package those characteristics that cannot be changed.

As described above in the section about how the master lock works, the subjobs for the filter packages request real locks from BI lock management. In BI lock management you can configure the characteristics that should be relevant for locking for each realtime-enabled InfoCube. To prevent subjobs from mutually locking one another because their filter packages cannot be separated with regard to lock management, only selected characteristics can be used for packaging.

○       Only certain characteristics can be packaged with respect to lock management. The table below shows how they are defined.

Type of Aggregation Level	Definition of Characteristics Permitted for Packaging at this Aggregation Level
Simple Aggregation Level (created directly on a realtime-enabled InfoCube)	Exactly the characteristics of the realtime-enabled InfoCubes that are relevant for locking are permitted.
Complex Aggregation Level (created on a MultiProvider)	A characteristic is permitted if the following rule is satisfied for all relevant realtime-enabled InfoCubes: If the characteristic gets its data from a realtime-enabled InfoCube, it must be relevant here for locking.

The figure below shows a complex aggregation level:

Planning function F1 is created on aggregation level A1.

Aggregation level A1 is created on MultiProvider MP1.

Its parameters are defined from InfoCubes C1, RC1 and RC2.

InfoCube C1 is not a realtime-enabled InfoCube. It provides the parameters for characteristics A, B, C, D and E in MultiProvider MP1.  However, it does not manage any locks. It is therefore not relevant for further discussion.

InfoCube RC1 is a realtime-enabled InfoCube. It defines the parameters for characteristics A, B, C, D and F in MultiProvider MP1.  Characteristics A, B, D and F are entered as relevant for locking in the lock management.

InfoCube RC2 is a realtime-enabled InfoCube. It defines the parameters for characteristics A, D, E and F in MultiProvider MP1.  Characteristics A, E and F are entered as relevant for locking in the lock management.

According to the above rule, the characteristics of the MultiProvider result in characteristics A, B, E and F being permitted for packaging:

○       A and F get their values from RC1 and RC2 and are relevant for locking in both of these. A and F are therefore permitted.

○       B only gets its data from RC1 and is relevant there for locking. B is therefore permitted.

○       C only gets its data from RC1 and is not relevant there for locking. C is therefore not allowed.

○       D gets its data from RC1 and RC2, but is not relevant for locking in RC2. D is therefore not allowed.

○       E only gets its data from RC2 and is relevant there for locking. E is therefore permitted.

Since the aggregation level does not contain F, the characteristics A, B and E are not used.

In the planning function, E is used as the characteristic to be changed. Therefore only A and B are available for packaging.

Automatic Selection of Characteristics

If you want to select a characteristic automatically, the required number of packages and how the values should be determined must be defined.

The system then defines the characteristics permitted for packaging. The number of characteristic values contained in the relevant characteristic restriction is determined one after the other for these characteristics. When a characteristic is detected for which the system found more characteristic values than packages were requested, it is proposed or used for packaging.

Segmenting Filters in Packages

If you want to segment a filter for a step in a package, you must first define which characteristic is used for packaging and how the value is to be determined. Either the number of packages or the number of values per package is also defined for each package.

The values are distributed randomly (but can be reproduced) amongst the set of packages so that each package contains at least one value but does not contain more than the number of values for each package.

Settings for Physical Parallelism

With Parallel Processing in the maintenance for the process of type Execute a planning sequence, you can overwrite the default values for process type PLSEQ for this process.

The default values for a process type can be stored in BI background management. More information: Setting Parallel Processing of BI Processes

With these settings you can define    

○       the number of parallel work processes in which the subjobs should be executed

○       the servers on which these work processes should be executed

○       the priority with which the subjobs should be executed

Step-by-Step Processing of the Planning Sequence

If you selected the option Process in packages, the planning sequence is processed step by step.

Each step is segmented into the required number of subjobs. All the subjobs of the step are then scheduled by BI background management. The master process checks if all the subjobs of the last step were executed. The next step begins when this check has been completed and if all subjobs were successful. If a subjob terminates with an error, the planning sequence is not executed. In this case the master process schedules an additional subjob that informs the BI background management that the reserved physical work processes can be released. The master process then releases the master lock.

The example Planning Sequence for Bottom-Up Planning demonstrates the step-by-step processing of a planning sequence.