Aus dem Leben eines ABAP-Programmieres

Posted by André Mühlnikel at April 20, 2009 8:17 p.m.

WAAAAAAAH. Tschuldige. Musste mal gesagt werden. Hier die lange Version:

Seit einer Woche oder so hänge ich – neben anderen Projekten – über einem Programm, dass eigentlich nix besonders kompliziertes tun soll: links ein Treeview, bei Doppelklick rechts die Details zu den Knoten anzeigen/ändern und ggf. aus der Änderung resultierende Anpassungen im Treeview aktualisieren. Was mit jeder anderen „höheren“ Programmiersprache ein Klacks wäre, gerät bei SAP zu einem Kampf wie einst David gegen Goliath - nur das Goliath in meinem Fall auf den Steinen sitzt und meine Schleuder kaputt gemacht hat …

Zunächst einmal musste ich traurigerweise feststellen, dass ABAP-Objects keine Klasse zur Abbildung eines Baumes mitbringt. Vielleicht braucht das niemand außer mir. Macht aber nichts, solche schnellen Fingerübungen machen ja von Zeit zu Zeit auch Spaß. Warum aber brauchte ich eine Baum-Struktur? Nunja, der (neue) ALV-Treeview hat eine relativ unübersichtliche Schnittstelle und das Einfügen von Knoten in seinen Baum ist alles andere als intuitiv und schon gleich gar nicht objektorientiert. Ergo erhielt mein Baum auch gleich eine Convert-To-Treeview-Methode. Bis hierhin noch ganz einfach.

Doch dann begann der Wahnsinn. Ich weiß nicht, was mich da geritten hat – und inzwischen ist es auch zu spät, umzudrehen – aber aus irgendeinem Grund wollte ich unbedingt einen Splitscreen, so schön mit verschiebbarer Mittellinie. Wie gesagt, mit einem ordentlichen Framework auch kein Problem. Und wie glücklich war ich, nach kurzer Suche eine passende Klasse SPLIT_CONTAINER (oder so) gefunden zu haben. Hihi.

Der Split-Container ist im Grunde 2 Container getrennt durch besagte verschiebbare Trennlinie. Super, linke Seite den Treeview (der zwar nicht von CONTROL erbt, aber trotzdem in einen Container eingebunden werden kann) und rechts mein Dynpro – für nicht-ABAPler: das ist das Window-Control-Pendant in ABAP. Soweit die Idee, nur leider sind Dynpros nicht mal ansatzweise (z.B. über einen Wrapper) in ABAP-Objects eingebunden. Notiz an mich: bei Gelegenheit mal einen Wrapper bauen. Das hat zur Folge, dass man Dynpros leider auch nicht in Container einbinden kann.

Gut, ein wenig gegoogelt, Vermutung bestätigt, Lösung gefunden: DOCKING_CONTAINER. Das sind größenveränderliche Container, die man an ein Dynpro andocken kann (also „the other way round“). Aber ich kenne mich: das habe ich bis zum nächsten Mal wieder vergessen, also konstruiere ich mir – mit Hilfe einer Funktionsgruppe (was sowas wie der Vorläufer von ABAP-Objects war, nur gruseliger, dafür fähig Dynpros zu verarbeiten) – eine SPLIT_DYNPRO-Klasse, links einen Docking-Container, rechts einen Subscreen-Bereich, ein bisschen Eventhandling (Process Before Output/Process After Input). Keine Große Sache. Jedenfalls die Basisklasse.Jetzt noch schnell 2 Unterklassen, je eine für ALV-Grid und ALV-Tree, und schon kanns losgehen. Hihihi.

Wer glaubt, wenn 2 Klassen, die beide eine Instanz-Methode DISPLAY mit derselben Schnittstelle bereitstellen, hätte auch ihre gemeinsame Oberklasse eine entsprechende Methode, der kennt ABAP-Objects noch nicht. Also hab ich die Hälfte meiner Methoden in meine Unterklassen verschoben, nur damit ichs irgendwie zum Laufen kriege. Und siehe da: wie durch ein Wunder erscheint mein Baum, und mit ein wenig Fummelei klappt sogar das mit dem Doppelklick.

Siegessicher in die nächste Runde: Daten speichern. Klappt überraschend gut. Nur jetzt die große Problematik der Aktualisierung des Treeviews. Denn leider sorgt das Caching von SAP und die unübersichtliche Verlinkung zwischen Container und Control für einige Probleme. Kurz: alles was man brauchen könnte ist entweder nicht erreichbar (weil PRIVATE) oder fehlt schlicht. Einmal initialisiert kann man nur noch Container samt Control löschen und neu aufbauen, will man eine Aktualisierung erzwingen. Die einzige Alternative (die ich mir morgen ob des häßlichen Flackerns durch diese Prozedur zu Gemüte führen werde) ist eine Methode, die als Input aber irgendeine Tabelle im internen Darstellungsformat des Treeviews erwartet. Dafür hab ich es Dank der ersten Erfolge immerhin geschafft, mein restliches Programm schonmal soweit zu strukturieren, dass ich wirklich „nur noch“ die Oberfläche hinfummeln muss.

Und das alles praktisch ohne irgendeine Doku, alles Raten, SAP-Coding nachsehen, Fluchen (Check-Methode mit 1 Exporting-Parameter, der die Werte 0 oder 1 annehmen kann – wieso macht man da keinen Returning-Parameter draus und erspart mir eine unnötige Variablendeklaration?). Habe heute mehrmals den Kopf auf den Tisch gehaun, damit ich weiß, dass das kein Albtraum ist.

Nebenbei bin ich heute aber noch auf einen anderen unerwarteten, „lustigen“ Effekt gestoßen: Wenn ihr ABAP nicht kennt, Popup-Nachrichten kann man recht entspannt sogar teildynamisch mit dem fest eingebauten Befehl MESSAGE (…) WITH (…) erzeugen. Dabei kann man nach WITH noch bis zu 4 Parameter mitgeben, die dann zur Laufzeit gegen entsprechende Platzhalter in der Nachricht ersetzt werden. Gleichzeitig schreibt MESSAGE diese Inhalte in 4 korrespondierende System-Variablen (sy-msgv1 bis sy-msgv4) zurück. Das ist extrem nützlich, wenn man Nachrichten protokollieren oder anderweitig nachverfolgen will. Was nun aber, wenn man die Inhalte einer anderen (nicht selbst erzeugten) Nachricht weiterverwenden will? „WITH sy-msgv1 bis sy-msgv4“ tut brav, was man erwartet. Doch interessant wird es, wenn man nur einen Teil dieser Variablen recyclen will. Nehmen wir an, der erste MESSAGE-Befehl hatte die Parameter 'A','B','C','D'. Dann sind selbstverständlich anschließend auch die System-Variablen mit diesen Buchstaben sauber gefüllt. Hat nun aber der zweite MESSAGE-Befehl die Parameter 'E', sy-msgv1, sy-msgv2, sy-msgv3, so wird man feststellen, dass im Ergebnis nicht etwa die Buchstaben 'E','A','B','C' auftreten, sondern viermal der Buchstabe 'E'. Und den Fehler soll man mal finden … was passiert dürfte klar sein: statt, wie erwartet zunächst alle Parameter einzulesen, anschließend die Nachricht aufzubereiten und schließlich die Systemvariablen zu aktualisieren, macht SAP das genau für je einen der Parameter. So wird das 'E' zunächst in sy-msgv1 übertragen, anschließend von dort in sy-msgv2 usw. Hihihihi *hab mich lieb*…

No comments | Defined tags for this entry: ABAP, algorithms, bizarre, software

Comments

No comments