CALL FUNCTION ... STARTING NEW TASK ... Task nachverfolgbar?
12 Beiträge
•
Seite 1 von 1
12 Beiträge
Seite 1 von 1
Liebe Leute,
nachdem ich mit "CALL FUNCTION FuBa STARTING NEW TASK TaskID" den FuBa gewissermaßen in den Hintergrund geschickt habe, habe ich ja außer der TaskID nichts mehr in der Hand, um diesen Hintergrundprozeß im Auge zu behalten. Irgendwann wird hoffentlich die Callback-Routine gerufen, die ich mit "PERFORMING routine ON END OF TASK" mitgegeben habe, und da bekomme ich auch die jeweilige TaskID zurück.
Was aber, wenn die Callback-Routine nie gerufen wird, weil der FuBa einfach sooo lange dauert, unerwartet viele Daten zu verarbeiten hat, in eine Endlosschleife rennt oder was auch immer? Dann brauche ich irgendeine Möglichkeit, sich evtl. ansammelnde, "ewig" laufende Hintergrundprozesse zwangsweise abzubrechen.
Alles was ich habe ist aber eine Liste der TaskID's, die sich bisher noch nicht zurückgemeldet haben. Kann ich anhand einer TaskID z.B. die Workprozessnummer oder die PID auf Systemebene herausfinden? In den gängigen APIs habe ich nichts gefunden...
Gruß&Dank
Wolfgang
nachdem ich mit "CALL FUNCTION FuBa STARTING NEW TASK TaskID" den FuBa gewissermaßen in den Hintergrund geschickt habe, habe ich ja außer der TaskID nichts mehr in der Hand, um diesen Hintergrundprozeß im Auge zu behalten. Irgendwann wird hoffentlich die Callback-Routine gerufen, die ich mit "PERFORMING routine ON END OF TASK" mitgegeben habe, und da bekomme ich auch die jeweilige TaskID zurück.
Was aber, wenn die Callback-Routine nie gerufen wird, weil der FuBa einfach sooo lange dauert, unerwartet viele Daten zu verarbeiten hat, in eine Endlosschleife rennt oder was auch immer? Dann brauche ich irgendeine Möglichkeit, sich evtl. ansammelnde, "ewig" laufende Hintergrundprozesse zwangsweise abzubrechen.
Alles was ich habe ist aber eine Liste der TaskID's, die sich bisher noch nicht zurückgemeldet haben. Kann ich anhand einer TaskID z.B. die Workprozessnummer oder die PID auf Systemebene herausfinden? In den gängigen APIs habe ich nichts gefunden...
Gruß&Dank
Wolfgang
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
mit so etwas aehnlichen wie "WAIT UNTIL....." http://help.sap.com/abapdocu_70/de/ABAPWAIT_UNTIL.htm
Code: Alles auswählen.
* Warten auf Resultate:
WAIT UNTIL g_callback_counter = g_callback_max UP TO 300 SECONDS.
IF g_callback_counter < g_callback_max.
MESSAGE '.....
ENDIF.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Eine Steuerung und Überwachung von Programmteilen die asynchron laufen sollen könnte man eventuell über IMC (Inter Modus Communication) bewerkstelligen. Das ist die Technologie mit der der neue Debugger arbeitet.
In Ennos Tricktresor gibts dazu eine kurze Beschreibung:
http://www.tricktresor.de/blog/interpro ... unikation/
Leider müsste man sich da selber ziemlich reinfuchsen, ehe was brauchbares ala CALL FUNCTION ... STARTING NEW TASK rauskommt, da die Kommunikation nur über String-Nachrichten erfolgt. Auch hab ich dazu kaum Informationsmaterial im Netz gefunden. Das einzige was ich damit bislang zusammengebracht hab, ist eine Möglichkeit andere Transaktionen, Programme oder Funktionsgruppen aufzurufen und beim Verlassen des Vater-Prozesses diese Kind-Prozesse zu beenden. Eine "echte" Komunikation und Überwachung ist das noch lange nicht, da die aufgerufenen Unter-Programmteile ja Rückmeldung über ihren aktuellen Status geben und auf Eingaben des Vater-Prozesses reagieren müssten. Dazu müsste zum Beispiel wenn ein Funktionsbaustein aufgerufen werden soll, dieser seinen aktuellen Status ähnlich wie SAPGUI_PROGRESS_INDICATOR dem Vater-Prozess mitteilen. Man merkt, dass man Standardfunktionsbausteine und BAPIs in diesem Umfeld nur bedingt einsetzen kann und deswegen eigentlich alles Neu schreiben müsste.
lg ADT
In Ennos Tricktresor gibts dazu eine kurze Beschreibung:
http://www.tricktresor.de/blog/interpro ... unikation/
Leider müsste man sich da selber ziemlich reinfuchsen, ehe was brauchbares ala CALL FUNCTION ... STARTING NEW TASK rauskommt, da die Kommunikation nur über String-Nachrichten erfolgt. Auch hab ich dazu kaum Informationsmaterial im Netz gefunden. Das einzige was ich damit bislang zusammengebracht hab, ist eine Möglichkeit andere Transaktionen, Programme oder Funktionsgruppen aufzurufen und beim Verlassen des Vater-Prozesses diese Kind-Prozesse zu beenden. Eine "echte" Komunikation und Überwachung ist das noch lange nicht, da die aufgerufenen Unter-Programmteile ja Rückmeldung über ihren aktuellen Status geben und auf Eingaben des Vater-Prozesses reagieren müssten. Dazu müsste zum Beispiel wenn ein Funktionsbaustein aufgerufen werden soll, dieser seinen aktuellen Status ähnlich wie SAPGUI_PROGRESS_INDICATOR dem Vater-Prozess mitteilen. Man merkt, dass man Standardfunktionsbausteine und BAPIs in diesem Umfeld nur bedingt einsetzen kann und deswegen eigentlich alles Neu schreiben müsste.
lg ADT
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
Klar, das ist das übliche. Anstelle der MESSAGE '... hätte ich aber gerne eine Möglichkeit, der fehlenden Callbacks irgendwie habhaft zu werden. Das scheint nicht so ohne weiteres möglich zu sein.Unit605 hat geschrieben:mit so etwas aehnlichen wie "WAIT UNTIL....." http://help.sap.com/abapdocu_70/de/ABAPWAIT_UNTIL.htm
Code: Alles auswählen.
* Warten auf Resultate: WAIT UNTIL g_callback_counter = g_callback_max UP TO 300 SECONDS. IF g_callback_counter < g_callback_max. MESSAGE '..... ENDIF.
VG
Wolfgang
Was hättest du denn vor, wenn du ihn greifen könntest?Obelix1 hat geschrieben: hätte ich aber gerne eine Möglichkeit, der fehlenden Callbacks irgendwie habhaft zu werden.
Wenn die Verarbeitung extrem lange dauert, dauert auch das Aufrufende Programm extrem lange. Es sei denn, du ignorierst, dass du von allen gestarteten Tasks auch auf eine Rückmeldung wartest.
Ob unerwartet viele Daten verarbeitet werden müssten, kann man ja vorher prüfen...
ihn schlicht abbrechen. Denn es gibt Zustände, bei denen man davon ausgehen muß, daß er nie mehr fertig wird.ewx hat geschrieben:Was hättest du denn vor, wenn du ihn greifen könntest?
Es kann immer zu Verklemmungen kommen, z.B. wenn ein RFC hängt. Wenn das bei Massenverarbeitungen häufiger passiert, sammeln sich irgendwann diese Hänger an. Ich will einen Maximal-Timeout haben, nach dessen Ablauf alle Tasks, die sich bis dahin immer noch nicht zurückgemeldet haben, abgebrochen werden. Dazu genügt mir aber die TaskID nicht, dazu brauche ich eine Prozess-ID. Habe ich eine Chance, an die ranzukommen?ewx hat geschrieben:Es sei denn, du ignorierst, dass du von allen gestarteten Tasks auch auf eine Rückmeldung wartest.
VG
Wolfgang
Müssten die Kind-Prozesse nicht beendet werden, wenn das Hauptprogramm beendet wird?
Hast du das mal ausprobiert?
ansonsten kommst du an den Prozess glaube ich nicht mehr dran.
Hast du das mal ausprobiert?
ansonsten kommst du an den Prozess glaube ich nicht mehr dran.
Natürlich, aber das Hauptprogramm soll ja weiterlaufen, u.U. tatsächlich sehr lange. Für eine Massenverarbeitung werden nacheinander mehrere tausend Kind-Prozesse gestartet, es ist immer möglich dass sich ein paar Prozent davon nie zurückmelden, wegen Verklemmungen, RFC-Hängern oder warum auch immer. Das wären dann gut über 100 ressourcenfressende Zombies.ewx hat geschrieben:Müssten die Kind-Prozesse nicht beendet werden, wenn das Hauptprogramm beendet wird?
Ich überlege jetzt eine Lösung, bei der jeder Kind-Prozeß seine Prozeß-ID in eine Datenbank einträgt und das Hauptprogramm die in der Callback-Routine wieder löscht. Bei jedem zwischen-Timeout würden alle in der Datenbank verbliebenen Prozeß-IDs zwangsweise abgebrochen.
Hat jemand eine besserre Idee?
VG
Wolfgang
Und dann mit TH_STOP_WP beenden?
Dann doch vielleicht lieber einen Job, der mittels TH_WPINFO alle Prozesse einliest und alle, die länger als x gelaufen sind, löschen.
Dann doch vielleicht lieber einen Job, der mittels TH_WPINFO alle Prozesse einliest und alle, die länger als x gelaufen sind, löschen.
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Kannst du evtl. mit den RFC-Tasks via Push-Channel kommunizieren? Gib den FuBas die TASK-ID mit, mit denen sie gestartet wurden ( vielleicht kann die der FuBa auch selbst ermitteln - weiß ich nicht ) und die FuBas melden in dem Push-Channel ihre eigene WorkProcess-ID und TASK-ID zurück oder was auch immer du zum Identifizieren brauchst.
Dann hast du die Dinger im Zugriff und könntest die vielleicht sogar überreden ihren aktuellen Fortschritt in den Channel zu senden, so dass du sogar siehst wie weit die einzelnen Prozesse jeweils sind oder bei welchem Datensatz die gerade hängen oder was sonst ihr Problem ist..
Dann hast du die Dinger im Zugriff und könntest die vielleicht sogar überreden ihren aktuellen Fortschritt in den Channel zu senden, so dass du sogar siehst wie weit die einzelnen Prozesse jeweils sind oder bei welchem Datensatz die gerade hängen oder was sonst ihr Problem ist..
Interessant, das kannte ich noch nicht. Da müsste ich mich reinwühlen. Scheint aber eher etwas von der Sorte "Kanonen und Spatzen" zu sein.black_adept hat geschrieben:Kannst du evtl. mit den RFC-Tasks via Push-Channel kommunizieren?
Mal sehen...
Danke
Wolfgang
Hi,
ist zwar schon ein paar Tage her, aber dennoch:
Habt Ihr Euch den ABAP Wait mal genauer angesehen? https://help.sap.com/http.svc/rc/abapdo ... _until.htm
Ich habe damit mal so etwas gebaut:
Ich rufe den RFC-fähigen Baustein aus einer Klasse, die Callback-Routine receive_check_results ist eine public-Methode, die das Ergebnis in die globale Attributstruktur gs_check_result zurückschreibt.
Wichtig: Der Prozess läuft maximal g_check_timeout seconds lang und wird dann ggf. abgebrochen. So kann ich erkennen, ob der Callback erfolgt ist oder auf einen Timeout gelaufen ist. Timeout ist auch über den sy-subrc auswertbar.
Oder hab ich die Zielstellung nicht richtig verstanden?
Grüße,
Hiob
ist zwar schon ein paar Tage her, aber dennoch:
Habt Ihr Euch den ABAP Wait mal genauer angesehen? https://help.sap.com/http.svc/rc/abapdo ... _until.htm
Ich habe damit mal so etwas gebaut:
Code: Alles auswählen.
call function 'Z_FUNCTION_RFC'
starting new task 'TEST1'
destination 'NONE'
calling receive_check_results on end of task.
wait for asynchronous tasks
until gs_check_result is not initial
up to g_check_timeout seconds.
Wichtig: Der Prozess läuft maximal g_check_timeout seconds lang und wird dann ggf. abgebrochen. So kann ich erkennen, ob der Callback erfolgt ist oder auf einen Timeout gelaufen ist. Timeout ist auch über den sy-subrc auswertbar.
Oder hab ich die Zielstellung nicht richtig verstanden?
Grüße,
Hiob
Seite 1 von 1
Vergleichbare Themen
5
Antw.
Antw.
5354
Views
Views
9
Antw.
Antw.
6149
Views
Views
CALL FUNCTION '...' STARTING NEW TASK in RECEIVE-Methode
von nickname8 » 12.02.2019 09:58 • Verfasst in ABAP® Core
von nickname8 » 12.02.2019 09:58 • Verfasst in ABAP® Core
0
Antw.
Antw.
699
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
1
Antw.
Antw.
2697
Views
Views
2
Antw.
Antw.
5215
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1129
vor 2 Tagen von DeathAndPain 4 / 1129
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1129
vor 2 Tagen von DeathAndPain 4 / 1129