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.

Anmerkung: Die Stapel-REST-API wird je URL versioniert. Die URLs ohne Versionsnummer werden als Version 1 der API betrachtet. Die Webadressen der REST-Schnittstelle für Stapel beginnen alle mit der Stammwebadresse: https://{Host}:{Port}/ibm/api/batch/{Version}/.
Hinweis: Die Webadressen der REST-Schnittstelle für Stapeljobs beginnen alle mit der folgenden Stammwebadresse: https://{Host}:{Port}/ibm/api/batch.

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. Die Zeichenfolgekriterien können einen Platzhalteroperator (*) an beiden Enden verwenden.
  • 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 createTime

Wenn 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.
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
*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.
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
[16.0.0.4 und höher]GET /ibm/api/batch/v3/jobinstances/
[16.0.0.4 und höher]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.
  • 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/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:
  1. 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.
  2. 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.
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.
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 createTime

Wenn 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.
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
*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.
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
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
enthält, dann lauten die entsprechenden REST-Links wie folgt:
/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

Folgende HTTP-Rückgabecodes werden für die REST-API verwendet:
  • 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.

JOBLOGS-Anforderungen in einer verteilten Serverstapelumgebung

Anforderungen für Jobprotokolle, die an die Stapel-REST-API gesendet werden, müssen direkt an das Steuerprogramm gesendet werden, in dem der Requests ausgeführt wird. Wird eine Jobprotokollanforderung 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 Jobprotokollanforderung verwendet werden muss.
Anmerkung: Werden Anforderungen für Jobprotokolle für die gesamte Jobinstanz an die Stapel-REST-API gesendet, sind diese nur dann gültig, wenn alle Jobausführungen für die betreffende Instanz in demselben Steuerprogramm ausgeführt werden. Wenn die Ausführungen in verschiedenen Steuerprogrammen ausgeführt werden, schlagen die Jobprotokollanforderungen für die Instanz fehl. In diesem Fall müssen Sie die Jobprotokolle für jede Ausführung getrennt abrufen.

Löschanforderungen in einer verteilten Serverstapelumgebung

Löschanforderungen, 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 Löschanforderung 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 Löschanforderung verwendet werden muss.
Anmerkung: Werden Löschanforderungen für die gesamte Jobinstanz an die Stapel-REST-API gesendet, sind diese nur dann gültig, wenn alle Jobausführungen für die betreffende Instanz in demselben Steuerprogramm ausgeführt werden. Wenn die Ausführungen in verschiedenen Steuerprogrammen ausgeführt werden, schlagen die Löschanforderungen für die Instanz fehl.

Symbol das den Typ des Artikels anzeigt. Referenzartikel



Symbol für Zeitmarke Letzte Aktualisierung: 01.12.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-libcore-mp&topic=rwlp_batch_rest_api
Dateiname: rwlp_batch_rest_api.html