Related links: Working with Business Rules, Rule Engines and Algorithms

Markers are labels in rules, used to process performance-critical rules preferentially. In Jedox, markers are defined within the rule.

By default configuration of OLAP Engine 7.0, markers are just hints for the engine that can be ignored for trivial rules that can be processed using a Data-Driven OLAP Engine (DDE).

Markers in 7.0 can be defined for any type of rules (B:,C:, or general)..

Markers are typically used to define rules for large target areas consisting of millions of cells and more, as is the case when target areas cannot be reduced sufficiently. Then markers can be used to mark in the target area only cells that make sense to calculate.

How are markers defined?

Ordinarily, a B:Rule is usually defined as follows:

['Turnover'] = B: ABS(['Quantity'] * ['Price'])


Now, if one of the source areas involved is labeled with a marker, a pair of double braces “[[” “]]” is used instead of single braces “[” “]”. If “Quantity” should get a marker, one writes:

['Turnover'] = B: ABS([['Quantity']] * ['Price'])


This defines a marker from [‘Quantity’] to [‘Turnover’]. This means that the value [‘turnover’] is calculated only for those basic cells where the value of [‘quantity’] is not 0. (This makes sense, since with a quantity of 0 the turnover will also be 0).

Occasionally, more dimensions are specified in the marker than in the target area:

['2013', 'Turnover'] = B: [['2011','Turnover','Cola']] + ['2012','Turnover']


In this case, the marker will be restricted correspondingly, i.e. from [‘2011’, ‘Turnover’, ‘Cola’] to [‘2013′,’Turnover’,’Cola’].

It is possible to define several markers:

['2013','Turnover'] = B: [['2011','Turnover']] + [['2012','Turnover']]


In this case, two markers are defined. One marker from [‘2011′,’Turnover’] to [‘2013′,’Turnover’] and one marker from [‘2012′,’Turnover’] to [‘2013′,’Turnover’]. In this case, the rule is calculated only if at least one of the marked arguments on the right side differs from 0.

It is also possible to define markers for entire cubes. In the simplest case, both cubes have the same dimensions:

['2013','Turnover'] = B: PALO.MARKER("Database","Planning-cube","2012","Turnover")


In this case, a marker from [‘2012′,’Turnover’] in the planning cube to [‘2013′,’Turnover’] is defined. If the marker cube has additional dimensions, these have to be specified with constants.

Below is an example with the name of the planner, Mr. Miller:

['2013','Turnover'] = B: PALO.MARKER("Database","Planning-cube","Mr. Miller","2012","Turnover")


It defines the marker from [‘Mr. Miller’, ‘2012’, ‘Turnover’] in the planning cube to [‘2013′,’Turnover’].

If the marker cube has fewer dimensions than the target cube, the target area can be specified without any restrictions, or it can be restricted by specifying a base element:

['Turnover'] = B: PALO.MARKER("Database","Planning-cube","Mr. Miller","Turnover")


['2013','Turnover'] = B: PALO.MARKER("Database","Planning-cube","Mr. Miller","Turnover")


Advantages of Markers

Definition of markers significantly reduces the number of calculated cells. If the markers are defined correctly, the results are identical to rules without markers, but calculation is significantly faster.

Accelerated calculation of marker rules is achieved only when these rules are calculated based only on cells whose value is not 0 (zero). All the basic cells with a value of 0 will be ignored. The result is a massive acceleration, but also the following restriction: for correct results, markers may only be used on rules that always result in 0 when all marked arguments have the value 0.

Arguments of PALO.MARKER()

Only constants and variables can be used as arguments for PALO.MARKER(). General expressions are not allowed.


['2013','Turnover'] = B: IF (['Price']>10, PALO.MARKER(…) * 2, PALO.MARKER(…) * 3)


This is allowed, because the IF expression does not occur in the argument of the marker.

['2013','Turnover'] = B: PALO.MARKER(…, IF (['Price'] > 10,"2012","2011"),"Turnover")


This is not allowed, because the IF expression occurs in the argument of the marker.

Markers for expressions: indirect markers

If you wish to mark expressions (formulas/functions), you can define indirect markers by appending “@” PALO.MARKER() to a formula with PALO.DATA().

For example:

['2013', 'Turnover'] = B: PALO.DATA("Database","Planning-cube",MID(!'Year',1,4),"Turnover")


Here you can define a marker as follows:

['2013', 'Turnover'] = B: PALO.DATA("Database","Planning-cube",MID(!'Year',1,4),"Turnover")@PALO.MARKER("Database","Planning-cube","AllYears%","Turnover")


In this case, a marker from [all children of ‘AllYears%’, ‘Turnover’] of the planning-cube to [‘2013′,’Turnover’] is defined.

Markers for STET() function

Jedox OLAP supports syntax for the STET() function. You can use shorter version similar to cell reference with empty restrictions:[ ] To define a markered version of STET() you can change it in the same way you would for cell reference. Just double the square brackets: [[ ]]

Old syntax STET() and STET() @ [[ ]] are still supported.

['2010']=B:STET()@[[ ]]
['2010']=B: [[ ]]
['2010']=B: []

Rules in pairs as shown above are always identical.

Engine Configuration

As of OLAP 6.0, big changes in marker processing have been implemented. Some of the existing models can perform slower than with OLAP 5.1.

To solve such situations, OLAP now provides a way to configure engines and control individual features. Each feature can be turned off by adding one character code to the palo.ini:

engine-configuration [engine_switch_code]*
engine-configuration MS

The long-term goal is to eliminate need for markers completely. See Rule Engines and Algorithms for more on this topic.

For many simple rules, markers are not needed. In comparison to version 5.1, the OLAP Engine prefers DDE on all compliant rules and ignores the fact that a rule has defined markers. This behavior can be overridden by switch code M.

As of OLAP 6.0, dynamic marker processing has been implemented. Unlike the static marker processing from 5.1, dynamic marker processing doesn’t cache all the markered cells in memory and doesn’t have to rebuild the cache every time a rule changes. In some situations, however, dynamic marker processing can also be slower—mainly when processing indirect markers on aggregated cells.

To switch back to static marker processing, add the switch code S and restart the OLAP Server. In this case, make sure your rules are valid according to the 5.1 marker requirements document.

Was this post helpful?
NoYes (No Ratings Yet)