CALL FUNCTION '...' STARTING NEW TASK in RECEIVE-Methode

[nickname8]

Hallo Kollegen,

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.
 

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:

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.

 

LG

[a-dead-trousers]

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.

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.

Damit hast du im Hauptprogramm eine einfache Schleife die ein oder mehrere Tasks, je nachdem wie hoch das UNTIL ist, verwaltet.

[nickname8]

Hi,
danke dir für dein Feedback!

Ich glaub dein Problem ist, dass du das Konzept nicht ganz verstanden hast:

Doch, ich denke schon.

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.

Japp, ich weiß. Will ich auch.

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.

Das ist in Ordnung, das braucht den Zustand nicht zu behalten.

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.

[a-dead-trousers]

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.

Siehe mein Coding.
Der "Hauptprozess" muss das Lauschen anstoßen. Er muss also auch darauf "warten" bis seine Tasks fertig werden.

[nickname8]

Ok, hab die Schleife übersehen.
Ich gucke mal ob ich damit ans Ziel komme.

[nickname8]

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?

[black_adept]

AMC

[nickname8]

AMC

ABAP 7.02

[a-dead-trousers]

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).

[black_adept]

DAnn schreib die Daten asynchron in irgend eine DB und das Hauptprogramm schaut da sporadisch rein und schaut ob was Neues drin steht.