Aufrufstelle eines Verbucher(prozess) ermitteln
7 Beiträge
•
Seite 1 von 1
7 Beiträge
Seite 1 von 1
Beitrag
von a-dead-trousers (Top Expert / 4419 / 224 /
1189
)
»
hi!
Ich hab mal wieder ein Problem bei dem ich nicht weiterkomme:
Wir haben bei uns auf dem System immer wieder Probleme mit falsch verbuchten Einträgen.
Um herauszufinden was schief läuft haben wir auch schon ein Logging und so weiter eingebaut, nur finden wir damit maximal heraus, dass der Fehler aufgetreten ist, wissen aber nichts vom Umfeld in dem das passiert ist. Der Verbucherbaustein ist ein Standardbaustein und alle Aufrufstellen zu loggen ist einfach zu umfangreich. Eine Auswertung des Aufrufstacks bringt nichts, weil da scheint ja nur der Verbuchungsprozess auf und nicht der Aufrufer, der den Verbucherbaustein registriert hat.
Nun meine Frage:
Gibt es eine Möglichkeit während der Verarbeitung des Verbuchers herauszubekommen, von wo aus man aufgerufen wurde?
Es würde schon reichen das betreffende COMMIT WORK zu kennen um dann dort gezielter mit der Fehleranalyse ansetzen zu können.
lg ADT
Ich hab mal wieder ein Problem bei dem ich nicht weiterkomme:
Wir haben bei uns auf dem System immer wieder Probleme mit falsch verbuchten Einträgen.
Um herauszufinden was schief läuft haben wir auch schon ein Logging und so weiter eingebaut, nur finden wir damit maximal heraus, dass der Fehler aufgetreten ist, wissen aber nichts vom Umfeld in dem das passiert ist. Der Verbucherbaustein ist ein Standardbaustein und alle Aufrufstellen zu loggen ist einfach zu umfangreich. Eine Auswertung des Aufrufstacks bringt nichts, weil da scheint ja nur der Verbuchungsprozess auf und nicht der Aufrufer, der den Verbucherbaustein registriert hat.
Nun meine Frage:
Gibt es eine Möglichkeit während der Verarbeitung des Verbuchers herauszubekommen, von wo aus man aufgerufen wurde?
Es würde schon reichen das betreffende COMMIT WORK zu kennen um dann dort gezielter mit der Fehleranalyse ansetzen zu können.
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
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4117 / 129 /
952
)
»
Hallo ADT,
wenn du verzweifelt bist könntest du einen Performance Trace auf die Tabelle VBMOD laufen lassen. Damit würdest du dann alle Stellen finden, an denen jemand etwas in die Verbucherliste einträgt.
Der Verbucherabbruch hat einen Schlüssel - nach dem könntest du dann in der Traceliste suchen und die Stelle finden wo der Insert auf die VBMOD mit diesem Schlüssel gemacht wurde und dann aus dem Trace heraus an die gewünschte Programmstelle springen.
Nur graue Theorie - aber ich schätze mal das müsste klappen.
wenn du verzweifelt bist könntest du einen Performance Trace auf die Tabelle VBMOD laufen lassen. Damit würdest du dann alle Stellen finden, an denen jemand etwas in die Verbucherliste einträgt.
Der Verbucherabbruch hat einen Schlüssel - nach dem könntest du dann in der Traceliste suchen und die Stelle finden wo der Insert auf die VBMOD mit diesem Schlüssel gemacht wurde und dann aus dem Trace heraus an die gewünschte Programmstelle springen.
Nur graue Theorie - aber ich schätze mal das müsste klappen.
Beitrag
von a-dead-trousers (Top Expert / 4419 / 224 /
1189
)
»
Danke mal für den Vorschlag.
Leider gibt es keinen Verbucherabbruch, das ist ja das Problem. Die Daten werden falsch eingebucht.
Und da der Fehler nur sehr sporadisch auftritt (1 - 2 mal pro Woche) fällt ein "dauerhafter" Performance-Trace auf die VBMOD vermutlich auch flach.
Ich würde eher sowas brauchen, wie CALL 'RFCControl' oder so ähnlich, nur eben im Kontext des Verbuchers.
lg ADT
Leider gibt es keinen Verbucherabbruch, das ist ja das Problem. Die Daten werden falsch eingebucht.
Und da der Fehler nur sehr sporadisch auftritt (1 - 2 mal pro Woche) fällt ein "dauerhafter" Performance-Trace auf die VBMOD vermutlich auch flach.
Ich würde eher sowas brauchen, wie CALL 'RFCControl' oder so ähnlich, nur eben im Kontext des Verbuchers.
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
Was heißt denn "falsch verbucht"?
Beitrag
von a-dead-trousers (Top Expert / 4419 / 224 /
1189
)
»
Einzelne Felder die gefüllt sein sollten sind leer.
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
Und das sind Felder, die aus dem rufenden Programm ermittelt und dann an den Verbucher übergeben werden?!
Also ist nicht der Verbucher ansich das Problem, sondern der Aufrufer. (Nur für mich zum Verständnis...)
1. Um was für Felder handelt es sich? Sind das zufällig Belegnummern oder andere Objekte, die per BAPI erzeugt und dann nachgelesen werden??
Oder sind es "irgendwelche" Felder, die dann in "irgendeinem Prozeß" nicht an den Verbucher übergeben werden?
2. du könntest den standard-VB-baustein kapseln in einem "normalen" Funktionsbaustein. In diesem Baustein machst du die Umfeldanalyse/ Aufrufhierarchie und rufst dann in dem neuen Baustein den Verbucher in update task auf.
Also ist nicht der Verbucher ansich das Problem, sondern der Aufrufer. (Nur für mich zum Verständnis...)
1. Um was für Felder handelt es sich? Sind das zufällig Belegnummern oder andere Objekte, die per BAPI erzeugt und dann nachgelesen werden??
Oder sind es "irgendwelche" Felder, die dann in "irgendeinem Prozeß" nicht an den Verbucher übergeben werden?
2. du könntest den standard-VB-baustein kapseln in einem "normalen" Funktionsbaustein. In diesem Baustein machst du die Umfeldanalyse/ Aufrufhierarchie und rufst dann in dem neuen Baustein den Verbucher in update task auf.
Beitrag
von a-dead-trousers (Top Expert / 4419 / 224 /
1189
)
»
Jepp!ewx hat geschrieben:Und das sind Felder, die aus dem rufenden Programm ermittelt und dann an den Verbucher übergeben werden?!
Also ist nicht der Verbucher ansich das Problem, sondern der Aufrufer. (Nur für mich zum Verständnis...)
Die Felder/Strukturen werden schon übergeben, nur halt leer.ewx hat geschrieben:1. Um was für Felder handelt es sich? Sind das zufällig Belegnummern oder andere Objekte, die per BAPI erzeugt und dann nachgelesen werden??
Oder sind es "irgendwelche" Felder, die dann in "irgendeinem Prozeß" nicht an den Verbucher übergeben werden?
Leider sind es zu viele Aufrufstellen. Und es tritt nicht immer auf. Irgendwie wenn der Mond gerade im dritten Haus an der Tür klopft.ewx hat geschrieben:2. du könntest den standard-VB-baustein kapseln in einem "normalen" Funktionsbaustein. In diesem Baustein machst du die Umfeldanalyse/ Aufrufhierarchie und rufst dann in dem neuen Baustein den Verbucher in update task auf.
Ne, das Standardsystem ist so verschachtelt, das irgendwo vielleicht eine globale Variable nicht ins Memory geschrieben wird und das auch nur wenn zuvor der Baustein XYZ nicht mit den richtigen Daten versorgt wurde.
Wahrscheinlich was total kleinliches, aber ganz schwer drauf zu kommen und deswegen so viele Standardänderungen zu machen steht einfach nicht dafür. Zumindest ist es (noch) nicht kritisch genug. Desshalb suche ich ja nach einer einfachen Lösung um eben den Kontext des Verbuchers zu ermitteln. Wenn wir das betreffende COMMIT wüssten, oder noch besser, wann und wo der Funktionsbaustein im Verbucher registiert wurde, wäre schon viel geholfen.
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
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
2817
Views
Views
Belege im Verbucher? / Verbucher sperren / Semaphoren
von christop » 20.02.2006 08:51 • Verfasst in Financials
von christop » 20.02.2006 08:51 • Verfasst in Financials
1
Antw.
Antw.
979
Views
Views
9
Antw.
Antw.
1813
Views
Views
Verbucher mit gemeinsamem Application Log
von ralf.wenzel » 28.06.2021 09:13 • Verfasst in ABAP® Core
von ralf.wenzel » 28.06.2021 09:13 • Verfasst in ABAP® Core
3
Antw.
Antw.
2303
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.