Assertions nutzen

Getting started ... Alles für einen gelungenen Start.
16 Beiträge • Seite 1 von 2 (current) Nächste
16 Beiträge Seite 1 von 2 (current) Nächste

Assertions nutzen

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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?

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Assertions nutzen

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
Eine umfassende how-to-use-assertions-docu kenne ich nicht.
Und schließlich steht in der SAP-Doku, dass solche IDs auch durch das Programm selbst aktiviert werden können. Aber wie?
Wo steht das denn? Das wäre mir neu.

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.

Re: Assertions nutzen

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Nur müsste ich dazu wissen, wie ich da rangehen muss.
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 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.

Re: Assertions nutzen

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
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.

Re: Assertions nutzen

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
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.
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

Re: Assertions nutzen

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Da wird es keinen Best-Practice geben.
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.

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.

Re: Assertions nutzen

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
DeathAndPain hat geschrieben:Wie aktiviere ich ihn programmgesteuert (was der SAP-Doku zufolge möglich sein soll)?
M.W. gar nicht. Ich glaube du hast die Doku falsch interpretiert..
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Assertions nutzen

Beitrag von ST22 (Specialist / 274 / 40 / 40 ) »
Hallo Zusammen,
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
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.

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

Re: Assertions nutzen

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
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.
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: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.
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.
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

Re: Assertions nutzen

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
adt hat geschrieben:Am Beginn deines Programms einen BREAK-POINT mit ID setzen, eine Hilfsvariable definieren und diese bei deinem ASSERT abfragen.
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?!
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


Re: Assertions nutzen

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
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?!
Du hast das "Big Picture" nicht bedacht:
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. :wink:
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

Re: Assertions nutzen

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
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.
Genau dafür sind die ASSERTIONS. Dafür brauche ich doch vorher keinen BREAK-POINT...?!
Plus: Genau dafür gibt es Layer-aware-Debugging und Debugger-Scripting... ;)

Re: Assertions nutzen

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
ewx hat geschrieben:
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.
Genau dafür sind die ASSERTIONS. Dafür brauche ich doch vorher keinen BREAK-POINT...?!
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. :wink:
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

Re: Assertions nutzen

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
ewx hat geschrieben:Plus: Genau dafür gibt es Layer-aware-Debugging und Debugger-Scripting... ;)
Meistens endet das bei mir in einem Kurzdump des Debuggers :cry:
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

Re: Assertions nutzen

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
a-dead-trousers hat geschrieben:
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.
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.
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.
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.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Vergleichbare Themen

4
Antw.
11033
Views
Wertebereich nutzen
von MarkusW » 19.12.2007 09:00 • Verfasst in ABAP® Core
4
Antw.
2159
Views
Selektionen der Log DB nutzen
von lucky65 » 26.07.2012 13:13 • Verfasst in ABAP® Core
2
Antw.
3117
Views
Assistance Klasse in WD nutzen
von Thanatos82 » 17.01.2013 15:41 • Verfasst in ABAP® für Anfänger
2
Antw.
2096
Views
TLB-Funktionalitäten in ABAP nutzen
von Johann » 17.10.2005 11:44 • Verfasst in ABAP® für Anfänger
1
Antw.
1748
Views
Geschützte EVENTS des ALV nutzen
von RiffRaff » 05.08.2008 10:51 • Verfasst in ABAP Objects®

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 4 Tagen von Lucyalison 1 / 71
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 111
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 141