• Devices
• Components
• Device Templates
• Interface Templates
• Probe Templates
• Log Templates

An example variable store for a device is shown in the following screenshot:

4.2.1 Scope, Variable Access, and Resolution
As detailed in 4.3 - Interpreter every expression in AutoNOC is evaluated at the scope of some object and variables are accessed via the % operator at that scope. When AutoNOC encounters the % operator, it looks at the scope of the current evaluation situation and then proceeds to evaluate and resolve the variable. An example of a variable would be %IP which attempts to resolve an IP address.

AutoNOC follows these steps when resolving a variable:

1. Record
   When AutoNOC is evaluating databases full of data, the expression interpreter will have the scope of a record. For instance, when the interpreter is evaluating an expression at the scope of a probe's database record and it is asked to evaluate the %V variable for the relevant value, it will return the value for the probe's record. If there is no current record in scope, then AutoNOC moves to the next resolution dependency below.
     
2. Object
   If there is no current record, then AutoNOC will attempt to resolve the variable as related to the current object state and properties. For instance, %V will return the current or most recent value, as %L will return the current level for the object. As another example, %OBJNAME looks up the current object name.
     
3. Variable Store
   If the variable is unresolvable in terms of the current record and the object state, then the next step is to examine the current variable store, if there is one, for a definition. AutoNOC takes the variable and searches the variable store in a case insensitive manner for a variable that is defined within the variable store for the object. If it finds one than this value is used for the variable.
     
4. Template
   If there is no available variable store, then AutoNOC checks to see if the current scope is a templatized object such as a probe. If it is, then AutoNOC will temporarily move the scope to the template and try and resolve the variable within the scope of the template. All templates have variable stores so usually this means looking through the variable store of the template for globally defined variables.
    
5. Alarm
   If an action is currently being fired, then certain variables, such as %TRIGGERTYPE will be defined. AutoNOC will evaluate the current variable against any such defined variables.
    
6. Parent
   If the variable is still unresolvable, then the software moves up the ladder to the parent of the object. For instance, when evaluating an expression in terms of a probe, AutoNOC then moves to the component of the object to resolve it, then to the category, and finally to the device. Each step along the way it tries to resolve the variable.
    
7. Global
   If a variable is unresolvable in terms of any parent object, then AutoNOC will check the globally defined variables to see if the variable can be resolved. %PORTALNAME would be an example of a globally resolvable variable.

This system is somewhat sophisticated when reading it on paper, but it actually works together in a very clean way to make it easy to author sophisticated expressions that can be applied generically in large scale operational models.

4.2.2 User Variables
Users can specify their own variables and add their own variables to objects. Note that if you specify a variable that AutoNOC makes use of by default, you will be over-riding that variable for objects evaluated in that scope. For instance, if you add a %PORTALNAME variable to a component, then any expression evaluated at that object level or as a child will return the user defined variable.

Also, let us point out that you can define your own custom variables. For instance, you can create probes that behave one way 95% of the time and another way for certain devices.

For a complete list of AutoNOC's standard defined variables, see A.2 - Variables.