Global Cell Locks in a Planning Application (Back End)

Defining Cell Locks

Cell locks are created for the current user session and are not persisted. When the planning application is restarted, no cells are locked any more.

Depending on the position of the cursor, a user can lock a cell, a row or a column. Only input-ready cells can be locked. Once they have been locked, they cannot be changed manually any more. Cells that contain aggregated values are not locked automatically if only locked cells contribute to them.

If cells have been locked or if cell locks have been deleted using the corresponding option in the context menu, the next server roundtrip transports this information to the back-end system. In the back-end system, the system translates the locks into a format that is independent of the query, thus making it possible for cells with exactly the same definition to be locked in other queries as well. Certain other properties of the query also need to be comparable, for example the filter used and certain characteristic properties.

Criteria for Matching the Lock Context of the Query Views

Locked cells are managed on the back end in accordance with their lock context. A lock context consists of the following information:

1. The query's effective filter, in other words the intersection of the filter in the query definition and the dynamic filter

2. The sequence of characteristics on the query's axes, and the following settings:

   1. Result display: always , never , with more than one value .

   2. Using the BW hierarchy; setting for whether or not the hierarchy display is active.

   We refer to these properties as the list geometry .

This basically means that the back-end server creates a lock context when a cell is locked. This lock context contains the effective filter and the list geometry of the current query view. To be able to contain cell locks of their own, all query views in a planning application must be compatible with this lock context. If any query views in the planning application do not match even just one - the system deletes all cell locks.

Criteria for Matching Structure Elements of Queries

A further condition is that the definition of structure elements of queries that are based on a locked cell must match.

The following input-ready structure elements of a query can form the basis of a locked cell:

• A basic key figure

• A restricted key figure

• A formula

Two structure elements match if all of the following properties are identical:

• If the structure elements are basic or restricted key figures, the following properties must match:

  • The key figures must be the same.

  • The input-readiness setting must be set for both key figures.

  • The restrictions made for the key figure must be identical.

  • The disaggregation settings must be identical.

• If the structure element is a formula, the formula definition must be identical, meaning that the formula expression edited in Query Designer is the same in terms of the operands, brackets, data functions, variables, exception aggregation used, and in terms of the sequence of operands in the formula.

Managing Cell Locks

As explained above, the back-end system manages the locked cells in terms of their lock context. A cell lock based on a basic key figure or restricted key figure is also always assigned to a real-time enabled InfoCube via the aggregation level used in the input-ready locked cell.

A locked cell on an input-ready formula is assigned to the InfoProvider that was used in the query definition. The locked cells on an input-ready formula can therefore only be used in other queries if these queries were defined on the same InfoProvider.

If the user performs any of the following activities, cell locks are retained :

• Displaying the properties of the characteristics (like Key or Text )

• Displaying attributes of the characteristics

• Sorting the result set by characteristic values, texts or key figures

• Switching the row axis and the column axis

• Expanding or collapsing nodes in BW hierarchies or universal display hierarchies

• Activating and deactivating a universal display hierarchy

• Hiding/showing structure elements (filter structure elements for example)

• Drilling down a characteristic: At the lowest point on the right in the rows and the furthest point inside in the columns

• Removing a characteristic from the drilldown: At the lowest point on the right in the rows and the furthest point inside in the columns

Note that some of the operations listed above hide locked cells. This does not undo the cell locks however. These "hidden" cell locks also remain active and are taken into account by the system when calculating inverse formulas and during disaggregation.

If the user performs any of the following activities, all cell locks are deleted :

• Changing the order of the characteristics included in a cell lock

• Change the axis of the characteristic included in a cell lock

• Changing the Display Result setting of the characteristic included in a cell lock

• Changing the settings for BW hierarchies (on/off) for characteristics included in a cell lock,

• Change the query's dynamic filter (by restricting the variable values without restarting the query, using the filter dialog for a characteristic from context menu option Keep Filter Value for example)

• Changing the filter using the variable screen

• Performing a planning function or planning sequence

What this all basically means is that any query view changes that are not compatible with the cell lock context will result in all cell locks being lost. The system displays a list of messages with information about the incompatible settings.

Modeling Recommendations

To make effective use of use global cell locks in a planning application with more than one query, queries should be modeled in such a way that the cell locks for a query are not deleted in other queries at runtime due to incompatibilities in other queries.

Accordingly, the lock context and the filters of all input-ready queries in the Web template should match.

In a compatibility check of the lock context, the system uses the effective filter of the other queries to calculate the intersection of the static and dynamic filters of the queries used in the Web template. For performance reasons, note that the back-end system does not check whether various definitions express the same thing. We therefore recommend always using the same modeling type.