Dependencies
(1) The execution of the Response Route can be made dependent on the successful or erroneous execution of a previous Response Route. The number to be entered corresponds to the position in (2). Note: If "on success" is selected, multiple response numbers can be specified comma separated. Note: If "on error" is selected and a variable that evaluates to "*" at runtime is specified as response number, the dependency is considered fulfilled.
(3) Executing a Response Route can be made dependent on a condition. On the one hand, string comparisons can be performed by comparing the value of a variable or system constant (selectable via the button) with an entered value or the value of a variable or system constant. On the other hand, you can perform Boolean comparisons if you select "true" or "false" on at least one side. In both cases an implicit type conversion takes place if one of the values is not of type "String" or "Boolean". Regular expressions are also allowed with the prefix "regex:", e.g. "regex:^[ABC|XYZ].*$".
Note: The string comparison is not case-sensitive. Note: A condition is displayed in the name of a Response Route with "[Variable: ...]". Note: Although only one variable can be used here in the condition in the Response Route, you can of course use a logic of any complexity with several variables and functions in the mapping. Whatever this logic produces as a result, you then store in a single variable and use this variable as a condition in the Response Route.
(4) The Response Route is either only executed in a test or not in a test or always.
States of Response Routes
After a job has been processed, the Response Routes always have exactly one (internal) state.
|
skipped |
The Response Route has not been processed. A Response Route is in state "skipped" in the following cases: The variable that determines the use of the Response Route has the value "false". The option "During test only" is set and the current job is not a test job. The option "Not during test" is set and the current job is a test job. The Response Route depends on a Response Route that itself is in state "skipped". |
|
success |
The Response Route was successfully processed. |
|
error |
An error has occurred during processing of the Response Route. |
Dependencies between Response Routes
Response Routes can be dependent on one another as shown in the following figure.
(1) A Response Route, with format and transmission method. There may be any number of these Response Routes in a profile.
(2) State of the Response Route. In this case "Error".
(3) State of the Response Route. In this case "Success".
(4) A dependency of a Response Route from the status of a previous Response Route. In this case, the dependency "on error". Thus, Response Route "B" is executed only if Response Route "A" has the status "Error".
(5) Response Route without dependency on previous Response Routes.
(6) A dependency of a Response Route from the status of a previous Response Route. In this case, the dependency "on success". Thus, Response Route "D" is executed only if Response Route "B" has the status "Success".
Example
Response Route "D" depends on Response Route "B". Response Route "B" is not executed due to its own (unfulfilled) dependencies. In this case, Response Route "B" gets status "Skipped". As a result, Response Route "D" is not executed and also gets status "Skipped" because it depends on Response Route "B". Generally, Response Routes dependent on skipped Response Routes are not executed.
Status of phase 6 - Error behaviour
If phase 6 is not successful, the job terminates with an error. Phase 6 of a profile job is considered successful in the following cases.
If at least one (out of one or more) Response Route has been processed successfully. The processing is not cancelled, only a log entry is generated for the unsuccessful Response Routes.
If all (out of one or more) Response Routes have been skipped.
If there is no Response Route.
Alternative behaviour
If there is a Response Route with set checkbox Mark whole job as failed if this response fails and this Response Route is not successful, phase 6 is not successful and the profile job terminates with an error.
In the event that the Response Routes do not have any dependencies, the following entry in the configuration file ./etc/startup.xml can be used to ensure that an error message appears whenever an error occurs. The default setting for this option is false.
<Call name="handleResponsesWithoutDependenciesAsError"> <Arg type="boolean">true</Arg></Call>