Settings

(1) Dependency: The execution of the Response can be made dependent on the successful or erroneous execution of a previous Response. The number to be entered corresponds to the position in the Response list. 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.

(2) Condition: Executing a Response 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 with "[Variable: ...]". Note: Although only one variable can be used here in the condition in the Response, 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.

(3) On test: The Response is either only executed in a test or not in a test or always.

States of Responses

After a job has been processed, the Responses always have exactly one (internal) state.

Dependencies between Responses

Responses can be dependent on one another as shown in the following figure.

(4) A Response A, with format and transmission method. There may be any number of these Responses in a profile.

(5) State of the Response A. In this case "Error".

(6) State of the Response A. In this case "Success".

(7) A dependency of a Response B on the status of a previous Response A. In this case, the dependency "on error". Thus, Response "B" is executed only if Response "A" has the status "Error".

(8) Response C without dependency on previous Responses.

(9) A dependency of a Response D on the status of a previous Response B. In this case, the dependency "on success". Thus, Response "D" is executed only if Response "B" has the status "Success".

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 has been processed successfully. The processing is not cancelled, only a log entry is generated for the unsuccessful Responses.

• If all (out of one or more) Responses have been skipped.

• If there is no Response.