BACKGROUND TASK bei DB_COMMIT
6 Beiträge
•
Seite 1 von 1
6 Beiträge
Seite 1 von 1
Hallo zusammen,
wir würden gerne im BAdI MD_MRP_LIST (Erstellung Dispoliste) eine Folgeverarbeitung starten, indem wir einen Funktionsbaustein als BACKGROUND TASK AS SEPARATE UNIT abschicken. Funktioniert soweit auch ganz gut.... allerdings funktioniert es nicht mehr, wenn z.B. die MD02 als Batch Input aufgerufen wird... in diesem Fall wird der FuBa nicht ausgeführt... wir erkennen das daran, weil die zu erwartenden Ergebnisse nicht eintreten. Jetzt habe ich etwas recherchiert und herausgefunden, dass RFC Funktionsbausteine erst getriggert werden, sobald das erste Mal ein COMMIT WORK erfolgt. Im Fall der Dispolistenerstellung ist es allerdings so, dass dort kein COMMIT WORK erfolgt, wenn per Batch Input aufgerufen wird. Stattdessen wird der Funtkionsbaustein "DB_COMMIT" aufgerufen, wenn SY-BINPT = 'X' (siehe Funktionsbaustein HINZUFUEGEN_NEW_DISPOSITION Zeile 166). Und anscheinend werden dann die RFC-Funktionsbausteine nicht gestartet, weil diese ja nur im COMMIT WORK getriggert werden?! Habt ihr hierfür einen Lösungsvorschlag?
Viele Grüße
Daniel
wir würden gerne im BAdI MD_MRP_LIST (Erstellung Dispoliste) eine Folgeverarbeitung starten, indem wir einen Funktionsbaustein als BACKGROUND TASK AS SEPARATE UNIT abschicken. Funktioniert soweit auch ganz gut.... allerdings funktioniert es nicht mehr, wenn z.B. die MD02 als Batch Input aufgerufen wird... in diesem Fall wird der FuBa nicht ausgeführt... wir erkennen das daran, weil die zu erwartenden Ergebnisse nicht eintreten. Jetzt habe ich etwas recherchiert und herausgefunden, dass RFC Funktionsbausteine erst getriggert werden, sobald das erste Mal ein COMMIT WORK erfolgt. Im Fall der Dispolistenerstellung ist es allerdings so, dass dort kein COMMIT WORK erfolgt, wenn per Batch Input aufgerufen wird. Stattdessen wird der Funtkionsbaustein "DB_COMMIT" aufgerufen, wenn SY-BINPT = 'X' (siehe Funktionsbaustein HINZUFUEGEN_NEW_DISPOSITION Zeile 166). Und anscheinend werden dann die RFC-Funktionsbausteine nicht gestartet, weil diese ja nur im COMMIT WORK getriggert werden?! Habt ihr hierfür einen Lösungsvorschlag?
Viele Grüße
Daniel
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Der Baustein, der im BACKGROUND TASK ausgeführt wird, sollte in den Tabellen ARFCSSTATE und ARFCSDATA vorhanden sein, auch wenn nur ein Datenbank-Commit mit dem Baustein DB_COMMIT ausgeführt wird.
Hier gibt es ja den Report RSARFCSE, der versucht diese Bausteine noch einmal zu verbuchen.
Vielleicht kannst du mit diesem Report die Verarbeitung noch dem COMMIT nochmals anstoßen.
Die TID (Transaktionkennung) kannst du dir mit dem Baustein ID_OF_BACKGROUNDTASK besorgen und daraufhin den Report RSARFCSE anstarten.
Hier gibt es ja den Report RSARFCSE, der versucht diese Bausteine noch einmal zu verbuchen.
Vielleicht kannst du mit diesem Report die Verarbeitung noch dem COMMIT nochmals anstoßen.
Die TID (Transaktionkennung) kannst du dir mit dem Baustein ID_OF_BACKGROUNDTASK besorgen und daraufhin den Report RSARFCSE anstarten.
Publikationen:
Qualitätsmanagement in der ABAP-Entwicklung,
Why we should take care about clean code
ABAP, Java, JavaScript
GitHub
Qualitätsmanagement in der ABAP-Entwicklung,
Why we should take care about clean code
ABAP, Java, JavaScript
GitHub
Hallo Jocoder,
vielen Dank für deine Antwort. Ich habe mir das jetzt mal angeschaut... und ich befürchte leider, dass die Einträge in den beiden Tabellen eben nicht erzeugt werden beim FuBa DB_COMMIT. Hab jetzt sogar für beide Szenarien einen DB Trace laufen lassen... beim klassischen Commit gibt es mehrere INSERT, UPDATE und DELETE Kommandos auf die beiden Tabellen, beim DB_COMMIT keinen einzigen DB-Zugriff.
Hast du denn sonst noch eine Idee?
Vielen Dank.
vielen Dank für deine Antwort. Ich habe mir das jetzt mal angeschaut... und ich befürchte leider, dass die Einträge in den beiden Tabellen eben nicht erzeugt werden beim FuBa DB_COMMIT. Hab jetzt sogar für beide Szenarien einen DB Trace laufen lassen... beim klassischen Commit gibt es mehrere INSERT, UPDATE und DELETE Kommandos auf die beiden Tabellen, beim DB_COMMIT keinen einzigen DB-Zugriff.
Hast du denn sonst noch eine Idee?
Vielen Dank.
habe hier noch einen interessante Erklärung zum FuBa DB_COMMIT gefunden:
Im Gegensatz Zur Anweisung COMMIT WORK in Open SQL schließt der Aufruf von DB_COMMIT die aktuelle SAP LUW nicht ab, d.h. die an das Ende eine SAP LUW gekoppelten Ereignisse (siehe Dokumentation zu COMMIT WORK) werden nicht ausgelöst.
Eventuell ist ja auch das Ausführen der tRFC Bausteine eines dieser Ereignisse?!
Im Gegensatz Zur Anweisung COMMIT WORK in Open SQL schließt der Aufruf von DB_COMMIT die aktuelle SAP LUW nicht ab, d.h. die an das Ende eine SAP LUW gekoppelten Ereignisse (siehe Dokumentation zu COMMIT WORK) werden nicht ausgelöst.
Eventuell ist ja auch das Ausführen der tRFC Bausteine eines dieser Ereignisse?!
Handelt es sich beim Batch-Input um einen einfachen Transaktionsaufruf ohne Batch-Input-Tabelle oder wird der Befehl CALL TRANSACTION mit einer Batch-Input-Tabelle ausgeführt?
Bei einer Batch-Input-Tabelle gibt es über den OPTIONS-Zusatz die Möglichkeit sy-binpt auf abap_false zu lassen und damit führt der Baustein HINZUFUEGEN_NEW_DISPOSTION den OpenSQL-Befehl COMMIT WORK aus und schließt damit die SAP-LUW ab.
So ungefährt müsste der CALL TRANSACTION-Befehl aussehen:
Bei einer Batch-Input-Tabelle gibt es über den OPTIONS-Zusatz die Möglichkeit sy-binpt auf abap_false zu lassen und damit führt der Baustein HINZUFUEGEN_NEW_DISPOSTION den OpenSQL-Befehl COMMIT WORK aus und schließt damit die SAP-LUW ab.
So ungefährt müsste der CALL TRANSACTION-Befehl aussehen:
Code: Alles auswählen.
DATA: batch_input_options TYPE ctu_params,
batch_input_steps TYPE STANDARD TABLE OF bdcdata.
batch_input-options-nobinpt = abap_true.
CALL TRANSACTION 'MD02'
USING batch_input_steps
OPTIONS FROM batch_input_options.
Publikationen:
Qualitätsmanagement in der ABAP-Entwicklung,
Why we should take care about clean code
ABAP, Java, JavaScript
GitHub
Qualitätsmanagement in der ABAP-Entwicklung,
Why we should take care about clean code
ABAP, Java, JavaScript
GitHub
das ist ein sehr guter Hinweis... vielen Dank. Damit ich das ganze dann wasserdicht bekomme, werde ich im BADI auf die Systemvariable SY-BINPT prüfen... wenn = 'X' schicke ich den FuBa nicht als BACKGROUND TASK ab. Gleichzeitig versuche ich, dass die MD02 möglichst wenig als Batch Input aufgerufen wird.
Danke.
Danke.
Seite 1 von 1
Vergleichbare Themen
6
Antw.
Antw.
9716
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
16
Antw.
Antw.
873
Views
Views
Parameter wird nicht an FuBa in Background Task übergeben
von Xilukarim » 02.12.2022 11:49 • Verfasst in ABAP® Core
von Xilukarim » 02.12.2022 11:49 • Verfasst in ABAP® Core
11
Antw.
Antw.
7109
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
0
Antw.
Antw.
229
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.
2317
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
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.