Stapel-REST-API
WebSphere Application Server Liberty enthält eine REST-konforme Verwaltungsschnittstelle, mit Sie Ihre Stapeljobs verwalten können.
Die den Stapeljobs zugeordneten Basisoperationen sind das Übergeben (Starten), Stoppen, erneute Starten und das Anzeigen des Status. Sie können diese Operationen mit jedem HTTP-REST-Client durchführen. Daten, die als Teil einer Anforderung abgeschickt oder als Teil einer Antwort zurückgegeben werden, sind in JSON formatiert.
Die folgenden Beispiele zeigen die Funktionen, die Sie mit der REST-API ausführen können.
- REST-API mit einer Benutzer-ID, die ausschließlich ein Übergebender ist
- Jobinstanzen
- Jobausführungen
- Schrittausführungen
- Jobprotokolle
- HTTP-Rückgabecodes
- STOP-Anforderungen in einer verteilten Serverstapelumgebung
- JOBLOGS-Anforderungen in einer verteilten Serverstapelumgebung
- Löschanforderungen in einer verteilten Serverstapelumgebung
REST-API mit einer Benutzer-ID, die ausschließlich ein Übergebender ist
Die von den GET-URLs ("read") zurückgegebenen Ergebnisse werden gefiltert, wenn die Benutzer-ID, die die REST-API über HTTPS aufruft, ausschließlich Zugriff auf die Rolle batchSubmitter hat. Der Übergebende sieht nur die Instanz- und Ausführungsdaten, die Jobinstanzen zugeordnet sind, die vom Übergebenden übergeben wurden. Im Gegensatz dazu können Benutzer-IDs mit Zugriff auf die Rollen batchAdmin und batchMonitor alle Instanz- und Ausführungsdaten (die von einer bestimmten URL mit einem bestimmten Parametersatz zurückgegeben wurden) anzeigen.
Eine Benutzer-ID, die ausschließlich Zugriff auf die Rolle batchSubmitter hat, sieht Ergebnisse, die zunächst anhand der Standardparameter gemäß der Dokumentation der angegebenen URL gefiltert und danach so gefiltert wurden, dass nur Instanz- und Ausführungsdaten zurückgegeben werden, die Jobinstanzen zugeordnet sind, die vom Übergebenden selbst übergeben wurden.
Weitere Informationen finden Sie unter Liberty-Stapelumgebung sichern.
Jobinstanzen
- GET /ibm/api/batch/jobinstances/
- Dieser URI gibt eine Liste der Jobinstanzen zurück. Gültige Abfrageparameter:
- page=[Seitenzahl]: Gibt an, welche Seite (d. h. welche Untermenge an Datensätzen) zurückgegeben werden soll. Der Standardwert ist 0.
- pageSize=[Anzahl Datensätze pro Seite]: Gibt die Anzahl der Datensätze pro Seite an. Der Standardwert ist "50".
- Beispielanforderungen:
https://localhost:9443/ibm/api/batch/jobinstances
https://localhost:9443/ibm/api/batch/jobinstances?page=13&pagesize=20
- Beispielantwort:
[ { "jobName":"test_sleepyBatchlet", "instanceId":7, "appName":"SimpleBatchJob#SimpleBatchJob.war", "submitter":"bob", "batchStatus":"COMPLETED", "jobXMLName":"test_sleepyBatchlet", "instanceState":"COMPLETED", "_links":[ { "rel":"self", "href":"https://localhost:9443/ibm/api/batch/jobinstances/7" }, { "rel":"job logs", "href":"https://localhost:9443/ibm/api/batch/jobinstances/7/joblogs" } ] }, { "jobName":"test_sleepyBatchlet", "instanceId":6, "appName":"SimpleBatchJob#SimpleBatchJob.war", "submitter":"bob", "batchStatus":"COMPLETED", "jobXMLName":"test_sleepyBatchlet", "instanceState":"COMPLETED", "_links":[ { "rel":"self", "href":"https://localhost:9443/ibm/api/batch/jobinstances/6" }, { "rel":"job logs", "href":"https://localhost:9443/ibm/api/batch/jobinstances/6/joblogs" } ] } ]
- GET /ibm/api/batch/v2/jobinstances/
- Dieser URI gibt eine mit den folgenden Abfrageparametern gefilterte Liste mit Jobinstanzen zurück:
- jobInstanceId=[Instanz-ID]:[Instanz-ID]: Gibt Jobinstanzen zurück, die im Instanz-ID-Bereich liegen.
- jobInstanceId=>[Instanz-ID]: Gibt Jobinstanzen zurück, die der angegebenen Instanz-ID entsprechen und deren IDs größer als diese ID sind.
- jobInstanceId=<[Instanz-ID]: Gibt Jobinstanzen zurück, die der angegebenen Instanz-ID entsprechen und deren IDs kleiner als diese ID sind.
- jobinstanceId=[Instanz-ID],[Instanz-ID],[Instanz-ID]: Gibt die angegebenen Jobinstanzen zurück.
- createTime=[jjjj-MM-tt]:[jjj-MM-tt]: Gibt Jobinstanzen zurück, die im Datumsbereich (einschließlich) liegen.
- createTime=[jjjj-MM-tt]: Gibt Jobinstanzen mit dem angegebenen Datum zurück.
- createTime=>3d: Gibt Jobinstanzen zurück, die an oder nach dem Tag erstellt wurden, der drei Tage zurückliegt. createTime ist beispielsweise ein Datum, das nach dem Anfang des Tages liegt oder dem Tag entspricht, der drei Tage zurückliegt.
- createTime=<3d: Gibt Jobinstanzen zurück, die an oder vor dem Tag erstellt wurden, der drei Tage zurückliegt. createTime ist beispielsweise ein Datum, das vor dem Ende des Tages liegt oder dem Tag entspricht, der drei Tage zurückliegt.
- instanceState=[Status],[Status]: Gibt die Jobinstanzen mit dem angegebenen Status zurück. Die folgenden Instanzstatus sind gültig: SUBMITTED, JMS_QUEUED, JMS_CONSUMED, DISPATCHED, FAILED, STOPPED, COMPLETED und ABANDONED.
- exitStatus=[Zeichenfolge]: Gibt Jobinstanzen zurück, die der Exitstatuszeichenfolge entsprechen. In den Zeichenfolgekriterien kann der Platzhalteroperator (*) an beliebiger Stelle verwendet werden.
- page=[Seitenzahl]: Gibt an, welche Seite (d. h. welche Untermenge an Datensätzen) zurückgegeben werden soll. Der Standardwert ist 0.
- pageSize=[Anzahl Datensätze pro Seite]: Gibt die Anzahl der Datensätze pro Seite an. Der Standardwert ist "50".
Anmerkung: Die Rolle der Standardzeitzone des Servers in Abfragen unter Einbeziehung von createTimeWenn Sie einen Job übergeben, wird die Erstellungszeit (createTime) für die Jobinstanz im Job-Repository gespeichert und in UTC normalisiert. Wenn Daten im Format "jjjj-MM-tt" wie in createTime=[jjjj-MM-tt] oder createTime=[jjjj-MM-tt]:[jjj-MM-tt]: angegeben werden, müssen Sie die Datumszeichenfolge im Format "jjjj-MM-tt" in einen bestimmten Bereich von UTC-Zeiten für den Abgleich mit den createTime-Werten in den Jobinstanztabellendatensätzen umwandeln. Hierzu verwendet die Anwendung die Standardzeitzone des Servers, der die REST-Anforderung bearbeitet. Die Zeitzone dieses Servers wird zum Umwandeln der Datumszeichenfolge in einen UTC-Zeitbereich verwendet, der für den Abgleich verwendet wird.
In der folgenden Tabelle sind die von den Abfrageparametern jobInstanceId=10:13 zurückgegebenen Daten beschrieben.
*Da die Erstellungszeit (createTime) im Job-Repository in einem UTC-Format gespeichert wird, müssen Sie verstehen, dass die Tabellendaten die mit der Standardzeitzone eines bestimmten Servers, z. B. "server1", formatierte Erstellungszeit (createTime) zeigen. Würde man eine ähnliche Tabelle aus der Perspektive eines zweiten Servers mit einer anderen Standardzeitzone (als die von "server1") erstellen, enthielte diese andere Spaltenwerte für CREATETIME mit der entsprechenden zeitzonenbasierten Differenz. In den nachfolgenden Beispielen wird die Standardzeitzone des Servers verwendet, der die REST-Anforderung bearbeitet, um Parameter für die Datumszeichenfolge im Format "jjjj-MM-tt" UTC-Erstellungszeitwerten in der Datenbank zuzuordnen.JOBINSTANCEID CREATETIME(* in der Zeitzone von server1) INSTANCESTATE EXITSTATUS 10 11-05-2015.01:10:00 COMPLETED SUCCESS 11 11-08-2014.02:20:00 COMPLETED SUCCESS 12 11-10-2015.03:30:00 FAILED FAILURE 13 11-11-2015:04:40:00 COMPLETED SUCCESS Die folgenden Befehle geben, unabhängig davon, auf welchem Server sie abgesetzt werden, dasselbe Ergebnis zurück:- jobInstanceId=11:13 gibt die JOBINSTANCEID-Werte 11, 12 und 13 zurück.
- jobInstanceId=>12 gibt die JOBINSTANCEID-Werte 12 und 13 zurück.
- jobInstanceId=<12 gibt die JOBINSTANCEID-Werte 11 und 12 zurück.
- jobInstanceId=11,12 gibt die JOBINSTANCEID-Werte 11 und 12 zurück.
- instanceState=FAILED gibt die JOBINSTANCEID 12 zurück.
- exitStatus=SUCCESS gibt die JOBINSTANCEID-Werte 10, 11 und 13 zurück.
Die folgenden Befehle geben möglicherweise andere Ergebnisse auf Servern mit unterschiedlichen Standardzeitzonen zurück. In diesen Beispiel werden sie auf "server1" (demselben Server, der zum Erstellen der vorherigen Tabelle verwendet wurde) mit dem Datum und der Uhrzeit "11-11-2015:07:00:00" in der Standardzeitzone des Servers abgesetzt.- createTime=>2d gibt die JOBINSTANCEID-Werte 12 und 13 (an dem Tag oder nach dem Tag, der zwei Tage zurückliegt, d. h. 11-09-2015) zurück.
- createTime=<2d gibt die JOBINSTANCEID-Werte 10 und 11 (an dem Tag oder vor dem Tag, der zwei Tage zurückliegt, d. h. 11-09-2015) zurück.
- createTime=2015-11-08:2015-11-11 gibt Datensätze mit den JOBINSTANCEID-Werten 11,12 und 13 zurück.
- createTime=2015-11-10 gibt den Datensatz mit der JOBINSTANCEID 12 zurück.
- Beispielanforderungen:
https://localhost:9443/ibm/api/batch/v2/jobinstances?jobInstanceId=20:50 https://localhost:9443/ibm/api/batch/jobinstances?createTime=>2d https://localhost:9443/ibm/api/batch/v2/jobinstances?jobInstanceId=4,12,17&instanceState=COMPLETED https://localhost:9443/ibm/api/batch/v2/jobinstances?jobInstanceId=4500:4600&createTime=2015-11-27&instanceState=COMPLETED&exitStatus=*JOB*&page=0&pageSize=1000
GET /ibm/api/batch/v3/jobinstances/
Zusätzlich zu allen Funktionen des GET-URI /ibm/api/batch/v2/job instances/ gibt dieser URI eine mit den folgenden Abfrageparametern gefilterte Liste mit Jobinstanzen zurück:
- lastUpdatedTime=[jjjj-MM-tt]: Gibt Jobinstanzen zurück, die zuletzt an dem angegebenen Datum aktualisiert wurden. Dieser Zeitwert wird bei Instanzstatusübergängen aktualisiert. Beispiel: Wechsel vom Status SUBMITTED in DISPATCHED.
- jobParameter.[Parametername]=[Parameterwert]: Gibt Jobinstanzen mit Ausführungen zurück, bei denen das angegebene Name-Wert-Paar als Jobparameter angegeben ist. Beispiel: jobParameter.jesJobName=myJobName.In den Zeichenfolgekriterien kann der Platzhalteroperator (*) an beliebiger Stelle verwendet werden.
- sort=[Zeichenfolge],[Zeichenfolge]: Gibt den Parameter oder die Parameter an, nach denen die Ergebnisse sortiert werden sollen. Die Angabe des Zeichens - als Präfix für den Parameter gibt an, dass die Sortierung in absteigender Reihenfolge erfolgt. Die Angabe sort=submitter sortiert beispielsweise die Ergebnisse nach Übergebendem in aufsteigender Reihenfolge. Die Angabe sort=submitter,-lastUpdatedTime sortiert die Ergebnisse zuerst nach Übergebendem und anschließend nach lastUpdatedTime in absteigender Reihenfolge.
GET /ibm/api/batch/v4/jobinstances/
Zusätzlich zu allen Funktionen des GET-URI /ibm/api/batch/v3/job instances/ gibt dieser URI eine mit den folgenden Abfrageparametern gefilterte Liste mit Jobinstanzen zurück:
- submitter=[Benutzer]: Gibt alle Jobinstanzen zurück, die vom angegebenen Benutzer übergeben wurden. In den Zeichenfolgekriterien kann der Platzhalteroperator (*) an beliebiger Stelle verwendet werden.
- appName=[Name]: Gibt alle Jobinstanzen mit dem angegebenen Anwendungsnamen zurück. Dies kann der einfache Anwendungsname oder der vollständige Name, der sich aus Anwendung, Modul und Komponente zusammensetzt, sein. Die Suche nach MeineAnw oder MeineAnwp#MeineAnw.war gibt beispielsweise eine Jobinstanz mit dem Anwendungsnamen MeineAnw und dem Modulnamen MeineAnw.war zurück. In den Zeichenfolgekriterien kann der Platzhalteroperator (*) an beliebiger Stelle verwendet werden.
- jobName=[Name]: Gibt alle Jobinstanzen mit dem angegebenen Jobnamen zurück. In den Zeichenfolgekriterien kann der Platzhalteroperator (*) an beliebiger Stelle verwendet werden.
- ignoreCase=true: Standardmäßig wird bei allen Textabgleichen die Groß-/Kleinschreibung beachtet. Wenn Sie diese Option angeben, wird die Groß-/Kleinschreibung bei allen Textsuchen nicht beachtet.
- lastUpdatedTime=[yyyy-MM-dd]:[yyyy-MM-dd]: Gibt Jobinstanzen zurück, die zuletzt im angegebenen Datumsbereich aktualisiert wurden.
- lastUpdatedTime=>3d: Gibt Joobinstanzen zurück, die an oder nach dem Tag, der drei Tage zurückliegt, aktualisiert wurden. lastUpdatedTime ist beispielsweise ein Datum, das nach dem Anfang des Tages liegt oder dem Tag entspricht, der drei Tage zurückliegt.
- lastUpdatedTime=<3d: Gibt Joobinstanzen zurück, die an oder vor dem Tag, der drei Tage zurückliegt, aktualisiert wurden. lastUpdatedTime ist beispielsweise ein Datum, das vor dem Ende des Tages liegt oder dem Tag entspricht, der drei Tage zurückliegt.
Anmerkung: Die Parameter appName, exitStatus, jobName und submitter können mehrfach angewendet werden. Das Ergebnis enthält alle Jobinstanzen, die einem der angegebenen Werte entsprechen. Wenn Sie beispielsweise jobinstances?submitter=Alice&submitter=Bob angeben, werden alle Jobinstanzen zurückgegeben, die von Alice oder von Bob übergeben wurden.- GET /ibm/api/batch/jobinstances/Jobinstanz-ID
- Dieser URI gibt detaillierte Informationen zur angegebenen Jobinstanz zurück, beispielsweise alle Ausführungen einer angegebenen Jobinstanz. Die Ergebnisse werden in der Reihenfolge vom neuesten zum ältesten Eintrag zurückgegeben. Das neueste Ergebnis wird in der Liste als Erstes angezeigt.
- Beispielantwort:
{ "jobName":"test_sleepyBatchlet", "instanceId":7, "appName":"SimpleBatchJob#SimpleBatchJob.war", "submitter":"bob", "batchStatus":"COMPLETED", "jobXMLName":"test_sleepyBatchlet", "instanceState":"COMPLETED", "_links":[ { "rel":"self", "href":"https://localhost:9443/ibm/api/batch/jobinstances/7" }, { "rel":"job logs", "href":"https://localhost:9443/ibm/api/batch/jobinstances/7/joblogs" }, { "rel":"job execution", "href":"https://localhost:9443/ibm/api/batch/jobinstances/7/jobexecutions/7" } ] }
- POST /ibm/api/batch/jobinstances/
- Verwenden Sie diesen URI, um einen neuen Job zu übergeben (zu starten). Das folgende Beispiel zeigt den Anforderungshauptteil zum Übergeben eines Jobs, der im JSON-Format in einem WAR-Modul gepackt ist:
{ "applicationName" : "SimpleBatchJob", "moduleName" : "SimpleBatchJob.war", "jobXMLName" : "test_batchlet_jsl", "jobParameters" : { "prop1" : "prop1value", "prop2" : "prop2value"} }
Das folgende Beispiel zeigt den Anforderungshauptteil zum Übergeben eines Jobs, der im JSON-Format in einem EJB-Modul gepackt ist:{ "applicationName" : "SimpleBatchJob", "moduleName" : "SimpleBatchJobEJB.jar", "componentName" : "MyEJB", "jobXMLName" : "test_batchlet_jsl", "jobParameters" : { "prop1" : "prop1value", "prop2" : "prop2value"} }
Die Angabe applicationName gibt den Namen der Stapelanwendung an. Diese Angabe ist erforderlich, sofern nicht mit moduleName der Modulname angegeben wird. In diesem Fall würde der Anwendungsname vom Modulnamen abgeleitet werden, indem das Suffix .war oder .jar des Modulnamens abgeschnitten wird. Wenn Sie beispielsweise keinen Anwendungsnamen (applicationName) angeben und moduleName=SimpleBatchJob.war festlegen, dann wird als Anwendungsname standardmäßig SimpleBatchJob verwendet.
Der Modulname (moduleName) gibt das Modul in der Stapelanwendung an, in dem die Jobartefakte, z. B. JSL, enthalten sind. Der Job wird unter dem Komponentenkontext des Moduls abgeschickt. Die Angabe moduleName muss angegeben werden, sofern nicht applicationName angegeben wird. In diesem Fall würde der Modulname vom Anwendungsnamen abgeleitet werden, indem das Suffix .war an den Anwendungsnamen angehängt wird. Wenn Sie beispielsweise applicationName=SimpleBatchJob festlegen und keinen Modulnamen angeben, wird als Modulname standardmäßig SimpleBatchJob.war verwendet.
Die Angabe componentName gibt die EJB-Komponente im EJB-Modul der Stapelanwendung an. Wenn der Komponentenname angegeben ist, wird der Job unter dem Komponentenkontext der EJB abgeschickt.Anmerkung: Der Komponentenname ist nur dann erforderlich, wenn es sich bei dem Modul um ein EJB-Modul handelt. Wenn das Modul ein WAR-Modul ist, ist der Komponentenname nicht erforderlich.Sie müssen einen Wert für jobXMLName angeben. Der Wert für jobParameters ist optional.
- Anstatt die in Ihrer Stapelanwendung unter META-INF/batch-jobs gepackte JSL-Jobdefinition zu verwenden, können Sie Ihre JSL integriert, im Rahmen der REST-Jobübergabeanforderung
übergeben. Die integriert übergebene JSL überschreibt die mit der Stapelanwendung gepackte JSL.
Für die Inline-Übergabe der JSL in der HTTP-Anforderung stehen die folgenden beiden Methoden zur Verfügung:
- Schließen Sie Ihre JSL als JSON-Eigenschaft in Ihre Jobübergabeanforderung ein. Fügen Sie die Eigenschaft
jobXML dem JSON-Objekt hinzu und fügen Sie den gesamten Inhalt der JSL-Datei in Form einer JSON-Zeichenfolge
als Wert der Eigenschaft hinzu. Anmerkung: Sie müssen die XML-Zeichenfolge ordnungsgemäß mit Escapezeichen versehen, damit sie von einem JSON-Parser geparst werden kann. Die meisten JSON-Bibliotheken tun dies automatisch.Das folgende Beispiel zeigt den Anforderungshauptteil für die Übergabe eines Jobs, der eine einteilige HTTP-Anforderung verwendet, bei der die JSL integriert von der JSON übergeben wird.
{ "applicationName" : "SimpleBatchJob", "jobXMLName":"test_multiPartition_3Steps", "jobXML":"<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?> \r\n<job id=\"test_multiPartition_3Steps\" xmlns=\"http://xmlns.jcp.org/xml/ns/javaee\"r\n\tversion=\"1.0> \r\n\t<step id=\"step1"\" next=\"step2\"> \r\n\t\t<batchlet ref=\"simpleBatchlet\"/> \r\n\t\t<partition>\r\n\t\t\t<plan partitions=\"3\"/> \r\n\t\t</partition>\r\n\t</step> \r\n\t<step id=\"step2\" next=\"step3\"> \r\n\t\t<batchlet ref=\"simpleBatchlet\" /> \r\n\t\t<partition>\r\n\t\t\t<plan partitions=\"3\" /> \r\n\t\t</partition>\r\n\t</step>\r\n\t<step id=\"step3\"> \r\n\t\t<batchlet ref=\"simpleBatchlet\" />\r\n\t\t<partition> \r\n\t\t\t<plan partitions=\"3\"/> \r\n\t\t</partition>\r\n\t</step>\r\n</job>" }
Anmerkung: Das Feld jobXML muss von einem JSON-Parser geparst und mit Marshalling in ein gültiges JSON-Objekt umgewandelt werden. Das Feld jobXMLName ist optional, da die Job-ID-Informationen in der integrierten JSL für den Jobnamen verwendet werden. - Verwenden Sie ein mehrteiliges HTTP-Formular. Wenn Sie ein mehrteiliges HTTP-Formular verwenden, müssen die JSON-Jobübergabedaten und
XML-Jobdefinition separat im HTTP-Hauptteil übergeben werden. Der JSON-Teil des mehrteiligen Formulars
muss den Namen jobdata und der XML-Teil des Formulars muss den Namen
jsl haben. Bei der Verwendung eines mehrteiligen Formulars muss die XML nicht mit Marshalling in eine JSON-Zeichenfolge umgewandelt werden.
Das folgende Beispiel zeigt die HTTP-Anforderung für die Übergabe eines Jobs, der eine mehrteilige HTTP-Anforderung verwendet, bei der die JSL integriert über den JSL-Nachrichtenteil übergeben wird.
Content-Type: multipart/form-data;boundary=---------------------------49424d5f4a4241544348 -----------------------------49424d5f4a4241544348 Content-Disposition: form-data; name="jobdata" Content-Type: application/json; charset=UTF-8 { "applicationName" : "SimpleBatchJob", "moduleName" : "SimpleBatchJob.war", "jobXMLName" : "test_multiPartition" } -----------------------------49424d5f4a4241544348 Content-Disposition: form-data; name="jsl" Content-Type: application/xml; charset=UTF-8 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <job id="test_multiPartition" xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="1.0"> <step id="step1"> <batchlet ref="simpleBatchlet" /> <partition> <plan partitions="3" /> </partition> </step> </job> -----------------------------49424d5f4a4241544348--
Anmerkung: Das Feld jobXMLName ist optional, da die Job-ID-Informationen in der integrierten JSL für den Jobnamen verwendet werden.
- Schließen Sie Ihre JSL als JSON-Eigenschaft in Ihre Jobübergabeanforderung ein. Fügen Sie die Eigenschaft
jobXML dem JSON-Objekt hinzu und fügen Sie den gesamten Inhalt der JSL-Datei in Form einer JSON-Zeichenfolge
als Wert der Eigenschaft hinzu.
- Das folgende Beispiel zeigt eine erfolgreiche Jobübergabe:
{ "jobName": "test_sleepyBatchlet", "instanceId": 10, "appName": "SimpleBatchJob#SimpleBatchJob.war", "submitter": "bob", "batchStatus": "STARTING", "jobXMLName": "test_sleepyBatchlet", "instanceState": "SUBMITTED", "_links": [ { "rel": "self", "href": "https://localhost:9443/ibm/api/batch/jobinstances/10" }, { "rel": "job logs", "href": "https://localhost:9443/ibm/api/batch/jobinstances/10/joblogs" } ] }
- PUT /ibm/api/batch/jobinstances/Jobinstanz-ID?action=stop
- Verwenden Sie diesen URI, um die letzte Jobausführung, die dieser Jobinstanz zugeordnet ist, zu stoppen, falls sie aktiv ist. Wenn Sie nicht aktiv ist, gibt die API einen Fehler zurück.
- PUT /ibm/api/batch/jobinstances/Jobinstanz-ID?action=restart
- Verwenden Sie diesen URI, um die letzte Jobausführung, die dieser Jobinstanz zugeordnet ist, dann zu stoppen, wenn sich diese im Status STOPPED (Gestoppt) oder FAILED (Fehlgeschlagen) befindet. Wenn dieser Instanz keine Jobausführung zugeordnet ist oder wenn die letzte Jobausführung den Status COMPLETED (Beendet) hat, gibt die API einen Fehler zurück.
- PUT /ibm/api/batch/jobinstances/Jobinstanz-ID?action=restart&reusePreviousParams=true
- Verwenden Sie diesen URI, um die letzte Jobausführung, die dieser Jobinstanz zugeordnet ist,
erneut zu starten und die Jobparameter aus der vorherigen Ausführung wiederzuverwenden.
Die vorherige Ausführung muss den Status
STOPPED (Gestoppt) oder
FAILED (Fehlgeschlagen) haben. Wenn dieser Instanz keine Jobausführung zugeordnet ist oder wenn die letzte
Jobausführung den Status COMPLETED (Beendet) hat, gibt die API einen Fehler zurück.
Beachten Sie, dass
reusePreviousParams eine optionale Einstellung ist. Die Standardeinstellung ist
reusePreviousParams=false.Anmerkung: Wenn die Einstellung reusePreviousParams=true verwendet wird, haben die Jobparameter, die als Teil der aktuellen Neustartanforderungen übergeben werden, Vorrang vor den vorher angegebenen Jobparametern. Aktuelle Parameter haben Vorrang vor vorherigen Jobparametern mit demselben Schlüsselnamen.
- DELETE /ibm/api/batch/jobinstances/Jobinstanz-ID
- Dieser URI löscht alle Datenbankeinträge und Jobprotokolle, die dieser Jobinstanz zugeordnet sind.
Diese
API gibt einen Fehler zurück, wenn der Jobinstanz aktive Jobausführungen zugeordnet sind. Wenn beim Löschen der Jobprotokolle ein Fehler auftritt,
wird nicht versucht, die Jobinstanzdaten aus der Jobspeicherdatenbank zu löschen.
Gültige Abfrageparameter:
- purgeJobStoreOnly=true|false: Wenn die Einstellung purgeJobStoreOnly=true
verwendet wird, wird nicht versucht, die dieser Jobinstanz zugeordneten Jobprotokolle zu löschen. Die Standardeinstellung ist
purgeJobStoreOnly=false. Diese
API gibt einen Fehler zurück, wenn der Jobinstanz aktive Jobausführungen zugeordnet sind. Anmerkung: Es wird keine Antwortnachricht für den Löschvorgang zurückgegeben, wenn Sie die API für Einzellöschvorgänge verwenden.
- purgeJobStoreOnly=true|false: Wenn die Einstellung purgeJobStoreOnly=true
verwendet wird, wird nicht versucht, die dieser Jobinstanz zugeordneten Jobprotokolle zu löschen. Die Standardeinstellung ist
purgeJobStoreOnly=false. Diese
API gibt einen Fehler zurück, wenn der Jobinstanz aktive Jobausführungen zugeordnet sind.
- DELETE /ibm/api/batch/v2/jobinstances/
- Dieser URI löscht alle Datenbankeinträge und Jobprotokolle, die den mit den folgenden Löschfilterparametern zurückgegebenen Jobinstanzen zugeordnet sind:
Anmerkung: Es wird empfohlen, die GET-Schnittstelle zu verwenden, um die Jobs aufzulisten und zu überprüfen, ob es sich um die richtigen zu löschenden Jobs handelt, bevor die DELETE-Schnittstelle zum Löschen ausgeführt wird.
- page=[Seitenzahl]: Gibt an, welche Seite (d. h. welche Untermenge an Datensätzen) zurückgegeben werden soll. Der Standardwert ist "0".
- pageSize=[Anzahl Datensätze pro Seite]: Gibt die Anzahl der Datensätze pro Seite an. Der Standardwert ist "50".
- purgeJobStoreOnly=true|false: Wenn die Einstellung "purgeJobStoreOnly=true" verwendet wird, wird nicht versucht, die dieser Jobinstanz zugeordneten Jobprotokolle zu löschen. Die Standardeinstellung ist "purgeJobStoreOnly=false". Diese API gibt einen Fehler zurück, wenn der Jobinstanz aktive Jobausführungen zugeordnet sind.
- jobInstanceId=[Instanz-ID]:[Instanz-ID]: Löscht Jobinstanzen, die im Instanz-ID-Bereich liegen.
- jobInstanceId=>[Instanz-ID]: Löscht Jobinstanzen, die der angegebenen Instanz-ID entsprechen und deren IDs größer als diese ID sind.
- jobInstanceId=<[Instanz-ID]: Löscht Jobinstanzen, die der angegebenen Instanz-ID entsprechen und deren IDs kleiner als diese ID sind.
- jobinstanceId=[Instanz-ID],[Instanz-ID],[Instanz-ID]: Löscht die angegebenen Jobinstanzen.
- createTime=[jjjj-MM-tt]:[jjj-MM-tt]: Gibt Jobinstanzen zurück, die im Datumsbereich (einschließlich) liegen.
- createTime=[jjjj-MM-tt]: Gibt Jobinstanzen mit dem angegebenen Datum zurück.
- createTime=>3d: Gibt Jobinstanzen zurück, die an oder nach dem Tag erstellt wurden, der drei Tage zurückliegt. createTime ist beispielsweise ein Datum, das nach dem Anfang des Tages liegt oder dem Tag entspricht, der drei Tage zurückliegt.
- createTime=<3d: Gibt Jobinstanzen zurück, die an oder vor dem Tag erstellt wurden, der drei Tage zurückliegt. createTime ist beispielsweise ein Datum, das vor dem Ende des Tages liegt oder dem Tag entspricht, der drei Tage zurückliegt.
- instanceState=[Status],[Status]: Löscht die Jobinstanzen mit dem angegebenen Status. Die folgenden Instanzstatus sind gültig: SUBMITTED, JMS_QUEUED, JMS_CONSUMED, DISPATCHED, FAILED, STOPPED, COMPLETED und ABANDONED.
- exitStatus=[Zeichenfolge]: Gibt Jobinstanzen zurück, die der Exitstatuszeichenfolge entsprechen. Die Zeichenfolgekriterien können einen Platzhalteroperator (*) an beiden Enden verwenden.
Anmerkung: Standardmäßig werden maximal 50 Datensätze gelöscht, wenn die Parameter "page" und "pageSize" nicht angegeben sind.Anmerkung: Die Rolle der Standardzeitzone des Servers in Abfragen unter Einbeziehung von createTimeWenn Sie einen Job übergeben, wird die Erstellungszeit (createTime) für die Jobinstanz im Job-Repository gespeichert und in UTC normalisiert. Wenn Daten im Format "jjjj-MM-tt" wie in createTime=[jjjj-MM-tt] oder createTime=[jjjj-MM-tt]:[jjj-MM-tt]: angegeben werden, müssen Sie die Datumszeichenfolge im Format "jjjj-MM-tt" in einen bestimmten Bereich von UTC-Zeiten für den Abgleich mit den createTime-Werten in den Jobinstanztabellendatensätzen umwandeln. Hierzu verwendet die Anwendung die Standardzeitzone des Servers, der die REST-Anforderung bearbeitet. Die Zeitzone dieses Servers wird zum Umwandeln der Datumszeichenfolge in einen UTC-Zeitbereich verwendet, der für den Abgleich verwendet wird.
In der folgenden Tabelle sind die von den Abfrageparametern jobInstanceId=10:13 zurückgegebenen Daten beschrieben.
*Da die Erstellungszeit (createTime) im Job-Repository in einem UTC-Format gespeichert wird, müssen Sie verstehen, dass die Tabellendaten die mit der Standardzeitzone eines bestimmten Servers, z. B. "server1", formatierte Erstellungszeit (createTime) zeigen. Würde man eine ähnliche Tabelle aus der Perspektive eines zweiten Servers mit einer anderen Standardzeitzone (als die von "server1") erstellen, enthielte diese andere Spaltenwerte für CREATETIME mit der entsprechenden zeitzonenbasierten Differenz. In den nachfolgenden Beispielen wird die Standardzeitzone des Servers verwendet, der die REST-Anforderung bearbeitet, um Parameter für die Datumszeichenfolge im Format "jjjj-MM-tt" UTC-Erstellungszeitwerten in der Datenbank zuzuordnen.JOBINSTANCEID CREATETIME(* in der Zeitzone von server1) INSTANCESTATE EXITSTATUS 10 11-05-2015.01:10:00 COMPLETED SUCCESS 11 11-08-2014.02:20:00 COMPLETED SUCCESS 12 11-10-2015.03:30:00 FAILED FAILURE 13 11-11-2015:04:40:00 COMPLETED SUCCESS Die folgenden Befehle geben, unabhängig davon, auf welchem Server sie abgesetzt werden, dasselbe Ergebnis zurück:- jobInstanceId=11:13 gibt die JOBINSTANCEID-Werte 11, 12 und 13 zurück.
- jobInstanceId=>12 gibt die JOBINSTANCEID-Werte 12 und 13 zurück.
- jobInstanceId=<12 gibt die JOBINSTANCEID-Werte 11 und 12 zurück.
- jobInstanceId=11,12 gibt die JOBINSTANCEID-Werte 11 und 12 zurück.
- instanceState=FAILED gibt die JOBINSTANCEID 12 zurück.
- exitStatus=SUCCESS gibt die JOBINSTANCEID-Werte 10, 11 und 13 zurück.
Die folgenden Befehle geben möglicherweise andere Ergebnisse auf Servern mit unterschiedlichen Standardzeitzonen zurück. In diesen Beispiel werden sie auf "server1" (demselben Server, der zum Erstellen der vorherigen Tabelle verwendet wurde) mit dem Datum und der Uhrzeit "11-11-2015:07:00:00" in der Standardzeitzone des Servers abgesetzt.- createTime=>2d gibt die JOBINSTANCEID-Werte 12 und 13 (an dem Tag oder nach dem Tag, der zwei Tage zurückliegt, d. h. 11-09-2015) zurück.
- createTime=<2d gibt die JOBINSTANCEID-Werte 10 und 11 (an dem Tag oder vor dem Tag, der zwei Tage zurückliegt, d. h. 11-09-2015) zurück.
- createTime=2015-11-08:2015-11-11 gibt Datensätze mit den JOBINSTANCEID-Werten 11,12 und 13 zurück.
- createTime=2015-11-10 gibt den Datensatz mit der JOBINSTANCEID 12 zurück.
- Beispielantwort:
[{"instanceId":394,"purgeStatus":"COMPLETED","message":"Successful purge.","redirectUrl":""}, {"instanceId":395,"purgeStatus":"COMPLETED","message":"Successful purge.","redirectUrl":""}, {"instanceId":396,"purgeStatus":"COMPLETED","message":"Successful purge.","redirectUrl":""}, {"instanceId":397,"purgeStatus":"COMPLETED","message":"Successful purge.","redirectUrl":""}, {"instanceId":398,"purgeStatus":"COMPLETED","message":"Successful purge.","redirectUrl":""}]
- Die folgenden purgeStatus-Werte können zurückgegeben werden:
- COMPLETED
- Gibt an, dass der Job erfolgreich gelöscht wurde.
- FAILED
- Gibt an, dass das Löschen des Jobs fehlgeschlagen ist.
- STILL_ACTIVE
- Gibt an, dass das Löschen des Jobs fehlgeschlagen ist, weil der Job noch aktiv war.
- JOBLOGS_ONLY
- Gibt an, dass die Datenbankbereinigung fehlgeschlagen ist, die Jobprotokolle aber erfolgreich gelöscht wurden.
- NOT_LOCAL
- Gibt an, dass das Löschen des Jobs fehlgeschlagen ist, weil es sich nicht um einen lokalen Job handelt.
Jobausführungen
- GET /ibm/api/batch/jobexecutions/Jobausführungs-ID
- Dieser URI gibt detaillierte Informationen zu einer angegebenen Jobausführung zurück sowie Links zu zugehörigen Schrittausführungen und Jobprotokollen.
- Beispielanforderung:
https://localhost:9443/ibm/api/batch/jobexecutions/9
- Beispielantwort:
{ "jobName":"test_sleepyBatchlet", "executionId":9, "instanceId":9, "batchStatus":"COMPLETED", "exitStatus":"COMPLETED", "createTime":"2015/05/07 16:09:41.025 -0400", "endTime":"2015/05/07 16:09:52.127 -0400", "lastUpdatedTime":"2015/05/07 16:09:52.127 -0400", "startTime":"2015/05/07 16:09:41.327 -0400", "jobParameters":{ }, "restUrl":"https://localhost:9443/ibm/api/batch", "serverId":"localhost/C:/ibm/RAD_workspaces/Liberty7/build.image/wlp/usr/server1", "logpath":"C:\\ibm\\Liberty\\wlp\\usr\\servers\\server1\\logs\\joblogs\\test_sleepyBatchlet\\2015-05-07\\instance.9\\execution.9\\", "stepExecutions":[ { "stepExecutionId":9, "stepName":"step1", "batchStatus":"COMPLETED", "exitStatus":"SleepyBatchlet:i=10;stopRequested=false", "stepExecution":"https://localhost:9443/ibm/api/batch/jobexecutions/9/stepexecutions/step1" } ], "_links":[ { "rel":"self", "href":"https://localhost:9443/ibm/api/batch/jobexecutions/9" }, { "rel":"job instance", "href":"https://localhost:9443/ibm/api/batch/jobinstances/9" }, { "rel":"step executions", "href":"https://localhost:9443/ibm/api/batch/jobexecutions/9/stepexecutions" }, { "rel":"job logs", "href":"https://localhost:9443/ibm/api/batch/jobexecutions/9/joblogs" }, { "rel":"stop url", "href":"https://localhost:9443/ibm/api/batch/jobexecutions/9?action=stop" } ] }
- GET /ibm/api/batch/jobexecutions/Jobausführungs-ID/jobinstance
- Dieser URI gibt ausführliche Informationen zu der Jobinstanz der angegebenen Jobausführung zurück.
- GET /ibm/api/batch/jobinstances/Jobinstanz-ID/jobexecutions
- Dieser URI gibt ausführliche Informationen zu den Jobausführungen für eine angegebene Jobinstanz zurück. Dazu gehören Links zu zugeordneten Jobausführungen und Jobprotokollen.
- GET /ibm/api/batch/jobinstances/Jobausführungs-ID/jobexecutions/Folgenummer der Jobausführung
- Dieser URI gibt ausführliche Informationen zu der angegebenen Jobausführung für die angegebene Jobinstanz-ID zurück.
Dazu gehören Links zu zugeordneten Jobausführungen und Jobprotokollen. Anmerkung: Die Folgenummer der Jobausführung bezieht sich auf die nullte, erste, zweite usw. Jobausführung für die angegebene Jobinstanz.
- PUT /ibm/api/batch/jobexecutions/Jobausführungs-ID?action=stop
- Verwenden Sie diesen URI, um die angegebene aktive Jobausführung zu stoppen. Die erforderlichen Parameter sind "action = stop, restart".
- PUT /ibm/api/batch/jobexecutions/Jobausführungs-ID?action=restart
- Verwenden Sie diesen URI, um die angegebene aktive Jobausführung erneut zu starten. Die erforderlichen Parameter sind "action = stop, restart".
Schrittausführungen
- GET /ibm/api/batch/jobexecutions/Jobausführungs-ID/stepexecutions
- Dieser URI gibt ein JSON-Array mit allen Details der Schrittausführung für die angegebene Jobausführung zurück. Wenn Ihr Job einen partitionierten Schritt enthält, werden die Partitionsinformationen in jedem Schritt aufgelistet.
- Beispielanforderung:
https://localhost:8020/ibm/api/batch/jobexecutions/40/stepexecutions
- Das folgende Beispiel zeigt eine Antwort für einen partitionierten Schritt.
[ { "stepExecutionId":47, "executionId":39, "instanceId":35, "stepName":"step1", "batchStatus":"COMPLETED", "startTime":"2015/03/30 11:10:08.652 -0400", "endTime":"2015/03/30 11:10:09.817 -0400", "exitStatus":"COMPLETED", "metrics":{ "READ_COUNT":"0", "WRITE_COUNT":"0", "COMMIT_COUNT":"0", "ROLLBACK_COUNT":"0", "READ_SKIP_COUNT":"0", "PROCESS_SKIP_COUNT":"0", "FILTER_COUNT":"0", "WRITE_SKIP_COUNT":"0" }, "partitions":[ { "partitionNumber":0, "batchStatus":"COMPLETED", "startTime":"2015/03/30 11:10:09.579 -0400", "endTime":"2015/03/30 11:10:09.706 -0400", "exitStatus":"step1", "metrics":{ "READ_COUNT":"0", "WRITE_COUNT":"0", "COMMIT_COUNT":"0", "ROLLBACK_COUNT":"0", "READ_SKIP_COUNT":"0", "PROCESS_SKIP_COUNT":"0", "FILTER_COUNT":"0", "WRITE_SKIP_COUNT":"0" } }, { "partitionNumber":1, "batchStatus":"COMPLETED", "startTime":"2015/03/30 11:10:09.257 -0400", "endTime":"2015/03/30 11:10:09.302 -0400", "exitStatus":"step1", "metrics":{ "READ_COUNT":"0", "WRITE_COUNT":"0", "COMMIT_COUNT":"0", "ROLLBACK_COUNT":"0", "READ_SKIP_COUNT":"0", "PROCESS_SKIP_COUNT":"0", "FILTER_COUNT":"0", "WRITE_SKIP_COUNT":"0" } }, { "partitionNumber":2, "batchStatus":"COMPLETED", "startTime":"2015/03/30 11:10:09.469 -0400", "endTime":"2015/03/30 11:10:09.548 -0400", "exitStatus":"step1", "metrics":{ "READ_COUNT":"0", "WRITE_COUNT":"0", "COMMIT_COUNT":"0", "ROLLBACK_COUNT":"0", "READ_SKIP_COUNT":"0", "PROCESS_SKIP_COUNT":"0", "FILTER_COUNT":"0", "WRITE_SKIP_COUNT":"0" } } ] }, { "stepExecutionId":51, "executionId":39, "instanceId":35, "stepName":"step2", "batchStatus":"COMPLETED", "startTime":"2015/03/30 11:10:09.915 -0400", "endTime":"2015/03/30 11:10:10.648 -0400", "exitStatus":"COMPLETED", "metrics":{ "READ_COUNT":"0", "WRITE_COUNT":"0", "COMMIT_COUNT":"0", "ROLLBACK_COUNT":"0", "READ_SKIP_COUNT":"0", "PROCESS_SKIP_COUNT":"0", "FILTER_COUNT":"0", "WRITE_SKIP_COUNT":"0" }, "partitions":[ { "partitionNumber":0, "batchStatus":"COMPLETED", "startTime":"2015/03/30 11:10:10.324 -0400", "endTime":"2015/03/30 11:10:10.417 -0400", "exitStatus":"step2", "metrics":{ "READ_COUNT":"0", "WRITE_COUNT":"0", "COMMIT_COUNT":"0", "ROLLBACK_COUNT":"0", "READ_SKIP_COUNT":"0", "PROCESS_SKIP_COUNT":"0", "FILTER_COUNT":"0", "WRITE_SKIP_COUNT":"0" } }, { "partitionNumber":1, "batchStatus":"COMPLETED", "startTime":"2015/03/30 11:10:10.260 -0400", "endTime":"2015/03/30 11:10:10.347 -0400", "exitStatus":"step2", "metrics":{ "READ_COUNT":"0", "WRITE_COUNT":"0", "COMMIT_COUNT":"0", "ROLLBACK_COUNT":"0", "READ_SKIP_COUNT":"0", "PROCESS_SKIP_COUNT":"0", "FILTER_COUNT":"0", "WRITE_SKIP_COUNT":"0" } }, { "partitionNumber":2, "batchStatus":"COMPLETED", "startTime":"2015/03/30 11:10:10.507 -0400", "endTime":"2015/03/30 11:10:10.557 -0400", "exitStatus":"step2", "metrics":{ "READ_COUNT":"0", "WRITE_COUNT":"0", "COMMIT_COUNT":"0", "ROLLBACK_COUNT":"0", "READ_SKIP_COUNT":"0", "PROCESS_SKIP_COUNT":"0", "FILTER_COUNT":"0", "WRITE_SKIP_COUNT":"0" } }, { "_links":[ { "rel":"job execution", "href":"https://localhost:9443/ibm/api/batch/jobexecutions/9" }, { "rel":"job instance", "href":"https://localhost:9443/ibm/api/batch/jobinstances/9" } ] } ]
- GET /ibm/api/batch/jobexecutions/Jobausführungs-ID/stepexecutions/Schrittname
- Dieser URI gibt ein JSON-Array mit den Details der Schrittausführung für die angegebene Jobausführung und den angegebenen Schrittnamen zurück.
- GET /ibm/api/batch/jobinstances/Jobinstanz-ID/jobexecutions/Folgenummer der Jobausführung/stepexecutions/Schrittname
- Dieser URI gibt ein JSON-Array mit den Details der Schrittausführung für die angegebene Jobinstanz, die angegebene Jobausführung und den angegebenen Schrittnamen zurück.
- GET /ibm/api/batch/stepexecutions/Schrittausführungs-ID
- Dieser URI gibt ein JSON-Array mit den Details der Schrittausführung für die angegebene Schrittausführung zurück.
Jobprotokolle
- GET /ibm/api/batch/jobinstances/Jobinstanz-ID/joblogs
- Dieser URI gibt ein JSON-Array mit REST-Links zu allen Jobprotokollabschnitten für die angegebene Jobinstanz zurück.
- GET /ibm/api/batch/jobexecutions/Jobausführungs-ID/joblogs
- Dieser URI gibt ein JSON-Array mit REST-Links zu allen Jobprotokollabschnitten für die angegebene Jobausführung zurück.Wichtig: Im folgenden Beispiel sehen Sie das Format der REST-Links.Wenn Ihre Jobausführung die Jobprotokollabschnitte
enthält, dann lauten die entsprechenden REST-Links wie folgt:joblogs/instance.Instanz-ID/execution.Ausführungs-ID/part.1.log joblogs/instance.Instanz-ID/execution.Ausführungs-ID/part.2.log joblogs/instance.Instanz-ID/execution.Ausführungs-ID/step.Schrittname/partition.0/part.1.log joblogs/instance.Instanz-ID/execution.Ausführungs-ID/step.Schrittname/partition.1/part.1.log
/ibm/api/batch/jobexecutionsAusführungs-ID/joblogs?part=part.1.log /ibm/api/batch/jobexecutionsAusführungs-ID/joblogs?part=part.2.log /ibm/api/batch/jobexecutionsAusführungs-ID/joblogs?part=step.Schrittname/partition.0/part.1.log /ibm/api/batch/jobexecutionsAusführungs-ID/joblogs?part=step.Schrittname/partition.1/part.1.log
- Optionale Parameter:
- type = text
- "Text" gibt alle Jobprotokolle als Klartext zurück. Alle Jobprotokollabschnitte sind zusammengefasst. Kopf- und Fußzeilendatensätze, die die Abschnitte begrenzen, werden in den Datenstrom eingefügt, um die verschiedenen zusammengefassten Abschnitte zu begrenzen.
- type = zip
- "Zip" gibt alle Jobprotokolle für die angegebene Jobinstanz oder Jobausführung als komprimierte Datei zurück. Die Verzeichnisstruktur der Jobprotokolle wird in der komprimierten Datei beibehalten.
- GET /ibm/api/batch/jobinstances/Jobinstanz-ID/joblogs?type=text|zip
- GET /ibm/api/batch/jobexecutions/Jobausführungs-ID/joblogs?type=text|zip
- Das Verhalten dieser beiden URIs unter Angabe des Parameters type variiert je nach Wert.
- type = text
- "Text" gibt alle Jobprotokolle als Klartext zurück. Alle Jobprotokollabschnitte sind zusammengefasst. Kopf- und Fußzeilendatensätze, die die Abschnitte begrenzen, werden in den Datenstrom eingefügt, um die verschiedenen zusammengefassten Abschnitte zu begrenzen.
- type = zip
"Zip" gibt alle Jobprotokolle für die angegebene Jobinstanz oder Jobausführung als komprimierte Datei zurück. Die Verzeichnisstruktur der Jobprotokolle wird in der komprimierten Datei beibehalten.
- GET /ibm/api/batch/jobexecutions/Jobausführungs-ID/joblogs?part=Pfad zum Abschnitt&type=text|zip
- Ist der Parameter part angegeben, gibt dieser URI Jobprotokollabschnitte als Klartext (type=text) oder in einer komprimierten Datei (type=zip) zurück. Die Standardeinstellung ist "type=text".
HTTP-Rückgabecodes
- HTTP 200 OK
- HTTP 201 Eine neue Ressource wurde erfolgreich erstellt.
- HTTP 202 Eine Anforderung wurde akzeptiert, aber die Verarbeitung ist noch nicht abgeschlossen.
- HTTP 400 Eine Anforderung ist fehlerhaft und enthält ungültige Parameter. Weitere Details enthält die zurückgegebene Nachricht.
- HTTP 401 Für den Zugriff auf diese Ressource besteht keine Berechtigung.
- HTTP 403 Die Authentifizierung ist fehlgeschlagen.
- HTTP 404 Die angeforderte Ressource wurde nicht gefunden oder existiert nicht.
- HTTP 409 Die Anforderung steht in Konflikt mit dem aktuellen Status der Ressource. Weitere Details enthält die zurückgegebene Nachricht.
- HTTP 500 Interner Serverfehler.
STOP-Anforderungen in einer verteilten Serverstapelumgebung
Stoppanforderungen, die an die Stapel-REST-API gesendet werden, müssen direkt an das Steuerprogramm gesendet werden, in dem der Job ausgeführt wird. Wird eine Stoppanforderung an einen Dispatcher oder ein Steuerprogramm gesendet, in dem der Job nicht ausgeführt wird, wird die Anforderung mit einer HTTP 302-Umleitungsantwortnachricht an das richtige Steuerprogramm umgeleitet. Das Feld location (Position) in der HTTP 302-Umleitungsantwort gibt die richtige URL an, die für die Stoppanforderung verwendet werden muss.