The <webserviceTrigger> tag encloses the definitions for a trigger with which a Job is started via a Webservice interface. This tag has no attribute.
Allowed sub-elements | Quantity |
---|---|
outputFolder | 1 |
failedFolder | 1 |
Example of a job definition on the basis of the Webservice trigger:
<?xml version="1.1"?>
<jobdefinition name="myjob" model="model.eox" xmlns:xi="http://www.w3.org/2001/XInclude">
<webserviceTrigger>
<outputFolder value="\output" />
</webserviceTrigger>
<actions>
<action name="MyLibrary.MyCustomAction" arguments="List{trigger.params}"/>
<action name="MyLibrary.MyCustomAction" arguments="List{trigger.params.value('mykey')}"/>
<action name="Engineering.MarkFileForDownloadCommand" arguments="List{trigger.outputFolder + 'results\\generated.file'}"/>
</actions>
</jobdefinition>
Description:
If the <failedFolder> tag is omitted, as in the example above, the result data are also stored in the directory that is specified in the <outputFolder> tag in case of a failure. If both the <failedFolder> and the <outputFolder> tags do not exist, no logs r result files are stored. This is used to save space when there are many Jobs and the results of the Job are transferred via the PutResultCommand with the Job status (see JobServer.PutResultCommand).
Example call of a Job (without callback)
The Job can be triggered by calling a URL in the browser (HTTP GET) or via an HTTP Webservice call (HTTP POST). Any key-value pairs can be included in sending via the URL parameter (HTTP GET) or in the Request body (HTTP POST). These are accessed in the job definition via trigger.params. The above example shows the access to the complete parameter map and the dedicated value of the key 'mykey', in this case: '1234'.
The progress page for the generated Job is displayed as the response.
Request | POST /api/jobs/request/WebShopNoOutput HTTP/1.1 |
Content-Type | application/json |
Accept | application/json |
Accept-Encoding | gzip, deflate |
Pragma | no-cache |
Body |
|
Note:
All URL parameters specified are ignored in case of a POST call.
Body |
|
Example query of the Job status
A Job that has been created but not completed can have the following statuses:
- "Queued" = Job is in the queue for execution on a Worker.
- "Running" = Job is being executed on a Worker.
A completed Job can have the following statuses:
- "FinishedSuccessfully" = Job has been completed successfully without errors.
- "FinishedInError" = Job has been completed with errors.
Request | GET /api/jobs/be3e05a5-de59-480e-80a4-181962267a90 HTTP/1.1 |
Accept | application/json |
Accept-Encoding | gzip, deflate |
Pragma | no-cache |
Body | empty |
Response | HTTP/1.1 200 OK |
Content-Type | application/json |
Body |
|
Example of Callback call by Job Server
If a Callback URL is specified when creating the Job, the Job Server calls the URL with a POST when the Job has been completed. The response is ignored.
Request | POST http(s)://callbackurl |
Accept | application/json |
Accept-Encoding | gzip, deflate |
Pragma | no-cache |
Body |
|
Downloading the generated files
The list of generated files of the Job can be sampled by the downloads link contained in the Job status. The individual file is then downloaded through the included file link. The files have to be made known to the Job Server during the Job execution by means of the MarkFileForDownloadCommand.
Request | GET /api/jobs/<jobId>/downloads |
Accept | application/json |
Accept-Encoding | gzip, deflate |
Pragma | no-cache |
Body |
|