Create Expectation
When you create an expectation, you can define a name of your choice. It is advisable to assign the name in a meaningful way, so that the assignment of the exposure in the job definition is as easy as possible.
The following expectations can be defined using a JSON string:
Typ | Zweck | Definition | Erklärung |
---|---|---|---|
|
Check the server response for the presence of a certain number of strings |
|
|
|
Verification of the server response by regular expressions |
Single values in the JSON array |
Each value is considered a regular expression and checked (see |
|
Check the server response for the presence of strings |
Single values in the JSON array |
Each value is checked for presence in the server response (see |
|
Check the server response for the presence of HTTP Headers |
Single values in the JSON array |
Each value is checked for presence in the server response (see |
|
Does a comparison of HTTP Header values for both textual or numeric compare |
Three values: HTTP Header name, comparison operator and comparison value |
Combination of Header, comparison operator and value will be checked with the server response’s HTTP Header. Textual comparison: eq and like Numeric comparison: =, <, <=, >, >= |
|
Checks number of registered FME Engines |
Number of engines |
|
|
Checks number of FME Engines available for processing |
Number of engines |
|
|
Checks for delayed job execution |
time period for maximum allowed delay |
|
|
Checks for expected execution of FME jobs which are triggered by an FME schedule |
Duration for calculation of time slot for an expected successful job execution |
In the content field of the expectation, a type is defined via the JSON notation, which controls the evaluation of the server response. In the content section, a JSON array can always be used to define several individual conditions (see table above and the examples on the website).
The matchAll
switch can be used to decide whether all conditions must be met in order for the service to be evaluated positively or for the fulfillment of a condition to be sufficient.
Test Expectations
In the lower input field you can simulate server responses and test them against the current definition of the expectation.
In the above example, the expectation would not be fulfilled because matchAll
is set to true
and the condition text2 occurs once only
with the example answer does not apply.
Testing HTTP Header related expectations can be done by adding HTTP Header line by line to the content field: <HTTP-Header>: <HTTP-HEADER-VALUE>