Von der Wichtigkeit des Default Komponentennamen....

Von der Wichtigkeit des Default Komponentennamen....

Keine Frage, sondern ein dringender Tipp an alle - gerade an die weniger Erfahrenen:

Leider hat auch die SAP nicht sonderlich viele davon vergeben, aber ich habe hier gerade (mal wieder) einen Fall, wo ich mir die Haare raufe, dass mein Hinweis "zu jedem Datenelement bitte einen Default Component Name vergeben, sonst gibt das bei so vielen Entwicklern ein Heidenchaos!" -- leider kam ich erst dazu, als das Projekt schon eine Weile lief und schon eine Menge Chaos da war.

Da wird dann aus einem SPENDER_TYP in der einen Struktur ein SPETYP in der nächsten, mal heißt es DONATION_NUM, ein anderer schreibt DONATIONNUMM oder DONATION_NO und dann passen haufenweise Zuweisungen nicht mehr - egal ob dynamisch oder per MOVE_CORRESPONDING. Ergebnis sind dann nicht funktionierende Anwendungen, ich habe gerade eine volle Stunde solche Abweichungen behoben und schon rennt die Anwendung.

Eine Namenrichtlinie ist von brennender Wichtigkeit in der Form, dass man sich über Begrifflichkeiten projektweit einigen muss. Am einfachsten geht das über Default Component Names und darüber, dass man Strukturen wiederverwendet. Das ist gerade dann besonders wichtig, wenn man viele Entwickler hat, die viele in sich abgeschlossene Module entwickeln, die miteinander kommunizieren müssen.

DAS ist dann auch der Grund für mein Engagement gegen die HN (die hier ja mehrfach Thema war), weil die wahren Namens-Vergabe-Probleme, die wirklich Fehler erzeugen, ganz woanders liegen. Das heutige Beispiel zeigt das. Das sind in meinen Augen einfach Regeln an der falschen Stelle, während eine solche Regel, mit der ich dieses Posting einleitete, oftmals nicht existiert.

Sprich: Eine Tabelle besteht nicht aus Feldern, sondern aus Includes, die zusammen die Tabellenstruktur darstellen. So hat man dann (neben dem MANDT-Feld) zum Beispiel eine Unterstruktur mit Gruppenname KEY (mit den Schlüsselfeldern) und eine weitere mit Gruppenname DATA (für die anderen Felder), was Fieldmappings deutlich vereinfacht. Diese Unterstrukturen kann man wiederverwenden, dann passiert so ein Mist auch nicht, wie ich ihn oben beschrieben habe. Da, wo man sie nicht wiederverwenden kann, muss man sich eben auf einheitliche Namen einigen.

Je enger ein Namenskorsett ist, umso weniger Abstimmungsprobleme gibt es - ich erinnere hierbei daran, was ewx über das Schreiben eines Buches schrieb und welche Regeln es da einzuhalten gibt. Das war eine sehr gut passende Parallele.


Ralf

Re: Von der Wichtigkeit des Default Komponentennamen....

DeathAndPain hat geschrieben:Vielen Dank für den Hinweis. Dass es ein Feld "Default-Komponentenname" überhaupt gibt, hatte meine Großhirnrinde bislang noch gar nicht erreicht, aber ich habe es mir gerade angeschaut. Ich bin auch ein Fan sorgsam gepflegter DDIC-Objekte. Meckert das System dann wenigstens an, wenn man das Datenelement in einer Tabelle verwendet und die Komponente dort dann anders nennt, oder wird erwartet, dass man selber im Datenelement nachsieht? Das macht dann nämlich wieder kein Schwein.

Nein, leider nicht - kleiner Kontrollreport, der täglich als Job durchläuft oder als Prüfung im Code Inspector hinterlegen. Am Besten so, dass es bei der Freigabe eines Transportauftrages prozessiert wird.


Ralf

Re: Von der Wichtigkeit des Default Komponentennamen....

ralf.wenzel hat geschrieben:Eine Namenrichtlinie ist von brennender Wichtigkeit in der Form, dass man sich über Begrifflichkeiten projektweit einigen muss.

Sehe ich auch so. Das ist das Wichtigste.
Der Komponentenname ist dabei hilfreich. Man kann sich aber auch ohne Verwendung des Komponentennames auf einheitliche Schreibweisen einigen.
Eine Einigung, die über den Komponentennamen bestärkt wird, finde ich jedoch auch sehr hilfreich. Da gibt es dann keine Missverständnisse mehr...

black_adept hat geschrieben: Aber in SAP-Programmen sollte man m.E. lieber den DTEL-Namen verwenden statt des Defaultnamens, einfach weil das von den Meisten (schätze ich) so erwartet wird!

Das gilt aber nur für die alten fünf-stelligen Datenelemente. Gerade in den Branchenlösungen oder oder Kundennamensräumen ist es wenig hilfreich ein Feld /CUSTOMER/MODUL_RICHTIGER_NAME zu nennen, sondern stattdessen "RICHTIGER_NAME".

Ich habe den Komponentennamen in einem Projekt verwendet, in dem wir viel mit dynamisch erstellten Tabellen gearbeitet haben. Wir haben dann nur das Datenelement definiert, das in einer Tabelle verwendet werden soll und der Name des Feldes wurde aus dem Komponentennamen ermittelt. Da ist es dann wichtig, dass auch der Feldname in den entsprechenden DB-Tabellen den gleichen Namen hat, damit ein Move-Corresponding funktioniert.

Ja, Move-Corresponding ist nicht ideal. aber wenn man mit dynamisch erstellten Tabellen arbeitet und man 20 dynamische Felder hat und drei bis vier Millionen Datensätze, dann ist ein Move-Corresponding einfacher und schneller als eine direkte Zuweisung mittels ASSIGN.

Re: Von der Wichtigkeit des Default Komponentennamen....

Ok - lasse ich mich erst mal von überzeugen. Gerade bei den /... Datenelementen sollte man die Felder natürlich nicht so nennen - und genau genommen gilt das für die meisten Z-Datenelemente genau so.
Also Namensgleichheit von DTEL und Feldnamen lasse ich mal weg
Aber: @Ralf: Wenn du in einem "neuen" Modul unterwegs bist - Wie viele von SAPs ausgelieferten Datenelementen haben denn dort eine von dir angesprochene, nicht triviale ( = Defaultname ist kein Bestandteil des Datenelementnamens ) Defaultbelegung. Ich schätze, dass SAP auch in den neuen Modulen nicht mehr als 5%-10% ihrer DTELs so ausliefert. Und da bei SAP ja auch diverse Entwickler zusammen arbeiten hätte ich erwartet, dass das da noch viel stärker forciert werden sollte als bei Kunden, so dass ich die Aussage "zu jedem DTEL auch ein Default Component Name zu vergeben" weiterhin nicht unterstütze.

Re: Von der Wichtigkeit des Default Komponentennamen....

Warum diskutierst du mit H.K. auf englisch? Und falls das in einem offenen (englischen) Thread/Forum war - dann poste doch bitte mal den Link dahin.