CALL FUNCTION '...' STARTING NEW TASK in RECEIVE-Methode
10 Beiträge
•
Seite 1 von 1
10 Beiträge
Seite 1 von 1
Hallo Kollegen,
ich habe folgendes programmiert:
in einer Methode START_LISTENER einen FUBA aufgerufen mit einer Fallback-Methode:
Hier habe ich jetzt die Anforderung, dass ich die Methode START_LISTENER in der RECEIVE_FROM_LISTENER aufrufen möchte, um weiter auf Änderungen zu hören.
Ich bekomme jedoch einen Kurzdump, weil es anscheinend nicht erlaubt ist, in der receive-Methode nochmal den asynchronen RFC aufzurufen.
Hat jemand eine Idee wie das zu umgehen wäre?
Kurzdump:
LG
ich habe folgendes programmiert:
in einer Methode START_LISTENER einen FUBA aufgerufen mit einer Fallback-Methode:
Code: Alles auswählen.
METHOD start_listener.
CALL FUNCTION 'Z_xyz_LISTENER'
STARTING NEW TASK 'LSTNR'
DESTINATION 'NONE'
CALLING receive_from_listener ON END OF TASK.
ENDMETHOD.
METHOD receive_from_listener.
DATA:
table TYPE TABLE OF ztable.
RECEIVE RESULTS FROM FUNCTION 'Z_xyz_LISTENER'
IMPORTING
e_table = table.
Ich bekomme jedoch einen Kurzdump, weil es anscheinend nicht erlaubt ist, in der receive-Methode nochmal den asynchronen RFC aufzurufen.
Hat jemand eine Idee wie das zu umgehen wäre?
Kurzdump:
Code: Alles auswählen.
Laufzeitfehler RPERF_ILLEGAL_STATEMENT
Datum und Zeit 12.02.2019 09:32:46
Kurztext
Anweisung "CALL FUNCTION .. DESTINATION/STARTING NEW TASK/IN BACKGROUND TASK/IN
Was ist passiert?
Fehler im ABAP-Anwendungsprogramm.
Das laufende ABAP-Programm "Z..." mußte abgebrochen werden, da
es auf
eine Anweisung gestoßen ist, die leider nicht ausgeführt werden kann.
Was können Sie tun?
Notieren Sie bitte, welche Aktionen und Eingaben zu dem Fehler geführt
haben.
Wenden Sie sich bitte zur weiteren Bearbeitung des Problems an Ihren
SAP-Administrator.
Mit der Transaktion ST22 zur ABAP-Dumpanalyse können Sie
Abbruchmeldungen anschauen und verwalten, insbesondere längere Zeit
aufbewahren.
Fehleranalyse
There is probably an error in the program
"Z...".
Vermutlich wurde das Programm in einem Konvertierungs-Exit
oder in einem Feld-Exit aufgerufen. Diese werden durch
Funktionsbausteine mit Namen CONVERSION_EXIT_xxxxx_INPUT/OUTPUT bzw.
USER_EXIT_xxxxx_INPUT realisiert.
Konvertierungs-Exits werden beim Dynpro-Feldtransport oder bei
WRITE-Anweisungen angestoßen, Feld-Exits beim Feldtransport vom
Dynpro in das ABAP-Programm.
In diesem Zusammenhang sind folgende ABAP-Anweisungen nicht zulässig:
- CALL SCREEN
- CALL DIALOG
- CALL TRANSACTION
- SUBMIT
- MESSAGE W... und MESSAGE I...
- COMMIT WORK, ROLLBACK WORK
- COMMUNICATION RECEIVE
- STOP
- REJECT
- EXIT FROM STEP-LOOP
Darüber hinaus sind in Konvertierungs-Exits für die Ausgabekonvertierung
(realisiert durch Funktionsbausteine mit Namen
CONVERSION_EXIT_xxxxx_OUTPUT) keine
- MESSAGE E...
Anweisungen erlaubt.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4419 / 224 /
1189
)
»
Ich glaub dein Problem ist, dass du das Konzept nicht ganz verstanden hast:
Wenn deine RECEIVE Methode aufgerufen wird, gibt es nichts mehr auf sich zu "hören" lohnt, weil die Verarbeitung auf der Gegenseite per se abgeschlossen ist.
Was du mit dem Aufruf von START_LISTENER eigentlich machst, ist eine neue Verarbeitung zu starten.
Beim RECEIVE RESULTS kannst du noch KEEPING TASK angeben, damit bleibt die Session auf der Gegenstelle erhalten. So kannst du, wenn du z.B. globale Datenfelder in deinem RFC-Baustein verwendest hast, auf die Daten in diesen Feldern noch zugreifen. Ohne den Zusatz KEEPING TASK wird die Session komplett abgebaut und wenn du erneut einen Task mit derselben Kennung startest, wird eine neue Session gestartet.
Was den Kurzdump betrifft, so glaube ich, dass hier wirklich nicht alles möglich ist wie in einem normalen Programmlauf. z.B. habe ich in diesem Schritt mal versucht ein Control zu aktualisieren und auch einen Kurzdump erhalten. Vermutlich läuft die Receive-Methode in einem eigenen Thread der nur bedingt Zugriff auf den Hauptprozess erlaubt. Dafür gibt es den Befehl WAIT FOR ASYNCRONOUS TASK. Der Aufrufer erhöht z.B. einen Zähler und wartet dann mit diesem Befehl, dass der Zähler wieder 0 wird. Erst dann darf mit der weiteren Verarbeitung fortgesetzt werden. In der Receive-Methode wird der Zähler einfach verringert.
Damit hast du im Hauptprogramm eine einfache Schleife die ein oder mehrere Tasks, je nachdem wie hoch das UNTIL ist, verwaltet.
Wenn deine RECEIVE Methode aufgerufen wird, gibt es nichts mehr auf sich zu "hören" lohnt, weil die Verarbeitung auf der Gegenseite per se abgeschlossen ist.
Was du mit dem Aufruf von START_LISTENER eigentlich machst, ist eine neue Verarbeitung zu starten.
Beim RECEIVE RESULTS kannst du noch KEEPING TASK angeben, damit bleibt die Session auf der Gegenstelle erhalten. So kannst du, wenn du z.B. globale Datenfelder in deinem RFC-Baustein verwendest hast, auf die Daten in diesen Feldern noch zugreifen. Ohne den Zusatz KEEPING TASK wird die Session komplett abgebaut und wenn du erneut einen Task mit derselben Kennung startest, wird eine neue Session gestartet.
Was den Kurzdump betrifft, so glaube ich, dass hier wirklich nicht alles möglich ist wie in einem normalen Programmlauf. z.B. habe ich in diesem Schritt mal versucht ein Control zu aktualisieren und auch einen Kurzdump erhalten. Vermutlich läuft die Receive-Methode in einem eigenen Thread der nur bedingt Zugriff auf den Hauptprozess erlaubt. Dafür gibt es den Befehl WAIT FOR ASYNCRONOUS TASK. Der Aufrufer erhöht z.B. einen Zähler und wartet dann mit diesem Befehl, dass der Zähler wieder 0 wird. Erst dann darf mit der weiteren Verarbeitung fortgesetzt werden. In der Receive-Methode wird der Zähler einfach verringert.
Code: Alles auswählen.
METHOD start_listener.
do.
CALL FUNCTION 'Z_xyz_LISTENER'
STARTING NEW TASK 'LSTNR'
DESTINATION 'NONE'
CALLING receive_from_listener ON END OF TASK.
add 1 to gd_zähler.
WAIT FOR ASYNCHRONOUS TASKS UNTIL gd_zähler EQ 0.
enddo.
ENDMETHOD.
METHOD receive_from_listener.
DATA:
table TYPE TABLE OF ztable.
RECEIVE RESULTS FROM FUNCTION 'Z_xyz_LISTENER'
IMPORTING
e_table = table.
SUBTRACT 1 FROM gd_zähler.
ENDMETHOD.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Hi,
danke dir für dein Feedback!
Ich will, dass der Listener in einem bestimmten Fall die Receive-Methode aufruft und anschließend wieder weiterhören soll. Also dass das Lauschen wieder anfängt.
danke dir für dein Feedback!
Doch, ich denke schon.a-dead-trousers hat geschrieben:Ich glaub dein Problem ist, dass du das Konzept nicht ganz verstanden hast:
Japp, ich weiß. Will ich auch.a-dead-trousers hat geschrieben:Wenn deine RECEIVE Methode aufgerufen wird, gibt es nichts mehr auf sich zu "hören" lohnt, weil die Verarbeitung auf der Gegenseite per se abgeschlossen ist.
Was du mit dem Aufruf von START_LISTENER eigentlich machst, ist eine neue Verarbeitung zu starten.
Das ist in Ordnung, das braucht den Zustand nicht zu behalten.a-dead-trousers hat geschrieben:Beim RECEIVE RESULTS kannst du noch KEEPING TASK angeben, damit bleibt die Session auf der Gegenstelle erhalten.So kannst du, wenn du z.B. globale Datenfelder in deinem RFC-Baustein verwendest hast, auf die Daten in diesen Feldern noch zugreifen. Ohne den Zusatz KEEPING TASK wird die Session komplett abgebaut und wenn du erneut einen Task mit derselben Kennung startest, wird eine neue Session gestartet.
Ich will, dass der Listener in einem bestimmten Fall die Receive-Methode aufruft und anschließend wieder weiterhören soll. Also dass das Lauschen wieder anfängt.
Beitrag
von a-dead-trousers (Top Expert / 4419 / 224 /
1189
)
»
Siehe mein Coding.nickname8 hat geschrieben:Ich will, dass der Listener in einem bestimmten Fall die Receive-Methode aufruft und anschließend wieder weiterhören soll. Also dass das Lauschen wieder anfängt.
Der "Hauptprozess" muss das Lauschen anstoßen. Er muss also auch darauf "warten" bis seine Tasks fertig werden.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
nickname8
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Also, es klappt schon, was du mir geschrieben hast.
Leider hakt es an einer anderen Stelle. Ich beschreibe mal kurz, was ich machen will:
In einem separaten Task soll überprüft werden, ob neue Daten vorhanden sind, die auf einem Bildschirm angezeigt werden sollen. Im Receiving-Teil wollte ich die dann aufbereiten und ausgeben. Da tritt aber der Kurzdump auf.
Im CALL FUNCTION-Loop kann ich die aber nicht ausgeben, weil ich ja nicht aus dem LOOP rauskomme um den PBO zu Ende zu führen.
Hat jemand eine Idee um asynchron auf Daten zu lauschen und die dann immer nur bei Bedarf auszugeben?
Leider hakt es an einer anderen Stelle. Ich beschreibe mal kurz, was ich machen will:
In einem separaten Task soll überprüft werden, ob neue Daten vorhanden sind, die auf einem Bildschirm angezeigt werden sollen. Im Receiving-Teil wollte ich die dann aufbereiten und ausgeben. Da tritt aber der Kurzdump auf.
Im CALL FUNCTION-Loop kann ich die aber nicht ausgeben, weil ich ja nicht aus dem LOOP rauskomme um den PBO zu Ende zu führen.
Hat jemand eine Idee um asynchron auf Daten zu lauschen und die dann immer nur bei Bedarf auszugeben?
Beitrag
von a-dead-trousers (Top Expert / 4419 / 224 /
1189
)
»
Da du in deiner Anwendung auch eine Oberfläche mitbrtreust macht das die ganze Sache leider um einiges komplizierter. 
Man könnte aber per GUI-Timer eine "Aktualisierung" der Oberfläche auslösen. Theoretisch könntest du es so machen, dass wie bisher dein Task im Hintergrund läuft und die Ergebnisse beim Receive in eine interne Tabelle geschrieben werden. Beim nächsten Aktualisieren der Oberfläche werden die zwischengeparkten Daten angezeigt und wiederum der Task für die Suche gestartet (sofern er nicht bereits läuft).
Man könnte aber per GUI-Timer eine "Aktualisierung" der Oberfläche auslösen. Theoretisch könntest du es so machen, dass wie bisher dein Task im Hintergrund läuft und die Ergebnisse beim Receive in eine interne Tabelle geschrieben werden. Beim nächsten Aktualisieren der Oberfläche werden die zwischengeparkten Daten angezeigt und wiederum der Task für die Suche gestartet (sofern er nicht bereits läuft).
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von black_adept (Top Expert / 4116 / 129 /
951
)
»
DAnn schreib die Daten asynchron in irgend eine DB und das Hauptprogramm schaut da sporadisch rein und schaut ob was Neues drin steht.
Seite 1 von 1
Vergleichbare Themen
11
Antw.
Antw.
8095
Views
Views
CALL FUNCTION ... STARTING NEW TASK ... Task nachverfolgbar?
von Obelix1 » 30.01.2017 18:10 • Verfasst in ABAP® Core
von Obelix1 » 30.01.2017 18:10 • Verfasst in ABAP® Core
5
Antw.
Antw.
5511
Views
Views
2
Antw.
Antw.
5348
Views
Views
6
Antw.
Antw.
10366
Views
Views
Call Function ... in background task ? Aber wie?
von Nordlicht » 25.03.2015 11:25 • Verfasst in Dialogprogrammierung
von Nordlicht » 25.03.2015 11:25 • Verfasst in Dialogprogrammierung
0
Antw.
Antw.
977
Views
Views
RFC FUBA IN BACKROUNG TASK / STARTING NEW TASK
von EZ09 » 05.02.2023 22:54 • Verfasst in ABAP® für Anfänger
von EZ09 » 05.02.2023 22:54 • Verfasst in ABAP® für Anfänger
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.