getSignals

Obtains signals from all bound components (or directly from environment properties for 1.x manifests). A typical use case is to obtain a map of environment properties, which can be set using Environment configuration management.

Only values seen by Workflow Instance at the time of current workflow start will be returned. To refresh these values during workflow execution, a waitPeers step should be used. Otherwise, getSignals will always return same values seen on workflow start or last waitPeers call.

Parameters

Name Type Default Meaning
multi bool false If true, gather values from each connected peer and return a map from a peer id to a properties map. If false, returns values only for interfaces with exactly one peer connected.

Return Values

Name Type Definition
result object A multi-level mapping with signals as values. When multi is false, the first-level key is an interface name, and the second-level key is a signal name. When multi is true, the first-level key is an interface name, the second-level key is a peer identifier and the third-level key is a signal name.

Example Usage

For 1.1 manifests, a step will return signals listed in services section of header:

header:
  services:
    properties:
      db-vm-image: consume-signal(string)
      app-vm-image: consume-signal(string)

launch:
  steps:
    - get-env-props:
        action: getSignals
        output:
          config: result
  return:
    db-vm-image:
      description: "VM image for DB tier"
      value: "{$.config.properties.db-vm-image}"
    app-vm-image:
      description: "VM image for APP tier"
      value: "{$.config.properties.app-vm-image}"

For 2.x manifests, step will return signals, listed in interfaces section of the workflow.Instance component. If you want to get properties or markers from the environment, then you should describe your values as interfaces of the corresponding services.

Note

If you did not mark the interface of the workflow.Instance as required, the component won’t wait for any peers on this interface. In this case a workflow can start when no signals have been received yet, which will result in “missing” values and evaluation errors. If getSignals output does not contain values it is supposed to contain, always check your interfaces and requirements first.

application:
  interfaces:
    output:
      red: "bind(workflow#result.red)"
      green: "bind(workflow#result.green)"
  components:
    markers:  # any name can be used
      type: reference.Service
      interfaces:
        has-internet-access:  # any name can be used
          has-internet-access: publish-signal(unit)
    properties:  # any name can be used
      type: reference.Service
      interfaces:
        properties:  # any name can be used
          sample-property-red: publish-signal(string)
          sample-property-green: publish-signal(int)
    workflow:
      type: workflow.Instance
      interfaces:
        result:
          red: publish-signal(string)
          green: publish-signal(int)
        has-internet-access:
          has-internet-access: consume-signal(unit)
        properties:  # any name can be used
          sample-property-red: consume-signal(string)
          sample-property-green: consume-signal(int)
      required: [has-internet-access, properties]  # client interface names
      configuration:
        configuration.workflows:
          launch:
            steps:
              - get-env-props:
                  action: getSignals
                  output:
                    props: result  # "result" here is the name of the getSignals output parameter.
                                   # Not to be confused with the "result" interface above.
            return:
              red:
                # interface name----v            v--- signal name
                value: "{$.props.properties.sample-property-red}"
              green:
                value: "{$.props.properties.sample-property-green}"
          destroy:
            steps: []
  bindings:
      - [workflow, markers]
      - [workflow, properties]