gelöst Gehaltsvorstellungen SAP ABAP-Entwickler


Getting started ... Alles für einen gelungenen Start.

Moderatoren: Jan, Steff

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon DeathAndPain » 21.09.2018, 17:31

für manche Sachen ist es im Konstruktor einfach zu spät.

Es wäre nett, wenn Du das genauer erläutern könnntest.

Ich mag öffentliche RO-Attribute nicht, es gibt IMMER GET-Methoden, weil sich oft herausstellt, dass für manche Lesezugriffe auf Attribute doch ein bisschen Logik notwendig ist. Auch wenn das in 9 von 10 Fällen nicht der Fall ist.

Nur wird damit die im Vergleich ohnehin schon hundsmiserable Performance von OO nochmal ein Stückchen schlechter. In den meisten Fällen mag ABAP-Performance keine Rolle spielen, aber in manchen eben doch (etwa wenn man einen Report programmiert, der sehr viele Zeilen kompliziert zu lesender Werte ermittelt).
DeathAndPain
Expert
 
Beiträge: 812
Registriert: 05.05.2006, 10:14
Dank erhalten: 189 mal
Ich bin: Entwickler/in

Sponsor

Alte ABAP-Entwicklerweisheit: Weißt du weder aus noch ein, baust du einen BADI ein

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon ewx » 21.09.2018, 17:44

DeathAndPain hat geschrieben:hundsmiserable Performance von OO

boaey, geht das schon wieder los? :mrgreen:
ewx
Top Expert
 
Beiträge: 3776
Registriert: 04.08.2003, 19:55
Wohnort: Schleswig-Holstein
Dank erhalten: 310 mal

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon ralf.wenzel » 21.09.2018, 18:45

Don‘t feed....

Wir bauen gerade ein sehr komplexes Modul, die Maschine ist kein Ferrari, Performance ist das kleinste Problem.


Ralf
ralf.wenzel
Top Expert
 
Beiträge: 3242
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 190 mal
Ich bin: Freiberufler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon DeathAndPain » 24.09.2018, 16:11

Das kann gut sein. Nur machst Du den Fehler, das Modul, das ihr baut, als Maßstab für die gesame Entwicklergemeinde zu betrachten. Es gibt Ecken, in denen ist Performance relevant und andere, da ist sie es nicht. Da muss man immer auf den Kontext achten.
DeathAndPain
Expert
 
Beiträge: 812
Registriert: 05.05.2006, 10:14
Dank erhalten: 189 mal
Ich bin: Entwickler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon ralf.wenzel » 24.09.2018, 18:21

Du hast mein Posting falsch verstanden. Ich meinte: Trotz strenger OO-Orientierung und einer recht lahmen Maschine ist die Performance richtig gut. Muss man halt ein paar Design Patterns für kennen. Ich meinte NICHT, Performance sei nicht wichtig im Projekt, im Gegenteil.


Ralf
ralf.wenzel
Top Expert
 
Beiträge: 3242
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 190 mal
Ich bin: Freiberufler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon DeathAndPain » 25.09.2018, 10:36

Kommt drauf an, wo und wie. Meine Lieblingsschätzchen sind zwei Programme, die aus ganz vielen Tabellen Werte zusammensuchen und eine Ergebnisliste daraus bauen. Dabei ist all diesen Quelltabellen gemein, dass sie periodenbasiert sind, soll heißen, dass sie Spalten BEGDA und ENDDA haben. Für jeden Mitarbeiter kann sich jederzeit in einer dieser Tabellen ein Wert ändern. Dann muss eine neue Tabellenzeile erzeugt werden, bei der alle anderen Werte gleich bleiben, aber der eine Wert sich halt ändert (mit BEGDA und ENDDA dieser Tabellenzeile entsprechend gesetzt). Da habe ich endlos viele und zudem geschachtelte Iterationen; da ist ABAP-Performance richtig bedeutsam (da ich die Datenbanktabellenzugriffe einmal zu Programmbeginn per SELECT FOR ALL ENTRIES IN puffere, was die Datenbankzugriffszeit auf einen winzigen Bruchteil reduziert). Wenn ich da OO einsetzen würde, dann würde die Laufzeit drastisch ansteigen. Das fängt schon bei so simplen Sachen an wie Tabellenzugriff mit 7.40-Syntax nebst CATCH CX_SY_ITAB_LINE_NOT_FOUND. Wie ich an anderer Stelle gemessen und hier berichtet habe, steigt damit im Falle des Nichtvorhandenseins der Zeile die Laufzeit des Tabellenlesezugriffs auf das Siebenfache.

Aber klar, wenn Du nur einfache Zugriffe außerhalb von Iterationen hast, dann kannst Du Dir auch luxuriöse Performance Hogs wie in Klassen gekapselte Funktionsbausteine und Getter/Setter-Methoden für jedes Attribut leisten, ohne dass der Anwender etwas davon merkt.
DeathAndPain
Expert
 
Beiträge: 812
Registriert: 05.05.2006, 10:14
Dank erhalten: 189 mal
Ich bin: Entwickler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon ewx » 25.09.2018, 10:59

DeathAndPain hat geschrieben:da ich die Datenbanktabellenzugriffe einmal zu Programmbeginn per SELECT FOR ALL ENTRIES IN puffere, was die Datenbankzugriffszeit auf einen winzigen Bruchteil reduziert. Wenn ich da OO einsetzen würde, dann würde die Laufzeit drastisch ansteigen.

Was hat das mit objektorientierter Programmierung zu tun?
ewx
Top Expert
 
Beiträge: 3776
Registriert: 04.08.2003, 19:55
Wohnort: Schleswig-Holstein
Dank erhalten: 310 mal

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon DeathAndPain » 25.09.2018, 14:43

Ich habe das nur am Rande erwähnt, um dem naheliegenden Argument vorzubeugen, dass die Datenbankzugriffe in aller Regel den erdrückenden Löwenanteil der Programmlaufzeit auszumachen pflegen, so dass die ABAP Performance kaum interessiere. Deshalb habe ich es auch in Klammern gesetzt, die Du aber nicht mitzitiert hast (und das bedeutet sofort: falsch zitiert!)

Wenn Dir das klar ist, kannst Du Dir die Klammer samt Inhalt in meinem Text gerne wegdenken.
DeathAndPain
Expert
 
Beiträge: 812
Registriert: 05.05.2006, 10:14
Dank erhalten: 189 mal
Ich bin: Entwickler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon ewx » 25.09.2018, 15:10

ok. jetzt hab ich's verstanden.
Trotzdem bezweifle ich, dass eine OO-Programmierung deines Lieblingsschätzchens eklatant langsamer wäre.
Und nur weil man die 7.40er Syntax benutzt, programmiert man noch lange nicht objektorientiert.
ewx
Top Expert
 
Beiträge: 3776
Registriert: 04.08.2003, 19:55
Wohnort: Schleswig-Holstein
Dank erhalten: 310 mal

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon ralf.wenzel » 25.09.2018, 15:52

DeathAndPain hat geschrieben:Ich habe das nur am Rande erwähnt, um


gegen OO zu stänkern mit einem Thema, das mit OO nichts zu tun hat.


Ralf
ralf.wenzel
Top Expert
 
Beiträge: 3242
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 190 mal
Ich bin: Freiberufler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon DeathAndPain » 25.09.2018, 16:19

Wenn Du meinen Text ernsthaft gelesen hast, anstatt darin nur das zu sehen, was Deine Vorurteile Dich sehen lassen wollen, dann kannst Du das nicht ernst meinen.

Ich kann nicht glauben, dass hier bei einem 209 Wörter umfassenden Beitrag von mir, der eine 22 Wörter umfassende, explizit in Klammern gesetzte Randbemerkung enthält, krampfhaft versucht wird, diese als Kern des Beitrags darzustellen. Sonst ist das Niveau in diesem Forum hier bedeutend höher; auf derartigem Niveau wird hier normalerweise nicht argumentiert.

ewx hat geschrieben:Trotzdem bezweifle ich, dass eine OO-Programmierung deines Lieblingsschätzchens eklatant langsamer wäre.

Tja, da sind wir halt unterschiedlicher Meinung.

ewx hat geschrieben:Und nur weil man die 7.40er Syntax benutzt, programmiert man noch lange nicht objektorientiert.

Da hast Du vollkommen recht, und das wollte ich auch nicht behaupten. Ich wollte nur darauf hinweisen, dass bei der kleinsten Verwendung von OO-Elementen, wie eine solche Ausnahmeklasse sie darstellt, sofort die ABAP-Performance eklatant einknickt.

Was ich nicht untersucht habe, was aber mal interessant wäre, ist, wie die Performance sich darstellen würde, wenn man FBs statt Formroutinen verwenden würde. Funktionsgruppen haben ja so große Ähnlichkeiten mit Klassen, dass ich sie als Vorläufer von Klassen einschätzen würde. Allerdings gibt es sie schon so lange, dass ihre Performance auch auf aus heutiger Sicht antiker Hardware noch in Ordnung sein sollte. Müsste man mal ein Testprogrämmchen für schreiben.
DeathAndPain
Expert
 
Beiträge: 812
Registriert: 05.05.2006, 10:14
Dank erhalten: 189 mal
Ich bin: Entwickler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon ralf.wenzel » 25.09.2018, 16:50

DeathAndPain hat geschrieben:Da hast Du vollkommen recht, und das wollte ich auch nicht behaupten. Ich wollte nur darauf hinweisen, dass bei der kleinsten Verwendung von OO-Elementen, wie eine solche Ausnahmeklasse sie darstellt, sofort die ABAP-Performance eklatant einknickt.


Das ist so nicht richtig, wenn man die Funktionalität dagegen hält. Immerhin halten Kaskaden von Ausnahmeklassen ganze Protokolle im Speicher, die man zum Beispiel ins Application Log schreiben kann. Das kannst du auch prozedural nicht nennenswert schneller machen. Du fragst den sy-subrc ab und sagst, das gehe schneller. Klar geht das schneller, aber das musst du ja irgendwie gescheit verarbeiten. Und diese Verarbeitung ist, bei entsprechender Komplexität, ein Performancefresser (ich nehme mal das provokante Wort, weil SO schlimm kann das nicht sein, sonst hätten wir das im Projekt gemerkt).

DeathAndPain hat geschrieben:Funktionsgruppen haben ja so große Ähnlichkeiten mit Klassen


Nein. Außer, dass beide aus ABAP-Coding bestehen, gibt es praktisch keine Parallelen. Ich kann (ohne Dirty Assign) nicht von außen auf Attribute einer Funktionsgruppe zugreifen (streng genommen HAT eine Funktionsgruppe keine Attribute, sondern Variablen, weil sie keinen Zustand hat). Ich kann auch keine Hilfs-Funktionsbausteine als geschützt deklarieren, damit sie nicht von außen im Zugriff sind. Dieses Problem habe ich gerade bei einem RFC-Funktionsbaustein, der eigentlich von anderen nicht aufgerufen werden darf. Es gibt auch keine Vererbung, ich kann nicht mehrere Funktionsgruppen-Instanzen im Speicher halten. Sprich: Ich muss dem Funktionsbaustein zum Verbuchen einer Blutspende stets alle Daten mitgeben, weil es eben nur eine Instanz gibt (darum hat eine Funktionsgruppe auch keinen Zustand, weil es eh nur eine Instanz gibt). Das Interface einer Funktionsgruppe besteht aus den Funktionsbausteinschnittstellen. Ich kann also nicht eine Teilfunktionalität an eine (wie auch immer realisierte) Prozedur übergeben. Genau genommen: Ich kann eine Funktionsgruppe oder einen Funktionsbaustein überhaupt nicht an eine Prozedur übergeben.

Und bis zu diesem Punkt habe ich noch nichtmal darüber NACHGEDACHT, welche Unterschiede mir noch so einfallen....

Ein Flugzeug hat Reifen, ein Fahrrad auch. Trotzdem muss man schon ziemlich schräg denken, das Fahrrad als Vorläufer des Flugzeuges zu betrachten. Nicht alles, was hinkt, ist ein Vergleich.


Ralf
ralf.wenzel
Top Expert
 
Beiträge: 3242
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 190 mal
Ich bin: Freiberufler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon ewx » 25.09.2018, 17:27

DeathAndPain hat geschrieben:Ich kann nicht glauben, dass hier bei einem 209 Wörter umfassenden Beitrag von mir, der eine 22 Wörter umfassende, explizit in Klammern gesetzte Randbemerkung enthält, krampfhaft versucht wird, diese als Kern des Beitrags darzustellen.

Das war ein Versehen, weil ich erst nur auf den geklammerten Teil Bezug nehmen wollte und dann gemerkt habe, dass es sich eben nicht auf den in Klammern stehenden Teil bezog...

DeathAndPain hat geschrieben:
ewx hat geschrieben:Und nur weil man die 7.40er Syntax benutzt, programmiert man noch lange nicht objektorientiert.

Da hast Du vollkommen recht, und das wollte ich auch nicht behaupten. Ich wollte nur darauf hinweisen, dass bei der kleinsten Verwendung von OO-Elementen, wie eine solche Ausnahmeklasse sie darstellt, sofort die ABAP-Performance eklatant einknickt.


Du hängst dich immer wieder an diesem einen Beispiel auf... Es ist wichtig zu wissen, dass das so ist. Und wenn dieser READ[ index ], der zudem oftmals fehlschlagen kann, ein zentrales, performancekritisches Element in der Programmierung ist, dann darf man ihn halt nicht verwenden. Aber die Aussage, "dass bei der kleinsten Verwendung von OO-Elementen [...] sofort die ABAP-Performance eklatant einknickt." ist definitiv falsch.

DeathAndPain hat geschrieben:Was ich nicht untersucht habe, was aber mal interessant wäre, ist, wie die Performance sich darstellen würde, wenn man FBs statt Formroutinen verwenden würde. Funktionsgruppen haben ja so große Ähnlichkeiten mit Klassen, dass ich sie als Vorläufer von Klassen einschätzen würde. Allerdings gibt es sie schon so lange, dass ihre Performance auch auf aus heutiger Sicht antiker Hardware noch in Ordnung sein sollte. Müsste man mal ein Testprogrämmchen für schreiben.

Du vergleichst Äpfel mit Rosinen... Performance hat so viele Facetten, die man nicht auf solche Dinge wie "Klasse" oder "Funktionsbaustein" reduzieren kann.
Beim Aufruf eines Funktionsbausteins wird übrigens die gesamte Funktionsgruppe in den Speicher geladen, beim Aufruf einer Methode nur der Sourcecode dieser Methode...
Meistens hängt die Performance nicht ab von der "Form" der Programmierung, sondern von der Logik. Wenn die Logik sch3!&%e ist, dann ist es egal, ob Programm, Funktionsgruppe oder Klasse.

Pack doch mal eine oder zwei zentrale Funktionen deines Lieblingsprogramm mit einem Demodatenbestand von x Datensätzen auf github und wir schauen mal, ob es überhaupt relevant ist, mit welcher Methodik es programmiert wird und was sich für Vorteile ergeben, wenn man es evtl. doch objektorientiert aufbaut...


Und - um noch einmal die Kurve zum eigentlichen Thema zu bekommen - von einem SAP-Entwickler erwarte ich, dass er einen guten Kompromiss aus Wartbarkeit und Entwicklungszeit findet. Und dafür muss man sich zumindest etwas in OO auskennen. Denn vieles ist definitiv nur mit OO möglich. Das heißt nicht, dass OO das stets perfekte Tool ist. Bei vielen Aufgaben ist es definitiv egal, ob ich den Report old-school oder objektorientiert programmiere.

Ein Bewerber, der mir im Bewerbungsgespräch sagen würde: "OO benutze ich nicht - das ist ja viel zu langsam", würde ich ziemlich sicher ziemlich zügig eine Absage schicken.

Für diese Nachricht hat ewx 2 Dankeschön bekommen :
AdrianSchm, ralf.wenzel
ewx
Top Expert
 
Beiträge: 3776
Registriert: 04.08.2003, 19:55
Wohnort: Schleswig-Holstein
Dank erhalten: 310 mal

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon DeathAndPain » 26.09.2018, 11:27

Ralf hat geschrieben:Das ist so nicht richtig, wenn man die Funktionalität dagegen hält.

Du beharrst darauf, nicht beim Thema zu bleiben. Dass OO viele Funktionalitäten bietet, die ohne nicht (bzw. nur auf Umwegen) erreichbar sind, ist unbestritten, hat aber mit der Performance nichts zu tun. Und wenn ich Daten für eine komplizierte Liste bereitstellen muss, bei der ich aus vielen Tabellen mit vielen Iterationen die Ergebniszeilen zusammenbasteln muss, dann nützen mir Kaskaden von Logs nichts, aus denen ich ersehen kann, an welcher Stelle mein Programm wegen Timeouts abgebrochen hat. Dann brauche ich einfach effizienten Code ohne Ballast.

An anderen Stellen ist die Performance praktisch gegenstandslos und Deine Funktionalitäten dafür wichtiger. Bei Deinem Blutspendeprojekt scheint das so zu sein. Das muss man fallweise entscheiden.

Ralf hat geschrieben:Nein. Außer, dass beide aus ABAP-Coding bestehen, gibt es praktisch keine Parallelen.

Da bin ich anderer Meinung. Natürlich sind Klassen viel neuer und damit ausgefeilter und umfassender. Man kann Funktionsgruppen als Vorläufer der Klassen bezeichnen. Aber wie Klassen enthalten Funktionsgruppen eine Ansammlung aufrufbarer Unterroutinen mit definierter Parameterschnittstelle, wie bei Klassen kann ich in Funktionsgruppen Werte verstecken, die Zustände definieren und von außen (legal) nicht zugreifbar sind, wie bei Klassen kann ich Ausnahmen zurückliefern (auch wenn man bei Klassen mehr damit anstellen kann). Klassen haben diverse Vorteile, weil bei ihnen das Konzept eben erheblich weiterentwickelt ist. Dafür haben Funktionsbausteine allerdings einen Vorteil, den ich persönlich als sehr gravierend wahrnehme: Sie bieten hervorragende Unterstützung von Online-Dokumentation bis hinunter zur plakativ angeboteten Detaildoku jedes einzelnen Parameters und jeder einzelnen Ausnahme an, während die Online-Dokumöglichkeiten von Methoden versteckt über das Menü, wo eh nie jemand reinschaut, nur als stiefmütterlich bezeichnet werden können.

ewx hat geschrieben:Aber die Aussage, "dass bei der kleinsten Verwendung von OO-Elementen [...] sofort die ABAP-Performance eklatant einknickt." ist definitiv falsch.

Jein. Ich halte das für eine Blickwinkelfrage. Der einzelne Befehl wird mit OO erheblich langsamer. Im Kontext betrachtet hat man aber in einem Benutzerdialog vielleicht eine Laufzeit von 200 ms, bis das nächste Fenster auf dem Schirm steht. Selbst wenn sich diese auf 400 ms verdoppeln würde, würde der Anwender es kaum wahrnehmen, so dass man nicht von einem unperformant laufenden Programm reden könnte. Diesen oder vergleichbare Fälle hat man oft in der Praxis, so dass die besseren Abstraktionsmöglichkeiten von OO durchaus ausschlaggebende Vorteile bieten können. Allerdings nach meiner Überzeugung eben nur bei hochkomplexen Großprojekten wie Ralfs Blutspendedienst, deren Komplexität mit konventionellen Programmiermethoden nicht beherrschbar ist, so dass man in den sauren Apfel beißen und zu OO-Code greifen muss, den später kein Projektfremder mehr versteht, wenn er nicht vorher seitenweise die Dokus der ganzen Objekte liest und versteht. Dazu müssen diese Dokus freilich existieren und detailliert und verständlich geschrieben sein. Gerade Letzteres ist ein bedeutsamer Engpass, denn die meisten Menschen (und ich rede noch nicht mal von Ausländern) sind gar nicht fähig, detaillierte Zusammenhänge strukturiert und nachvollziehbar in Worte zu kleiden. Und nun lass noch Englisch als Projektsprache gefordert sein... Es ist einfach ein nicht zu unterschätzender Vorteil, wenn man noch eine Chance hat, sich aus dem Programmcode selbst dessen Funktionsweise zu erarbeiten. Auch dann, wenn noch der eine oder andere Bug vorhanden ist (was bei Klassen auch bitter ist, denn wenn ich versuche, eine Klasse zu verstehen und diese sich dann nicht sollgemäß verhält, dann lege ich mir die Karten angesichts der Frage, ob das ein Bug ist oder ich nur noch nicht richtig verstanden habe, wie die Klasse funktioniert).

Wenn ich in meinem Programm mit seinem vielen Iterationen über die internen Tabellen mit den Teilwerten jetzt aber anfangen würde, aus den internen Tabellen Containerobjekte zu machen und - überspitzt formuliert - jeden READ TABLE durch den Aufruf einer GETter-Methode zu ersetzen, die sich dann über diverse Dereferenzierungen den Wert besorgt, dann habe ich keine Zweifel, dass das absolut verheerend für die Programmlaufzeit wäre.

ewx hat geschrieben:Beim Aufruf eines Funktionsbausteins wird übrigens die gesamte Funktionsgruppe in den Speicher geladen, beim Aufruf einer Methode nur der Sourcecode dieser Methode...

Du meinst, die zugehörige Klasse mit ihren Attributen usw. wird nicht in den Speicher geladen? Ist das Dein Ernst?!? Eine Klasse ist ein Rahmenprogramm. Ohne dieses sind die zugehörigen Methoden doch gar nicht funktionsfähig!

Möglicherweise wird bei Klassen der Quelltext anderer Methoden nicht in den Hauptspeicher geladen, wenn eine Methode aufgerufen wird. Da stecke ich nicht tief genug im Kernel drin, um das beurteilen zu können. Aber der Speicherbedarf von Quelltexten ist heutzutage ja ein Lacher. Selbst wenn der Quelltext als unkomprimiertes ASCII geladen werden würde, reden wir bei 1000 Zeilen Code nur von ein paar kb. Tatsächlich hoffe ich, dass der ABAP-Compiler zumindest das kann, was schon der BASIC-Interpreter des C64 konnte, nämlich aus Schlüsselwörtern (Befehlen) Tokens zu machen, die im Hauptspeicher dann nur noch ein Byte belegen.

ewx hat geschrieben:Pack doch mal eine oder zwei zentrale Funktionen deines Lieblingsprogramm mit einem Demodatenbestand von x Datensätzen auf github und wir schauen mal, ob es überhaupt relevant ist, mit welcher Methodik es programmiert wird und was sich für Vorteile ergeben, wenn man es evtl. doch objektorientiert aufbaut...

Ich kann nicht einfach Firmencode ins Internet hochladen. Zumal sich einzelne Funktionen nicht wirklich isoliert betrachten lassen, sondern sich das über die Iterationen verzahnt. Im Prinzip habe ich eine Tabelle von Mitarbeitern (da könnteste im MM aber genauso gut Materialien nehmen). Zu diesen lese ich jetzt innerhalb eines Zeitraums einen Wert, sagen wir, die Mitarbeitergruppe. Immer, wenn sie sich ändert, erzeuge ich eine neue Zeile. Ändert sich für Mitarbeiter X im Zeitintervall also zweimal die Mitarbeitergruppe, dann hat er in der Ergebnistabelle hinterher drei Zeilen.

Jetzt nehme ich diese Ergebnistabelle und lese das nächste Attribut, sagen wir, den Mitarbeiterkreis. Für jede einzelne Zeile der Ergebnistabelle, also nicht nur für jeden Mitarbeiter, sondern auch für jeden einzelnen bereits in der Tabelle bestehenden Teilzeitraum muss ich jetzt nicht nur den Mitarbeiterkreis lesen, sondern schauen, ob dieser sich möglicherweise innerhalb dieses Teilzeitraums ändert, womöglich sogar mehrfach ändert. Dann muss ich diese Tabellenzeile in entsprechend viele Unterzeilen aufteilen, die alle dieselbe Mitarbeitergruppe haben, aber unterschiedliche Mitarbeiterkreise.

Dann mache ich dasselbe mit dem nächsten Attribut. Dann wieder mit dem nächsten. Usw. Das eine der beiden Programme hat 92 Attribute, die auf diese Weise gelesen werden! Und nicht alle davon stehen im Klartext in der Datenbank, sondern müssen z.T. selber erst ermittelt werden. Wenn ich beispielsweise den Vorgesetzten des Mitarbeiters ermitteln möchte, dann muss ich dafür die (zuvor ermittelte) Planstelle des Mitarbeiters nehmen, deren Organisationseinheit ermitteln, schauen, ob diese eine Führungsplanstelle hat, hat sie nicht, also die übergeordnete Orgeinheit ermitteln, schauen, ob die eine Führungsplanstelle hat, hat sie, dann den Inhaber dieser Führungsplanstelle ermitteln, schauen, ob der überhaupt aktiv ist (er könnte z.B. auch in Sabbatical oder in Elternzeit sein, was dann bedeuten würde, dass ich entweder einen anderen Planstelleninhaber finden oder doch wieder eine Orgeinheit nach oben gehen muss), und dann erst habe ich die Personalnummer des Vorgesetzten.

Nun kann es natürlich auch passieren, dass sich innerhalb des Zeitraums der Inhaber der Führungsplanstelle ändert, was dann bedeutet, dass der Vorgesetzte sich ändert und ich damit wieder in zwei Tabellenzeilen aufteilen muss.

Von daher sind Werkzeuge zur Abstraktion hier eigentlich interessant. Aber wenn ich da mit Objekten und Methoden jongliere, dann geht mir die Performance dermaßen in die Knie, dass das Ganze nicht zu gebrauchen ist.
DeathAndPain
Expert
 
Beiträge: 812
Registriert: 05.05.2006, 10:14
Dank erhalten: 189 mal
Ich bin: Entwickler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon black_adept » 26.09.2018, 11:33

ewx hat geschrieben:Beim Aufruf eines Funktionsbausteins wird übrigens die gesamte Funktionsgruppe in den Speicher geladen, beim Aufruf einer Methode nur der Sourcecode dieser Methode...
Bitte nachreichen, wo diese Information offiziell dokumentiert ist ( falls es überhaupt stimmt, was ich ohne die nachzureichende Doku erst mal bezweifele ).
ewx hat geschrieben:Und - um noch einmal die Kurve zum eigentlichen Thema zu bekommen - von einem SAP-Entwickler erwarte ich, dass er einen guten Kompromiss aus Wartbarkeit und Entwicklungszeit findet. Und dafür muss man sich zumindest etwas in OO auskennen.[...]. Das heißt nicht, dass OO das stets perfekte Tool ist. Bei vielen Aufgaben ist es definitiv egal, ob ich den Report old-school oder objektorientiert programmiere.
Ein Bewerber, der mir im Bewerbungsgespräch sagen würde: "OO benutze ich nicht - das ist ja viel zu langsam", würde ich ziemlich sicher ziemlich zügig eine Absage schicken.
Mit dieser Aussage machst du dir weder Ralf noch D&P zum Freund. Aber ich kann dir endlich mal vollumfänglich zustimmen.
ewx hat geschrieben:Denn vieles ist definitiv nur mit OO möglich.
Das gilt aber fast ausschließlich für Sichtbarkeiten - alles andere ist auch ohne OO machbar/möglich - evtl. aber deutlich aufwändiger.
ralf.wenzel hat geschrieben:
DeathAndPain hat geschrieben:Funktionsgruppen haben ja so große Ähnlichkeiten mit Klassen
Nein. Außer, dass beide aus ABAP-Coding bestehen
@Ralf: Doch - die beiden haben große Ähnlichkeiten in der Verwendung.
ralf.wenzel hat geschrieben: Ich kann (ohne Dirty Assign) nicht von außen auf Attribute einer Funktionsgruppe zugreifen
Wenn ich andere Posts von dir lese stellst du auch all deine Attribute auf privat und arbeitest mit Settern und Gettern, so dass das dann doch wieder ähnliches Verhalten ist
ralf.wenzel hat geschrieben:Ich kann eine Funktionsgruppe oder einen Funktionsbaustein überhaupt nicht an eine Prozedur übergeben.
Wenn du den Namen der FuGr oder des FuBa übergibst ist das völlig ausreichend um damit i.a. das abzubilden von dem ich glaube, dass du es meinst.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de
black_adept
Top Expert
 
Beiträge: 3100
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 525 mal
Ich bin: Freiberufler/in

VorherigeNächste

Zurück zu ABAP® für Anfänger

  Aktuelle Beiträge   
Scope items
Gestern von SAP_ENTWICKLER 0 Antw.
Favoriten-Menü in selbst programmierter Werthilfe
Gestern von ralf.wenzel 6 Antw.
gelöst Erweitern Matchcode KREDA/M_KREDA /LFA1)
Gestern von deejey 7 Antw.
BAPI_CHARACT_CHANGE (Änderung Klassifizierung)
vor 2 Tagen von sap_inchen 0 Antw.
Query SQVI - Benutzergruppe wechseln
vor 16 Stunden von wreichelt 7 Antw.

  Ähnliche Beiträge beta
Keine Beiträge gefunden - versuche es mit der erweiterten Suche.

 

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder