Pins are the data interfaces between steps. They are used to read and pass data such as parameters, data sets or simple control information and represent the inputs and outputs of an activity. Output values of one activity are transported via a connection from the output pin to one or multiple input pins of other processing steps. When all required inputs of a processing step are available, an activity is created, which processes the input values, computes one or multiple result values, and transfers them via the output pins to further processing steps.
- 1 Different types of Pins
- 2 Input Pins
- 3 Output Pins
- 4 Individual Inputpin Attributes
- 5 Multiple Input Triggering Behavior
Different types of Pins
The different types of pins are shown in this image in clockwise order:
- Data-input (at the left)
- Enable-input (also called "triggerInput" at top-left),
- Data-output (at the right),
- Exception (at bottom-right)
- Enable-output (triggerOutput).
The Execution-Time output pin, which has been added to expecco version 1.8, is not shown in the above picture.
Input pins are located at the left and/or at the top of a step. They receive data and process this depending on their type.
Special Input Pins
The enable input pin is used to trigger an activity. If connected, it is used like an additional triggering, required input. Trigger inputs are needed if either all of a step's inputs are frozen to static values, or if the execution has to be synchronized to be after another step's execution. Trigger input pins are consuming.
The cancel pin can be used to cancel an ongoing activity. A long-running activity can be cancelled, by passing any data to a step's cancel pin. The dataflow-behavior of a cancel input is different from other input pins' behavior: cancel input behave like message-inputs; this means that input values are not fetched and remembered at triggering time, as is the case with normal input pins.
The timelimit pin can be used to cancel an activity after a given time. The timelimit value can either come from another step's output, frozen to a constant value, or read from an environment variable. In most real-world applications, environment variables are used. The timelimit pin is a non-triggering, non-consuming parameter pin.
The repeat-count pin (also: "iteration-count") can be used to execute a step's action multiple times. The iteration value can originate from another step's output or from a constant freeze-value, or from an environment variable. This is a non-triggering, non-consuming parameter pin. If used together with a timelimit pin, the timelimit is applied to the overall execution (i.e. NOT applied to each individual iteration).
The performer pin can be used to dynamically specify a concrete action block performed by a virtual block. If a virtual block's performer input is left unconnected, the environment is consulted for a binding of the virtual action or the virtual actions library (see virtual library). This is a non-consuming, non-triggering pin.
Output pins are located on the right (data output) and at the bottom of a step (control output). They pass data/control information to other steps.
Special Output Pins
The optional enable output pin (also sometimes called "trigger-out") is activated after the execution of a step is finished successfully. The enable output pin is NOT given a value, if an exception is raised AND an exception output pin is present. However, it is triggered, if an exception is ignored.
The optional exception pin is used for exception handling and reporting. Whenever an execution leads to an error, and the exception output is connected, an exception information datum is generated and passed to that output. Steps which do not handle the exception (i.e. those without an exception output and not ignoring the exception) pass the exception up to their enclosing network's step. If nowhere handled, this exception forwarding will continue up to the top-level testcase, and lead to an ERROR verdict there.
Notice, that by connecting both the exception-out and the enable-out pins to different followup steps, conditional execution based on a step's success is possible.
This pin, if present, will provide the step's execution time (as a TimeDuration value).
Each input pin can individually be configured to be one of:
- triggering, consuming ("regular")
- non-triggering, non-consuming ("parameter")
- non-triggering, pass-through ("mailbox")
- triggering, pass-through mailbox ("telegram")
The trigger / non-trigger attribute affects if a new activity is to be created for the step. Each triggering pin is considered by the input-fetcher algorithm (as described below).
The consuming / non-consuming attribute defines if incoming values are read-out from the pins input basket (consuming) or stay there. Consuming baskets show the normal producer-consumer behavior. Non-comsuming pins are used for parameter values: these are stored in the pin and kept remembered for the next activity, until changed. Frozen pins are always configured to be non-triggering, non-consuming pins.
If an input value is to be reused in a loop, it must be configured as a non-consuming pin. Because this is so common an error (to "eat" the input value in a loop), there is an extra check-entry for that in the tree-pane's error-search tab.
The pass-through (mailbox) pin stereotype specifies that input values are not latched and remembered in the activity, but instead are passed through to either the underlying elementary action or the internal network of a compound activity. This means, that these pins, when receiving a value, are forwarded to an already executing activity (all of them, if there are multiple).
When multiple triggering pins are present in a step, the overall trigger behavior can be specified to be one of:
All triggering pins must be connected and have a value for the trigger to happen. Parameter- and mailbox-pins are excluded from this test.
All connected triggering pins must have a value for the trigger to happen. Disconnected, parameter- and mailbox-pins are ignored.
Any triggering pin with a value will trigger the activity. This is useful if a step receives values from multiple sources