Parallelverarbeitung nich alle RFCs werden nicht verarbeitet
7 Beiträge
•
Seite 1 von 1
7 Beiträge
Seite 1 von 1
Hallo folks,
wir wollen bei uns die Parallelverarbeitung einsetzen und sind gerade in den finalen tests.
Wir setzen die RFC-Parallelverarebeitung über RZ12 Logongruppe ein.
Jetzt bekomme ich aber folgendes Problem. Alles funktioniert soweit, doch kommt es machmal vor, dass ich den FUBA via RFC Call aufrufe, der RFC aber hängen bleibt. In der SM04 sehe ich dann, dass ich 100mal angemeldet bin und der Funktionsbaustein kommt mit "sy-subrc 3 = resource failure" zurück. Die RFCs werden auch nie verarbeitet. Diese kommen auch nicht in die Formroutine get_prg120_para_results.
In der SM04 muss ich mich dann über "Benutzer abmelden" komplett aus dem System werfen.
Hier mal kurz das Coding von den AUfrufen:
Vielleicht hatte mal schon jemand von Euch dieses Phänomen und es liegt an irgend einem handling Fehler.
Für Eure Hife auf jedenfall jetzt schon besten Dank im Vorraus.
So long
Markus
wir wollen bei uns die Parallelverarbeitung einsetzen und sind gerade in den finalen tests.
Wir setzen die RFC-Parallelverarebeitung über RZ12 Logongruppe ein.
Jetzt bekomme ich aber folgendes Problem. Alles funktioniert soweit, doch kommt es machmal vor, dass ich den FUBA via RFC Call aufrufe, der RFC aber hängen bleibt. In der SM04 sehe ich dann, dass ich 100mal angemeldet bin und der Funktionsbaustein kommt mit "sy-subrc 3 = resource failure" zurück. Die RFCs werden auch nie verarbeitet. Diese kommen auch nicht in die Formroutine get_prg120_para_results.
In der SM04 muss ich mich dann über "Benutzer abmelden" komplett aus dem System werfen.
Hier mal kurz das Coding von den AUfrufen:
Code: Alles auswählen.
do.
call function 'YSDA01410_PRG120_PARA'
starting new task lv_tasknam
destination in group p_group
performing get_prg120_para_results on end of task
exporting
i_matrix = lw_matrix_matnr
i_xlast = lv_xlast
exceptions
communication_failure = 1 message vl_msg
system_failure = 2 message vl_msg
resource_failure = 3.
if sy-subrc is initial.
exit.
elseif sy-subrc eq 3.
wait up to 1 seconds.
endif.
enddo.
*Formroutine:
form get_prg120_para_results using up_tasknam type any.
data: lv_xlast_para type flag,
lw_vbestand like line of gt_vbestand.
receive results from function 'YSDA01410_PRG120_PARA'
importing
e_vbestand = lw_vbestand
e_xlast = lv_xlast_para.
if lw_vbestand is not initial.
insert lw_vbestand into table gt_vbestand.
endif.
if lv_xlast_para is not initial.
move lv_xlast_para to gv_xlast_para.
endif.
clear gv_xresource_failure. "Ressource wieder frei ...
endform. "get_prg120_para_results
Für Eure Hife auf jedenfall jetzt schon besten Dank im Vorraus.
So long
Markus
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Moin Markus.
Wenn ich sowas mache initialisiere ich die Umgebung vorher mit SPBT_INITIALIZE. Da bekommt man schon mal die maximal möglichen Tasks im Parameter MAX_PBT_WPS zurück. Während der Verarbeitung (bevor ich einen neuen Task abschicke) setze ich dann einen SPBT_GET_CURR_RESOURCE_INFO ab. Der liefert in FREE_PBT_WPS die derzeit freien Tasks zurück. Den nächsten RFC setze ich nur dann ab, wenn hier irgendwas > 0 zurück geliefert wird. Wenn nicht alles schief läuft sollte der RFC dann nicht auf den Poller laufen.
Generell merke ich mir immer, wie viele Tasks derzeit laufen und baue mir dann auch eine Obergrenze ein, so dass ich das System auf keinen Fall komplett lahmlege. Hat sich bewährt...
Grüße,
Haubi
Wenn ich sowas mache initialisiere ich die Umgebung vorher mit SPBT_INITIALIZE. Da bekommt man schon mal die maximal möglichen Tasks im Parameter MAX_PBT_WPS zurück. Während der Verarbeitung (bevor ich einen neuen Task abschicke) setze ich dann einen SPBT_GET_CURR_RESOURCE_INFO ab. Der liefert in FREE_PBT_WPS die derzeit freien Tasks zurück. Den nächsten RFC setze ich nur dann ab, wenn hier irgendwas > 0 zurück geliefert wird. Wenn nicht alles schief läuft sollte der RFC dann nicht auf den Poller laufen.
Generell merke ich mir immer, wie viele Tasks derzeit laufen und baue mir dann auch eine Obergrenze ein, so dass ich das System auf keinen Fall komplett lahmlege. Hat sich bewährt...
Grüße,
Haubi
Folgende Benutzer bedankten sich beim Autor Haubi für den Beitrag (Insgesamt 2):
wayder • a-dead-trousers
Das sieht mir sehr nach einer Endlosschleife aus, in der Du immer und immer wieder den gleichen FuBa aufrufst.
Du faengst auch nur Sy-subrc EQ 0 oder 3 ab, aber nicht 1 und 2???
Bei Sy-subrc 1 oder 2 wird der FuBa wiederholt aufgerufen???
Evlt. hilft "WAIT UNTIL ....": Use the statement WAIT UNTIL to stop the program execution until certain callback routines or all callback routines have been executed.
Code: Alles auswählen.
Do.
Call Fuba...
if sy-subrc is initial.
exit.
elseif sy-subrc eq 3.
wait up to 1 seconds. Wenn Fehler, ok ruf den gleichen Fuba in 1 sec. noch mal auf???
endif.
enddo.Bei Sy-subrc 1 oder 2 wird der FuBa wiederholt aufgerufen???
Evlt. hilft "WAIT UNTIL ....": Use the statement WAIT UNTIL to stop the program execution until certain callback routines or all callback routines have been executed.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Die Bausteine muss ich gleich mal ausprobieren! Danke!Haubi hat geschrieben:Wenn ich sowas mache initialisiere ich die Umgebung vorher mit SPBT_INITIALIZE. Da bekommt man schon mal die maximal möglichen Tasks im Parameter MAX_PBT_WPS zurück. Während der Verarbeitung (bevor ich einen neuen Task abschicke) setze ich dann einen SPBT_GET_CURR_RESOURCE_INFO ab. Der liefert in FREE_PBT_WPS die derzeit freien Tasks zurück. Den nächsten RFC setze ich nur dann ab, wenn hier irgendwas > 0 zurück geliefert wird. Wenn nicht alles schief läuft sollte der RFC dann nicht auf den Poller laufen.
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
Tach.Unit605 hat geschrieben:Das sieht mir sehr nach einer Endlosschleife aus, in der Du immer und immer wieder den gleichen FuBa aufrufst.Du faengst auch nur Sy-subrc EQ 0 oder 3 ab, aber nicht 1 und 2???Code: Alles auswählen.
Do. Call Fuba... if sy-subrc is initial. exit. elseif sy-subrc eq 3. wait up to 1 seconds. Wenn Fehler, ok ruf den gleichen Fuba in 1 sec. noch mal auf??? endif. enddo.
Bei Sy-subrc 1 oder 2 wird der FuBa wiederholt aufgerufen???
Evlt. hilft "WAIT UNTIL ....": Use the statement WAIT UNTIL to stop the program execution until certain callback routines or all callback routines have been executed.
Der WAIT UP TO steht da ja nur, um im Falle eines Resource Failures (=alle Dialog-Tasks der Gruppe belegt) einen neuen Versuch zu machen. Ich gebe Dir aber insofern Recht, als dass die SUBRCs 1 & 2 ebenfalls behandelt werden müssen, ansonsten kommt es zur Endlosschleife.
Wenn übrigens ein Task während der Wartezeit bei WAIT UP TO zurück kommt löst das ebenfalls die Verarbeitung der Routine aus, die bei "PERFORMING" angegeben wurde (analog zu WAIT UNTIL).
Übrigens gibt es mittlerweile den Zusatz "CALLING <method>" (statt "PERFORMING <form") zur Ausführung einer OO-Methode zu Taskende.
Grüße,
Haubi
Hallo folks,
vielen Dank für die Postings. Den Code habe ich etwas abgeändert, dass nicht alles dran steht. sy-subrc 1 & 2 werden auch mit abgefragt. Die Geschichte mit den freien LUW's habe ich noch eingebaut, jedoch bekam ich das gleiche problem. Die RFC's bauten sich nicht ab.
Vielleicht liegt es auch am Kernel. Wir haben bei uns SAP_BASIS 700 0025 SAPKB70025 / SAPKA70025
Das Problem tritt nicht auf, wenn ich den Zusatz "performing get_prg120_para_results on end of task" weg lasse. Daher habe ich jetzt das ganze wie folgt gemacht:
In meinem Fuba baue ich eine Temp-Tabelle auf der Datenbank auf die für alle RFC aufrufe die gleiche ID + Taskname hat.
Danach prüfe ich ab, ob alle Requests verarbeitet wurde (Anzahl RFC Aufrufe zu Anzahl DB einträge zur ID). Dann kann ich das Ergebnis, das ind er Tabelle steht wieder holen und danach die Tabelle mit der ID löschen.
Ist nicht gerade schön, da ich die DB damit belaste aber was anderes fiel mir nicht ein. Ich werde aber bei der SAP noch eine OSS Meldung hierzu auch aufmachen, denn das Probelm ist bei unsererm System leicht nachzustellen.
Vielen Dank nochmals für die Hilfe !!
Grüße aus dem Hohenlohischen
Markus
vielen Dank für die Postings. Den Code habe ich etwas abgeändert, dass nicht alles dran steht. sy-subrc 1 & 2 werden auch mit abgefragt. Die Geschichte mit den freien LUW's habe ich noch eingebaut, jedoch bekam ich das gleiche problem. Die RFC's bauten sich nicht ab.
Vielleicht liegt es auch am Kernel. Wir haben bei uns SAP_BASIS 700 0025 SAPKB70025 / SAPKA70025
Das Problem tritt nicht auf, wenn ich den Zusatz "performing get_prg120_para_results on end of task" weg lasse. Daher habe ich jetzt das ganze wie folgt gemacht:
In meinem Fuba baue ich eine Temp-Tabelle auf der Datenbank auf die für alle RFC aufrufe die gleiche ID + Taskname hat.
Danach prüfe ich ab, ob alle Requests verarbeitet wurde (Anzahl RFC Aufrufe zu Anzahl DB einträge zur ID). Dann kann ich das Ergebnis, das ind er Tabelle steht wieder holen und danach die Tabelle mit der ID löschen.
Ist nicht gerade schön, da ich die DB damit belaste aber was anderes fiel mir nicht ein. Ich werde aber bei der SAP noch eine OSS Meldung hierzu auch aufmachen, denn das Probelm ist bei unsererm System leicht nachzustellen.
Vielen Dank nochmals für die Hilfe !!
Grüße aus dem Hohenlohischen
Markus
Tach.
Da kommt mir noch eine Idee: Setzt Du denn außer dem "WAIT UP TO 1 SECONDS" noch irgend einen anderen WAIT ab?
Ich hatte in meinem letzten Posting bereits angedeutet, dass die Routine zu Taskende nur abgearbeitet wird, während ein WAIT läuft. Kommt kein WAIT bleibt der Task offen! Das könnte Deine Fehlerursache sein.
Grüße,
Haubi
Da kommt mir noch eine Idee: Setzt Du denn außer dem "WAIT UP TO 1 SECONDS" noch irgend einen anderen WAIT ab?
Ich hatte in meinem letzten Posting bereits angedeutet, dass die Routine zu Taskende nur abgearbeitet wird, während ein WAIT läuft. Kommt kein WAIT bleibt der Task offen! Das könnte Deine Fehlerursache sein.
Grüße,
Haubi
Seite 1 von 1
Vergleichbare Themen
3
Antw.
Antw.
1594
Views
Views
0
Antw.
Antw.
8576
Views
Views
Instandhaltung: Rückmeldungen Serviceaufträge per IDOC nicht verarbeitet im Eingang. PPCC2PRETTICKET
von Romaniac » 25.03.2020 19:42 • Verfasst in Sonstige Module
von Romaniac » 25.03.2020 19:42 • Verfasst in Sonstige Module
1
Antw.
Antw.
1389
Views
Views
VA22 Nachricht wird beim Sichern verarbeitet - aber kein Spool erstellt.
von Pfalz-Zauber » 13.03.2024 13:36 • Verfasst in ABAP® Core
von Pfalz-Zauber » 13.03.2024 13:36 • Verfasst in ABAP® Core
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 21 Stunden von DeathAndPain 4 / 839
vor 21 Stunden von DeathAndPain 4 / 839
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 21 Stunden von DeathAndPain 4 / 839
vor 21 Stunden von DeathAndPain 4 / 839