Timeout abfangen / Start eines zweiten Threads

[Lilia3936]

Hallo zusammen,

ich benötige mal wieder euer geballtes Wissen.

Ich rufe auf meiner BSP-Seite im Eventhandler OnInputProcessing einen Funktionsbaustein auf, welcher sich per RFC an einem anderen R/3 System anmeldet und einen call transaction durchführt. Leider läuft der Fuba manchmal etwas länger als erwartet und führt zu Abbrüchen. Den Timeoutparameter habe ich schon erhöht.

Ich möchte gerne den Fuba im Hintergrund laufen lassen und dem Anwender die Möglichkeit geben auf den Bsp-Seiten weiterzuarbeiten. Das Ergebnis des Fuba's benötige ich aber trotzdem zurück, weil ich es in einem Cookie speichern muss.

Hat von euch einer eine gute idee wie ich den Timeout abfangen kann, bzw. eine Hintergrundverarbeitung starte. Die Doku von SAP ist hier etwas dürftig.

http://help.sap.com/saphelp_webas620sp9 ... ameset.htm

Hier wird beschrieben mann soll einen zweiten Thread starten. Wie mach ich das?

Ich würde mich auf Antwort freuen

Gruß Rene

[Fabian1957]

Einen zweiten Thread kannst Du starten über Call Function ... in background task.

Siehe Zitat aus SAP-Docu:

Syntax
CALL FUNCTION func IN BACKGROUND TASK
[DESTINATION dest]
parameter_list
[AS SEPARATE UNIT].



Zusatz:
... AS SEPARATE UNIT



Wirkung
Transaktionaler Aufruf eines in func angegebenen remote-fähigen Funktionsbausteins über die RFC-Schnittstelle. Mit dem Zusatz DESTINATION kann eine einzelne Destination in dest angegeben werden. Falls die Destination nicht angegeben ist, wird implizit die Destination "NONE" verwendet. Für func und dest werden zeichenartige Datenobjekte erwartet.

Beim transaktionalen Aufruf wird der Name der gerufenen Funktion zusammen mit der Destination und den in parameter_list übergebenen Aktualparametern für die aktuelle SAP-LUW in den Datenbanktabellen ARFCSSTATE und ARFCSDATA des aktuellen SAP-Systems unter einer eindeutigen Transaktionskennung registriert (Abkürzung TID, abgelegt in einer Struktur vom Typ ARFCTID aus dem ABAP Dictionary, Ansicht über Transaktion SM58). Das aufrufende Programm wird nach der Registrierung hinter der Anweisung CALL FUNCTION fortgesetzt.

Die zur aktuellen SAP-LUW registrierten Funktionsbausteine werden bei Ausführung der Anweisung COMMIT WORK in der Reihenfolge gestartet, in der sie registriert wurden. Die Anweisung ROLLBACK WORK löscht alle vorhergehenden Registrierungen der aktuellen SAP-LUW.

Falls die angegebene Destination bei COMMIT WORK nicht zur Verfügung steht, wird ein ausführbares Programm namens RSARFCSE in der Hintergrundverarbeitung gestartet, das standardmäßig alle 15 Minuten und bis zu 30 Mal versucht, die zu einer SAP-LUW registrierten Funktionsbausteine in ihrer Destination zu starten. Änderungen dieser Parameter können in der Transaktion SM59 vorgenommen werden. Wenn die Destination innerhalb der vorgegebenen Zeit nicht verfügbar wird, wird dies in der Datenbanktabelle ARFCSDATA als Eintrag "CPICERR" vermerkt. Der Eintrag in der Datenbanktabelle ARFCSSTATE wird standardmäßig nach 8 Tagen gelöscht.



Zusatz
... AS SEPARATE UNIT


Wirkung
Bei Verwendung des Zusatzes AS SEPARATE UNIT wird der betreffende Funktionsbaustein in einem eigenen Kontext ausgeführt, in dem die globalen Daten der Funktionsgruppe nicht von vorhergehenden Aufrufen beeinflusst sind. Jeder Funktionsbaustein, der mit dem Zusatz AS SEPARATE UNIT registriert wird, erhält eine eigene Transaktionskennung. Ohne den Zusatz AS SEPARATE UNIT gilt für den Kontext der aufgerufenen Funktionsbausteine die übliche Beschreibung, so dass bei Verwendung der gleichen Destination bei mehreren Aufrufen von Funktionsbausteinen der gleichen Funktionsgruppe gemeinsam auf die globalen Daten dieser Funktionsgruppe zugegriffen wird.



Hinweise
Mit dem Funktionsbaustein ID_OF_BACKGROUNDTASK kann man nach einem transaktionalen RFC die Transaktionskennung (TID) der aktuellen SAP-LUW feststellen.

Der transaktionale RFC (tRFC) ist dazu geeignet, LUWs in verteilten Umgebungen zu realisieren (eine typische Anwendung ist ALE). Dabei ist zu beachten, dass die Ausführung der Funktionsbausteine innerhalb einer Transaktionskennung zwar vorgegeben ist, die Reihenfolge der LUWs in den RFC-Servern aber nicht unbedingt der Reihenfolge der SAP-LUWs im RFC-Client entspricht. Um eine Serialisierung auch auf den RFC-Servern zu erreichen, kann der tRFC auf queued RFC ( qRFC) erweitert werden. Hierfür kann der Funktionsbaustein TRFC_SET_QUEUE_NAME vor einem transaktionalen RFC aufgerufen werden.

In Deinem Fall würde der 'neue' Thread die Arbeit im Hintergrund ausführen, während der 'Frontend-Thread' auf die Folgeseite führt. Da kann lt. Doku der HTML-Refreshmechanismus (z.B. refresh alle 10 sek.)genutzt werden z.B. mit einer Fortschrittsanzeige und einer Infomeldung, dass das System noch beschäftigt ist, oder ähnliches.

Hermann
Hermann