Child pages
  • Input Ready Query with Nagivation Attributes
Skip to end of metadata
Go to start of metadata

This page will help you to understand how to make a planning query cell input ready (inputable). 

The Rule

Rule 4 explains when a query using a navigation attribute, how the system works:

4.If a query used for manual planning includes a navigation attribute that is restricted using a fixed or dynamic filter or a restricted key figure, the system treats the navigation attribute as a normal characteristic. The rule under point 1 applies here. If the navigation attribute is not restricted, the system responds as if the navigation attribute was not part of the query.

This means: 

If a input ready query is using navigation attribute A__B with a filter on it, although A__B value can be derived from A, such derivation is not checked when the filter on A__B contains more than one value.

The Designed Behavior

Let's explain it with an example.

 A is drilled-down in the rows and we have a restricted key figure ‘Revenue’ restricted by A__B = 1,2. Although A__B is redundant, the redundancy adds a constraint here: we have to determine whether the attribute value of ‘a’ (being a master data value for A) has a non-empty intersection with A__B = 1,2. Only if the intersection is non-empty we can make the corresponding cell input ready.

This would be an ‘expensive’ check (considering MultiProvider, strange mappings, etc situations). Considering the performance, it is reasonable to treat navigation attributes as normal characteristics when the selection is not a simple one (restricted to more than one value).

So, for a query as below:

A        A__B         RKF with (A__B=1,2)
A1           1                  inputable
A2           2                  inputable
A3           3                  not inputable

with A__B drill down, each row has a filter on A__B with only one value, thus input ready of the cells can be determined.

If remove drill down A__B:

A                RKF with (A__B=1,2)       RKF with (A__B=1)
A1                       not inputable     inputable
A2                       not inputable     not inputable
A3                       not inputable     not inputable

here the green cell is inputable because filter A__B has only one value, thus the navigation attribute derivation is taken into consideration and intersects with filters on cell.

Red cell as A__B has more than one value filter, A__B is treated as a normal char, the derived value of A__B =1 from drill down of A1 is not took into consideration, thus it is not inputable.

For the second row and third row, the input ready of the cells is determined in the same way as the first row explained above.

 

If we set  RKF with (A__B=1,2) with disaggregation, again we have no A__B drill down,  we will get query result as follows:

A                RKF with (A__B=1,2)with disaggregation      
A1              inputable, disaggregation possible        
A2              inputable, disaggregation possible
A3              inputable, disaggregation not possible

The column of RKF with (A__B=1,2)  will be all inputable. Because here A__B is treated as a normal characteristic, with disaggregation set

Whether it is really can be disaggregated will be checked only when disaggregation is performed. An error will be issued if you input data in the purple and save, because it actually can't be disaggregated.

The Logic

Here is a list of things checked for cell inputable or not:

1- any KID (i.e. query structure element) has a list of required characteristics to support input. This means at run time for a cell, the value for the required characteristic has to be known. Depending on the effective filter (intersection of fix and dynamic filter), navigation attributes are put or remove to the list of required characteristics

2- by the above design a cell is converted to a ‘record’ that contains characteristic values; all fields of the aggregation level have to be filled; this record will be checked for data slices, characteristic relationships, etc.

3- for any KID having a non-trivial restriction ('trival' means no restriction at all or a restriction to a single value) the system will check the intersection of the KID restriction with the drilled-down characteristics and the effective filter.

Here, for performance concern, there is no ‘test derivation’ to check the intersection of a KID with the derived navigation attribute value from a base characteristic if the navigation attribute is not drilled-down (or restricted to one value).

Notes

2216099 - Input-ready queries, navigation attributes, and disaggregation

 

A simple example about input ready behavior with a navigation attribute 

  • No labels