Expectations
Expectations allow to define concrete expectations for the response of a job execution. If the expectation does not apply, the service will be evaluated as faulty and notifications will be sent.
Expectations are stored independently of service and job. When you add a new job, you can select one or more expectations to be associated with the job.
The administration page can be accessed via service.monitor’s dashboard. First, an overview with all registered expectations opens and offers various actions: Create, Edit, Delete, View.
![all](../_images/user/monitoring/expectation/all.png)
Create
When you create an expectation, you can define a name of your choice. It is advisable to assign the name meaningful, 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 |
---|---|---|---|
StringCountExpectation |
Check the server response for the presence of a certain number of strings. |
|
|
RegularExpressionExpectation |
Verification of the server response by regular expressions. |
Single values in the JSON array |
Each value is considered a regular expression and checked. |
StringContainsExpectation |
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. |
HttpHeaderAvailableExpectation |
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. |
HttpHeaderAndValueExpectation |
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: Numeric comparison: |
FmeEngineCountExpectation |
Checks number of registered FME Engines. |
Number of engines |
|
FmeEngineAvailableExpectation |
Checks number of FME Engines available for processing. |
Number of engines |
|
FmeJobTimeShiftExpectation |
Checks for delayed job execution. |
time period for maximum allowed delay |
|
FmeScheduleJobExecutionExpectation |
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. |
|
ElasticAggregationValueExpectation |
Checks the response of an Elastic Aggregation query against a specific numerical value. Only one aggregation is checked per query. |
Two values in the JSON array: comparison operator, numeric comparison value |
The defined combination of operator and numerical value is checked against the server response. operators: |
Define a type in the content field of the expectation via the JSON notation, which controls the evaluation of the server response. In the content section, you can use a JSON array to define several individual conditions. For further information see the table above and the linked example page in monitor webapp.
Use the matchAll
switch to determine whether all conditions must be true.
Otherwise, the fulfillment of one condition is sufficient.
![create](../_images/user/monitoring/expectation/create.png)
Test
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 is not 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>
.