Variables

A major benefit of using a workflow solution is the consistency and availability properties provided by the system. A simple litmus test for identifying the need for a workflow based solution is answering the question, "Where does the state live?"  If it's ok for the state to live on a single system, then running a regular script or program there is probably a simpler solution. Another way to ask the question is this: "Is there a system whose failure makes the operation irrelevant?"  If such a system exists, then it should be the one driving the operation and keeping the state. For example, if the operation consists of cleaning the temporary files of an instance, then that instance failing makes the operation irrelevant. Therefore, it is OK for it to be responsible for scheduling the operation.

For distributed operations, there is often no simple answer to where state can be kept or where a conventional program can be run. The operation must continue regardless of individual system failures. For example, if the operation consists of analyzing the metrics data on all the instances in a deployment and taking action if certain values reach a given threshold, then no single instance is a good place to run the operation. And a separate "management server" isn't good either as it can fail as well. In this case, using a workflow based solution makes sense as the workflow engine is in charge of keeping the state and making sure that the operation is either carried out or gives proper feedback in case of failure. This is obviously not the only reason to use a workflow solution, but state bookkeeping is one of the main perks that come out of it. (Managing concurrent execution of activities is another big one described in the Cloud Workflow Processes section.)

The state of a process is kept in variables and references. References were already covered in Cloud Workflow Resources. They contain collections of resources. A Cloud workflow variables may contain a number, a string, a boolean, a time value, the special null value, an array or a hash. Variables are initialized directly via literal values in code, from resource fields or from the results of a computation. A variable name must start with $ and may contain letters, numbers, and underscores. As with references the naming convention consists of using lower_case. For example: 

• Initializing a variable from a literal value:

$variable = 1

•  Initializing a variable from a resource field:

@servers = rs.get(href: "/api/deployments/123").servers()
$names = @servers.name[]

The above code initializes the $names variable to an array containing the names of all servers in deployment with href /deployments/123.

Accessing a variable that has not been initialized is not an error, it just returns the value null.

$object = { "rails/app_name": "Mephisto", "db_mysql/password": "cred:DB_PASSWORD", "app_server/ports": [80, 443] }

$object["rails/app_name"] # Will resolve to "Mephisto"

$object["app_server/ports"][0] # Will resolve to 80

d"2012/07/01"
d"2012/07/12 04:21:14 PM"

$one = 1 # 1
$two = 2 # 2
$three = $one + $two # 3
$four = $two ^ 2 # 4

$string_concat = "foo" + "bar" # "foobar"
$array_concat = [$one, "2"] + [3, 4] # [1, "2", 3, 4]
$object_merge = { "one": 1, "two": 2 } + { "one": 0, "three": 3 } # { "one": 1, "two": 2, "three": 3 }

$false = true && false # false
$true = true || false # true
$false = !true # false
$true = 1 == $one # true
$true = $two < 3 # true

$array_append = [$one, "2"] << 3 # [1, "2", 3]
$regex_compare = "hello" =~ "^h" # true

$variable = 42
sub do
  assert $variable == 42 # $variable is "inherited" from parent block
  $variable = 1
end
assert $variable == 1 # $variable is updated in child block

sub do
  @servers = rs.servers.get(filter: ["name==my_other_server"])
  assert @servers.name == "my_other_server" # true, @servers was "overridden"
  sub do
    assert @servers.name == "my_other_server" # true, @servers contains value defined in parent block
  end
end
assert @servers.name == "my_other_server" # RAISES AN ERROR, @servers is not defined in the parent block

define main() do
  @servers = rs.servers.get(filter: ["name==my_server"])
  @other_servers =rs.servers.get(filter: ["name==my_other_server"])
  call launch_servers(@servers)
end

define launch_servers(@servers) do
  assert @servers.name == "my_server" # @servers contains value passed in arguments
  assert @other_servers.name == "my_other_server" # RAISES AN ERROR, @other_servers is not passed in arguments
end

sub do
  $$one = 1
end
assert $$one == 1 # global variable remains set for the entire execution of the process

define init_servers() do
 ​ @@servers = rs.get(href: "/api/servers/234")
end
call init_servers()
assert @@servers.name == "my_server" # @@servers set for the entire execution of the process