Parallelverarbeitung implementieren (SAP-Bibliothek - Basis-Programmierschnittstellen (BC-DWB))

Parallelverarbeitung implementieren

Für die Verarbeitung von bestimmten R/3-Reports reichen die Nächte allein nicht mehr aus. Speziell bei Kunden mit großen Datenvolumen können einige R/3-Reports, die gewöhnlich im Hintergrundverarbeitungssystem ausgeführt werden (wie z. B. Dispositionsläufe) Laufzeiten von vielen Stunden haben. Es kann sich als schwierig erweisen, diese Jobs in der verfügbaren "Nachtzeit" auszuführen, besonders dann, wenn die Dialoganwender über mehrere Zeitzonen verteilt sind.

Mit Release 3.1G bietet R/3 eine Lösung für dieses Problem der "kurzen Nächte": parallel verarbeitete Hintergrund-Jobs. Zeitaufwendige R/3-Reports können jetzt die Parallelverarbeitung implementieren, bei der die anstehende Arbeit in kleineren Paketen an verfügbare Dialog-Workprozesse im System R/3 verteilt werden kann. Die Ergebnisse können dann gesammelt werden.

Die Parallelverarbeitung wird in ABAP-Reports und -Programmen, und nicht im Hintergrundverarbeitungssystem selbst implementiert. Das bedeutet, daß die Jobs nur dann parallel verarbeitet werden, wenn der Report, der in einem Job-Step ausgeführt wird, für die Parallelverarbeitung programmiert ist. Diese Reports können auch dann die Parallelverarbeitung ausführen, wenn sie interaktiv gestartet werden.

Die Parallelverarbeitung wird mit einer speziellen Variante der asynchronen RFC implementiert. Es ist wichtig, daß Sie nur die korrekte Variante für Ihre eigenen Parallelverarbeitungsvarianten verwenden: das Schlüsselwort CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP. Die Verwendung anderer Varianten der asynchronen RFC umgeht die integrierten Sicherungsmechanismen im korrekten Schlüsselwort und kann das System in die Knie zwingen

Funktionsbausteine und ABAP-Schlüsselwörter

Die Parallelverarbeitung wird in den Anwendungs-Reports implementiert, die im Hintergrund ausgeführt werden. Sie können die Parallelverarbeitung mit den folgenden Funktionsbausteinen und ABAP-Schlüsselwörtern in Ihren eigenen Hintergrundanwendungen implementieren:

Funktionsbaustein SPBT_INITIALIZE: Wahlfrei. Verwenden Sie diesen Funktionsbaustein, um die Verfügbarkeit der Ressourcen für die Parallelverarbeitung zu ermitteln.

Sie können die folgenden Schritte ausführen:

Prüfen, ob die angegebene Gruppe für die Parallelverarbeitung korrekt ist.
Prüfen, wie viele Workprozesse verfügbar sind, so daß Sie die Größe der Datenpakete besser festlegen können.

ABAP-Schlüsselwort CALL FUNCTION <Funktion> STARTING NEW TASK <Aufgabenname> mit Argument DESTINATION IN GROUP. Verwenden Sie dieses Schlüsselwort, wenn das System R/3 den Funktionsbausteinaufruf parallel ausführen soll. Die normale Vorgehensweise ist, dieses Schlüsselwort in eine Schleife zu stellen, in der die zu verarbeitenden Daten in Workpakete aufgeteilt sind. Sie können die Daten in Form einer internen Tabelle übergeben (Argumente EXPORT, TABLE). Das Schlüsselwort implementiert die Parallelverarbeitung, indem es asynchrone RFC-Aufrufe an die Server in der RFC Server-Gruppe absetzt, die für die Verarbeitung angegeben wurde.

Funktionsbaustein SPBT_GET_PP_DESTINATION: Wahlfrei. Muß sofort nach dem Schlüsselwort CALL FUNCTION aufgerufen werden, um den Namen des Servers abzurufen, auf dem die Parallelverarbeitung stattfindet.

Funktionsmodul SPBT_DO_NOT_USE_SERVER: Wahlfrei. Schließt einen bestimmten Server von der weiteren Verwendung für Parallelverarbeitungsaufgaben aus. Kann zusammen mit SPBT_GET_PP_DESTINATION verwendet werden, wenn Sie feststellen, daß ein bestimmter Server nicht für die Parallelverarbeitung verfügbar ist (z. B. Ausnahme COMMUNICATION FAILURE, wenn ein Server nicht mehr verfügbar ist).

ABAP-Schlüsselwort WAIT: Erforderlich, wenn Sie auf die Rückgabe aller asynchronen Parallelverarbeitungen warten möchten, die mit der Funktion CALL FUNCTION erstellt wurden. Dies ist normalerweise eine Bedingung für die geregelte Hintergrundverarbeitung. Kann nur verwendet werden, wenn CALL FUNCTION den Zusatz PERFORMING ON RETURN enthält.

ABAP-Schlüsselwort RECEIVE: Erforderlich, wenn Sie die Ergebnisse der Verarbeitung eines asynchronen RFC empfangen möchten. RECEIVE ruft IMPORT- und TABLE-Parameter sowie Nachrichten und Rückkehrcodes ab.

Bedingungen

Bevor Sie die Parallelverarbeitung implementieren, stellen Sie sicher, daß Ihre Anwendung für die Hintergrundverarbeitung und Ihr System R/3 die folgenden Bedingungen erfüllen:

Logisch unabhängige Arbeitseinheiten. Die Datenverarbeitungsaufgabe, die parallel ausgeführt werden soll, muß logisch unabhängig sein von anderen Instanzen der Aufgabe. Das bedeutet, daß die Aufgabe ohne Referenz auf andere Sätze aus demselben Datenbestand ausgeführt werden kann, die ebenfalls parallel verarbeitet werden, und daß die Aufgabe nicht abhängig ist von den Ergebnissen der anderen parallelen Operationen. Die Parallelverarbeitung eignet sich beispielsweise nicht für Daten, die nacheinander verarbeitet werden müssen, oder in denen die Verarbeitung einer bestimmten Dateneinheit von der Verarbeitung einer anderen Dateneinheit abhängig ist.

Definitionsgemäß ist bei der Parallelverarbeitung nicht garantiert, daß die Daten in einer bestimmten Reihenfolge verarbeitet werden oder daß ein bestimmtes Ergebnis an einem bestimmten Punkt der Verarbeitung zur Verfügung stehen wird.

ABAP-Bedingungen (siehe auch die Online-Dokumentation für das Schlüsselwort CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP):

Der Funktionsbaustein, den Sie aufrufen, muß als extern aufrufbar markiert sein. Dieses Attribut wird im Feld Remote Function Call unterstützt in der Definition des Funktionsbausteins (Transaktion SE37) angegeben.
Der aufgerufene Funktionsbaustein darf keinen Funktionsaufruf zum Destination "BACK" enthalten.
Das aufrufende Programm sollte nicht zu einer neuen internen Sitzung wechseln, nachdem ein asynchroner RFC-Aufruf übergeben wurde. Das bedeutet, daß Sie SUBMIT oder CALL TRANSACTION in einem derartigen Bericht nicht nach CALL FUNCTION STARTING NEW TASK verwenden sollten.
Sie können das Schlüsselwort CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP nicht zum Starten externer Programme verwenden.
In Aufrufen zwischen Systemen R/3 müssen beide Systeme auf dem Stand von Release 3.0A oder höher sein.

Ressourcen des Systems R/3: Um die Aufgaben von parallelen Jobs zu verarbeiten, muß ein Server in Ihrem System R/3 mindestens 3 Dialog-Workprozesse haben. Er muß auch die Workload-Kriterien des Parallelverarbeitungssystems erfüllen: Dispatcher-Warteschlange weniger als 10% belegt, mindestens ein Dialog-Workprozeß frei für die Verarbeitung von Aufgaben aus dem parallelen Job.

Ressourcenverwaltung in RFC-Servergruppen

Das Parallelverarbeitungssystem verfügt über integrierte Sicherungsmechanismen, mit denen die Möglichkeit ausgeschaltet wird, daß ein paralleler Job alle Ressourcen in einem System R/3 für sich verbraucht und hierdurch bei anderen Jobs oder Benutzern Performance-Probleme verursacht.

Zusätzlich zu diesen integrierten Sicherungen haben Sie die Möglichkeit, die gemeinsame Nutzung in den RFC-Servergruppen optimieren. Bei der Parallelverarbeitung bezeichnet eine "Gruppe" die R/3-Anwendungsserver, die für die parallele Ausführung eines bestimmten Programms verwendet werden können. Standardmäßig besteht die Gruppe aus allen Servern, die die Ressourcenkriterien erfüllen (CALL FUNCTION STARTING NEW TASK mit dem Zusatz DESTINATION IN GROUP DEFAULT). Sie können jedoch auch ihre eigenen eingeschränkten Gruppen anlegen. Sie können Gruppen jedoch auch mit Transaktion RZ12 anzeigen und pflegen (Tools ® Administration ® Administration ® Network ® RFC destinations und anschließend RFC ® RFC groups).

Geben Sie die gewünschte Gruppe sowohl im Funktionsbaustein SPBT_INITIALIZE (falls verwendet) als auch im ABAP-Schlüsselwort CALL FUNCTION STARTING NEW TASK an. Es ist nur eine Gruppe pro parallelem ABAP-Report oder -Programm (Job-Step) zulässig.

Nachrichten und Ausnahmen

In den Funktionsbausteinen, die Sie aufrufen, sollten Sie Ausnahmen für die Mitteilung von Fehlern verwenden, und nicht das Schlüsselwort MESSAGE. Die Ausnahmebehandlung ist bei asynchronen RFCs vollständig unter Ihrer Kontrolle. Sie fügen einfach die Ausnahmen, die durch den Funktionsbaustein generiert wurden, den reservierten Ausnahmen SYSTEM_FAILURE und COMMUNICATIONS_FAILURE des Schlüsselworts CALL FUNCTION hinzu. Sie können dann die Ausnahmen in dem Programm bearbeiten, das die parallelen Programmieraufgaben startet.

Berechtigungen

Ist der Parameter auth/rfc_authority_check im Systemprofil festgelegt (Wert 1), prüft das System automatisch für das Schlüsselwort CALL FUNCTION, ob der Benutzer des Hintergrundjobs die erforderliche RFC-Berechtigung hat. Das RFC-Berechtigungsobjekt ist S_RFC. Die Berechtigung legt den Zugriff auf Funktionsbausteine nach Funktionsbausteingruppe fest, d.h., ob ein Benutzer dazu berechtigt ist, Funktionsbausteine einer bestimmten Gruppe auszuführen.

Sie können die RFC-Berechtigung eines Benutzers mit dem Funktionsbaustein AUTHORITY_CHECK_RFC prüfen. Dieser Funktionsbaustein gibt RC = 0 zurück, wenn der Benutzer für die angegebene Gruppe berechtigt ist. Der Funktionsbaustein prüft nicht, ob eine Berechtigungsprüfung tatsächlich stattfinden wird.

Programmbeispiel: Paralleler Job

Dieses Programmbeispiel zeigt die Erstellung eines Reports, der parallel ausgeführt wird, wenn er interaktiv oder im Hintergrundverarbeitungssystem gestartet wird. Es basiert auf der Online-Dokumentation für ABAP CALL FUNCTION STARTING NEW TASK.

Programmstruktur

SPBT_INITIALIZE: Nach der Datendeklaration ruft der Report den Funktionsbaustein SPBT_INITIALIZE auf. Der Aufruf veranlaßt das Programm, zu prüfen, ob die Parallelverarbeitungsgruppe gültig ist und die Ressourcen verfügbar sind. Dieser Aufruf ist wahlfrei. Wenn Sie den Funktionsbaustein nicht aufrufen, ruft das System R/3 selbst SPBT_INITIALIZE auf, um die RFC-Servergruppe zu initialisieren.

Da der Funktionsbaustein die Anzahl der verfügbaren Workprozesse zurückgibt, könnte mit dem Aufruf festgestellt werden, welche Größe die Workpakete haben sollen, die zu verarbeiten sind. Stehen 10 Workprozesse zur Verfügung, können Sie beispielsweise die Daten zur Verarbeitung in 10 Pakete aufteilen. Es besteht jedoch keine Garantie, daß die Anzahl der freien Workprozesse zwischen dem Zeitpunkt des Aufrufs und dem Zeitpunkt, an dem das Programm seine Workpakete sendet, gleich bleibt - es sei denn, Sie arbeiten mit einer Gruppe von Servern, die für Ihren Job reserviert sind.

Es ist jedoch selbstverständlich auch möglich, die Daten mit einem Parallelverarbeitungsaufruf für jeden zu verarbeitenden Datensatz zu bearbeiten. In diesem Fall wird natürlich nicht versucht, die Größe der Workpakete zu optimieren.

CALL FUNCTION... Schleife: Kernstück des Reports ist eine DO-Schleife, in der der Funktionsbaustein zur Parallelverarbeitung aufgerufen wird (CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP). Die Schleife in diesem Beispiel wird durch einen einfachen Countdown-Mechanismus gesteuert. In einem Produktivreport würden Sie die Schleife wiederholen, bis alle Daten mit CALL FUNCTION zur Verarbeitung übergeben wurden.

Aus Gründen der Einfachheit ruft die Schleife in diesem Beispiel einen Funktionsbaustein auf, der keine Daten benötigt (RFC_SYSTEM_INFO). In einem Produktivreport würden Sie Logik einfügen, um einen Datensatz oder eine Gruppe von Datensätzen für die Verarbeitung auszuwählen. Diese Datensätze würden Sie in eine interne Tabelle packen und sie mit den Zusätzen EXPORTING oder TABLES des Aufrufs CALL FUNCTION STARTING NEW TASK in den Parallelverarbeitungsaufruf aufnehmen.

Um eine Wiederherstellung zu vereinfachen, sollte ein Produktivprogramm außerdem Logik für die Protokollierung des Verarbeitungsfortschrittes enthalten. Wenn das Programm in der Mitte der Verarbeitung abnormal beendet wird, ist es wichtig, daß Sie feststellen können, welche Daten bereits verarbeitet wurden und bei welchen Daten der Report die Verarbeitung wiederaufnehmen soll. In ihrer einfachsten Form sollte diese Logik die Daten protokollieren, die zur Parallelverarbeitung übergeben wurden, und die Beendigung der Verarbeitung jeder Dateneinheit festhalten.

Aufgabenverwaltung: Ein Rückkehrcode 0 (SY-SUBRC) von CALL FUNCTION gibt an, daß Ihre Parallelverarbeitungsaufgabe erfolgreich übergeben wurde. Es ist jetzt wichtig, daß Ihr Job diese Parallelverarbeitungsaufgaben verfolgen kann. Die Aufgabenverwaltung sollte die folgenden Punkte übernehmen:

Eindeutige Aufgabennamen für jede CALL FUNCTION-Aufgabe generieren.

Verwenden Sie den Aufgabennamen, den Sie in CALL FUNCTION angegeben haben, zur Kennzeichnung von Parallelverarbeitungsaufgaben. Jede Aufgabe, die Sie übergeben, muß einen eindeutigen Namen haben, damit die Daten, die von der Aufgabe zurückgegeben werden, korrekt identifiziert werden können.

Warten, bis Ressourcen verfügbar werden, wenn alle Parallelverarbeitungsressourcen (Dialog-Workprozesse) temporär belegt sind. Siehe "Ausnahme CURRENTLY_NO_RESOURCES_AVAIL" unten.
Feststellen, ob alle Aufgaben beendet wurden. Nur dann kann Ihr Programm beendet werden. Weitere Informationen unter "Beendigung eines Jobs abwarten".

Im Beispiel erhöht die Aufgabenverwaltung einen Zähler und verwaltet eine Tabelle der Aufgaben, die übergeben wurden. Als wahlfreie Funktion kann die Aufgabenverwaltung mit SPBT_GET_PP_DESTINATION feststellen, wo jede Parallelverarbeitungsaufgabe verarbeitet wird.

Ausnahme RESOURCE_FAILURE: Bei jeder Übergabe einer Parallelverarbeitungsaufgabe errechnet das System R/3 die Anzahl der Ressourcen (Dialog-Workprozesse) neu, die für die Verarbeitung weiterer Aufgaben vorhanden sind. Diese Zahl erhöht sich wieder, sobald eine Parallelverarbeitungsaufgabe abgeschlossen ist und zum Programm zurückkehrt.

Dauert die Ausführung von Parallelverarbeitungsaufgaben sehr lange, sind die Ressourcen für die Parallelverarbeitung möglicherweise vorübergehend belegt. In diesem Fall gibt CALL FUNCTION die Ausnahme RESOURCE_FAILURE zurück. Dies bedeutet einfach, daß alle Dialog-Workprozesse in der RFC-Gruppe belegt sind, die von Ihrem Programm verwendet wird.

Ihr Programm muß jetzt warten, bis die Ressourcen verfügbar werden, und anschließend den fehlgeschlagenen Aufruf CALL FUNCTION erneut übergeben. Im Beispielprogramm wird ein einfacher, ziemlich sicherer Wartemechanismus verwendet. Das Programm wartet, bis Parallelverarbeitungsaufgaben zurückgegeben werden und Ressourcen freigeben. WAIT gibt außerdem eine vorläufige Zeitüberschreitung von 1 Sekunde an. Wenn CALL FUNCTION erneut fehlschlägt, wird WAIT mit einem längeren Zeitüberschreitungswert wiederholt. Sie können die Zeitüberschreitungswerte erhöhen, wenn Sie erwarten, daß die Verarbeitung Ihrer Parallelverarbeitungsaufgaben länger dauert. Sie sollten außerdem Code zum Verlassen der Wiederholungsschleife hinzufügen, der nach einer angemessenen Anzahl von Wiederholungen ausgeführt wird.

Antworten erhalten: Das Schlüsselwort CALL FUNCTION startet die Verarbeitung des Formulars RETURN_INFO, sobald die Verarbeitung einer Parallelverarbeitungsaufgabe abgeschlossen ist. Dieses Formular verwendet das Schlüsselwort RECEIVE, um die Ergebnisse der Parallelverarbeitung zu erfassen. In diesem Fall wird die Struktur RFCSI_EXPORT aus RFC_SYSTEM_INFO in der internen Struktur INFO erfaßt.

RECEIVE wird benötigt, um die IMPORTING- und TABLE-Antworten eines asynchron ausgeführten RFC-Funktionsmoduls zu sammeln.

Beispiel: Angenommen, Ihr Report generiert eine Liste. Sie würden ein Formular wie z. B. RETURN_INFO und RECEIVE zum Erfassen der Listeneinträge verwenden, die von jeder Parallelverarbeitungsaufgabe generiert wurden. Nachdem alle Parallelverarbeitungsaufgaben zurückgekehrt sind, könnte Ihr Report die Listeneinträge vor der Präsentation sortieren oder anderweitig weiterverarbeiten.

Beendigung eines Jobs abwarten: Als Teil Ihrer Aufgabenverwaltung geben Sie an, daß Ihr Job warten muß, bis alle Parallelverarbeitungsaufgaben abgeschlossen sind. Zu diesem Zweck verwendet das Beispielprogramm das Schlüsselwort WAIT, um zu warten, bis die Anzahl der abgeschlossenen Parallelverarbeitungsaufgaben der Zahl der erstellten Aufgaben entspricht. Unabhängig von diesem Schlüsselwort WAIT wird das Formular RETURN_INFO gestartet. RETURN_INFO verfolgt die Anzahl der abgeschlossenen Parallelverarbeitungsaufgaben, so daß die WAIT-Bedingung korrekt geprüft werden kann.

REPORT PARAJOB.
*
* Datendeklarationen
*
DATA: GROUP LIKE RZLLITAB-CLASSNAME VALUE ' ',
"Parallelverarbeitungsgruppe.
"SPACE = Standardgruppe (alle
"Server)
WP_AVAILABLE TYPE I, "Anzahl der verfügbaren Prozesse
"für Parallelverarbeitung
"(freie Workprozesse)
WP_TOTAL TYPE I, "Gesamtanzahl der Dialog-
"Workprozesse in der Gruppe
MSG(80) VALUE SPACE, "Container für Fehlernachricht bei
"einer fernen RFC-Ausnahme.
INFO LIKE RFCSI, C, "Nachrichtentext
JOBS TYPE I VALUE 10, "Anzahl der parallelen Jobs
SND_JOBS TYPE I VALUE 1, "Zur Verarbeitung gesendete Pakete
RCV_JOBS TYPE I VALUE 1, "Empfangene Workpaketantworten
EXCP_FLAG(1) TYPE C, "Anzahl der RESOURCE_FAILUREs
TASKNAME(4) TYPE N VALUE '0001', "Aufgabenname (Arbeits-
"einheit für Parallelverarbeitung)
BEGIN OF TASKLIST OCCURS 10, "Aufgabenverwaltung
TASKNAME(4) TYPE C,
RFCDEST LIKE RFCSI-RFCDEST,
RFCHOST LIKE RFCSI-RFCHOST,
END OF TASKLIST.
*
* Wahlfreier Aufruf an SBPT_INITIALIZE, um die Gruppe zu prüfen,
* in der die Parallelverarbeitung stattfinden soll.
* Kann zur Optimierung der Größe der Workpakete verwendet werden
* / WP_AVAILABLE).
*
CALL FUNCTION 'SPBT_INITIALIZE'
EXPORTING
GROUP_NAME = GROUP
"Name der zu prüfenden Gruppe
IMPORTING
MAX_PBT_WPS = WP_TOTAL
"Gesamtanzahl der verfügbaren
"Dialog-Workprozesse in Gruppe
"für Parallelverarbeitung
FREE_PBT_WPS = WP_AVAILABLE
"Anzahl momentan für Parallel-
"verarbeitung verfügbarer
"Dialog-Workprozesse in Gruppe
EXCEPTIONS
INVALID_GROUP_NAME = 1
"Ungültiger Gruppenname; RFC-
"Gruppe nicht definiert. Siehe
"Transaktion RZ12
INTERNAL_ERROR = 2
"R/3-Systemfehler; Diagnose-
"infos im Systemprotokoll
"(Transaktion SM21)
PBT_ENV_ALREADY_INITIALIZED = 3
"Funktionsbaustein darf nur
"einmal aufgerufen werden;
"wird automatisch von R/3
"aufgerufen, wenn kein Aufruf
"vor Start d. Parallelverarb.
CURRENTLY_NO_RESOURCES_AVAIL = 4
"Keine Dialog-Workprozesse
"in der Gruppe verfügbar.
"Sie werden verwendet oder
"Serverauslastung ist zu hoch.
NO_PBT_RESOURCES_FOUND = 5
"Keine Server in der Gruppe
"erfüllten Kriterien von > "zwei definierten Workprozessen.
"
CANT_INIT_DIFFERENT_PBT_GROUPS = 6
"Sie haben bereits eine Gruppe
"initialisiert und haben jetzt
"versucht, eine andere Gruppe " zu initialisieren.
OTHERS = 7.

CASE SY-SUBRC.
WHEN 0.
"Alles in Ordnung. Größe der Workpakete kann auf Wunsch
"optimiert werden.
WHEN 1.
"Gruppenname nicht vorhanden. Report stoppen.
MESSAGE E836. "Group not defined.
WHEN 2.
"Systemfehler. Stoppen und zur Fehleranalyse
"Systemprotokoll prüfen.
WHEN 3.
"Programmierfehler. Stoppen und Programm korrigieren.
MESSAGE E833. "PBT environment was already initialized.
WHEN 4.
"Keine Ressourcen. Möglicherweise ein temporäres Problem.
"Nach kurzer Pause den Aufruf wiederholen oder
"RFC-Gruppenverwaltung prüfen: Gruppe in Übereinstimmung
"mit Ihren Bedingungen definiert?
MESSAGE E837. "All servers currently busy.
WHEN 5.
"Prüfen Sie Server, Netzwerk und Betriebsmodi.

WHEN 6.

* Parallelverarbeitung ausführen. CALL FUNCTION STARTING NEW TASK
* DESTINATION IN GROUP verwenden, um den entsprechenden
* Funktionsbaustein aufzurufen. Ein Aufruf pro zu verarbeitendem
* Datensatz oder Datensätze in Workpakete unterteilen. In jedem
* Fall den Datensatz als interne Tabelle im CALL FUNCTION-
* Schlüsselwort (Argumente EXPORT, TABLES) angeben.

DO.
CALL FUNCTION 'RFC_SYSTEM_INFO' "Parallel auszuführender
"Funktionsbaustein.
STARTING NEW TASK TASKNAME "Name zur Kennzeichnung dieses
"RFC-Aufrufs.
DESTINATION IN GROUP group "Name der Servergruppe für
"Parallelverarbeitung.
"Gruppennamen exakt eingeben,
"wie er in Transaktion
"RZ12 angezeigt wird
"(nur Großbuchst.). Nur ein
"Name pro ABAP-Programm.
PERFORMING RETURN_INFO ON END OF TASK
"Wird nach Abschluß des RFC-
"Aufrufs aufgerufen. Kann mit
"RECEIVE die IPORT-/TABLES-
"Parameter aus der aufger.
"Funktion sammeln.

EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE msg
"Zielserver nicht erreicht
"oder Kommunikation
"unterbrochen. MESSAGE msg
"erfaßt alle Nachrichten,
"die mit dieser Ausnahme
"zurückgegeben wurden.

" (z. B. Nachrichten vom Typ
"E oder A vom aufgerufenen
"FM. Nach Ausnahme 1 oder 2
"können Sie, anstatt das
"Programm abzubrechen,
"SPBT_GET_PP_DESTINATION und
"SPBT_DO_NOT_USE_SERVER zum
"Ausschließen dieses Servers
"von der weiteren Parallel-
"verarbeitung verwenden. Dann
"den Aufruf mit anderem
"Server wiederholen.
SYSTEM_FAILURE = 2 MESSAGE msg
"Programm- oder anderer
"interner R/3-Fehler. MESSAGE
"msg erfaßt alle Nachrichten,
"die mit dieser Ausnahme
"zurückgegeben wurden.
RESOURCE_FAILURE = 3. "Gegenwärtig keine
"Workprozesse verfügbar. Ihr
"Programm MUSS diese Ausnahme
"behandeln.
YOUR_EXCEPTIONS = X. "Vom aufgerufenen Funktions-
"baustein generierte Aus-
"nahmen hier hinzufügen.
"Ausnahmen werden an Sie
"zurückgegeben und können
"hier von Ihnen beantwortet "werden.

CASE SY-SUBRC.
WHEN 0.
"Verwaltung der asynchronen RFC-Aufgaben
"Namen der Aufgabe sichern...
TASKLIST-TASKNAME = TASKNAME.
"... und Server abrufen, der RFC-Aufruf ausführt.
CALL FUNCTION 'SPBT_GET_PP_DESTINATION'
EXPORTING
RFCDEST = TASKLIST-RFCDEST
EXCEPTIONS
OTHERS = 1.
APPEND TASKLIST.
WRITE: / 'Started task: ', TASKLIST-TASKNAME COLOR 2.

TASKNAME = TASKNAME + 1.
SND_JOBS = SND_JOBS + 1.
"Mechanismus, mit dem festgelegt wird, wann Schleife ver-
"lassen werden soll. Hier ein einfacher Zähler der Parallel- "verarbeitungsaufgaben. Im Echteinsatz würden Sie die Schleife
"nach Übergabe der zu verarbeitenden Daten beenden.
JOBS = JOBS - 1. "Anzahl der vorhandenen Jobs
IF JOBS = 0.
EXIT. "Jobverarbeitung abgeschlossen
ENDIF.
WHEN 1 OR 2.
"Kommunikations- und Systemfehler bearbeiten. Ihr Programm
"muß diese Ausnahmen erfassen und wiederherstellbare
"Beendigung des Hintergrundverarbeitungs-Jobs
"ermöglichen. Empfehlung: Daten protokollieren, die bei
"Start und Rückkehr einer RFC-Aufgabe verarbeitet wurden, so
"daß Job m. unverarbeiteten Daten neu gestartet werden kann. WRITE msg.

"Server nicht mehr für Parallelverarbeitungs-
"aufgaben in diesem Programm berücksichtigen.
"Namen des gerade aufgerufenen Servers abrufen...
CALL FUNCTION 'SPBT_GET_PP_DESTINATION'
EXPORTING
RFCDEST = TASKLIST-RFCDEST
EXCEPTIONS
OTHERS = 1.
"Anschließend aus Liste verfügbarer Server entfernen.
CALL FUNCTION 'SPBT_DO_NOT_USE_SERVER'
IMPORTING
SERVERNAME = TASKLIST-RFCDEST
EXCEPTIONS
INVALID_SERVER_NAME = 1
NO_MORE_RESOURCES_LEFT = 2
"Keine Server übrig in "Gruppe.
PBT_ENV_NOT_INITIALIZED_YET = 3
OTHERS = 4.
WHEN 3.

WHEN 3.
"Momentan keine Ressourcen (Dialog-Workprozesse) verfügbar.
"Sie müssen warten und CALL FUNCTION
"wiederholen, bis Verarbeitung fortgesetzt
"werden kann oder offensichtlich ein Problem vorliegt,

"das Fortsetzung verhindert.
MESSAGE I837. "All servers currently busy.
"Antworten auf asynchrone RFC-Aufrufe abwarten. Mit jeder
"Antwort wird ein Dialog-Workprozeß wieder verfügbar.
IF EXCP_FLAG = SPACE.
EXCP_FLAG = 'X'.
"Erster Versuch zur RESOURCE_FAILURE-Fehlerbehandlung.
"Warten, bis alle RFC-Aufrufe zurückgegeben wurden bzw.
"bis zu 1 Sekunde. Dann CALL FUNCTION wiederholen.
WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '1' SECONDS.
ELSE.
"Zweiter Versuch zur RESOURCE_FAILURE-Fehlerbehandlung.
WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '5' SECONDS.
"SY-SUBRC 0 von WAIT zeigt, daß Antworten zurückgegeben
"wurden. Ressourcenproblem war wahrscheinlich temporär
"und auf Workload zurückzuführen. RC ungleich Null
"legt nahe, daß keine RFC-Aufrufe ausgeführt wurden und
"evtl. Probleme bestehen.
IF SY-SUBRC = 0.
CLEAR EXCP_FLAG.
ELSE. "Keine Antworten
"Endlosschleife
...
ENDIF.
ENDIF.
ENDCASE.
ENDDO.
...
*
* Jobende abwarten: Antworten von allen RFC-Aufgaben.
* Übrige asynchrone Antworten empfangen
WAIT UNTIL RCV_JOBS >= SND_JOBS.
LOOP AT TASKLIST.
WRITE:/ 'Received task:', TASKLIST-TASKNAME COLOR 1,
30 'Destination: ', TASKLIST-RFCDEST COLOR 1.
ENDLOOP.
...
*
* Diese Routine wird angestoßen, wenn ein RFC-Aufruf ausgeführt
* wurde und zurückkehrt. Die Routine verwendet RECEIVE zum Sammeln
* von IMPORT- und TABLE-Daten vom RFC-Funktionsbaustein.
*
* Beachten sie, daß das Schlüsselwort WRITE im asynchronen RFC
* nicht unterstützt wird. Wenn Sie eine Liste generieren müssen,
* muß der RFC-Funktionsbaustein die Listendaten in einer internen
* Tabelle zurückgeben. Sie können diese Daten sammeln und die
* Liste nach Verarbeitungsende ausgeben.
*
FORM RETURN_INFO USING TASKNAME.

DATA: INFO_RFCDEST LIKE TASKLIST-RFCDEST.

RECEIVE RESULTS FROM FUNCTION 'RFC_SYSTEM_INFO'
IMPORTING RFCSI_EXPORT = INFO
EXCEPTIONS
COMMUNICATION_FAILURE = 1
SYSTEM_FAILURE = 2.

RCV_JOBS = RCV_JOBS + 1. "Daten werden empfangen
IF SY-SUBRC NE 0.
* Kommunikations- und Systemfehlerbehandlung
...
ELSE.
READ TABLE TASKLIST WITH KEY TASKNAME = TASKNAME.
IF SY-SUBRC = 0. "Zählen
TASKLIST-RFCHOST = INFO_RFCHOST.
MODIFY TASKLIST INDEX SY-TABIX.
ENDIF.
ENDIF.
...
ENDFORM