DiagramElements-Pin/en

Aus expecco Wiki (Version 2.x)
(Weitergeleitet von DiagramElements-Pin)
Zur Navigation springen Zur Suche springen

Inhaltsverzeichnis

Introduction[Bearbeiten]

Pins are the data interface between steps. They are used to read and pass data such as parameters, results and measurement data, documents 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. Input values can come from other Pins (via connections), Literal Freeze Values or from Environment Variables. 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.

Types of Pins[Bearbeiten]

The different types of pins are shown in this image from left to right:

All pins

Data Inputs:

  • Data Input (at the left, named "in1")

Control Inputs:

  • Enable Input (also called "Trigger Input" at top left)
  • Cancel Input
  • Timelimit Input
  • Repeatcount Input
  • Performer Input

Data Outputs:

  • Data Output (at the right, named "out1")

Control Outputs:

  • Enable Output (also called "Trigger Output" at bottom left)
  • Exception Output
  • ExecutionTime Output

Input Pins[Bearbeiten]

Input pins are located at the left (data inputs) and/or at the top (called control or special inputs) of a step. They receive data and process this depending on their type.

Input Basket: Queue of Incoming Values[Bearbeiten]

Every input pin has an associated incoming data basket, which is capable of buffering multiple input values. Values as coming from other steps via a connection remain there until the receiving step gets triggered (all of its required inputs are present) and consumes the next value from the input basket(s). This means, that an output pin can write multiple values to a connection or multiple output pins from different steps may connect and send data to the same input pin.

By default, an input basket's buffer is unlimited in capacity (actually, the capacity is limited by the amount of available memory in the system). However, a limit may be configured in the diagram editor via the pin's popup menu. If a limit is given, and the input basket is full, any further incoming data is blocked and the sending step(s) are suspended until the basket is emptied below the limit. This solves the traditional producer-consumer problem, where a generator is sending data to a consumer, which cannot process the values fast enough (i.e. the producer outruns the consumer).

Input Pin Trigger Attributes[Bearbeiten]

Each regular (data) input pin can individually be configured to behave according to one of the following built-in stereotypes. This affects its triggering and value consumption behavior:

  • triggering & consuming ("Regular Pin")
  • non-triggering & non-consuming ("Parameter Pin")
  • non-triggering & pass-through ("Mailbox Pin")
  • triggering & pass-through mailbox ("Telegram Pin")

Actually, there are 8 possible combinations of the triggering/non-triggering, consuming/non-consuming and mailbox/non-mailbox attributes. However, in practice, only the four combinations above are useful. In fact, almost all pins are either regular (trigger & consuming) or parameter pins (non-trigger & non-consuming). Therefore, those have been given special names and they have special menu items in the network editor's pop-up menu for pins. Other combinations are to be set via a sub-menu, if they are ever needed. Some combinations are blocked as they do not make sense at all.

Trigger vs. Non-Trigger[Bearbeiten]

The trigger / non-trigger attribute affects if a new activity is to be created for the step when a value arrives. Each triggering pin is considered by the input-fetcher algorithm and an activity is started when all triggering pins have received a value (more on this below).

A step without any triggering data input pin must be activated by either an autostart attribute, or by an explicit trigger via the trigger-input pin.

Consuming vs. Non-Consuming[Bearbeiten]

The consuming / non-consuming attribute defines if incoming values are read-out from the pin's input basket (consuming) or stay there. Consuming baskets show the normal producer-consumer behavior. Non-consuming pins are used for parameter values: these values are stored with the pin and kept remembered for the next activity, until changed. The diagram editor will always silently change the pin to be non-consuming and non-triggering, when a freeze value is defined.

Due to the big difference in the behavior (possibly affecting the execution of the diagram), this attribute is also visualized in the diagram: consuming pins are drawn as an unfilled pin-rectangle (meaning that a value is taken out of the basket which will be empty afterwards), whereas non-consuming pins are drawn as a filled rectangle (meaning that the value remains there).

Notice for consuming pins:

If a pin's input value is to be reused in a loop, it must be configured as a non-consuming pin. Otherwise the input data value is already consumed when the second iteration is due, and the step would not be triggered again. 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. Be especially careful when a compound action's input pin is connected to a looped step inside.

Notice for non-consuming pins:

A pin which has been declared as BOTH non-consuming AND triggering will fire an activity again and again (we call this a "machine gun error". There are situations, where such a pin setup does actually make sense, but only if the step has additional triggering (and consuming) pins. The automatic diagram checker will generate a red warning message in the editor's info area. Also the error search tab will look for and report this.

Telegram and Mailbox Pins[Bearbeiten]

The pass-through (mailbox/telegram) pin stereotypes specify that input values are not latched and remembered in a basket, but instead are passed through to either the underlying elementary action or the internal network of a compound activity.

This means that these pins forward any received value immediately to an already executing activity (all of them, if there are multiple). The mailbox attribute can only be specified in the schema (i.e. not for individual steps), because the action's implementation needs to be prepared for this kind of of behavior. It does not make sense to change the attribute of a pin which was never intended to be used as telegram pin.

In a compound network, an incoming telegram value will immediately be sent to the inner connection and possibly trigger execution of the connected step there.

In an elementary block, the pin gets the value and the program code can check for the presence of a value with "pin.hasValue()" or "pin.waitForValue()" and then consume the value e.g. in a loop (details are found in the elementary action API documentation).

Non-Triggering Pins which are Unconnected or which Received no Value[Bearbeiten]

Elementary code should check for a value being present at the pin, using the "pin.hasValue()" query before accessing the pin value. Otherwise a "No-Pin Value" exception will be thrown when the value is fetched.

In compound actions, any connected inner diagram step (the inner connection) will never get a value from the pin and therefore will possibly never be triggered.

Summary of Trigger + Consuming Combinations[Bearbeiten]

As mentioned above, some combinations of trigger vs. consuming are useless or seldom used. The following table gives a summary of all.

  • Triggering + Consuming + Non-Mailbox (also called "Regular Pin")
    This is the most common setup. The input value is consumed from the (underlying) input queue and used by the activity when all required input values are available. If another value arrives at the pin later, another activity will be started for that step.
  • Non-Triggering + Non-Consuming + Non-Mailbox (also called "Parameter Pin")
    The second most common setup. Typically, the input value is a freeze-value (i.e. a constant), and that same value is used for every incarnation of the step. However, if the input value is coming from another step's output, the "last value" is remembered for the next activity ("latched", so to speak)
  • Triggering + Non-Consuming + Non-Mailbox
    Questionable. In this setup, the step starts its activity when all other available pin values are present AND that particular pin has also received a value. Such a setup can be used to ensure that a particular value has been generated, and this value is to be reused later. One example is, when a collection is enumerated, and the enumeration is to be triggered by incoming key values, but the collection itself may or may not be present when the first key is computed. I.e. the collection may arrive any time later, but should be reused for each incoming key. There are other, more visible ways to model such a behavior, and the diagram should probably be changed to use explicit trigger-out to trigger-in connections for this.
Attention:
make sure that the step has additional trigger conditions, such as a trigger-input or another triggering input pin. Otherwise, the input may behave like a "machine gun" and force an endless retriggering.
  • Non-Triggering + Consuming + Non-Mailbox
    We cannot think of any use for this combination, so it should not be used.
  • Triggering + Mailbox
    The activity will be started when the first value arrives. The pin value will be passed directly to the internal step (if it is a compound). This setup can be used to start an event processing action, possibly with a variable number of triggering mailbox pins.
  • Non-Triggering + Mailbox
    Any value which arrives at the pin while the activity is already running will be passed directly to the running activities internal step an will possibly trigger that step there (if it is a compound). This setup is typically used to tell a running activity about a special condition (eg. to cancel or lead it into another state).

Triggering Behavior when no Triggering Input is Present[Bearbeiten]

If a step has either no data input at all, or they are disconnected, or all of them are frozen (i.e. "have a constant value" or read from a variable) and are therefore non-triggering pins, the step has no trigger condition due to data flow.

The step's activity must then be initiated either by manually adding a "Trigger Input Pin", or by giving the step the "Autostart" attribute.

Triggering Behavior when Multiple Inputs are Present[Bearbeiten]

The overall trigger behavior is specified in a block's schema definition - not at the step in a diagram. The reason is that the implementor of an action block (especially if it is an elementary block) would know better what the intended and appropriate behavior will be, and if the action can or should deal with unconnected pins or pins which have not received a datum.

When multiple triggering pins are present in a step, the overall trigger behavior can be specified to be one of:

  • AND-connected
  • AND
  • OR

AND-connected Triggering Behavior[Bearbeiten]

All connected triggering pins must have a value for the trigger to happen. Disconnected, parameter- and mailbox-pins are ignored.

AND Triggering Behavior[Bearbeiten]

All triggering pins must be connected and have a value for the trigger to happen. Parameter- and mailbox-pins are excluded from this test.

OR Triggering Behavior[Bearbeiten]

Any triggering pin with a value will trigger the activity. Unconnected pins and pins with no value are ignored and provide no value when referred to inside a network or elementary action code.

This is useful if a step receives values from multiple sources (i.e. to implement a join from alternative branches).

Notice:

In a traditional Petri Net, synchronization of values is done at explicit transition points. To make the diagram easier to read and understand, expecco has merged the transition functionality into the action steps. Thus, every step with multiple input pins has an implicit transition behavior already built-in. In situations, where explicit transition points are preferred or required (for semantic or didactic reasons), the standard library also provides a number of synchronization blocks, which can be used to model the traditional join, merge and fork transition primitives as extra items in the network.

OLD Behavior Modes[Bearbeiten]

There was a change in the way the trigger behaves when autostart is enabled but no input values are present. For backward compatibility, these previous modes are still supported and presented as "AND (old behavior)" and "OR (old behavior)". As there are situaions, where these modes are useful, they will remain (and might be renamed to "xxx (alternative mode)" in the future.

Special Input Pins[Bearbeiten]

The following special input pins are optional and not automatically present after initial creation of a step in the diagram editor. You have to explicitly create them via the step's right button pop-up menu or via one of the toolbar shortcut action buttons of the diagram editor. Their trigger behavior is implicit and depends on the type of pin.

Enable Input Pin[Bearbeiten]

The "Enable Input Pin" (also called "Trigger-In" pin) is used to explicitly trigger the execution of a step.

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 definitely after another step's execution, independent of when data input arrived. Trigger inputs are also useful to create loops in the diagram.

Trigger input pins are consuming (and of course: triggering).

Notice:

if a step's execution is controlled by a trigger-input, AND the step is part of a loop, you will need an extra START step, whose trigger output feeds the loop's trigger input. Otherwise, your loop will never get a signal to start executing.

Cancel Input Pin[Bearbeiten]

The "cancel input pin" can be used to cancel (abort) an ongoing activity. A long-running activity can be cancelled, by passing any data value to a step's cancel pin while it is executing.

The data-flow-behavior of a cancel input is different from other input pins' behavior: cancel input pins behave like a mailbox-input pin; this means that input values are not fetched and remembered at triggering time, as is the case with normal input pins. Instead, an incoming value is immediately handled at any time during the execution of the step and forces the activity to stop.

If a cancel pin receives a value before the step's activity has started or after it has finished, nothing happens. Especially, a cancel value arriving before the activity has started, is ignored. If uncertain, make sure that no race conditions arise, by inserting appropriate delay steps, or by enforcing a definite execution order via "trigger-out -> trigger-in" chains.

Timelimit Input Pin[Bearbeiten]

The "time-limit" input pin is used to automatically cancel an activity after a given maximum execution time. The time-limit 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, a constant freeze value or an environment variables are used.

The time-limit pin is a non-triggering, non-consuming parameter pin.

Iterate Input Pin[Bearbeiten]

The "Iterate Input Pin" (also called: "Repeat Count") can be used to execute a step's action multiple times. The iteration value can originate from another step's output, from a constant freeze-value, or from an environment variable. This is a triggering, non-consuming pin, however, if the action has already been triggered, it will not retrigger another activity.

On the outside, the iteration is invisible (except for any outputs which might be written to multiple times). This means, that in the activity log, the block is only shown once (but the iteration value is shown in the log). Also, if used together with a time-limit pin, the time-limit is applied to the overall execution (i.e. NOT applied to each individual iteration).

Finally, a cancel input finishes the overall execution, not only the current iteration. If present, the time-output of repeated step gets the overall time (it is not written multiple times with the individual times).

Notice that the action is repeated with the same input values. If there are any consuming input values, only a single value is consumed, regardless of how often the action is repeated. Thus to the outside the activity looks like a regular one, except that its internal operation is repeated. If that is not intended, the behavior must be realized via an explicit loop, or by triggering the step multiple times.

Performer Input Pin[Bearbeiten]

The "performer input pin" is only present at a virtual block's step. It is be used to dynamically specify a concrete action block to be performed by the 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 action's library (see virtual library). This is a non-consuming, non-triggering pin.

Variable Number of Pins[Bearbeiten]

An elementary action may specify that a variable number of input and/or output pins is allowed in its steps. Then, the number of pins can be changed by pulling down a special pin-count handle in the activity diagram, where the step is placed. To enable a variable number of input or output pins, use the "Special Attributes" popup menu function in the schema editor of the action block.

Before expecco version 2.8, only the very last pin could be defined as a "variable" pin, and only the last pin could be replicated in a step. In current versions, it is also possible to replicate a group of pins. For example, by specifying the last 2 pins as a replicated group, additional pins can be added to a step in multiples of 2. Individual pins within a group may have different datatypes, and the replicated pins take the datatype of their corresponding pin from the action's schema definition. This is very useful to define "multi-key-value" groups, for example for multi-setter actions of collections or user data objects.

Notice that only elementary actions can have a variable number of pins (because there is no way currently, to connect those pins in a diagram). Also, special elementary code is required which dynamically determines the number of pins and enumerates them. The elementary code API of variable pins is described in Expecco API.


Input Pin Special Attributes[Bearbeiten]

Accessable via "Special Attributes" in the pin's context menu (select the pin, then right click)

Input Pin: Read without Typecheck Attribute[Bearbeiten]

By default, an input pin checks if its value matches the pin's data type and reports an error if an incompatible value is received.

Be reminded, that even though you can specify a pin's datatype, there is no guarantee, that the datum is actually of that type (for example, the producer's elementary Python code might be wrong).

In theory, such input pins should be declared with a broader datatype (eg. "Any") in the schema definition. However, there might be situations where you do not want to or you cannot change the schema definition but are certain, that the action can deal with the situation in a particular diagram. Therefore this is an attribute of an individual step and not a scheme attribute.

The input type check can be disabled via the pin's "Special Attributes" menu item.

Input Pin: Duplicate Backslashes Attribute[Bearbeiten]

This is defined in the action's schema - not at individual step pins.

If set, the incoming pin value is first converted to a string, then backslash characters ("\") are duplicated. This feature is useful for filename strings, which are passed to script actions, where they may end up being sliced into a string constant.

For example, assuming that a script's input pin gets the pathname "c:\temp\foo\bar", and the the pin is used inside the script as

print "$(inPinName)"

then this would result in an invalid pathname in most scriptng languages (i.e. where the filename shoud be written as "c:\\temp\\foo\\bar" inside a string constant).

This is usually only a problem of Windows pathnames, but does usually not hurt if your script runs under a Unix system.

Input Pin: Read Without Typecheck[Bearbeiten]

Disables the typecheck.

Input Pin: Do not Log Pin Value[Bearbeiten]

The value is not recorded in the log. Set this for secret data or huge data values which would otherwise make the activity log unacceptably large.

Input Pin: Limit Input Basket Size[Bearbeiten]

Set the number of values which are queued in the pin's input basket. If the basket is full, a producing step will be suspended until it gets emptied.

Be reminded, that for every incoming pin a new activity is created which executes the action; in a producer-consumer situation, the producer may easily outrun the consumer unless the basket size is limited. By default, the bssket size is unlimited.

Output Pins[Bearbeiten]

Output pins are located at the right ("data outputs") and at the bottom of a step (called "control" or "special" outputs). They pass data/control information to other steps (if connected). Notice that output pins can be configured to be either buffered or unbuffered:

Output Pin Buffer Attribute[Bearbeiten]

Each regular (data) output pin can individually be configured to be either buffering or non-buffering. The default for new created pins is buffered. Their behavior differs in the error situation and in case of multiple writes to the pin:

Buffered vs. Unbuffered Output Pins[Bearbeiten]

  • Buffered
    a buffered output pin collects and remembers outgoing values until the action is finished without being either canceled or terminated by an exception.
    If finished without success, no values are written.
    If finished with success, the remembered values are written (at the same time as other buffered pins of the same action) to their output connections.
    It is ensured that all outgoing values of a step with multiple output pins are written in one atomic operation, so that follow up steps which receive those values will get them in a synchronized fashion (just imagine, that there are multiple values to be passed to receiving steps, and those values form a tuple of related values). If a buffered output pin is written multiple times, all written values are buffered until successful finished.
  • Unbuffered
    unbuffered output pins forward their output values immediately to any connected input pin of receiving steps. If multiple values are generated during the action's execution, the values may immediately trigger other activities as values are generated, and those may execute in parallel to the generating activity. Once a value is generated, it will be processed by receiving steps, regardless of the sending action's final termination status - even if failing or canceled will those values be "out in the world". Also, there will be no synchronization with respect to values as generated for other output pins of the same action.

Due to the big difference in the behavior (possibly affecting the execution of the diagram), this attribute is also visualized in the diagram: buffered pins are drawn as an unfilled pin-rectangle (meaning that values are put into that Buffer temporarily), whereas non-buffered pins are drawn as a filled rectangle (meaning that values appear immediately).

When Should an Unbuffered Output be Used?[Bearbeiten]

Think of a block which is programmed to send out 100 values (or value tuples) to its output pin(s), which are fed to a test scenario action to receive those tuples. The values may contain tuples of test data or individual data values. Also assume, that these 100 values are sent 1 per second. I.e. the test should run for 100 seconds, with 1 seconds delay between runs. This is done by putting a delay into the generator, to produce only one data tuple per second (which can be done easily both in an elementary block, or in a compound block).

If the data generator block's outputs are buffered, it would run for 100 seconds, remember all generated values, and then send them out as one jet of 100 tuples to the receiving block. Thus the system would seem idle, doing no test for 100 seconds, then execute them all as fast as it can.

With buffering turned off, each tuple is immediately sent to the receiving block, which would start one test run every second.

Another example could be a test-data feeder, which reads tupled data linewise from a file (say a CSV file from excel), and passes those tuples to its output pin(s), again one tuple per second. Here again, unbuffered outputs are needed, so that the action connected to the output gets triggered once per second.

Output Pin Special Attributes[Bearbeiten]

Accessable via "Special Attributes" in the pin's context menu (select the pin, then right click)

Output Pin: Write without Typecheck Attribute[Bearbeiten]

By Default, values written to a pin are verified to match the pin's type, and an error is reported (raised) at execution time if it does not. This check can be disabled for individual output pins via the menu function, or globally via the "Execution" → "Debugging" settings dialog.

Output Pin: Nullable Attribute[Bearbeiten]

Specifies if a nil (aka. "null") value is allowed.

Output Pin: Convert Value if Possible[Bearbeiten]

This is an attribute of the schema pin - not of individual step pins.

Tries to convert the value if possible. For example, a string of digits can be converted to an integer and vice versa. Also some other types (Floats, Unit Quantities, Arrays etc.) may be convertable.

This option is most useful with bridged actions, where the bridge language is not able to provide enough type information (for example, a Python-program, which generates strings like "5 m/s", which is to be converted to a velocity value).

Output Pin: Value is JSON Encoded String[Bearbeiten]

Will decode the JSON string to an expecco object. This option is also useful with bridged actions, to pass composite objects to expecco.

Output Pin: Do not Log Pin-Value in Activitylog Attribute[Bearbeiten]

This is an attribute associated to a step's input and output pins. By default, all of a step's pin values are recorded in the activity log, unless either the owning step has been given a "Skip in Activity Log" attribute, or pin value logging is globally disabled (via the project settings), or logging is completely disabled (also via the project settings).

However, there are some rare situations, when an individual pin's value should not be recorded in the activityLog:

  • if the datum contains security sensitive information (e.g. a password or cryptographic key)
  • if the datum is huge and would otherwise fill up the memory too fast if remembered (e.g. big transfer data buffers, which are not needed for later reporting)

The "Do not Log Pin-Value" attribute can be set for every step-pin individually via the pin's context menu-"Special Attributes" submenu.

Notice: if big data buffers are required to be recorded, these should be written into an attachment file, and the involved pins be marked as non-logged.

Output Pin: Value is Timestamped Attribute[Bearbeiten]

If enabled, a timestamp is attached to every pin's output datum as it is created (written to the pin). This is useful for unbuffered pins of actions, which write multiple times to an output pin (for example: server actions, which send logging information to a stream-output pin).

Notice that timestamps are disabled by default, because they will require a lot of additional storage to be held in the (in-memory) activity logs.

Also notice, that by default, timestamps have millisecond precision. This can be changed to microsecond precision in the settings, if the underlying operating system supports it.

Special Output Pins[Bearbeiten]

Enable Output Pin[Bearbeiten]

The optional "Enable output" pin (also called "Trigger-out") is activated after the execution of a step is finished successfully. Its main use is to enforce sequential execution of steps which would otherwise either execute in parallel or in no definite execution order. It can also be used to trigger actions , depending on the outcome of a previous computation. Finally, it can be used to create looping constructs, by connecting a trigger output back to a previously executed action's trigger input pin.

The value appearing at the trigger output pin is arbitrary - it should be treated as an anonymous token, of no specific data type (actually, it is not defined, what is appearing there).

The enable output pin is NOT given a value if an exception is raised AND an exception output pin is present (because then, you may want to direct the execution to different paths to handle or report the error). However, it is triggered, if an exception is ignored via the "ignore exceptions" attribute.

The enable output is written after any data output is written.

Exception Output Pin[Bearbeiten]

The optional "exception output pin" is used for exception handling and reporting. Whenever an execution leads to an error, and the exception output pin is connected, an exception information datum is generated and passed to that output. Usually the value is used to trigger or cancel other activities via their cancel or trigger input pins. 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 and possibly handled there. If nowhere handled, this exception forwarding will continue up to the top-level test case, and lead to an ERROR verdict there.

Notice, that by connecting both the exception-out and the trigger-out pins to different follow up steps, conditional execution based on a step's success is possible.

Also note that if the "Ignore Exceptions" option is set for a step, both enable output pin AND the exception output pins are triggered. But again: ONLY if the "Ignore Exceptions" attribute is set. This at first sight unintuitive behavior gives you a chance to detect failures and write a log entry, but still continue with the normal execution order. Without this, you had to duplicate the paths from the exception and the trigger output.


Exception Pin Example 1: Selecting a different execution path on failure
Depending on the success or failure of Step1, either Step2 or Step3 is executed:

Exception handling example 1

Exception Pin Example 2: Cancelling another operation on failure
Both are started in parallel (due to the autostart flag). If the execution of the first step fails, the second will be canceled via its cancel pin (if it has not already finished by that time):

Exception handling example 2

ExecutionTime Output Pin[Bearbeiten]

This pin, if present, will provide the step's execution time (as a TimeDuration value). You can pass this value to an "Assert Less", "Assert Greater" or "Assert in Range" block to ensure that the execution time of an action is within some bounds. Typically this is used to ensure that performance and response-time requirements are met.

The time output is written, if either the step executes with success, or the "ignore exceptions" or the "cancel is OK" attribute of the step is set.

Special Pins of Script Action Blocks[Bearbeiten]

Script actions can provide a number of additional special pins.

In order to make activity diagrams easier to read, these are not automatically created for new script actions (when created in the navigation tree).

Those pins are created via the "Special Pins" menu function in the scheme editor.

Special pins on the input side:

  • execDir
    an optional execution directory
  • args
    an optional list of command line arguments
  • stdin
    the standard input to be sent to the script
  • ignoreExitCode
    to treat a non-zero exit code as success
  • rawOutput
    to provide raw output (no line end canonicalization)
  • outNLInes
    to define the stdout pin's line-buffering behaviour (0 = all in one; 1 = linewise)
  • errNLines
    to define the stderr pin's line-buffering behaviour (0 = all in one; 1 = linewise)
  • prompt_optional
    an optional prompt string to search for
  • command
    an optional command

and on the output side:

  • stdout
    the standard output; either linewise, all-in-one, or chunked, as specified by the "outNLines" input pin
  • stderr
    the standard error; either linewise, all-in-one, or chunked, as specified by the "errNLines" input pin
  • result (exit code)
    the program's exit code
  • prompt_detected
    a trigger if the optional prompt was detected on stdout or stderr
  • stdoutValue
    the stdout type-converted as per datatype. That means that if the stdoutValue pin is of type Number, expecco will try to convert the generated output (which is a string initially) to a number, and report an error if it fails to do so. Likewise, if the pin's type is Boolean, it will look for "true" or "false" (in either case). If the generated output is more complicated or consists of multiple lines, you will have to extract the relevant data using either a regular expression matching action, or by defining a customized extract action.

More information is found in the "Script action API" document.

Special Pins of Bridged Action Blocks[Bearbeiten]

Bridged actions provide additional special pins:

  • bridge
    the bridge in which the action should be executed. This is only needed if you have started multiple bridges and you need to specify the concrete bridge instance in which the action should be executed.
    If no bridge pin is present or it has received no value, then a default bridge instance is used.
  • groovy
    this pin is only available for bridged groovy (i.e. Java) actions.
    It is used to specify a concrete Groovy instance inside a bridge. This is only needed if you have instantiated multiple Groovy instances within a single JVM, and you have to specify the concrete Groovy instance in which the action should be executed.
    If no groovy pin is present or it has received no value, then the default (first) groovy interpreter of the executing JVM is used (which is either the default JVM or the one given to the bridge pin).

Multiple bridges and/or multiple groovy instances can be activated at the same time to control multiple (possibly remote) machines in a parallel setup (eg. in load test scenarios, or to talk to multiple components of a distributed System Under Test).

In such a setup, you would start the bridge connections explicitly via one of the Bridge-Start actions from the standard library, and then pass the bridge connection handle to those bridge pins. If only one bridge is needed, you will usually leave the bridge input pin unconnected; then, one single bridge will be used (one per bridge language).

See Also[Bearbeiten]

Block Element, Activity, Step, Connection, Elementary Action, Compound Action,

For elementary code API to pins see: Expecco API

Back to Online Documentation.



Copyright © 2014-2024 eXept Software AG