Parallelverarbeitung implementieren
Für die Verarbeitung von bestimmten SAP-Reports reichen die Nächte allein nicht mehr aus. Speziell bei Kunden mit großen Datenvolumen können einige SAP-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.
SAP bietet eine Lösung für dieses Problem der "kurzen Nächte": parallel verarbeitete Hintergrund-Jobs. Zeitaufwendige SAP-Reports können jetzt die Parallelverarbeitung implementieren, bei der die anstehende Arbeit in kleineren Paketen an verfügbare Dialog-Workprozesse im SAP-System 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, dass 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.
Achtung
Die Parallelverarbeitung wird mit einer speziellen Variante der asynchronen RFC implementiert. Es ist wichtig, dass 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 dass 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 SAP-System 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. Muss 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, dass 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, dass Ihre Anwendung für die Hintergrundverarbeitung und Ihr SAP-System die folgenden Bedingungen erfüllen:
Logisch unabhängige Arbeitseinheiten. Die Datenverarbeitungsaufgabe, die parallel ausgeführt werden soll, muss logisch unabhängig sein von anderen Instanzen der Aufgabe. Das bedeutet, dass die Aufgabe ohne Referenz auf andere Sätze aus demselben Datenbestand ausgeführt werden kann, die ebenfalls parallel verarbeitet werden, und dass 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, dass die Daten in einer bestimmten Reihenfolge verarbeitet werden oder dass 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, muss 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, dass 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 müssen beide Systeme auf dem Stand von Release 3.0A oder höher sein.
Ressourcen des SAP-Systems: Um die Aufgaben von parallelen Jobs zu verarbeiten, muss ein Server in Ihrem SAP-System mindestens drei Dialog-Workprozesse haben. Er muss auch die Workload-Kriterien des Parallelverarbeitungssystems erfüllen: Dispatcher-Warteschlange weniger als 10% belegt, mindestens ein Dialog-Workprozess 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, dass ein paralleler Job alle Ressourcen in einem SAP-System 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 SAP-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 veranlasst 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 SAP-System 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, dass 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, dass 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, muss 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 SAP-System 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 muss 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, dass 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 erfasst.
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, dass Ihr Job warten muss, 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 dass die WAIT-Bedingung korrekt geprüft werden kann.
Syntax
REPORT PARAJOB. * * Data declarations * DATA: GROUP LIKE RZLLITAB-CLASSNAME VALUE ' ', "Parallel processing group. "SPACE = group default (all "servers) WP_AVAILABLE TYPE I, "Number of dialog work processes "available for parallel processing "(free work processes) WP_TOTAL TYPE I, "Total number of dialog work "processes in the group MSG(80) VALUE SPACE, "Container for error message in "case of remote RFC exception. INFO LIKE RFCSI, C, "Message text JOBS TYPE I VALUE 10, "Number of parallel jobs SND_JOBS TYPE I VALUE 1, "Work packets sent for processing RCV_JOBS TYPE I VALUE 1, "Work packet replies received EXCP_FLAG(1) TYPE C, "Number of RESOURCE_FAILUREs TASKNAME(4) TYPE N VALUE '0001', "Task name (name of "parallel processing work unit) BEGIN OF TASKLIST OCCURS 10, "Task administration TASKNAME(4) TYPE C, RFCDEST LIKE RFCSI-RFCDEST, RFCHOST LIKE RFCSI-RFCHOST, END OF TASKLIST. * * Optional call to SBPT_INITIALIZE to check the * group in which parallel processing is to take place. * Could be used to optimize sizing of work packets * work / WP_AVAILABLE). * CALL FUNCTION 'SPBT_INITIALIZE' EXPORTING GROUP_NAME = GROUP "Name of group to check IMPORTING MAX_PBT_WPS = WP_TOTAL "Total number of dialog work "processes available in group "for parallel processing FREE_PBT_WPS = WP_AVAILABLE "Number of work processes "available in group for "parallel processing at this "moment EXCEPTIONS INVALID_GROUP_NAME = 1 "Incorrect group name; RFC "group not defined. See "transaction RZ12 INTERNAL_ERROR = 2 "SAP system error; see the "system log (transaction "SM21) for diagnostic info PBT_ENV_ALREADY_INITIALIZED = 3 "Function module may be "called only once; is called "automatically by the SAP system if you "do not call before starting "parallel processing CURRENTLY_NO_RESOURCES_AVAIL = 4 "No dialog work processes "in the group are available; "they are busy or server load "is too high NO_PBT_RESOURCES_FOUND = 5 "No servers in the group "met the criteria of > "two work processes "defined. CANT_INIT_DIFFERENT_PBT_GROUPS = 6 "You have already initialized "one group and have now tried "initialize a different group. OTHERS = 7.. CASE SY-SUBRC. WHEN 0. "Everything’s ok. Optionally set up for optimizing size of "work packets. WHEN 1. "Non-existent group name. Stop report. MESSAGE E836. "Group not defined. WHEN 2. "System error. Stop and check system log for error "analysis. WHEN 3. "Programming error. Stop and correct program. MESSAGE E833. "PBT environment was already initialized. WHEN 4. "No resources: this may be a temporary problem. You "may wish to pause briefly and repeat the call. Otherwise "check your RFC group administration: Group defined "in accordance with your requirements? MESSAGE E837. "All servers currently busy. WHEN 5. "Check your servers, network, operation modes. WHEN 6. * Do parallel processing. Use CALL FUNCTION STARTING NEW TASK * DESTINATION IN GROUP to call the function module that does the * work. Make a call for each record that is to be processed, or * divide the records into work packets. In each case, provide the * set of records as an internal table in the CALL FUNCTION * keyword (EXPORT, TABLES arguments). DO. CALL FUNCTION 'RFC_SYSTEM_INFO' "Function module to perform "in parallel STARTING NEW TASK TASKNAME "Name for identifying this "RFC call DESTINATION IN GROUP group "Name of group of servers to "use for parallel processing. "Enter group name exactly "as it appears in transaction "RZ12 (all caps). You may "use only one group name in a "particular ABAP program. PERFORMING RETURN_INFO ON END OF TASK "This form is called when the "RFC call completes. It can "collect IMPORT and TABLES "parameters from the called "function with RECEIVE. EXCEPTIONS COMMUNICATION_FAILURE = 1 MESSAGE msg "Destination server not "reached or communication "interrupted. MESSAGE msg "captures any message "returned with this "exception (E or A messages "from the called FM, for "example. After exception "1 or 2, instead of aborting "your program, you could use "SPBT_GET_PP_DESTINATION and "SPBT_DO_NOT_USE_SERVER to "exclude this server from "further parallel processing. "You could then re-try this "call using a different "server. SYSTEM_FAILURE = 2 MESSAGE msg "Program or other internal "SAP error. MESSAGE msg "captures any message "returned with this "exception. RESOURCE_FAILURE = 3. "No work processes are "currently available. Your "program MUST handle this "exception. YOUR_EXCEPTIONS = X. "Add exceptions generated by "the called function module "here. Exceptions are "returned to you and you can "respond to them here. CASE SY-SUBRC. WHEN 0. "Administration of asynchronous RFC tasks "Save name of task... TASKLIST-TASKNAME = TASKNAME. "... and get server that is performing RFC call. 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. "Mechanism for determining when to leave the loop. Here, a "simple counter of the number of parallel processing tasks. "In production use, you would end the loop when you have "finished dispatching the data that is to be processed. JOBS = JOBS - 1. "Number of existing jobs IF JOBS = 0. EXIT. "Job processing finished ENDIF. WHEN 1 OR 2. "Handle communication and system failure. Your program must "catch these exceptions and arrange for a recoverable "termination of the background processing job. "Recommendation: Log the data that has been processed when "an RFC task is started and when it returns, so that the "job can be restarted with unprocessed data. WRITE msg. "Remove server from further consideration for "parallel processing tasks in this program. "Get name of server just called... CALL FUNCTION 'SPBT_GET_PP_DESTINATION' EXPORTING RFCDEST = TASKLIST-RFCDEST EXCEPTIONS OTHERS = 1. "Then remove from list of available servers. CALL FUNCTION 'SPBT_DO_NOT_USE_SERVER' IMPORTING SERVERNAME = TASKLIST-RFCDEST EXCEPTIONS INVALID_SERVER_NAME = 1 NO_MORE_RESOURCES_LEFT = 2 "No servers left in group. PBT_ENV_NOT_INITIALIZED_YET = 3 OTHERS = 4. WHEN 3. "No resources (dialog work processes) available at "present. You need to handle this exception, waiting "and repeating the CALL FUNCTION until processing "can continue or it is apparent that there is a "problem that prevents continuation. MESSAGE I837. "All servers currently busy. "Wait for replies to asynchronous RFC calls. Each "reply should make a dialog work process available again. IF EXCP_FLAG = SPACE. EXCP_FLAG = 'X'. "First attempt at RESOURCE_FAILURE handling. Wait "until all RFC calls have returned or up to 1 second. "Then repeat CALL FUNCTION. WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '1' SECONDS. ELSE. "Second attempt at RESOURCE_FAILURE handling WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '5' SECONDS. "SY-SUBRC 0 from WAIT shows that replies have returned. "The resource problem was therefore probably temporary "and due to the workload. A non-zero RC suggests that "no RFC calls have been completed, and there may be "problems. IF SY-SUBRC = 0. CLEAR EXCP_FLAG. ELSE. "No replies "Endless loop handling ... ENDIF. ENDIF. ENDCASE. ENDDO. ... * * Wait for end of job: replies from all RFC tasks. * Receive remaining asynchronous replies WAIT UNTIL RCV_JOBS >= SND_JOBS. LOOP AT TASKLIST. WRITE:/ 'Received task:', TASKLIST-TASKNAME COLOR 1, 30 'Destination: ', TASKLIST-RFCDEST COLOR 1. ENDLOOP. ... * * This routine is triggered when an RFC call completes and * returns. The routine uses RECEIVE to collect IMPORT and TABLE * data from the RFC function module. * * Note that the WRITE keyword is not supported in asynchronous * RFC. If you need to generate a list, then your RFC function * module should return the list data in an internal table. You * can then collect this data and output the list at the conclusion * of processing. * 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. "Receiving data IF SY-SUBRC NE 0. * Handle communication and system failure ... ELSE. READ TABLE TASKLIST WITH KEY TASKNAME = TASKNAME. IF SY-SUBRC = 0. "Register data TASKLIST-RFCHOST = INFO_RFCHOST. MODIFY TASKLIST INDEX SY-TABIX. ENDIF. ENDIF. ... ENDFORM