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.
Beitrag von a-dead-trousers (Top Expert / 3238 / 81 / 817 ) » 12. Feb 2019 11:25
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.07
Basis: 7.40
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.07
Basis: 7.40
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 / 3238 / 81 / 817 ) » 12. Feb 2019 11:41
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.07
Basis: 7.40
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.07
Basis: 7.40
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 / 3238 / 81 / 817 ) » 12. Feb 2019 15:16
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.07
Basis: 7.40
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.07
Basis: 7.40
Beitrag von black_adept (Top Expert / 3256 / 54 / 574 ) » 12. Feb 2019 15:18
DAnn schreib die Daten asynchron in irgend eine DB und das Hauptprogramm schaut da sporadisch rein und schaut ob was Neues drin steht.
Frage die ABAP Experten
Wähle das Themengebiet für deine Frage an die ABAP Experten:
Aktuelle Forenbeiträge
VL10B - Partner ändern -> Funktionsbaustein?
vor 13 Stunden von black_adept 2 / 44
vor 13 Stunden von black_adept 2 / 44
Datenaustausch mit externen Lieferanten
vor 20 Stunden von DeathAndPain 5 / 162
vor 20 Stunden von DeathAndPain 5 / 162
Vorschlagswerte IT0700
vor 23 Stunden von DeathAndPain 8 / 122
vor 23 Stunden von DeathAndPain 8 / 122
Aktuelle Forenbeiträge
VL10B - Partner ändern -> Funktionsbaustein?
vor 13 Stunden von black_adept 2 / 44
vor 13 Stunden von black_adept 2 / 44
Datenaustausch mit externen Lieferanten
vor 20 Stunden von DeathAndPain 5 / 162
vor 20 Stunden von DeathAndPain 5 / 162
Vorschlagswerte IT0700
vor 23 Stunden von DeathAndPain 8 / 122
vor 23 Stunden von DeathAndPain 8 / 122
Stellenangebote
(Junior) Developer for SAP Fiori launchpad Core & UX Job bei SAP
vor 2 Wochen 72
vor 2 Wochen 72
Development Manager for SAP Concur Travel Job bei SAP
vor 3 Wochen 164
vor 3 Wochen 164
Unbeantwortete Forenbeiträge
SP01 Verweildauer
vor 4 Tagen von SAP_ENTWICKLER 1 / 67
vor 4 Tagen von SAP_ENTWICKLER 1 / 67
Transaktion OMT3B Subscreens in Dynpros einhängen
vor 5 Tagen von SAP_ENTWICKLER 1 / 49
vor 5 Tagen von SAP_ENTWICKLER 1 / 49
Zeitereignisarten anlegen
vor einer Woche von Flashtie 1 / 160
vor einer Woche von Flashtie 1 / 160
Genehmiger & Status der Genehmigung bei einer BANF
vor 3 Wochen von Der Formulator 1 / 233
vor 3 Wochen von Der Formulator 1 / 233
Migrationstool Upload QUAN und CURR Felder
vor 3 Wochen von SAP_ENTWICKLER 1 / 222
vor 3 Wochen von SAP_ENTWICKLER 1 / 222