"Neue" Befehle im ABAP - wer verwendet diese

Re: "Neue" Befehle im ABAP - wer verwendet diese

CHECK ist doch fast neu. Gibt es erst seit Release 4.2B.
Im ABAP3 ging das aber auch schon - hieß bloß nicht so.

Re: "Neue" Befehle im ABAP - wer verwendet diese

DeathAndPain hat geschrieben:Funktionsbausteine mag ich sehr gerne, weil sie technisch gut implementiert sind. Übersichtliche Schnittstelle, die bei Pflege direkt einen exzellent lesbaren Kommentar am Anfang des Codes triggert (wodurch sie auch in Eclipse gut lesbar zur Verfügung steht),...

Wusstest du eigentlich, dass die SE24 auch Schnittstellenkommentare generiert, wodurch sie in Eclipse gut lesbar zur Verfügung stehen? Dumm nur, dass das m.W. von Eclipse selber nicht unterstützt wird.

Beispiel: (Leider hier im Forum mit nicht dargestellten eckigen Klammern - daher als Quote statt als Code

* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Static Public Method ZZZZZZ=>MYMETHOD
* +-------------------------------------------------------------------------------------------------+
* | [--->] IV_BUKRS TYPE BKPF-BUKRS
* | [--->] IV_GJAHR TYPE BKPF-GJAHR
* | [--->] IV_BELNR TYPE BKPF-BELNR
* | [<-()] RV_EINSENDER TYPE KUNNR
* | [!CX!] ZCX_UTILITIES
* +--------------------------------------------------------------------------------------</SIGNATURE>
METHOD MYMETHOD.

was hier kommt ist eigentlich egal
ENDMETHOD.

Edit: Quelltext reduziert, da das Wichtige in den Kommentarzeilen steht.

Re: "Neue" Befehle im ABAP - wer verwendet diese

Das Problem bei Funktionsbausteinen ist, dass die normale Syntaxprüfung die Typen der Schnittstelle nicht verprobt, das dumpt dann erst zur Laufzeit. Darin sehe ich einen erheblichen Vorteil einer Klasse

Von der Sache her bin ich bei Dir, nur bei der Gewichtung habe ich eine deutlich andere Meinung. Was soll an diesem Vorteil "erheblich" sein, wenn einen das System schon beim ersten Ausprobieren (ich sage bewusst nicht "Test", denn einen solchen braucht es dazu noch nicht mal) glasklar auf den Fehler hinweist? Wenn die Probleme alle nur solcherart wären, dann könnten wir froh und glücklich sein!

Spannend finde ich hingegen, dass ich in einem fremden Code gesehen habe, wie jemand einen an einen Funktionsbaustein übergebenen Parameter, der in der Tat nicht auf demselben Datenelement basiert hat, vorher passend mit CONV( ) konvertiert hat, und der Editor hat an der Stelle eine Warnung geworfen, dass dies ein überflüssiger Einsatz von CONV( ) sei!

Die Schnittstelle am Anfang des Codings ist insofern verwirrend, als dass man sie dort nicht pflegen kann, sie ist wirklich nur ein Kommentar. Anfängern muss man sowas oft sagen, sonst pflegen die im Editor vermeintlich die Schnittstelle und wundern sich

Also das finde ich erst recht trivial und kein Problem. Zumal sowohl die SE38 als auch Eclipse Kommentare deutlich als solche hervorheben. Anfänger mögen das lernen müssen, aber was zählt, ist die tägliche Arbeit, und da ist das exzellent handhabbar.

Funktionsbausteine kapseln nicht strikt, und dass sie das nicht tun, ist kein Fehler, sondern Konzept.

Ich weiß, Funktionsgruppen gibt es nicht aus Zufall. Ich finde dieses Konzept nur halt nicht gut und hätte es lieber gesehen, wenn man auf die Funktionsgruppen verzichtet und die Datenversorgung von Funktionsbausteinen auf deren Schnittstelle festgenagelt hätte.

Ich sag mal vereinfachend: Wenn du wirklich kapseln willst, nimm Klassen, keine Funktionsgruppen.

Ach, in bezug auf das, was ich an FBs kritisiert habe, machen Klassen genau den gleichen Mist. Bei einer Methode ist es auch nicht so, dass Du Dich darauf verlassen kannst, dass die Methode ihr Ergebnis allein auf dem aufbaut, was Du ihr als Parameter mitgibst. Was beim FB die funktionsgruppenglobalen Felder sind, sind bei der Klasse die privaten Attribute. Du rufst die Klasse, die verwurstet bei der Bearbeitung Deine Inputparameter mit dem, was andere, zuvor gerufene Methoden derselben Klasse ihr geheim hinterlassen haben, und am Ende bekommst Du gleichfalls ein Ergebnis, das Du nicht nachvollziehen kannst, weil Du nicht weißt, was alles bei seiner Ermittlung eingeflossen ist.

In diesem Sinne ist Klasse = Funktionsgruppe, privates Attribut = funktionsgruppenglobale Variable und Methode = Funktionsbaustein.

Ich weiß, diese Darstellung ist extrem ketzerisch, aber der Fakt ist, dass man eine aufrufbare Subroutine, die insofern leicht zu verstehen ist, als man sich darauf verlassen (!) kann, dass sie nur über ihr definiertes Interface ihre Daten bekommt, in ABAP OO genauso wenig bekommt wie bei herkömmlichen Funktionsbausteinen. Ich finde private Attribute extrem widersinnig. Ein Objekt muss nicht nach außen publizieren, mit welchen Befehlen es arbeitet, aber ich sehe keinen Sinn darin, dass es geheime Informationen aufbewahrt, die die Beschaffenheit des Objektes verschleiern.

Wenn Du der OO-Doktrin folgst, dann wirst Du jetzt argumentieren, dass diese Geheimhaltung wichtig ist, weil sonst die Moral leidet, da Programmierer dann nämlich in unerwünschter Weise von außen diese Attrribute lesen, anstatt brav Methoden zu verwenden und die Kapselung zu respektieren. Aber die in der realen Welt existierende Programmiermoral im Umgang mit OO ist doch sowieso am Boden, weil OO dem schlampig arbeitenden Programmierer nämlich zahllose Möglichkeiten bietet, katastrophalen Code zu erzeugen. Von daher setzt eine sinnvolle Nutzung von OO sowieso voraus, dass man die Disziplin und den Sachverstand hat, korrekt im Geiste von OO zu entwickeln, und wenn man das tut, dann muss man auch nicht mit Schikanen wie verborgenen Attributen "erzogen" werden, die es einem erschweren, das Programm nachzuvollziehen.

Dass es von der Performance her auch schlechter ist, eine GET-Methode aufzurufen anstatt einfach ein Attribut zu lesen, sei hier nur am Rande erwähnt.

Begrüßen würde ich eine komplett attributfreie Form von Klassen, bei der man auf einen Blick erkennen kann, dass es sich um eine attributfreie Klasse handelt. Für viele Zwecke würde die ausreichen, und beim Lesen würde man allein an der Tatsache, dass es sich um eine attributfreie Klasse handelt, erkennen können, dass sämtliche relevanten Informationen in der Schnittstelle stehen und könnte sich so manche Nachforschung im Code sparen. Für komplexere Zwecke, für die man Attribute zwingend braucht, könnte man dann ja immer noch auf die herkömmlichen Klassen zurückgreifen.

Das kommt JETZT? Wo der Fokus (sinnvollerweise) auf UI5 liegen soll? Wer hat sich das denn ausgedacht?

Ich staune auch, aber auf der anderen Seite finde ich es auch sehr angenehm, mit Elementen zu arbeiten, die komplett in der SAP-Welt beheimatet sind und ohne Browser auskommen. Jetzt zum Beispiel ärgere ich mich, dass seit einigen Wochen durch ein Update des Firefox ESR (betrifft aber genauso den normalen Firefox) im Solution Manager keine Checkboxen mehr anklickbar sind! Wenn ich mir also im Solman Transportaufträge für Änderungsdokumente beschaffen möchte, dann muss ich immer Customizing- und Workbench-Auftrag nehmen, auch wenn ich genau weiß, dass ich nur einen von beiden brauchen werde. Ich könnte auf einen anderen Browser umsteigen, aber dazu habe ich auch keine Lust, zumal der FF ja als voll unterstützt gilt. Die SAP zuckt zu dem Problem mit dem Schultern. All solch Gefaxe hätte man nicht, wenn der Solman im SAPGui laufen würde.

Wie unendlich viele zusätzliche Probleme hat man sich damit eingehandelt, dass UI5 und Fiori browserbasiert sind! Ständig ärgert man sich über falsche Darstellungen, und die Fehlersuche ist dann viel aufwendiger, als wenn man in der ABAP-Welt bleiben würde. Klar, Fiori ermöglicht vieles, was im SAPGui nicht geht, insbesondere hinsichtlich moderner Optik und Unterstützung unterschiedlicher Darstellungsgeräte (Smartphone etc.). Aber dennoch finde ich die Frage legitim, für welche Anwendungen man das tatsächlich benötigt, statt aus Hypegründen alles und seinen Hudn in den Browser transferieren zu wollen.

Sowas hat man auch immer, wenn man externe Systeme anbindet. FPM-Formulare und generell das ganze Adobe Interactive Forms-Geraffel sind auch erheblich schwerer zu warten als die perfekt in ABAP eingebetteten Smartforms. Man muss also kein steinzeitliches SAPscript mehr machen, um in ABAP schöne Formulare zu erstellen.

Unter UI5 ist das Teil einfach ein Endgerät mit einem Browser, fertig.

Und wenn dieses Endgerät aus irgendeinem Grund nicht funktioniert, dann legt man sich die Karten und betet, dass es einen Hinweis dazu gibt, weil man sich selbst nicht mehr helfen kann.

Wusstest du eigentlich, dass die SE24 auch Schnittstellenkommentare generiert, wodurch sie in Eclipse gut lesbar zur Verfügung stehen?

Ja, ich glaube, ich habe das mal gesehen. Rein subjektiv finde ich das Interface der SE37 aber angenehmer als das der SE24.

Re: "Neue" Befehle im ABAP - wer verwendet diese

Der Ketzer hat sowas von Recht, de sollte Papst werden

Re: "Neue" Befehle im ABAP - wer verwendet diese

Bei der religiösen Diskussion ging es aber gar nicht um die Präfixe
(die ich für den größten Schwachsinn der Menschheitsgeschichte halte).

Re: "Neue" Befehle im ABAP - wer verwendet diese

Wie attributfreie Klassen oder Funktionsgruppen funktionieren sollen, weiß ich allerdings nicht. Irgendwie musst du doch den Zustand speichern.

Nein, das ist ja der Witz, dass das gute Stück gar keinen Zustand haben soll! In vielen Fällen reicht das aus und macht den Code leichter verständlich bzw. überprüfbar.

Wenn ich zum Beispiel sage:
dann soll mir der FB zum Material den Text liefern. Und da will ich sicher sein, dass er den nur anhand der von mir übermittelten MARA-MATNR ermittelt und nicht manchmal auf russisch, weil vorher jemand den Funktionsbaustein FOOL_THE_DEVELOPER aus derselben Funktionsgruppe aufgerufen und damit einen hier völlig unnützen Zustand in der Funktionsgruppe versteckt hat!

Zustände können nützlich sein, aber ich behaupte, dass man sie sogar bei der Mehrzahl der Funktionsbausteine nicht braucht. In dem Moment, in dem ich das beim Lesen des Funktionsbausteins syntaktisch zugesichert bekomme (etwa weil der FB einen Typ "stateless" hat), weiß ich schon mal, dass eine riesige Quelle von Fehlern und Unsicherheiten ausgeschlossen ist und ich mich allein auf das, was ich in der Schnittstelle sehe, verlassen kann. Zugleich vereinfacht sich das Testen des Bausteins dramatisch!

Gleiches gilt für statische Klassen.

Re: "Neue" Befehle im ABAP - wer verwendet diese

Kommt ein bisschen spät, aber:

Daniel hat geschrieben:CHECK ist doch fast neu. Gibt es erst seit Release 4.2B.
Im ABAP3 ging das aber auch schon - hieß bloß nicht so.

Bist Du Dir da ganz sicher? Ich könnte schwören, dass ich CHECK von Anfang an benutzt habe, und das war Release 3.1i. Von dort aus haben wir damals direkt auf 4.7 upgegradet (ja, das ging und war offiziell supportet!), so dass ich ja sonst erst sehr spät mit dem CHECK hätte anfangen können. Und ich glaube, dass ich das wüsste, wenn ich so lange ohne ihn hätte auskommen müssen.

Re: "Neue" Befehle im ABAP - wer verwendet diese

Ich bin jetzt nicht ganz sicher, was Du mit "4,2B" meinst. Ich hätte gedacht, ein 4er-Release, das dann offensichtlich nach 3.1i gekommen wäre.

Auf der anderen Seite ist meine Erinnerung, dass nach 3.1i 4.0 und dann gleich 4.5 gekommen ist.

Wie dem auch sein mag, 3.1i war irgendwo um das Jahr 2000, ist also schon richtig lange her. Und zumindest seitdem gibt es den CHECK-Befehl.

Spannender finde ich da schon die Betrachtung der Syntax WITH HEADER LINE. Die gab es nämlich in 3.1i definitiv noch nicht; da ging nur OCCURS. Sie muss später gekommen sein, obgleich die SAP dann ja alsbald Kopfzeilen deprecated hat.