Unterschiedliche Tasks einer Stapelanwendung können in Stapelabschnitte
unterteilt werden. Stapelabschnitte werden als lokale containergesteuerte
Enterprise-JavaBeans (EJB) implementiert, die das
com.ibm.websphere.batch.BatchJobStepLocalInterface als Business-Interface angeben.
Callback-Methoden im BatchJobStepLocalInterface erlauben der
Ausführungsumgebung für lange Laufzeit (Long-Running
Execution Environment, LREE), beim Ausführen
eines Stapeljobs Stapelabschnitte auszuführen.
Eine Stapelabschnitts-EJB enthält stapelfähige Business-Logik, die für einen
Abschnitt des Stapeljobs ausgeführt werden soll. Normalerweise enthält ein
Stapelabschnitt Code, mit dem ein Satz aus einem Batch-Datenstrom gelesen werden kann.
Dieser Satz wird verwendet, um Business-Logik auszuführen, anschließend wird der
nächste Satz gelesen. Die Methode processJobStep einer Stapelabschnitts-EJB wird von der
LREE in einer Stapelschleife aufgerufen. Diese Methode muss die gesamte Logik enthalten,
die stapelfähig ist und für Daten ausgeführt werden kann.
Die LREE ruft Methoden der Stapelabschnitts-EJB in einer globalen Transaktion
auf. Diese globale Transaktion wird von der LREE gesteuert. Das Verhalten der
Transaktion, z. B. das Zeitlimit oder das Festschreibungsintervall für die Transaktion,
wird von dem Prüfpunktalgorithmus gesteuert, der dem Stapeljob, zu dem der Abschnitt
gehört, zugeordnet ist.
Es folgen die LREE-Callback-Methoden im BatchJobStepLocalInterface, die von der LREE
in der genannten Reihenfolge aufgerufen werden:
- setProperties(java.util.Properties properties) - stellt Merkmale, die in
xJCL definiert sind, für Jobabschnitte in einem java.util.Properties-Objekt zur
Verfügung.
Diese Methode wird in einer globalen Transaktion aufgerufen.
- void createJobStep() - zeigt dem Abschnitt an, dass er initialisiert
wurde. Initialisierungslogik, z. B. das Abrufen einer Kennung für einen
Batch-Datenstrom, kann hier platziert werden. Diese Methode wird in einer globalen
Transaktion aufgerufen.
- int processJobStep() - wird wiederholt von der LREE in einer Stapelschleife
aufgerufen, bis der Rückkehrcode dieser Methode, der als ganze Zahl dargestellt wird,
anzeigt, dass der Abschnitt die Verarbeitung beendet hat. Überprüfen Sie unter
BatchConstants in der Stapel-API, welche Rückkehrcodes zurückgegeben werden können. Der
Rückkehrcode BatchConstants.STEP_CONTINUE signalisiert der LREE, dass sie diese Methode
in der Stapelschleife weiterhin aufrufen soll. Der Rückkehrcode
BatchConstants.STEP_COMPLETE zeigt der LREE an, dass der Abschnitt abgeschlossen ist, und
destroyJobStep wird aufgerufen.
- int destroyJobStep() - zeigt dem Abschnitt an, dass er
abgeschlossen ist. Der Rückkehrcode dieser Methode ist völlig beliebig und kann vom
Entwickler der Stapelanwendung ausgewählt werden. Dieser Rückkehrcode
wird in der LREE-Datenbank gespeichert und repräsentiert den Rückkehrcode des
Stapelabschnitts. Wenn der Ergebnisalgorithmus dem Stapeljob zugeordnet ist, wird
dieser Rückkehrcode an ihn übergeben. Enthält die xJCL des Stapeljobs bedingte,
auf Rückkehrcodes basierende Logik, verwendet die LREE diesen Rückkehrcode, um die Logik
auszuwerten.
Beachten Sie, dass die Methode getProperties() im BatchJobStepLocalInterface
gegenwärtig nicht von der LREE aufgerufen wird. Die Methode ist im Interface aus
Gründen der Symmetrie enthalten und wird möglicherweise in der Zukunft verwendet.
Fehlerbehebung und Stapelentwicklung
- Der Deployment-Deskriptor der Stapel-Controller-Bean muss im
EJB-Deployment-Deskriptor einer Stapelanwendung deklariert werden und lokale
EJB-Referenzen auf die Abschnitts-EJBs, die in einer Stapelanwendung verwendet werden,
besitzen. Pro Stapelanwendung kann nur eine Controller-Bean definiert werden.
- Die Transaktionsattribute aller Stapelabschnittsmethoden sollten auf "required"
(erforderlich) gesetzt werden.
- Der Entwickler der Stapelanwendung muss sicherstellen, dass transaktionsorientierte
Arbeitsvorgänge, die in den Callback-Methoden des Stapelabschnitts ausgeführt werden, die
globale, von der LREE gestartete Transaktion übernimmt. Dadurch wird
sichergestellt, dass der in einem Stapelabschnitt ausgeführte Arbeitsvorgang an jedem
Prüfpunkt festgeschrieben und, im Falle einer Fehlerbedingung für den Abschnitt, zurückgesetzt wird.
- Wenn der Stapelabschnitt einen Batch-Datenstrom verwendet, dessen Daten sich im
Dateisystem des lokalen Anwendungsservers befinden, auf dem die Stapelanwendung implementiert wird,
ist es wichtig, bestimmte Schritte auszuführen, um die Szenarios zum Neustart
von Jobs zu unterstützen. Wenn eine solche Stapelanwendung auf Anwendungsservern
implementiert wird, die auf mehreren Systemen ausgeführt werden können - z. B. bei einer
Implementierung in einem dynamischen Cluster, der sich in einer Knotengruppe mit mehreren
Knoten-Membern befindet - und wenn ein Stapeljob, der für eine solche
Anwendung ausgeführt wird, abgebrochen und anschließend erneut gestartet wird,
gibt es keine Garantie, dass die Anforderung des Neustarts an das System gesendet wird,
auf dem der Stapeljob ursprünglich ausgeführt wurde.
In diesem Szenario wird bei der Verteilung für lange Laufzeit die Anforderung des
Neustarts an einen Anwendungsserver gesendet, der auf einem anderen System ausgeführt
wird. Daher sind in den Fällen, in denen die dateibasierte Affinität erforderlich ist,
folgende Lösungen zur Unterstützung des Szenarios "Neustart des Jobs" möglich:
- Vergewissern Sie sich, dass die Daten allen Systemen, auf denen die Stapelanwendung
gestartet werden kann, zur Verfügung steht, z. B. über ein Netzdateisystem (die
Leistung der Anwendung wird möglicherweise beeinträchtigt).
- Implementieren Sie die Anwendung auf einem oder mehreren Anwendungsservern, die nur
auf dem System, auf dem die lokalen Daten sich befinden, gestartet werden können. Dazu
müssen Sie die Anwendung in einem dynamischen Cluster implementieren, der
sich in einer Knotengruppe mit nur einem Member-Knoten befindet.