When building routines, there will likely be a need to set variables. A variable may be a simple number or a calculated value that needs to be used repeatedly throughout the routine.
The Set Variable action in a routine allows you to create local and global variables. The notations for referencing these variables are:
Local variables are as the name may suggest, are used only within the context of the current routine they are referenced in.
We can create a local routine by selecting to add the "Variable" action within your routine
We can then reference that variable via an EL function - ${_local.variablename}
![] (..\images\ELVariables21.png)
A global variable unlike a local variable may be used in more than one routine, however it is limited to only those routines which are triggered by the same action, that is, if you have more than one routine which is triggered by an incoming message type, a global variable can be set in the first of these routines and may be called in subsequent routines without redefining it.
Global variables may also be referenced in sub-routines triggered as part of a routine.
Routines are executed in the order they appear in your routine list, so in order to use a global routine effectively you would need to set it in the first routine of a particular origin and then reference it in subsequent routines or sub routines.
We can reference the variable via an EL function - ${_global.variablename}
The fact that a global variable cannot be referenced out of context (across different routine types) foes limit its advantages over local variables but this is certainly still a use case which will save time in defining multiple local variables.
Example
One use of global vs local variables may be a pair of routines triggered by an incoming message.
Routine 1 finds all application resources, collects all their current temperature values, and using a temperature value from the incoming message sets a global variable ${average_temp}
Routine 2 is executed after this and updates the message resource with current data and calculates whether or not this resource is above or below temperature average - the "temperature difference" field would look something like:
${_source.machine_temp - _global.average_temp}
We could then take an action if the difference is too great…
A common issue we may have when processing device messages in a routine is identifying the resource parent. Often times it may be best practice to store and update a customer value on a resource, to simplifying identifying what customer a resource belongs to for sending notifications for example. Another way around this though is to use a “parent” attribute.
${object._parent}–the parent object associated with the source object in the routine
Example:
Find group “customer” for resource where “customer name” = ${source._parent._code}
When we have a user submit a form or take some other action in a routine we may want to present some specific representation of the user, so the user object itself has a number of identifiable attributes:
${user.name}–the name of the user stored against his profile
${user.login}–the users login name
${user.timezone}–where that user is located based on the time zone in his or her profile