Das Tag <webserviceTrigger> umhüllt die Definitionen für einen Trigger, mit dem über eine Webservice-Schnittstelle ein Job gestartet wird. Dieses Tag besitzt keine Attribute.
Erlaubte Unterelemente | Anzahl |
---|---|
outputFolder | 1 |
failedFolder | 1 |
Beispiel einer Jobdefinition auf Basis des Webservice-Triggers:
<?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>
Beschreibung:
Durch weglassen des Tags <failedFolder> wie im obigen Beispiel, werden Ergebnisdaten auch im Fehlerfall in dem Verzeichnis abgelegt, das im Tag <outputFolder> angegeben ist. Fehlt sowohl das Tag <failedFolder>, als auch das Tag <outputFolder>, werden keinerlei Logs oder Ergebnisdateien abgelegt. Dies wird verwendet, um Platz zu sparen, wenn viele Jobs anfallen und die Ergebnisse des Jobs über das PutResultCommand mit dem Job-Status übergeben werden (siehe JobServer.PutResultCommand).
Beispielaufruf eines Jobs (ohne Callback)
Der Job kann über den Aufruf einer URL im Browser (HTTP GET) oder über einen HTTP-Webservice-Aufruf (HTTP POST) ausgelöst werden. Dabei können beliebige Schlüssel-Wert-Paare über URL-Parameter (HTTP GET) bzw. im Request-Body (HTTP POST) mitgesendet werden. Auf diese wird in der Job-Definition über trigger.params zugegriffen. Das obige Beispiel zeigt den Zugriff auf die gesamte Parameter-Map und den dedizierten Wert des Schlüssels 'mykey', hier: '1234'.
Als Antwort wird die Fortschrittsseite für den erzeugen Job angezeigt.
Request | POST /api/jobs/request/WebShopNoOutput HTTP/1.1 |
Content-Type | application/json |
Accept | application/json |
Accept-Encoding | gzip, deflate |
Pragma | no-cache |
Body |
|
Hinweis:
Bei einem POST-Aufruf werden alle angegebenen URL-Parameter ignoriert.
Body |
|
Beispielabfrage des Job-Status
Ein angelegter, noch nicht abgeschlossener Job kann folgende Zustände haben:
- "Queued" = Job ist in der Warteschlange für die Ausführung auf einem Worker.
- "Running" = Job wird auf einem Worker ausgeführt.
Ein abgeschlossener Job kann folgende Zustände einnehmen:
- "FinishedSuccessfully" = Job ist erfolgreich ohne Fehler beendet worden.
- "FinishedInError" = Job ist abgeschlossen und hatte Fehler.
Beispiel GET-Aufruf des Job Servers für einen laufenden Job:
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 |
|
Beispielaufruf des Callbacks durch den Job Server
Wird beim Anlegen des Jobs eine Callback-URL angegeben, ruft der Job Server bei Fertigstellung des Jobs die URL mit einem POST auf. Die Antwort wird ignoriert.
Request | POST http(s)://callbackurl |
Accept | application/json |
Accept-Encoding | gzip, deflate |
Pragma | no-cache |
Body |
|
Download der erzeugten Dateien
Über den, im Job-Status enthaltenen, Link downloads kann die Liste der erzeugten Dateien des Jobs abgefragt werden. Die einzelne Datei wird dann über den enthaltenen file-Link heruntergeladen. Die Dateien müssen während der Job-Ausführung mittels MarkFileForDownloadCommand dem Job Server bekanntgegeben werden.
Request | GET /api/jobs/<jobId>/downloads |
Accept | application/json |
Accept-Encoding | gzip, deflate |
Pragma | no-cache |
Body |
|