Working with rules

You can configure complex logic through Longview Application Administrator. The complex logic is known as a rule.

This chapter contains information on these main topics:

• “Understanding rule types”
• “Creating rules”
• “Copying rules”
• “Editing rules”
• “Exporting rules”
• “Deleting rules”
• “Writing rule statements”

Understanding rule types

There are several types of rules.

• Model—For more information, see “Understanding Model rules”.
• Rollup—For more information, see “Understanding Rollup rules”.
• Query—For more information, see “Understanding Query rules”.
• Event—For more information, see “Understanding Event rules”.
• Validation—For more information, see “Understanding Validation rules”.

Understanding Model rules

A model rule is an expression specifying a mathematical formula involving symbols in your Longview database. When data is processed on the server, the system detects dependencies on these model rules, performing the required mathematical calculations, and producing output data.

Once created, models run dynamically as you or someone else in your company imports or adds data to the database.

Caution: When you delete a model rule from the system, data resulting from that rule will be deleted from the database once a recalculation is run.

Understanding Rollup rules

Rollup rules define the process of calculating the values of parent symbols, all the way up to the root symbol in each dimension.

Many combinations of dimensional detail do not need to be calculated. To improve performance, you can configure Longview to discard these surplus combinations of data during rollup operations, speeding up the overall time and significantly reducing the data volumes. To do so, you use a rollup rule.

Depending on your system setting for the Use Inclusion Method for Rollup Rules parameter, rollup rules will either rollup all the data within the rule or will not rollup the data within the rule. The default system setting does not rollup data within the area specified by the rule. For more information, see the Longview Server Manager Guide.

There may be some confusion if a user happens to query an area not considered by the rollup rules configured for their application. This could occur if the System Administrator missed some combinations or chose to exclude some data because of space restrictions. In these cases, the system detects that the query is to an area not being calculated and gives an appropriate warning to the user.

Understanding Query rules

A query rule is an expression equating two data cubes. Query rules specify the placement of data virtually in a data cube and are used to avoid storing redundant data in a system. When data is processed on the server, Longview detects any query rules and retrieves data from the source cube and places it virtually into the target cube as if it actually exists in the target cube. Query rules apply only to base data.

Once created, query rules are applied dynamically whenever a request is made to retrieve target data from the database.

Understanding Event rules

Event rules instruct the server to watch for certain conditions and to perform certain tasks when they arise. Event rules are triggered by submitting either a string or a numeric value. Only numeric values that result in a delta—that is, a difference in value between the previous and current values—will trigger a rule. Entering a value of “0” to a string will not trigger a rule.

Caution: The procedures triggered by an event rule must reside on the server, not in the application folders or elsewhere. Creating, editing, or deleting rules may cause changes that you do not expect. If in doubt, see your Longview Professional Services representative.

Configuring and initiating event rules

The following configuration settings are related to event rules and must be set appropriately before you start using event rules:

• Use Event Rules
• Event Queue Max
• Default Actions Time Interval
• Data Event Sequencing
• Max Active Data Events
• Event Profiling

For more information on these configuration settings, see the Longview Server Manager Guide.

Configuring Event timing

You can configure the timing of events using either the Default Actions Time Interval, or by using Data Event Sequencing.

If you are using Data Event Sequencing, events are processed in iterations. Any events that are triggered at the same time are in the initial iteration. Any events triggered while an iteration is running wait until the next iteration. Using event sequencing ensures that the same events do not run multiple times unnecessarily, which allows for consistent event tracking and more efficient use of system resources.

If you are using the Default Actions Time Interval, the system waits for an event with a specific rule ID to run to completion before it runs the same rule ID again. The wait period also allows for subsequent data submissions to coalesce with the initial submission.

If you are not using any event timing features, events run when triggered.

Understanding Validation rules

A validation rule compares two cubes of data in Longview database to make sure that certain cells within those cubes equal each other. For example, Total Accounts must equal Total Liabilities and Owner’s Equity, for all symbols in the ENTITIES, CURRENCY, and TIMEPER dimensions.

Once created, validation rules always run when you or someone else in your company imports data into the database. For each instance in the designated cube of data where the data does not balance, Longview stores the error message and amount in a validation data table.

Creating rules

You can use Longview Application Administrator to create server rules.

To create a rule:

1. Open Longview Application Administrator.
2. Select File > New > Rule. The New Rule dialog opens.

   

3. Complete these fields:

   Field	Description
   Rule ID	Type a unique numeric value for the rule (the Rule List in the Contents window contains a list of all existing rules and their numbers).
   Rule Type	Select one of the following: Model Rollup Query Event Validation For more information on rule types, see “Understanding rule types”.
   Description	Type a brief description of the rule. The description can contain a maximum of 100 characters.
   Email Message	For Event rules that include email statements only, type the body of the email that is sent when the rule is triggered.
   Error Message Template	For Validation rules only, the error message to display when validation fails.

4. For Rule, do the following:
   • Type the rule. For more information on writing rule statements, see “Writing rule statements”.
   • To add symbols to the rule, click Insert. The Rule Selection dialog opens, allowing you to make selections from the dimensions list. Click OK when you are finished adding symbols.

   Note: Symbols that are entirely numeric must be prefixed with an exclamation mark ( ! ) in rules. For example, !22342 identifies 22342 as a symbol name and not a numeric value.

   

5. Click OK. The new rule appears in the Rules list in the Contents window.

Copying rules

You can create a new rule by copying an existing one and then modifying it.

Caution: Creating, editing, or deleting rules may cause changes that you do not expect. If in doubt, see your Longview Professional Services representative.

To copy an existing rule, follow these steps:

1. Open Longview Application Administrator.
2. In the Server Explorer pane, select Rules. The Rules list appears in the Contents window.
3. Right-click the rule you want to copy and select Duplicate. A copy of the rule opens in the New Rule dialog.
4. Make the necessary changes to the rule, including typing a new Rule ID and Description.

   Note: You will not be permitted to save the rule until you have changed the rule. Exact duplicates of existing rules are not permitted in the system.

5. Click OK. The new rule appears in the Rules list in the Contents window.

Editing rules

You may need to edit an existing rule to either run a different type of rule or display a different error message.

Caution: Creating, editing, or deleting rules may cause changes that you do not expect. If in doubt, see your Longview Professional Services representative.

To edit an existing rule, follow these steps:

1. Open Longview Application Administrator.
2. In the Server Explorer pane, select Rules. The Rules list appears in the Contents window.
3. Right-click the rule you want to modify and select Properties. The Properties dialog opens.
4. Make the necessary changes to the rule.
5. Click OK. The changes to the rule are entered into the system.

Exporting rules

You can export rules to an ASCII file. For information on exporting a rule to a file, see “Exporting server objects”.

Deleting rules

You may want to delete a rule that you no longer need.

Caution: Creating, editing, or deleting rules may cause changes that you do not expect. If in doubt, see your Longview Professional Services representative.

To delete a rule, follow these steps:

1. Open Longview Application Administrator.
2. In the Server Explorer pane, select Rules. The Rules list appears in the Contents window.
3. Right-click the rule you want to remove and select Delete. A confirmation dialog opens.

   Caution: If you delete a rule, it cannot be recovered. To restore a deleted rule to the system, it must be recreated. Use this function with caution.

4. Click Yes. The rule is removed from the system and the Rules list.

Writing rule statements

A rule statement provides the definition for a server rule. The syntax of the rule statement varies depending on the type of rule that you are working with.

For more information, see:

• “Writing Model rule statements”
• “Writing Rollup rule statements”
• “Writing Query rule statements”
• “Writing Event rule statements for emails”
• “Writing Event rule statements for procedures”
• “Writing Validation rule statements”

Writing Model rule statements

In a model statement, you must specify:

• The cell coordinates of the cube of base data or schedule data from which you want to Model
• The cell coordinates of the cube of base data or schedule data to which you want to Model

The following Model statement copies the values of ACC1 from base data in a six-dimensional database, to ACC1 in schedule data (Schedule S1160) for all the leaf symbols within the year-to-date time period symbol and four remaining dimensions.

SCH(S1160,ACC1,YTDROOT###,#ALL,#ALL,#ALL,#ALL, 0) = KLX(ACC1,YTDROOT###,#ALL,#ALL,#ALL,#ALL)

Where:

Modeling syntax

All examples are based on three base dimensions of data and two extra schedule dimensions.

Data expression

KLX ( )

Representation of data using symbol names in each dimension to specify coordinates, for example:

KLX ( ACC1, A9701, TORONTO )

SCH ( )

Representation of schedule data using schedule name, symbol names in each base dimension, and symbol names in each extra dimensions to specify coordinates, for example:

SCH ( S1043, ACC1, A9701, TORONTO, L1, C2 )

Range expression

#ALL

Representation of all leaf data in dimensions; for example:

KLX ( ACC1, #ALL, #ALL ) or

SCH ( S1043, ACC1, #ALL, #ALL, L1, #ALL )

###

Representation of all leaf data under a particular base dimension parent symbol. This syntax does not apply to symbols in the extra dimensions. For example:

KLX ( ACC1, A97###, ONTARIO### ) or

SCH ( S1043, ACC1, A97###, ONTARIO###, L1, C2 )

#TOTAL

Representation of the total value in extra dimension (one per extra dimension is available), for example:

KLX ( ACC1, A97###, ONTARIO### ) (applies only to extra dimensions)

or

SCH ( S1043, ACC1, A97###, ONTARIO###, L1,#TOTAL )

Time expression

#LAGNumber

Representation of going backward a specific number of periods in the time dimension.

• The hierarchy structure on time dimension must have a priority according to the sequence of the time period.
• This syntax does not apply to symbols in the extra dimensions.

For example:

KLX ( ACC1, #ALL, TORONTO ) = KLX ( ACC2, #LAG2, TORONTO ) means that in TORONTO, value of ACC1 equals the value of last two periods of ACC2

or

SCH ( S1043, ACC1, #ALL, TORONTO, L1, C1 ) = SCH ( S1043, ACC1, #LAG1, TORONTO, L1, C2 ) means that value of C1 equals the value of last period of C2.

#LEADNumber

Representation of going forward a specific number of periods in the time dimension.

• The hierarchy structure on time dimension must have a priority according to the sequence of the time period.
• This syntax does not apply to symbols in the extra dimensions.

For example:

KLX ( ACC1, #ALL, TORONTO ) = KLX ( ACC2, #LEAD2, TORONTO ) means that in TORONTO, value of ACC1 equals the value of next two periods of ACC2.

or

SCH ( S1043, ACC1, #ALL, TORONTO, L1, C1 ) = SCH ( S1043, ACC1, #LEAD2, TORONTO, L1, C2 ) means that value of C1 equals the value of next period of C2.

#YTDLAG

Representation of previous ending period.

• The hierarchy structure on time dimension must have a priority according to the sequence of the time period.
• It must not be used with other expressions.
• This syntax does not apply to symbols in the extra dimensions.

For example:

KLX ( ACC1, #ALL, TORONTO ) = KLX ( ACC2, #YTDLAG, TORONTO ) means that in TORONTO, value of ACC1 equals value of previous ending period of ACC2.

or

SCH ( S1043, ACC1, #ALL, TORONTO, L1, C1 ) = SCH ( S1043, ACC1, #YTDLAG, TORONTO, L1, C2 ) means that value of C1 equals the value of previous ending period of C2.

or

SCH ( S1043, ACC1, ACTUAL, TORONTO, L1, C1 ) = SCH ( S1043, ACC1, #YTDLAG, TORONTO, L1, C2 )

#OPEN

Representation of opening period (specified by SYMBOL attribute ZFXTimePeriodsOpen).

• The type ZFXTimePeriodsOpen Attribute is a symbol list (value can be “CP99,AYR99”). However, the function will only pick up the first defined root (CP99).
• The time range must be consistent throughout the rule.
• Can specify different opening period within the specified time range if each opening period refers to different opening roots.
• Consider symbol A990PEN has ZFXTimePeriodsOpen attribute specified as CP99. Both CP99 and A99OPEN must be within the specified range (ACTUAL).

For example:

KLX ( ACC1, ACTUAL###, TORONTO ) = KLX ( ACC2, #OPEN, TORONTO ) - KLX ( ACC2, ACTUAL###, TORONTO ) means that in TORONTO, any leaf of CP99, the value of ACC1 equals value of opening period (A99OPEN) of ACC2 - value of ACC2

#PLUG

Refers to the ability to identify a symbol in a particular hierarchy that would be used as a “plug-to” symbol. Whenever a certain total in that hierarchy (n levels above the plug-to symbol) changes because of contributions from other leaf symbols, the plug-to symbol should get an equal but opposite amount added to it. The net effect would be that the total would always be maintained at its current balance.

Consider the following hierarchy:

Initially, everything is zero. If a delta of +10 were submitted to symbol D, it would normally roll up to contribute +10 to A. However, the plug-to logic would apply, producing a value of -10 to G (assuming G is the plug to symbol). The net effect causes A to remain at zero.

Symbol G is defined as the plug-to symbol for total A. If G has a positive weight, the syntax would be:

KLX(G,#ALL,...) = KLX(A#PLUG,#ALL,...) * -1

or

KLX(G,#ALL,...) = - KLX(A#PLUG,#ALL,...)

If G had a negative weight, the syntax would be:

KLX(G,#ALL,...) = KLX(A#PLUG,#ALL,...)

The value put into G is the sum of all leaf values under A, except for G itself. So, to truly keep A at zero (or whatever its current balance is), you need to either reverse the sign of the number or specify the plug to symbol to a negative weighting.

Modeling restrictions

There are certain restrictions when using modeling on the server assignment.

Restriction on assignment with any product or quotient of expressions

Incorrect:

KLX ( ACC1, #ALL, TORONTO ) = KLX ( ACC2, #ALL, TORONTO ) * KLX ( ACC3, #ALL, TORONTO)

or

KLX ( ACC1, #ALL, TORONTO ) = KLX ( ACC2, #ALL, TORONTO ) / KLX ( ACC3, #ALL, TORONTO )

or

SCH ( S1043, ACC1, #ALL, TORONTO, L1, C1 ) = SCH ( S1043, ACC1, #ALL, TORONTO, L1, C3 ) * SCH ( S1043, ACC1, #YTDLAG, TORONTO, L1, C2 )

or

SCH ( S1043, ACC1, #ALL, TORONTO, L1, C1 ) = SCH ( S1043, ACC1, #ALL, TORONTO, L1, C3 ) * SCH ( S1043, ACC1, #YTDLAG, TORONTO, L1, C2 )

Range restriction

All Longview expressions must have same range size in the corresponding Dimension in an equation.

Correct:

KLX ( ACC1, #ALL, ONTARIO### ) = KLX ( ACC2, #ALL, ONTARIO###)

or

SCH ( S1043, ACC1, #ALL, TORONTO, L1, #ALL ) = SCH ( S1043, ACC1, #ALL, TORONTO, L2, #ALL )

or

SCH ( S1043, ACC1, #ALL, TORONTO, L1, #ALL ) = SCH ( S1043, ACC1, #ALL, TORONTO, #TOTAL, #ALL )

Incorrect:

KLX ( ACC1, #ALL, TORONTO ) = KLX ( ACC2, A9701###, TORONTO )

or

KLX ( ACC1, #ALL, TORONTO ) = KLX ( ACC2, A9701, TORONTO ) + KLX ( ACC3, #ALL, TORONTO )

or

SCH ( S1043, ACC1, #ALL, TORONTO, L1, #ALL ) = SCH ( S1043, ACC1, #ALL, TORONTO, L2, C1 )

or

SCH ( S1043, ACC1, #ALL, TORONTO, L1, #ALL ) = SCH ( S1043, ACC1, #ALL, TORONTO, #TOTAL, #TOTAL )

Non-specified coordinate restriction

Longview expressions must have at least one specified symbol in one of the base dimensions and at least one specified symbol in one of the extra dimensions.

Incorrect:

KLX ( #ALL , #ALL , #ALL )

or

SCH ( S1043, ACC1, #ALL, TORONTO, #ALL , #ALL )

or

SCH ( S1043, #ALL , #ALL , #ALL , L2, #ALL )

#YTDLAG restriction

#YTDLAG can be used only on the right-hand side of the equation and cannot be used with other combinations of Longview expressions.

Correct:

KLX ( ACC1, #ALL, ONTARIO### ) = KLX ( ACC2, #YTDLAG, ONTARIO###)

or

SSCH ( S1043, ACC1, #ALL, TORONTO, L1, #ALL ) = SCH ( S1043, ACC1, #YTDLAG, TORONTO, L2, #ALL )

or

KLX ( ACC1, #ALL, ONTARIO### ) = KLX ( ACC2, #YTDLAG, ONTARIO###) + 100

Incorrect:

KLX ( ACC1, #YTDLAG, TORONTO ) = KLX ( ACC2, #ALL, TORONTO )

or

KLX ( ACC1, #YTDLAG, TORONTO ) = KLX ( ACC2, #ALL, TORONTO ) + KLX ( ACC3, #ALL, TORONTO )

LHS restriction

The left-hand side of the equation must be in the form of a single Longview expression.

Correct:

KLX ( ACC1, #ALL, ONTARIO### ) = KLX ( ACC1, #YTDLAG, ONTARIO###) + KLX ( ACC2, #YTDLAG, ONTARIO###)

or

SCH ( S1043, ACC1, #ALL, TORONTO, L1, #ALL ) = SCH ( S1043, ACC1, #YTDLAG, TORONTO, L2, #ALL ) + SCH ( S1043, ACC1, #YTDLAG,TORONTO, L2, #ALL )

Incorrect:

100 = KLX ( ACC2, #YTDLAG, ONTARIO###)

or

KLX ( ACC1, #ALL, ONTARIO### ) + KLX ( ACC2, #YTDLAG, ONTARIO###) = KLX ( ACC2, #YTDLAG, ONTARIO###)

or

SCH ( S1043, ACC1, #ALL, TORONTO, L1, #ALL ) + SCH ( S1043, ACC1, #YTDLAG, TORONTO, L2, #ALL ) = SCH ( S1043, ACC1, #YTDLAG,

Single assignment restriction

The same coordinates cannot be in the left-hand side of two different rules.

Incorrect:

Rule Id 1

KLX ( ACC1, #ALL, ONTARIO### ) = KLX ( ACC2, #YTDLAG, ONTARIO###) + KLX ( ACC3, #YTDLAG, ONTARIO###)

Rule Id 2

KLX ( ACC1, #ALL, ONTARIO### ) = KLX ( ACC3, #YTDLAG, ONTARIO###) + KLX ( ACC4, #YTDLAG, ONTARIO###) or

Rule Id 1

KLX ( ACC1, A9601, ONTARIO### ) = KLX ( ACC2, #YTDLAG, ONTARIO###) + KLX ( ACC3, #YTDLAG, ONTARIO###)

Rule Id 2

KLX ( ACC1, #ALL, ONTARIO### ) = KLX ( ACC3, #YTDLAG, ONTARIO###) + KLX ( ACC4, #YTDLAG, ONTARIO###)

#Plug restrictions

• Ability to #PLUG can only be specified to one dimension in any single rule. Therefore, the following example is not allowed:

  KLX(G,PX,...) = - KLX(A#PLUG,PY#PLUG,...)

• When #PLUG is used, the coordinates for the other dimensions must be identical. Therefore, the following example is not allowed:

  KLX(G,P1,...) = - KLX(A#PLUG,P2,...)

• Only one plug symbol may be identified for any parent value. Therefore, the following example is not allowed:

  KLX ( ACC1, CP1, … ) = - KLX ( ACCT#PLUG, CPT, … )

  KLX ( ACC1, CP2, … ) = - KLX ( ACCT#PLUG, CPT, … )

• Valid only with models (not rollup rules)

#ALL restrictions

• Each KLX or SCH must have at least one specific symbol or symbol hierarchy specified. You cannot use #ALL in its base dimension coordinate:

  Incorrect:

  KLX(#ALL,#ALL,#ALL) = 10

  Correct:

  KLX(A1###,#ALL,#ALL) = 10

• When an equation contains KLX and SCH, #ALL cannot be specified in any extra dimension:

  Incorrect:

  KLX(A1###,#ALL,#ALL) = SCH(ST1,A1###,#ALL,#ALL,CO1,#ALL)

  Correct:

  KLX(A1###,#ALL,#ALL) = SCH(ST1,A1###,#ALL,#ALL,CO1,R01)

• When an equation contains different schedules, #ALL cannot be specified in any extra dimension:

  Incorrect:

  SCH(ST2,A1###,#ALL,#ALL,LO1,#ALL) = SCH(ST1,A1###,#ALL,#ALL,LO1,#ALL)

  Correct:

  SCH(ST2,A1###,#ALL,#ALL,LO1,C01) = SCH(ST1,A1###,#ALL,#ALL,LO1,R01)

  SCH(ST2,A1###,#ALL,#ALL,LO1,#ALL) = SCH(ST2,A1###,#ALL,#ALL,LO2,#ALL)

• It is strongly suggested that #ALL be avoided in the TIMEPER dimension when constructing rules as its use may lead to the doubling of expected results.

Writing Rollup rule statements

Rollup rules can specify high level symbols without specifying the intermediate symbols necessary for the rollup. For example, if a symbol C rolls to B, which rolls to A (C to B to A), there could be a rollup rule stating: KLX(A,#ALL,#ALL)

This means “keep the data associated with A only”. Even though A depends on B, the data for B will be discarded during the rollup operation (but A will still be calculated correctly).

You can use the following parameters in the syntax:

Writing Query rule statements

In a query rule statement, you must specify:

• The cell coordinates of the cube of base data that is the source of the data you want to repeat virtually
• The cell coordinates of the target cube of base data where you want to place the virtual data

Query rule statements must be in the form target cube = source cube.

Note: The target cube must be a static Data Area. Data that is virtually placed in the target cell does not roll up.

Caution: If a user updates the value directly in the target cube, there will be no way to retrieve this value since any attempt to read the value of the target cube will be redirected to the source cube.

Restrictions

There are some restrictions on query rule statements:

• Only simple KLX() = KLX() query rules are supported
• Lag and lead functions are not supported
• The target cube must be a static Data Area
• Schedule data is not supported
• Each Dimension of the source cube must:
• Have the same number of symbols as the corresponding dimension in the target cube or
• Have only one symbol

Examples

This example is a one-to-one statement for all dimensions. Each dimension of the target cube has the same number of symbols as the corresponding dimension in the source cube.

KLX(ATTEND3A,DIM1SET,DIM2SET,DIM3SET,DIM4SET,DIM5SET,DIM6SET,DIM7SET)=

KLX(ATTDRVR1,DIM1SET,DIM2SET,DIM3SET,DIM4SET,DIM5SET,DIM6SET,DIM7SET)

This example is a one-to-many statement for the ACCOUNTS dimension. In this example, the target cube has many symbols in the ACCOUNTS dimension set equal to one symbol in the ACCOUNTS dimension of the source cube. All other dimensions of the target cube have the same number of symbols as the corresponding dimensions in the source cube.

KLX(ATTEND1#99,#ALL,DIM2SET,DIM3SET,DIM4SET,DIM5SET,DIM6SET,DIM7SET)=

KLX(ATTDRVR1,#ALL,DIM2SET,DIM3SET,DIM4SET,DIM5SET,DIM6SET,DIM7SET)

This example is a many-to-many statement for the ACCOUNTS and TIMEPER dimensions. In this example, the target cube has many symbols in the ACCOUNTS dimension set equal to many symbols in the ACCOUNTS dimension of the source cube. All other dimensions of the target cube have the same number of symbols as the corresponding dimensions in the source cube. This query rule statement is only valid if the number of symbols in ATTEND2### is equal to the number of symbols in ATTEND3###.

KLX(ATTEND2###,CP#99,DIM2SET,DIM3SET,DIM4SET,DIM5SET,DIM6SET,DIM7SET)=

KLX(ATTEND3###,CP#99,DIM2SET,DIM3SET,DIM4SET,DIM5SET,DIM6SET,DIM7SET)

Writing Event rule statements for emails

The email action causes an email to be sent to the addresses specified when data in the defined area changes.

If your user ID contains an “at” sign ( @ ), your user ID and email address must be the same for the Email event rule to work correctly.

Syntax

KLX(Sym0,Sym1,…SymN)=Email(ID1[,ID2[…,IDn]])[;Interval]

SCH(Sched,Sym0,…SymN,SSym0,…SSymM)= Email(ID1[,ID2[…,IDn]])[;Interval]

Where:

Interval is an optional parameter which overrides the value of

DEFAULT_ACTIONS_TIME_INTERVAL with the specified value (in minutes; valid values are 0 to 1440). If the value is not specified, the DEFAULT_ACTIONS_TIME_INTERVAL value applies.

Example

The following is an example of an event rule:

KLX(stdact###,P01YTD,nfl###,DIM3SET,DIM4SET,SUBMITQA,CCAD,DIM7SET)=RUNPROC(" someproc1.lvpro")

This rule will launch someproc1.lvpro and run the commands listed in it when data changes in the intersection defined in the rule.

Note: In both examples, ### means that all leaf symbols that are children of the named symbol are included in the intersection. This can also be #0-#99, the same as in database queries.

Writing Event rule statements for procedures

The RUNPROC action causes a procedure to be executed when data in the defined area changes.

Syntax

KLX(Sym0,Sym1,…SymN)=[Queue_ID:]RUNPROC("ProcName")[;Interval]

SCH(Sched,Sym0,…SymN,SSym0,…SSymM)=[Queue_ID:]RUNPROC("ProcName")[;Interval]

Where:

• ProcName is the location of procedure. If the path is relative, the procedure will be launched from the server’s working directory. If the path is absolute, the working path will be changed to that directory and the procedure will be launched from there.

  Note: If an absolute path is used, lv_af.exe must be accessible from the new working directory (either in that absolute path or in the PATH environment variable).

• Queue_ID is an optional parameter to prevent the simultaneous activation of rules with the same Queue_ID number. The value is a three-character alphanumeric string.
• Interval is an optional parameter which overrides the value of DEFAULT_ACTIONS_TIME_INTERVAL with the specified value (in minutes; valid values are 0 to 1440). If the value is set to 0 or not specified, the DEFAULT_ACTIONS_TIME_INTERVAL value applies.

  Note: If you make any changes to the list of persistent event rules (in either the Persistent Event Rule Setup dialog, or the rulepersists.txt file) or the name of the procedure launched by the persistent event rules, you must restart the servers for your changes to take effect.
  For more information on persistent event rules, see “Specifying Persistent Event rules”.

Example

The following is an example of an email event rule:

KLX(stdact###,QAPLAN01,nfl###,DIM3SET,DIM4SET,SUBMITQA,CCAD,DIM7SET)=EMAIL("n ame@domain.com");62

This rule will submit an email message to the address indicated if data changes in the data intersection defined in the left side of the rule. If a subsequent change in data is detected, the action will not be launched again until 62 minutes after the last time it was launched.

Caution: New rules will not go into effect until Maintenance is turned off.

Writing Validation rule statements

In a validation rule statement, you must specify:

• The cell coordinates of the cube of base or schedule data against which you want to compare the imported values
• The cell coordinates of the cube of base or schedule data that you want to validate

Example 1

The following validation statement compares two cubes of base data in a six-dimensional database, to make sure certain values within those cubes are equal. This statement verifies that the value of the account symbol A1000 equals the value of the account symbol A2000 for all the leaf symbols within the year-to-date time period symbol and four remaining dimensions.

KLX(A1000,YTDROOT###,#ALL,#ALL,#ALL,#ALL)=

KLX(A2000,YTDROOT###,#ALL,#ALL,#ALL,#ALL)

Where:

Example 2

The following validation statement compares the total schedule data in the S1043 schedule for the ACC1 account across all time periods and entities, with the base cell value for that account across all time periods and entities. the schedule total and base data should match. If they do not, the validation error message appears in a validation report.

SCH(S1043,ACC1,#ALL,#ALL,#TOTAL)=

KLX(ACC1,#ALL,#ALL)

Where:

Validation message

For each validation rule that you create, you must create a corresponding error message that will appear in a validation report. This message specifies the cell coordinates and provides a brief description of the error.

For example:

%ENTITIES;%TIMEPER;%PRODUCTS;%CURRENCY;ASSETS & LIABILITIES OUT OF BALANCE BY;%VALUE

Where:

You can also use the following parameters in the syntax of the message: