CenterView Variables
Introduction
CenterView has 3 different kinds of Variable which can be referenced in Attribute Expressions and other places where expressions are allowed. These are :
Defining a Variable
A User Defined Variable must start with the $ character. By convention, Camel case naming convention is used (Camel case is a convention where names are made up of multiple words, with no spaces and the first letter of each word is capitalised. e.g. ThisIsCamelCase) when giving a variable a name, and variables that are local to the current function or expression should start with a lower case letter after the initial $ character. Variables whose scope extends beyond the current attribute expressions should start with an upper case letter after the initial $ character.
A User Defined variable need not be declared. The first time a variable is referred to in an expression, it is assumed that the variable is being declared and a value is being assigned to it.
$localVar = 'Smith' $GlobalVar = 'St.John-Smith'
Variable Typing
When a variable is first used, CenterView will make a best guess about what type of data is stored in that variable. e.g.
$thisNumber = 4 // A Number $thisAddress = '123 Fake St' // A String Value
When CenterView has decided what type of data is stored in a variable, that type will not change. So in the above example,
$thisNumber = $thisAddress
will cause CenterView to reject the expression you are building. In some cases a Type Conversion function (e.g. toDate) can be used to force a value of one type, into a variable of another type.Note : in some cases, Centerview will be able to convert from one type to another. e.g. from an integer to a floating point value.
A further discussion of type assignments and full list of types is available in the Parameter Types section on the help page for Scripting Basics and a discussion on how complex expressions can be defined for attributes is available here.
Variable Scoping
When writing expressions that reference variables it is important to understand the scope of those variables.
A Variable (or an Attribute Name) can only be referenced in an Expression if that Variable has already had a value assigned to it.
Note : Attributes are evaluated in order, so Variables defined in an Attribute (or the
attribute name itself) can be referenced in a later Attribute Expression, or in a dependent
Expression that is referenced after that Attribute is evaluated.
E.g. you can refer in a
pipe index Expression to a $variable if you have done a “lookup($variable)� in the Stream
before that pipe reference (or in an Output Multiplier, or an Output Filter), but otherwise you can’t.
The following tables gives some guidelines for the availability of Variables, based on the CenterView Timing Cycle for evaluating Models.
| Location of Expression | Available Variables |
|---|---|
| Input Multiplier | Some Internal Variables (e.g. _toDate)
User Defined Variables (i.e. variables declared locally in the Input Multiplier) |
| Database Collector SQL script | _inputMultiplier %USERNAME%, %PASSWORD% User Defined Variables |
| Output Multiplier | Internal Variables (e.g. _toDate) User Defined Variables |
| Attribute Expression | Internal Variables (e.g. _toDate) All <pipeName> values (e.g. inpipe.accountVal All _out.value where value is the name of the attribute and it is before the current attribute in the Stream All user defined variables created in a prior Attribute expression |
| Output Filter Expression | Internal Variables (e.g. _toDate) All _out.attribute values All user defined variables created in any Attribute expression |
| Pipe Index Expression on a Lookup pipe |
Internal Variables <pipename>.attribute - the name on an input pipe All _out.value where value is the name of the attribute and it is before the current attribute in the Stream |
| Alarm Generator Expressions | Internal Variables <pipename>.attribute - the name on an input pipe |
| Workflow Tasks | Internal Variables <pipename>.attribute - the name on an input pipe that formed an input to the workflow |