Wie benutze ich COMMIT WORK richtig

Wie benutze ich COMMIT WORK richtig

Hallo,

Ich verstehe Commit Work nicht ganz.

Wenn ich in einem LOOP jedes Mal ein BAPI aufrufe und einzelne Datenbankeinträge(durch BAPI) ändere, soll dann anschließend bei jedem Erfolg Commit Work aufgerufen werden und bei Misserfolg ein rollback?

Oder Commit erst nach dem LOOP? Was passiert dann mit den Einträgen, die in ein Fehler gelaufen sind durch den BAPI?

Ziel ist es natürlich, bei jedem Erfolgsmeldung in die Datenbank zu schreiben und bei Misserfolge soll nichts in die Datenbank geschrieben werden (Rollback).

Soll ich auch mit einem WAIT beim COMMIT arbeiten?

Kann mir jemand weiterhelfen & die Unterschiede verständlich erklären?

Danke

Re: Wie benutze ich COMMIT WORK richtig

Ob in, oder ausserhalb vom LOOP, hängt davon ab, was du erreichen möchtest.

Wenn du es ausserhalb des LOOPs machst, hast du die Möglichkeit bei einem ROLLBACK alle zuvor angelegten Datensätze auch zu löschen. Wenn du es innerhalb des LOOPs machst, dann bezieht sich dein ROLLBACK nur auf den aktuellen Datensatz. Die davor hast du ja dann schon commited.

Bei BAPIs und FMs der SAP muss du immer in die Doku schauen. In einigen schreibt die SAP, dass der BAPI kein zweites mal aufgerufen werden darf, bevor nicht ein COMMIT/ROLLBACK gemacht wurde. Da hast du dann gar nicht die Wahl.

Ein WAIT musst du verwenden, wenn du später in deinem Programm auf das erstellte Objekt zugreifen möchtest. Durch WAIT erfolgt die Buchung synchron, d.h. es geht erst weiter, wenn die Daten auch tatsächlich persistiert sind. Ohne Wait läuft dein Programm direkt weiter und die Buchung findet im Hintergrund statt.

Die SAP Hilfe ist sehr ausführlich bei dem Thema
https://help.sap.com/doc/abapdocu_lates ... commit.htm

Re: Wie benutze ich COMMIT WORK richtig

Ich will den BAPI_PO_CHANGE in einem LOOP verwenden.

Was passiert mit den Einträgen, wo ein Fehler passiert ist, wenn ich einfach nach dem ENDLOOP ein COMMIT WORK mache?

Re: Wie benutze ich COMMIT WORK richtig

DeathAndPain hat geschrieben: ↑

19.04.2024 11:10

Die Frage ist, was Du unter "Fehler" verstehst. Wenn der Eintrag nicht geschrieben werden kann, kann er nicht geschrieben werden, egal wieviele COMMITs Du machst. Wenn Der Fehler allerdings so beschaffen ist, dass Du mehrere inhaltlich zusammenhängende Datensätze in die Datenbank geschrieben hast und der dritte davon konnte nicht geschrieben werden, daher willst Du auch nicht, dass die übrigen geschrieben werden, weil der Kram sonst nicht mehr konsistent ist, dann wäre es blöd, nach dem ersten geschriebenen Eintrag schon einen COMMIT zu machen, weil Du Dir damit die Möglichkeit nimmst, auch die erfolgreichen Schreibzugriffe mit einem ROLLBACK rückabzuwickeln. Das ist die Idee dahinter: Du schreibst alle inhaltlich zusammengehörigen Tabellenänderungen und machst dann einen COMMIT.

Wobei zu beachten ist, dass Puffer gefüllt werden, bis der COMMIT kommt, der sie auf die Datenbank schreibt. Wenn Du riesige Datenmengen schreibst, bevor Du irgendwann mal einen COMMIT machst, dann kannst Du hinsichtlich des Pufferspeicherplatzes in Probleme laufen.

Fehler ist, wenn ich vom BAPI in der Returntable eine Nachricht von Typ AEX habe.
Muss ich ein ROLLBACK machen, wenn ich nur diesen einen BAPI aufrufe und Fehler von Typ AEX habe? Kann ich direkt mit der nächsten Bestellung weitermachen, weil sowieso nichts in der Datenbank gespeichert wird bei dieser Fehlermeldung?

Hier wird nämlich auch kein ROLLBACK gemacht. Es wird nur ein COMMIT WORK gemacht, wenn keine Fehlermeldung vorhanden ist.
https://codezentrale.de/tag/bapi_po_change/

Re: Wie benutze ich COMMIT WORK richtig

ABAPlerv hat geschrieben: ↑

19.04.2024 13:43

Muss ich ein ROLLBACK machen, wenn ich nur diesen einen BAPI aufrufe und Fehler von Typ AEX habe?

Nein. Wenn der BAPI gescheitert ist, hat er nichts geschrieben, das zurückge"rollt" werden müsste.

ABAPlerv hat geschrieben: ↑

19.04.2024 13:43

Kann ich direkt mit der nächsten Bestellung weitermachen, weil sowieso nichts in der Datenbank gespeichert wird bei dieser Fehlermeldung?

Wenn das für Dich ok ist, dass diese eine Bestellung halt auf die Nase gefallen ist und Du mit der Tagesordnung weitermachen möchtest, als sei nichts geschehen, dann kannst Du das machen. Kann auch Sinn ergeben, wenn die Bestellungen nichts miteinander zu tun haben und Du für die fehlgeschlagenen die Fehler in einem Protokoll sammelst, um das sich später jemand händisch kümmern soll, ohne dass die einwandfrei funktionierenden dadurch ausgebremst werden sollen.

Einen Rollback brauchst Du dann und nur dann, wenn Du vorher schon Datensätze geschrieben hast, deren Schreiben geklappt hat, die Du aber auch mit rückabwickeln möchtest, weil sie durch Deinen Fehler keinen Sinn ergeben.

Frei erfundenes Beispiel: Du verringerst Deinen Lagerbestand um 1: erfolgreich. Dann schreibst Du den zugehörigen Warenausgang in die Datenbank: fehlgeschlagen. Dann willst Du auch den Lagerbestand (bis zur Klärung und Behebung des Sachverhalts) nicht verringert haben, daher machst Du einen ROLLBACK, der auch die erste Buchung rückgängig macht.

Hat hingegen beides geklappt, machst Du einen COMMIT, denn danach fängst Du mit der nächsten Buchung an, die mit diesem Vorgang nichts zu tun hat. Scheitert diese nächste Buchung, willst Du die erfolgreiche Bestandssenkung + Warenausgang nicht auch mit rückabwickeln. Ein ROLLBACK wickelt rück ab bis zum vorhergehenden COMMIT. Daher bestätigst Du mit einem COMMIT, dass Dein "Paket" zusammengehöriger Buchungen vollständig ist und in die Datenbank geschrieben werden darf, egal was danach dann noch scheitern mag.

black_adept hat geschrieben:Von daher würde ich im Fehlerfall immer den BAPI_TRANSACTION_ROLLBACK aufrufen.

Ich muss gestehen, dass ich nie verstanden habe, was der Vorteil dieses BAPIs gegenüber einem gewöhnlichen Befehl ROLLBACK WORK sein soll.

Re: Wie benutze ich COMMIT WORK richtig

msfox hat geschrieben: ↑

20.04.2024 19:31

Woher weißt du, dass ein BAPI nichts schreibt, wenn er eine Fehlermeldung liefert?

Weil ich in meiner Naivität davon ausgehe, dass der BAPI nicht komplett dilettantisch geschrieben ist. Wenn ich mich darauf nicht verlassen kann oder will, sollte ich den BAPI gar nicht benutzen.

Wenn ich einem BAPI die Anweisung gebe, einen logischen Informationsblock zu verbuchen und in die Datenbank wegzuschreiben, dann muss ich davon ausgehen können, dass er das entweder erledigt oder einen Fehler feststellt und daraufhin gar nichts verbucht, aber nicht, dass er möglicherweise die Hälfte verbucht und mir dann ohne Rollback eine Fehlermeldung zurückliefert und die Kontrolle zurückgibt. Ein solcher BAPI wäre der ultimative unprofessionelle Schrott und daher grundsätzlich zu meiden, weil man dann unterstellen muss, dass er auch in anderer Hinsicht unzuverlässig ist und nichts taugt.

Selbst wenn der BAPI einen Bug enthalten und dadurch komplett crashen würde (ABAP Dump), würde das intern automatisch einen Rollback auslösen. Er müsste also schon so dämlich geschrieben sein, meinem aufrufenden Code halb verbucht koordiniert die Kontrolle zurückzugeben. So einen Müll habe ich bei der SAP zum Glück noch nicht erlebt.

Re: Wie benutze ich COMMIT WORK richtig

Danke euch.

Das heißt zur Sicherheit, nehme ich nach einem Fehlschlagen von BAPI immer ein ROLLBACK.

Re: Wie benutze ich COMMIT WORK richtig

msfox hat geschrieben: ↑

20.04.2024 19:31

Und wenn man mit BAPI's arbeitet, dann nimmt man immer den FUba BAPI_TRANSACTION_COMMIT. Denn dieser macht intern nicht nur ein COMMIT, sondern verarbeitet/löscht auch noch Memories u.ä.

@D&P: Das ist m.E. der entscheidende Hinweis. Es gibt diverse BAPIs, die sich Sachen merken, weil sie z.B. durch eine Kette von BAPI-Aufrufen quasi angefüttert werden bis es dann zum finalen Buchen kommt ( z.B. im Projektsystem ). Aber auch sonst kann es sein, dass sich die BAPIs Sachen merken bzw. bei einem neuen Aufruf nicht vollständig initialisiert werden. Daher sollte beim Abschluss einer logischen Sequenz einer der beiden BAPIs zum Rollback oder Commit aufgerufen werden in der Hoffnung, dass SAP sauber programmiert hat.
In seltenen Fällen/BAPIS hilft aber selbst das nicht, so dass es dann zu Fehlermeldungen beim erneuten Aufruf des BAPIs kommt weil SAP ( oder der Kunde durch tolle Erweiterungen) vergessen hat etwas zu initialisieren. In solchen Fällen muss man als Ultima Ratio zu weiteren Maßnahmen greifen, um sicherzustellen, dass jeder BAPI ( evlt. BAPISequenz) vollständig initialisiert wird.