CALL FUNCTION - STARTING NEW TASK - ABAP-Schlüsselwortdokumentation

ABAP - Schlüsselwortdokumentation → ABAP - Referenz → Daten- und Kommunikationsschnittstellen → RFC - Remote Function Call → CALL FUNCTION - RFC →

CALL FUNCTION - STARTING NEW TASK

Kurzreferenz

Syntax

CALL FUNCTION func STARTING NEW TASK task
              [DESTINATION {dest|{IN GROUP {group|DEFAULT}}}]
              [{CALLING meth}|{PERFORMING subr} ON END OF TASK]
              parameter_list.

Zusätze:

1. ... DESTINATION IN GROUP {group|DEFAULT}

2. ... {CALLING meth}|{PERFORMING subr} ON END OF TASK

Wirkung

Asynchroner Aufruf (aRFC) eines in func angegebenen remote-fähigen Funktionsbausteins über die RFC-Schnittstelle. Mit dem Zusatz DESTINATION kann entweder eine einzelne Destination in dest oder über IN GROUP eine Gruppe von Applikationsservern angegeben werden. Letzteres unterstützt die Parallelverarbeitung mehrerer Funktionsbausteine. Das aufrufende Programm wird hinter der Anweisung CALL FUNCTION fortgesetzt, sobald die remote aufgerufene Funktion im Zielsystem gestartet wurde, ohne das Ende ihrer Verarbeitung abzuwarten. Mit CALLING und PERFORMING können Callback-Routinen zur Übernahme von Ergebnissen bei Beendigung der remote aufgerufenen Funktion angegeben werden. Für func und dest werden zeichenartige Datenobjekte erwartet.

Falls die Destination nicht angegeben und auch nicht über den Zusatz KEEPING TASK der Anweisung RECEIVE in einer Callback-Routine festgelegt ist, wird implizit die Destination"NONE" verwendet. Der asynchrone RFC unterstützt keine Kommunikation mit Fremdsystemen bzw. Programmen in anderen Programmiersprachen.

Für task muss ein zeichenartiges Datenobjekt angegeben werden, das eine maximal 32-stellige frei wählbare Aufgabenkennung für den aufgerufenen remote-Funktionsbaustein enthält. Diese Aufgabenkennung wird den Callback-Routinen zur Identifikation der Funktion übergeben. Jede Aufgabenkennung definiert eine eigene RFC-Verbindung mit eigener RFC-Sitzung.

Wenn eine Callback-Routine angegeben ist, muss diese beendet sein, bevor ein Funktionsbaustein nochmals mit derselben Aufgabenkennung und Destination aufgerufen wird.
Ein wiederholt aufgerufener Funktionsbaustein derselben Aufgabenkennung und Destination verwendet die gleiche RFC-Sitzung, in der auf die globalen Daten der zugehörigen Funktionsgruppe zugegriffen werden kann, wenn die Verbindung noch vorhanden ist. Dies ist nur dann der Fall,

falls der PERFORMING- oder CALLING-Zusatz verwendet wird und

in der Callback-Routine der Zusatz KEEPING TASK zur Anweisung RECEIVE angegeben ist.

In allen anderen Fällen wird in der Regel für wiederholt aufgerufene Funktionsbausteine eine neue RFC-Sitzung geöffnet. Dies ist der Fall,

bei anderer Aufgabenkennung oder Destination, auch wenn die Verbindung noch vorhanden ist, und

wenn mit dem PERFORMING- oder CALLING-Zusatz keine Callback-Routine angegeben ist oder in einer Callback-Routine die Anweisung RECEIVE ohne den Zusatz KEEPING TASK verwendet wird. In diesen Fällen wird die RFC-Verbindung gleich nach dem Aufruf wieder geschlossen.

Wenn eine Callback-Routine angegeben ist, muss diese beendet sein, bevor ein Funktionsbaustein nochmals mit derselben Aufgabenkennung und Destination aufgerufen wird, sonst kommt es zu einer Ausnahme beim Aufruf.

Weitere Informationen

Ausführliche Informationen zum aRFC finden Sie in der Dokumentation RFC im SAP Help Portal.

Hinweise

Ein asynchroner RFC öffnet wie jeder RFC eine Benutzersitzung. Wenn in einem aufrufenden Programm mehrere asynchrone RFCs mit verschiedenen Destinationen oder Aufgabenkennungen hintereinander abgesetzt werden oder wenn keine Verbindung mehr vorhanden ist, führt dies automatisch zur Parallelverarbeitung der aufgerufenen Funktionsbausteine in verschiedenen Benutzersitzungen. Diese Eigenschaft kann für die Parallelisierung von Anwendungen ausgenutzt werden. Da die zugehörige Verwaltung sowohl auf dem Client als auch auf den Servern zu Ressourcenengpässen führen kann, wird empfohlen eine solche Parallelisierung nur mit dem Zusatz DESTINATION IN GROUP durchzuführen.
Wenn ein Funktionsbaustein mehrmals hintereinander über asynchronen RFC gestartet wird, liegt die Reihenfolge der Ausführung nicht fest, sondern hängt von der Systemverfügbarkeit ab.
Der Aufruf von Dynpros während der Verarbeitung eines aRFC öffnet zusätzliche ABAP-Sitzungen im RFC-Client (siehe auch RFC-Dialoginteraktionen). Dabei ist zu beachten, dass die maximale Anzahl von möglichen ABAP-Sitzungen nicht überschritten werden kann, ansonsten kommt es zu einer Fehlermeldung. Die maximale Anzahl ist im Profilparameter rdisp/max_alt_modes festgelegt und kann nicht größer als 16 sein.
Der asynchrone RFC löst im aufrufenden Programm einen Datenbank-Commit aus. Ausgenommen hiervon ist ein aRFC während der Verbuchung.
Ein Aufruf mit STARTING NEW TASK wird immer über die RFC-Schnittstelle ausgeführt und eine als dest angegebene Destination wird immer als solche interpretiert. Deshalb darf hier für dest anders als beim synchronen RFC weder ein initialer String noch ein Textfeld, das nur Leerzeichen enthält, angegeben werden.
Die als task übergebene Aufgabenkennung muss nicht pro Aufruf eindeutig sein. Eine eindeutige Aufgabenkennung kann aber der besseren Identifikation eines Aufrufs in einer Callback-Routine dienen.
Wenn in einer mit dem PERFORMING- oder CALLING-Zusatz angegebenen Callback-Routine die Anweisung RECEIVE fälschlicherweise nicht verwendet wird, bleibt die Verbindung wie bei der Angabe von RECEIVE mit dem Zusatz KEEPING TASK erhalten.

Zusatz 1

... DESTINATION IN GROUP {group|DEFAULT}

Wirkung

Die Angabe von IN GROUP als Destination unterstützt die parallele Ausführung mehrerer Funktionsbausteine auf einer vordefinierten Gruppe von Applikationsservern des aktuellen AS ABAP. Diese Variante des aRFC wird auch als paralleler Remote Function Call (pRFC) bezeichnet.

Für group muss ein Datenobjekt vom Typ RZLLI_APCL aus dem ABAP Dictionary angegeben werden, das entweder den Namen einer in der Transaktion RZ12 angelegten RFC-Server-Gruppe enthält oder initial ist. Bei der Angabe von DEFAULT oder wenn group initial ist, werden alle aktuell zur Verfügung stehenden Applikationsserver des aktuellen AS ABAP als Gruppe verwendet. Innerhalb eines Programms darf nur eine einzige RFC-Server-Gruppe verwendet werden. Beim ersten asynchronen RFC mit dem Zusatz IN GROUP wird die angegebene RFC-Server-Gruppe initialisiert. Bei jedem asynchronen RFC mit Angabe der Gruppe wird automatisch der am besten geeignete Applikationsserver ermittelt und der aufgerufene Funktionsbaustein auf diesem ausgeführt.

Falls der Funktionsbaustein auf keinem der Applikationsserver ausgeführt werden kann, da momentan nicht genügend Ressourcen zur Verfügung stehen, kommt es zur vordefinierten Ausnahme RESOURCE_FAILURE, der zusätzlich zu den übrigen RFC-Ausnahmen ein Rückgabewert zugewiesen werden kann. Bei dieser Ausnahme ist der Zusatz MESSAGE nicht erlaubt.

Hinweise

Die Parallelverarbeitung von Funktionsbausteinen mit dem Zusatz IN GROUP nutzt die vorhandenen Ressourcen optimal aus und ist einer selbst programmierten Parallelverarbeitung mit explizit angegebenen Destinationen vorzuziehen.
Ein Applikationsserver, der als Teil einer RFC-Server-Gruppe zur Parallelverarbeitung eingesetzt wird, muss mindestens drei Dialog-Workprozesse haben, von denen einer gerade frei ist. Andere Ressourcen wie Aufträge in der Warteschlange, Anzahl der Systemanmeldungen etc. werden ebenfalls berücksichtigt und dürfen gewisse Grenzwerte nicht überschreiten.
Um sicherzustellen, dass nur auf Applikationsserver zugegriffen wird, die genügend Ressourcen haben, wird empfohlen, statt mit dem Zusatz DEFAULT mit explizit definierten RFC-Server-Gruppen zu arbeiten.
Die Funktionsbausteine der Funktionsgruppe SPBT stellen Service-Funktionen für die Parallelverarbeitung zur Verfügung, zum Beispiel Initialisierung von RFC-Server-Gruppen, Ermittlung der verwendeten Destination oder temporäres Entfernen eines Applikationsservers aus einer RFC-Server-Gruppe.

Zusatz 2

... {CALLING meth}|{PERFORMING subr} ON END OF TASK

Wirkung

Mit diesem Zusatz kann entweder eine Methode meth oder ein Unterprogramm subr als Callback-Routine angegeben werden, die zur Ausführung registriert wird, nachdem der asynchron aufgerufene Funktionsbaustein beendet wurde. Für meth sind die gleichen Angaben wie beim allgemeinen Methodenaufruf möglich, insbesondere also auch dynamische. Für subr muss statisch ein Unterprogramm des gleichen Programms angegeben werden.

Die Methode meth muss öffentlich sein und muss genau einen nicht-optionalen Eingabeparameter p_task vom Typ clike haben. Das angegebene Unterprogramm subr muss genau einen USING-Parameter vom Typ clike haben. Dieser Parameter wird beim Aufruf von der RFC-Schnittstelle mit der Aufgabenkennung der remote aufgerufenen Funktion versorgt, die beim Aufruf in task angegeben wurde.

In der Methode meth bzw. im Unterprogramm subr müssen die Ergebnisse der remote-Funktion mit der Anweisung RECEIVE empfangen werden. In der Callback-Routine dürfen keine Anweisungen ausgeführt werden, durch die diese unterbrochen oder ein impliziter Datenbank-Commit ausgelöst wird. Klassenbasierte Ausnahmen müssen innerhalb der Callback-Routine behandelt werden. Anweisungen zur Listenausgabe werden nicht ausgeführt.

Voraussetzung für die Ausführung einer registrierten Callback-Routine ist, dass das aufrufende Programm bei Beendigung der remote-Funktion noch in seiner internen Sitzung vorhanden ist. Dann wird sie dort beim nächsten Wechsel des Workprozesses beim Hereinrollen ausgeführt. Falls das Programm beendet wurde oder als Teil einer Aufrufkette auf dem Stack liegt, wird die Callback-Routine nicht ausgeführt.

Wenn während eines Programmabschnitts mehrere Callback-Routinen registriert werden, werden diese beim Wechsel des Workprozesses beim Hereinrollen in undefinierter Reihenfolge ausgeführt. Mit der Anweisung WAIT FOR ASYNCHRONOUS TASKS kann die Programmausführung angehalten werden, bis bestimmte oder alle Callback-Routinen ausgeführt wurden.

Hinweise

Wenn in der Callback-Routine keine RECEIVE-Anweisung aufgeführt ist, um die Ergebnisse der remote-Funktion zu empfangen, bleibt die Verbindung bestehen und verhält sich implizit wie bei der Anweisung RECEIVE mit dem Zusatz KEEPING TASK. Dieses implizite Verhalten ist in der Regel nicht erwünscht und eine Callback-Routine ohne RECEIVE-Anweisung ist als Programmierfehler anzusehen.
Der Zeitpunkt zum Ausführen der Callback-Routinen kann, explizit programmiert werden oder implizit auftreten:

Für die explizite Programmierung dient die Anweisung WAIT FOR ASYNCHRONOUS TASKS. Diese Anweisung führt in Abhängigkeit von einer Bedingung zu einem Wechsel des Workprozesses und damit zum Ausführen der bis dahin registrierten Callback-Routinen Sie wartet dann solange auf die Beendigung von registrierten Callback-Routinen bis die Bedingung erfüllt ist, wobei die maximale Wartezeit eingeschränkt werden kann. Die explizite Programmierung wird immer dann empfohlen, wenn die Ergebnisse der remote-Funktion im aktuellen Programm benötigt werden.

Wenn die Ergebnisse der remote-Funktion nicht im aktuellen Programm benötigt werden, kann der Zeitpunkt zum Ausführen der Callback-Routinen auch durch implizite Wechsel des Workprozesses, wie z.B. am Ende eines Dialogschritts, bestimmt werden. Dies kann beispielsweise in GUI-Szenarien sinnvoll sein, in denen eine Verwendung von WAIT unerwünscht sein kann. In diesem Fall muss dafür gesorgt werden, dass vor Beendigung des Programms ein Wechsel des Workprozesses erfolgt. Weiterhin besteht das Risiko, dass bei einem impliziten Wechsel des Workprozesses noch nicht alle Callback-Routinen registriert sind.

Weiterlesen
CALL FUNCTION - STARTING NEW TASK parameter_list
RECEIVE
WAIT FOR ASYNCHRONOUS TASKS
Grenzwerte für Ressourcenbereitstellung beim asynchronen RFC