commit work problem bei Verbucherbausteine
12 Beiträge
•
Seite 1 von 1
12 Beiträge
Seite 1 von 1
Hallo Leute,
Folgendes Problem:
Mit dem FB L_TO_CREATE_MOVE_SU erstelle ich einen Transportauftrag mit einem Commit Work. Danach mache ich einen Select single auf die LTAP.
Des Weiteren habe ich auch Verbucherfunktionsbausteine (asyncron) die später aufgerufen werden.
Nun passiert folgendes:
Wenn ich die VFB's im Code habe, dann findet er keinen Eintrag beim Select auf die LTAP. Wenn ich die VFB's aber auskommentiere, dann findet er einen Eintrag in der LTAP. Wenn ich aber vor dem Select "wait up to 1 seconds" mache, dann findet er den Eintrag sowohl mit VFB's als auch ohne.
Kann mir das jemand erklären???
Es sieht ja so aus als ob der commit work bei einem Programm wo es Verbuchungsbausteine gibt, länger dauert als bei einem ohne VFB's. Das darf doch aber nicht sein!?
Gruß
dimes
Folgendes Problem:
Mit dem FB L_TO_CREATE_MOVE_SU erstelle ich einen Transportauftrag mit einem Commit Work. Danach mache ich einen Select single auf die LTAP.
Des Weiteren habe ich auch Verbucherfunktionsbausteine (asyncron) die später aufgerufen werden.
Nun passiert folgendes:
Wenn ich die VFB's im Code habe, dann findet er keinen Eintrag beim Select auf die LTAP. Wenn ich die VFB's aber auskommentiere, dann findet er einen Eintrag in der LTAP. Wenn ich aber vor dem Select "wait up to 1 seconds" mache, dann findet er den Eintrag sowohl mit VFB's als auch ohne.
Kann mir das jemand erklären???
Es sieht ja so aus als ob der commit work bei einem Programm wo es Verbuchungsbausteine gibt, länger dauert als bei einem ohne VFB's. Das darf doch aber nicht sein!?
Gruß
dimes
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Aber wieso haben die Verbuchungsbausteine damit was zu tun?
- ich erstellen den TA (mit commit work)
-dann suche ich nach dem TA
-
-
- und dann rufe ich erst den VFB auf (erst später)
Und bei der Suche nach dem TA findet er nicht! Der aufruf des VFB passiert ja erst später im Code!
Gruß
Dimes
- ich erstellen den TA (mit commit work)
-dann suche ich nach dem TA
-
-
- und dann rufe ich erst den VFB auf (erst später)
Und bei der Suche nach dem TA findet er nicht! Der aufruf des VFB passiert ja erst später im Code!
Gruß
Dimes
Hallo,
offensichtlich braucht auch der erste commit etwas Zeit ...
(oder die Tabellen sind gepuffert, oder das Zeug läuft als Kontext, oder als persistente Klasse, die ihre Sachen im Memory hält, und nur von Fall zu Fall neu liest oder oder oder).
Klappt es denn nach ca. 10 Sekunden warten???
Gruß
babap
offensichtlich braucht auch der erste commit etwas Zeit ...
(oder die Tabellen sind gepuffert, oder das Zeug läuft als Kontext, oder als persistente Klasse, die ihre Sachen im Memory hält, und nur von Fall zu Fall neu liest oder oder oder).
Klappt es denn nach ca. 10 Sekunden warten???
Gruß
babap
Bei sowas mit WAIT zu arbeiten ist allerdings ziemlich stümperhaft.
Mit SET UPDATE TASK LOCAL kann man den Verbucher in der selben LUW ausführen. Dann sind die Daten auf jeden Fall da.
Mit SET UPDATE TASK LOCAL kann man den Verbucher in der selben LUW ausführen. Dann sind die Daten auf jeden Fall da.
Enno glaubstz du das liegt an einem asynchronen Verbucher, den du einfach in die Reihe bringen willst.
Ich glaube, er hat eine synchrone Verarbeitung und nur durch den impliziten Wechsel des Workprozesses (Wait) sieht er die Daten auf der DB.
Ich glaube, so etwas hatte ich auch schon und da half auch kein SET UPDATE TASK LOCAL aber vielleicht hilft es ja bei ihm.
Ich glaube, er hat eine synchrone Verarbeitung und nur durch den impliziten Wechsel des Workprozesses (Wait) sieht er die Daten auf der DB.
Ich glaube, so etwas hatte ich auch schon und da half auch kein SET UPDATE TASK LOCAL aber vielleicht hilft es ja bei ihm.
aber nur, wenn's auch wirklich nötig ist und nicht, wenn das recht offensichtlich an der asynchronen Verbuchung liegt.DeathGuardian hat geschrieben:in der Praxis muss es leider manchmal sein.
Manchmal ist das aber tatsächlich nicht so offensichtlich. Gerade im WM wird auch schon mal gerne ein asynchroner RFC abgesetzt... Da kann man dann wirklich nur noch warten und hoffen...
Dann sollte aber auch die Fehlerbehandlung wirklich gut sein. Denn selbst wenn man 10 SEK wartet, kann das bei sehr hoher Systemlast oder einem Problem mit den Verbucherprozessen auch nicht ausreichen.
Der SAP-Standard ist ja häufig ein Quell abstruser Programmierungen...DeathGuardian hat geschrieben:Hab sogar schon einen WAIT UP TO 5 SECONDS im Standard gesehen.
Sieht man ja schon im WM... 
Beitrag
von DeathGuardian (Expert / 759 / 0 /
3
)
»
JO, mein Lieblingsbeispiel:ewx hat geschrieben:Der SAP-Standard ist ja häufig ein Quell abstruser Programmierungen...
Es wird ein Unterprogramm gerufen, welches in einem seperaten Include liegt und dieses enthält folgenden Code
Code: Alles auswählen.
FORM weis_leider_den nacmen_nicht_mehr.
* dies muss noch codiert werden
ENDFORM.
Das ist ja sogar noch einigermaßen "sinnvoll". Immerhin weiss man, dass da noch was gemacht werden muss.
Anders als bei
Anders als bei
Code: Alles auswählen.
FUNCTION weissichauchnichtmehr.
ENDFUNCTIONJa, es funktionier auch wenn ich form Select 1 Sekunde warte.Klappt es denn nach ca. 10 Sekunden warten???
Das Problem ist, dass das im RF Dialog passiert und da ist so eine Wartezeit nicht besonders gut angebracht.
Ich habe es heute wieder versucht und siehe da, es funktioniert wieder ohne das ich da was gemacht habe. Kein einzieger Fall... Irgendwie eigenartig.
Ich habs mit dem "Set up update task" probiert aber da es ja im moment funktionier kann ich es im Moment nicht weiter testen...
/dimes
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
5312
Views
Views
3
Antw.
Antw.
3200
Views
Views
0
Antw.
Antw.
1389
Views
Views
5
Antw.
Antw.
1967
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.