Assertions nutzen
Beitrag
von DeathAndPain (Top Expert / 1947 / 257 /
413
)
»
Man glaubt, längst alle Grundlagen zu kennen und entdeckt doch immer wieder Neues. Jetzt bin ich über Assertions gestolpert.
Dazu habe ich verschiedene Online-Dokus von der SAP gefunden, aber irgendwie beschreiben alle nur ein Fragment des Gesamtpuzzles und vermitteln mir kein geschlossenes Bild, wie man denn nun ganz praktisch mit Assertions arbeitet.
Assertions ohne ID sind klar. Die sind immer aktiv und legen eine Bedingung fest, die von der Programmlogik her erfüllt sein muss. Andernfalls dumpts.
Interessanter sind die Assertions mit ID. Da kann man ja auch den Debugger von starten lassen. Ich verstehe das als einen gewissermaßen im Coding eingebetten Watchpoint. Aber wie nutzt man das? Ich habe gefunden, dass man Checkpoint-Gruppen mit der Transaktion SAAB definieren kann. Sind das die Gruppen, die vom ASSERT für die ID genutzt werden? Wenn ja, wie gehe ich damit um, und wo stelle ich ein, was das Programm machen soll, wenn solch Assertion verletzt ist? Und schließlich steht in der SAP-Doku, dass solche IDs auch durch das Programm selbst aktiviert werden können. Aber wie?
Gibt es irgendwo einen in sich geschlossenen Schritt-für-Schritt-Einführungsleitfaden in den Umgang mit ID-behafteten Assertions?
Dazu habe ich verschiedene Online-Dokus von der SAP gefunden, aber irgendwie beschreiben alle nur ein Fragment des Gesamtpuzzles und vermitteln mir kein geschlossenes Bild, wie man denn nun ganz praktisch mit Assertions arbeitet.
Assertions ohne ID sind klar. Die sind immer aktiv und legen eine Bedingung fest, die von der Programmlogik her erfüllt sein muss. Andernfalls dumpts.
Interessanter sind die Assertions mit ID. Da kann man ja auch den Debugger von starten lassen. Ich verstehe das als einen gewissermaßen im Coding eingebetten Watchpoint. Aber wie nutzt man das? Ich habe gefunden, dass man Checkpoint-Gruppen mit der Transaktion SAAB definieren kann. Sind das die Gruppen, die vom ASSERT für die ID genutzt werden? Wenn ja, wie gehe ich damit um, und wo stelle ich ein, was das Programm machen soll, wenn solch Assertion verletzt ist? Und schließlich steht in der SAP-Doku, dass solche IDs auch durch das Programm selbst aktiviert werden können. Aber wie?
Gibt es irgendwo einen in sich geschlossenen Schritt-für-Schritt-Einführungsleitfaden in den Umgang mit ID-behafteten Assertions?
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Eine umfassende how-to-use-assertions-docu kenne ich nicht.
Das schöne an der SAAB (log-Points, Asserts und Break-Points) ist, dass du für einen Prozess oder eine Teilproblematik IDs erstellen kannst.
Wenn dann Probleme dazu auftauchen, dann musst du als Programmierer nicht wissen, in welchen Programmen und Klassen und Funktionsbausteinen irgendwelche Parameter dazu abgefragt werden. Du aktivierst einfach den entsprechenden Break-Point oder Assert mit ID und landest automatisch an den kritischen Stellen.
Problem dabei: Du weißt eigentlich erst hinterher, wo du ein ASSERT hättest setzen sollen...
Du kannst den ASSERTs und Log-Points auch Daten zur Protokollierung mitgeben. Du kannst hier sogar ganze Tabellen protokollieren.
Schön, um Fehler im Produktivsystem zu analysieren ohne dass man eine eigene Protokollierung programmieren oder diese wieder ausbauen muss.
Wo steht das denn? Das wäre mir neu.Und schließlich steht in der SAP-Doku, dass solche IDs auch durch das Programm selbst aktiviert werden können. Aber wie?
Das schöne an der SAAB (log-Points, Asserts und Break-Points) ist, dass du für einen Prozess oder eine Teilproblematik IDs erstellen kannst.
Wenn dann Probleme dazu auftauchen, dann musst du als Programmierer nicht wissen, in welchen Programmen und Klassen und Funktionsbausteinen irgendwelche Parameter dazu abgefragt werden. Du aktivierst einfach den entsprechenden Break-Point oder Assert mit ID und landest automatisch an den kritischen Stellen.
Problem dabei: Du weißt eigentlich erst hinterher, wo du ein ASSERT hättest setzen sollen...
Du kannst den ASSERTs und Log-Points auch Daten zur Protokollierung mitgeben. Du kannst hier sogar ganze Tabellen protokollieren.
Schön, um Fehler im Produktivsystem zu analysieren ohne dass man eine eigene Protokollierung programmieren oder diese wieder ausbauen muss.
Beitrag
von DeathAndPain (Top Expert / 1947 / 257 /
413
)
»
Nur müsste ich dazu wissen, wie ich da rangehen muss.
Da fängt es schon an. Wenn ich einen Report habe, für den ich solch ID erstellen will, was ist in dem Zusammenhang dann ein "Prozess"? Mir fehlt da noch das große Bild.Das schöne an der SAAB (log-Points, Asserts und Break-Points) ist, dass du für einen Prozess oder eine Teilproblematik IDs erstellen kannst.
Da wird es keinen Best-Practice geben. Das musst du IMHO machen und Erfahrungen sammeln.
Ich verwende das eher selten, weil es eben keinen Fahrplan dafür gibt.
Verwenden kannst du es z.B., wenn du ein Zusatzfeld im Kundenauftrag füllen möchtest.
Dann hast du den Exit im SAPMV45A, vielleicht einen Funktionsbaustein, der die Initialisierung macht und eine Methode mit der du den Wert je Kunde/Material/etc ermittelst und am Ende hast du noch einen Exit + Methode für Abschlußprüfungen.
Wenn irgendwas an dem Prozess "Zusatzfeld füllen" nicht funktioniert, bist du erstmal aufgeschmissen, weil du nicht erkennst, welche Bauteile dazu gehören.
Wenn du überall eine Assertion oder Log-point einbaust, dann schaltest du für diese "Anhalten" an und schon landest du beim Debuggen automatisch an allen relevanten Stellen.
Ich verwende das eher selten, weil es eben keinen Fahrplan dafür gibt.
Verwenden kannst du es z.B., wenn du ein Zusatzfeld im Kundenauftrag füllen möchtest.
Dann hast du den Exit im SAPMV45A, vielleicht einen Funktionsbaustein, der die Initialisierung macht und eine Methode mit der du den Wert je Kunde/Material/etc ermittelst und am Ende hast du noch einen Exit + Methode für Abschlußprüfungen.
Wenn irgendwas an dem Prozess "Zusatzfeld füllen" nicht funktioniert, bist du erstmal aufgeschmissen, weil du nicht erkennst, welche Bauteile dazu gehören.
Wenn du überall eine Assertion oder Log-point einbaust, dann schaltest du für diese "Anhalten" an und schon landest du beim Debuggen automatisch an allen relevanten Stellen.
Beitrag
von a-dead-trousers (Top Expert / 4396 / 223 /
1182
)
»
Und dank der Bedingung in der ASSERTION bleibt das Programm auch nur dann stehen, wenn diese verletzt wurde.
z.B. wenn ein notwendiger Parameter nicht befüllt wurde oder ein Baustein einen "unerwarteten" Wert zurückliefert.
z.B. wenn ein notwendiger Parameter nicht befüllt wurde oder ein Baustein einen "unerwarteten" Wert zurückliefert.
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
Beitrag
von DeathAndPain (Top Expert / 1947 / 257 /
413
)
»
Ich bin weniger auf der Suche nach einem Best Practice und mehr nach einem verständlichen Einstieg. Wo und wie stelle ich ein, was der ID-behaftete ASSERT machen soll, wenn seine Bedingung verletzt ist? Wie aktiviere ich ihn programmgesteuert (was der SAP-Doku zufolge möglich sein soll)? Gibt es Beispiele für die Nutzung ID-behafteter ASSERTs? Ich will nur verstehen, wie das Ding syntaktisch bzw. mechanisch funktioniert. Was ich dann damit anstelle, überlege ich mir schon selber.Da wird es keinen Best-Practice geben.
Eine mögliche Idee wäre ein Watchpoint, wenn ich im Entwicklungssystem einem seltsamen Effekt auf der Spur bin. Ich könnte mir vorstellen, dass es schneller geht, rasch einen ASSERT mit dem in Frage stehenden Feldwert reinzustellen, der mir im richtigen Moment den Debugger anschmeißt, als das Programm zu starten, auf einen Breakpoint laufen zu lassen, manuell einen Watchpoint einzustellen und dann bis zum Watchpoint weiterlaufen zu lassen. Erst recht, nachdem ich heute leidvoll lernen musste, dass man auf Feldsymbole keine Watchpoints legen kann (vor allem in LOOPs). Das ist dann wieder ein großer Pluspunkt für Workareas statt Feldsymbolen - und da ich sperrige Workareas Mist finde, ein großer Pluspunkt für Tabellenkopfzeilen.
Beitrag
von black_adept (Top Expert / 4090 / 127 /
940
)
»
M.W. gar nicht. Ich glaube du hast die Doku falsch interpretiert..DeathAndPain hat geschrieben:Wie aktiviere ich ihn programmgesteuert (was der SAP-Doku zufolge möglich sein soll)?
Hallo Zusammen,
Aktivieren würdest du einen so programmierten ASSERT auch in der SAAB. Stellt sich dann der Zustand ein, werden eben u.U. gewisse Daten protokolliert.
Vielleicht ein Beispiel wäre ein Aufruf eines RFC aus einem externen System, der unter gewissen Konstellationen abbricht und man nicht wirklich weiß, welche Datenkonstellation zum Abbruch führt. Da könnte man in einem solchen Fall bestimmte Importparameter aufzeichnen.
Die Protokolle bekommst du wohl auch in der SAAB dann zu sehen.
Zugegebener Maßen habe ich das selbst noch nicht genutzt, wohl aber die Checkpoints um mir an definierten Stellen schnell mal die gewünschten Breakpoints zu aktivieren.
Schöne Grüße
Frank
Wenn du in der SAAB den Infobutton drückst (Strg+F8), dann bekommst du schon die Antwort auf deine Frage, ob das die IDs sind für das Assert Kommando.DeathAndPain hat geschrieben:Sind das die Gruppen, die vom ASSERT für die ID genutzt werden? Wenn ja, wie gehe ich damit um, und wo stelle ich ein, was das Programm machen soll
Aktivieren würdest du einen so programmierten ASSERT auch in der SAAB. Stellt sich dann der Zustand ein, werden eben u.U. gewisse Daten protokolliert.
Vielleicht ein Beispiel wäre ein Aufruf eines RFC aus einem externen System, der unter gewissen Konstellationen abbricht und man nicht wirklich weiß, welche Datenkonstellation zum Abbruch führt. Da könnte man in einem solchen Fall bestimmte Importparameter aufzeichnen.
Die Protokolle bekommst du wohl auch in der SAAB dann zu sehen.
Zugegebener Maßen habe ich das selbst noch nicht genutzt, wohl aber die Checkpoints um mir an definierten Stellen schnell mal die gewünschten Breakpoints zu aktivieren.
Schöne Grüße
Frank
Beitrag
von a-dead-trousers (Top Expert / 4396 / 223 /
1182
)
»
Du musst eigentlich schon zur Designtime, also beim Programmieren, den Fehlerzustand kennen und diesen als Bedingung für deinen ASSERT definieren. Was ich mir vorstellen könnte, wie du das von dir beschriebene Szenario bewerkstelligen kannst, wäre mit BREAK-POINTs und ASSERTs zu arbeiten: Am Beginn deines Programms einen BREAK-POINT mit ID setzen, eine Hilfsvariable definieren und diese bei deinem ASSERT abfragen. Wenn du dann deine Checkpoint-Gruppe aktivierst, bleibt der Debugger am Anfang stehen, du setzt die Variable auf den gewünschten Wert. Sobald dann der ASSERT erreicht ist, bleibt das Programm dann wieder stehen und du kannst prüfen, warum es zu der "Verletztung" der Bedingung gekommen ist.DeathAndPain hat geschrieben:Eine mögliche Idee wäre ein Watchpoint, wenn ich im Entwicklungssystem einem seltsamen Effekt auf der Spur bin. Ich könnte mir vorstellen, dass es schneller geht, rasch einen ASSERT mit dem in Frage stehenden Feldwert reinzustellen, der mir im richtigen Moment den Debugger anschmeißt, als das Programm zu starten, auf einen Breakpoint laufen zu lassen, manuell einen Watchpoint einzustellen und dann bis zum Watchpoint weiterlaufen zu lassen.
Dafür kann man aber einen WatchPoint auf das Ziel des Feldsymbols (Tabellenzeile, Strukturfeld usw.) legen. Toll wäre es da natürlich, wenn der Debugger das sofort und korrekt aus einem Feldsymbol auflösen könnte.DeathAndPain hat geschrieben:Erst recht, nachdem ich heute leidvoll lernen musste, dass man auf Feldsymbole keine Watchpoints legen kann (vor allem in LOOPs). Das ist dann wieder ein großer Pluspunkt für Workareas statt Feldsymbolen - und da ich sperrige Workareas Mist finde, ein großer Pluspunkt für Tabellenkopfzeilen.
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 soll das denn bringen?adt hat geschrieben:Am Beginn deines Programms einen BREAK-POINT mit ID setzen, eine Hilfsvariable definieren und diese bei deinem ASSERT abfragen.
An relevanten Stellen kann ich BREAK-POINT id xyz. programmieren und dann hält das Programm dort an, wenn ich die Checkpoint-Gruppe aktiviere.
Warum sollte ich erst einen Break-Point definieren, dann eine Variable umsetzen, um diese mit ASSERT abzufragen?!
Oder habe ich das falsch verstanden...?
Das Hauptproblem hast du bereits angesprochen: Man muss im Grunde vorher wissen, wo hinterher Break-Points nützlich gewesen wären.
Das kann man aber kaum, weil man dann bereits wüsste, welche Fehler auftreten. Und wenn man das vorher weiß, programmiert man gleich anders...
Hier hatte ich einmal aufgeführt, wie man die SAAB für eigene Zwecke nutzen kann:
Checkpoint-Gruppe - Die Fahrkarten bitte
Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
a-dead-trousers
Beitrag
von a-dead-trousers (Top Expert / 4396 / 223 /
1182
)
»
Du hast das "Big Picture" nicht bedacht:ewx hat geschrieben:Was soll das denn bringen?
An relevanten Stellen kann ich BREAK-POINT id xyz. programmieren und dann hält das Programm dort an, wenn ich die Checkpoint-Gruppe aktiviere.
Warum sollte ich erst einen Break-Point definieren, dann eine Variable umsetzen, um diese mit ASSERT abzufragen?!
Im Programm werden zig Zeilen Code durchlaufen, hundert Objekte instanziert und irgendwann beim tausendsten Schleifendurchlauf steht statt einer 0 eine 1 drinnen. Finde das mal per reinem Debugging.
Und ja, das kann man theoretisch auch ohne ASSERTs lösen, aber als Einstiegsbeispiel schien es mir passend.
Deine Variante, die Checkpoint-Gruppen für Teststellungen zu "missbrauchen", klingt spannend und werd ich mir im Hinterkopf behalten.
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
Genau dafür sind die ASSERTIONS. Dafür brauche ich doch vorher keinen BREAK-POINT...?!a-dead-trousers hat geschrieben: Im Programm werden zig Zeilen Code durchlaufen, hundert Objekte instanziert und irgendwann beim tausendsten Schleifendurchlauf steht statt einer 0 eine 1 drinnen.
Plus: Genau dafür gibt es Layer-aware-Debugging und Debugger-Scripting...
Beitrag
von a-dead-trousers (Top Expert / 4396 / 223 /
1182
)
»
Der BREAK-POINT ist nur dazu da, um beim Eisntieg in das Programm die Abbruch-Bedingung (z.B. suche alle Ergebnisse mit 1) für den ASSERT zu setzen.ewx hat geschrieben:Genau dafür sind die ASSERTIONS. Dafür brauche ich doch vorher keinen BREAK-POINT...?!a-dead-trousers hat geschrieben: Im Programm werden zig Zeilen Code durchlaufen, hundert Objekte instanziert und irgendwann beim tausendsten Schleifendurchlauf steht statt einer 0 eine 1 drinnen.
Das ist in etwas was DeathAndPain haben wollte:
DeathAndPain hat geschrieben:Ich könnte mir vorstellen, dass es schneller geht, rasch einen ASSERT mit dem in Frage stehenden Feldwert reinzustellen, der mir im richtigen Moment den Debugger anschmeißt, als das Programm zu starten, auf einen Breakpoint laufen zu lassen, manuell einen Watchpoint einzustellen und dann bis zum Watchpoint weiterlaufen zu lassen.
Zuletzt geändert von a-dead-trousers am 08.06.2018 09:31, insgesamt 1-mal geändert.
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
Beitrag
von a-dead-trousers (Top Expert / 4396 / 223 /
1182
)
»
Meistens endet das bei mir in einem Kurzdump des Debuggersewx hat geschrieben:Plus: Genau dafür gibt es Layer-aware-Debugging und Debugger-Scripting...
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
Beitrag
von black_adept (Top Expert / 4090 / 127 /
940
)
»
Watchponts auf Feldsymbole geht mit einem Workaround. Man kann ja einem Breakpunkt eine Bedingung mitgeben - und in dieser Bedingung nun kann man auch ein Feldsymbol mitgeben. Das entspricht dann etwa einem Watchpoint.a-dead-trousers hat geschrieben:Dafür kann man aber einen WatchPoint auf das Ziel des Feldsymbols (Tabellenzeile, Strukturfeld usw.) legen. Toll wäre es da natürlich, wenn der Debugger das sofort und korrekt aus einem Feldsymbol auflösen könnte.DeathAndPain hat geschrieben:Erst recht, nachdem ich heute leidvoll lernen musste, dass man auf Feldsymbole keine Watchpoints legen kann (vor allem in LOOPs). Das ist dann wieder ein großer Pluspunkt für Workareas statt Feldsymbolen - und da ich sperrige Workareas Mist finde, ein großer Pluspunkt für Tabellenkopfzeilen.
Sogar die Doku zu den Breakpointbedingungen sagt, dass man Feldsymbole verwenden kann - allerdings ist das nur halb richtig, insofern als diese Aussage zwar schon lange so drin steht aber nicht in allen Releases funktioniert.
Ich habe auf 3 Systemen geschaut 2 7.40 Systemen - einer mit Patchstand 13 und einer mit Patchstand 16 und ein 7.50er System. Bei 7.40 Patchstand 13 funktioniert eine Breakpointbedinung mit einem Feldsymbol nicht, bei Patchstand 16 hingegen schon und bei 7.50 auch.
Vergleichbare Themen
4
Antw.
Antw.
2344
Views
Views
2
Antw.
Antw.
3285
Views
Views
2
Antw.
Antw.
2704
Views
Views
1
Antw.
Antw.
1818
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.