"Modulpools sind veraltete Technologie"
Es macht einen Unterschied, ob ich jemanden kenne, der schon mal für die SAP gearbeitet hat (das sind ca. 100.000 Menschen) oder ob ich jemanden kenne der über ene aussergewöhnliche Qualifikation verfügt.Ich kenne die Details ...
Letzteres kann man auch mit begründen ohne persönliche Dinge zu veröffentlichen
Ich lade den produktiven Stand ins Entwicklungs-System, berichtige den Fehler und stelle die korrigierte Fassung produktiv. Danach lade ich den aktuellen Entwicklungszustand zurück. Das kostet mich keine 5 Minuten weil ich entsprechende Werkzeuge habe.Baust du den ganzen Rotz zurück um den Fehler zu beheben? Oder sagst du dem Fachbereich "Ok, bucht mal x Wochen weiter falsche Belege ins System, das Progamm ist leider durch eine Entwicklung gesperrt".
Das sieht nur so aus, ist aber tatsächlich das selbe.Zum Beispiel etwas vollkommen anderes als eine Funktionsgruppe - allerspätestens wenn du versuchst, es von einem anderen Programm aus aufzurufen.Was ist ein Modulpool?
Der Unterschied zwischen
Code: Alles auswählen.
Call FunktionCode: Alles auswählen.
perform form in progUnd Funktionsbibliotheken haben das gleiche globale Speicherprinzip wie Modulpools. Darüber hinaus lassen sich Funktionsbibliotheken auch als Modulpools nutzen, wenn man gemischt programmiert. Da gibt es dann keine Einschränkung.
Verbuhungsmodulpools gibt es seit R/2 nicht mehrvon Verbuchungslogik vom Modulpool zur Funktionsgruppe
Da bin ich nicht mal so sicher. Im Grunde basiert das alles noch auf den Ursprüngen des R/2 und hat sich vielfach bewährt.Na, dass man die SAP Entwicklungsumgebung heute völlig anders aufbauen würde, würde man JETZT damit anfangen, es zu designen, steht außer Frage - das gilt im Übrigen für SAP an sich auch.
Sicher würde man einige Details anders implementieren, aber noch niemand hat bisher ein besseres Konzept präsentieren können.
Da hat offensichtlich jemand das Prinzip der dynamischen Programmierung noch nicht verstanden. Modulpool unterscheiden sich von prozeduralen (normalen) Programmen durch das Fehlen der Ablauflogik - und das ist ein erheblicher Unterschied!Was ist ein Modulpool?
Im Grunde ist es doch nix anderes als ein Normales Programm welches alle INCLUDE-Anweisungen in einem eigenständigen Include (welches sich Rahmenprogramm schimpft) stehen hat.
Gruss
Daniel
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Mich stört vielmehr, dass man das Verhalten bei der Anlage neuer Objekte nicht steuern kann.
Wenn ich einen kleinen Testreport schreibe, dann nervt es einfach, den Vorschlag weg- und das Rahmenprogramm anzuklicken.
Eine Auswahl:
[_] Neue Objekte immer im Hauptprogramm
[_] Neue Objekte typabhängig in Includes
[_] Neue Objekte immer in eigenem Include anlegen
wäre schon nett...
Wenn ich einen kleinen Testreport schreibe, dann nervt es einfach, den Vorschlag weg- und das Rahmenprogramm anzuklicken.
Eine Auswahl:
[_] Neue Objekte immer im Hauptprogramm
[_] Neue Objekte typabhängig in Includes
[_] Neue Objekte immer in eigenem Include anlegen
wäre schon nett...
Hallo,
Modulpools sind doch eigentlich Programme, die keine Programme sind.
Mittlerweile können alle die dort möglichen Funktionen in jedem anderen SAP-Entwicklungskonstrukt (außer OO) dargestellt werden.
Die Anwendung von Modulpools, die Verschachtelung, Modifizierung, PERFORM xxx in PROGRAM sonstwo kenne ich aus dem SD und FI- Umfeld. Das ist GRAUSAM.
Neue Programme erstelle ich in ABAP-OO.
Wenn ich dabei ein Dynpro brauche, nehme ich dazu eine Funktionsgruppe. Jedes Bild bekommet einen Funktionsbaustein vorweg, den rufe ich aus dem OO-Kontext auf und der liefert mir das, was "jemand" eingetippt hat.
Die Bildfunktionen sind mehrfach verwendbar, liefern eindeutige Ergebnisse. Welche Dynpros nacheinander aufgerufen werden bestimmt das OO-Objekt.
Kein Rumgehüpfe mit Call Screen, set Screen Perform xxx in Program zzz etc.
Mehrfach verwendete Incluldes sind heute niche mehr zeitgemäß. Ein sauberes OO-Objekt mit definierter Schnittstelle ist übersichtlicher und leichter zu testen.
Wie und wann welche Includes in das Coding eingebaut werden, entscheidet die FB-Oberfläche oder die Klassen-Oberfläche. (Ist mir grade egal!)
Ich denke. gerade in der Bildschirmsteuerung kann ein bisschen Objektorientierung nicht schaden.
Gruß
babap
Modulpools sind doch eigentlich Programme, die keine Programme sind.
Mittlerweile können alle die dort möglichen Funktionen in jedem anderen SAP-Entwicklungskonstrukt (außer OO) dargestellt werden.
Die Anwendung von Modulpools, die Verschachtelung, Modifizierung, PERFORM xxx in PROGRAM sonstwo kenne ich aus dem SD und FI- Umfeld. Das ist GRAUSAM.
Neue Programme erstelle ich in ABAP-OO.
Wenn ich dabei ein Dynpro brauche, nehme ich dazu eine Funktionsgruppe. Jedes Bild bekommet einen Funktionsbaustein vorweg, den rufe ich aus dem OO-Kontext auf und der liefert mir das, was "jemand" eingetippt hat.
Die Bildfunktionen sind mehrfach verwendbar, liefern eindeutige Ergebnisse. Welche Dynpros nacheinander aufgerufen werden bestimmt das OO-Objekt.
Kein Rumgehüpfe mit Call Screen, set Screen Perform xxx in Program zzz etc.
Mehrfach verwendete Incluldes sind heute niche mehr zeitgemäß. Ein sauberes OO-Objekt mit definierter Schnittstelle ist übersichtlicher und leichter zu testen.
Wie und wann welche Includes in das Coding eingebaut werden, entscheidet die FB-Oberfläche oder die Klassen-Oberfläche. (Ist mir grade egal!)
Ich denke. gerade in der Bildschirmsteuerung kann ein bisschen Objektorientierung nicht schaden.
Gruß
babap
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Ok, so allgemein wie es nur irgend geht: Er war u. a. an der Entwicklung der Entwicklungswerkzeuge beteiligt, mit denen wir alle arbeiten.Daniel hat geschrieben:Es macht einen Unterschied, ob ich jemanden kenne, der schon mal für die SAP gearbeitet hat (das sind ca. 100.000 Menschen) oder ob ich jemanden kenne der über ene aussergewöhnliche Qualifikation verfügt.Ich kenne die Details ...
Letzteres kann man auch mit begründen ohne persönliche Dinge zu veröffentlichen
Jo, das machst du mit kleineren Programmen. Aber ich sehe, wir reden hier von verschiedenen Welten. Beispiel das ich genau jetzt am Wickel habe: Modulpool mit 55 Includes (und zwar nicht mit nur einer FORM drin), an dem sechs Entwickler in einem Projekt Erweiterungen programmieren.Ich lade den produktiven Stand ins Entwicklungs-System, berichtige den Fehler und stelle die korrigierte Fassung produktiv. Danach lade ich den aktuellen Entwicklungszustand zurück. Das kostet mich keine 5 Minuten weil ich entsprechende Werkzeuge habe.
Da machst du genau gar nichts "mal eben". Richtig schwierig wird es, wenn die Maschine in Bangkok steht, und ein verteiltes Entwickler- und Beraterteam auf dem System arbeitet (und ich spreche hier von WELTWEIT).
Das ist für mich ein völlig normales Projekt, wenngleich die Verteilung der Personen extrem ist. Wir leben in Zeiten, wo Maschinen stehen, wo es am billigsten ist und viele sich schlichtweg nicht die Zeit nehmen, durch die Weltgeschichte zu reisen.
Na, das sehe ich aber etwas anders. Wie rufst du noch gleich einen Modulpool per definierter Schnittstelle auf?Das sieht nur so aus, ist aber tatsächlich das selbe.
Und steht einem noch öfter im Wege.Da bin ich nicht mal so sicher. Im Grunde basiert das alles noch auf den Ursprüngen des R/2 und hat sich vielfach bewährt.
Sicher würde man einige Details anders implementieren, aber noch niemand hat bisher ein besseres Konzept präsentieren können.
WENN du schon von mehreren Leuten in einem Posting zitierst, schreibe bitte die Namen dazu - das kam nicht von mir!Da hat offensichtlich jemand das Prinzip der dynamischen Programmierung noch nicht verstanden. Modulpool unterscheiden sich von prozeduralen (normalen) Programmen durch das Fehlen der Ablauflogik - und das ist ein erheblicher Unterschied!
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Dann sollte er es aber besser wissen!ralf.wenzel hat geschrieben: Ok, so allgemein wie es nur irgend geht: Er war u. a. an der Entwicklung der Entwicklungswerkzeuge beteiligt, mit denen wir alle arbeiten.
Das mache ich auch mit 500 Programmen + 2000 Includes. Und sämtliche Dynpros und alles was sonst noch dazugehört. Einzige Grenze ist der Speicherverbrauch - der darf 2GB pro Transport nicht überschreiten.ralf.wenzel hat geschrieben: Jo, das machst du mit kleineren Programmen. Aber ich sehe, wir reden hier von verschiedenen Welten. Beispiel das ich genau jetzt am Wickel habe: Modulpool mit 55 Includes (und zwar nicht mit nur einer FORM drin), an dem sechs Entwickler in einem Projekt Erweiterungen programmieren.
Da machst du genau gar nichts "mal eben". Richtig schwierig wird es, wenn die Maschine in Bangkok steht, und ein verteiltes Entwickler- und Beraterteam auf dem System arbeitet (und ich spreche hier von WELTWEIT).
Erst vorgestern habe ich 35.000 Domänen "mal eben" in ein anderes System transportiert. (ok, hat fast 25 Minuten gedauert)
Wo das System steht spielt dabei keine Rolle. Und jedes Release ab 4.0A bis 7.00 wird bedient. Incl. Unicode zu ASCIIi und umgekehrt.
für mich auch.ralf.wenzel hat geschrieben: Das ist für mich ein völlig normales Projekt, ...
Daniell hat geschrieben: Das sieht nur so aus, ist aber tatsächlich das selbe.
Gar nicht, weil MP's kann man genausowenig rufen wie FL's.ralf.wenzel hat geschrieben: Na, das sehe ich aber etwas anders. Wie rufst du noch gleich einen Modulpool per definierter Schnittstelle auf?
Betrachte das ganze nicht so sehr von der Syntax des Aufrufes her.
Der FB wurde schon im R/2 in die Sprache integriert. Wenn du den PG38 kennst, weist du auch, daß die selbe Routine für CALL FUNCTION und PERFORM FORM IN PROG gerufen wird. Das schlägt sich auch in der Tabelle RSYN nieder, in welcher die Vorschriften für die Compilierung abgelegt sind.
Das Kernel des R/3 kenne ich zwar nicht im Source, aber die Aufrufe in der RSYN sind gleich - daher passiert zwangsläufig auch das gleiche.
Beim Aufruf eines FB's werden "nur" ein paar zusätzliche Prüfungen vorgenommen, technisch ist das absolut identisch.
Identisch ist auch die Verwaltung des Speichers in globalen und lokalen Variablen. Hierbei sind die Parameter der Funktion nichts anderes als lokale Variablen.
Was genau steht dir im Weg ?ralf.wenzel hat geschrieben:Und steht einem noch öfter im Wege.
Ich gelobe Besserungralf.wenzel hat geschrieben:WENN du schon von mehreren Leuten in einem Posting zitierst, schreibe bitte die Namen dazu - das kam nicht von mir!
Daniel
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Ich habe mal meine Kontakte zur SAP spielen lassen. Über ein paar Ecken wurde ich an Thomas Jung weitergegeben, der mir sinngemäß und frei übersetzt schrieb:
Ist beides veraltet, Webdynpro ist die zeitgemäße Technik
Ralf *so kann man das auch sehen.....
Ist beides veraltet, Webdynpro ist die zeitgemäße Technik
Ralf *so kann man das auch sehen.....
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hallo Jungs,
erst einmal danke für die spannende Diskussion. Habe diesen interssanten Threat durchgelesen und werden nun einige Punkte bei den nächsten Entwicklungen hinerleuchten.
An so riesigen Projekten wie ihr arbeite ich zwar nicht, dennoch wollte ich auch mal meinen Senf dazu geben.
Zu eurer Geschichte mit dem Sperren der Objekte bzw. dem Reparaturtransport
Situation: Ihr arbeitet also in großen Projekten - unter anderem auch in welchen mit 500 Programmen und 2000 Includes. Nun tritt ein Fehler in der Produktivumgebung auf.
Problem: Ihr seid noch in der Realisierungsphase und habt noch keine Transporte freigeben. Demnach habt ihr auch noch keine Versionen erzeugt. Lieder habt ihr im entsprechenden Include leider schon an einigen Stellen etwas geändert. Da ihr zwar sauber programmiert und kommentiert, sind die Änderungsstellen leicht zu finden. Aber es ist schon eine ordentliche Arbeit, alle Stellen zurückzudrehen. Ein großes Problem ist es dann auch, wenn ihr Codezeilen gelöscht habt, weil ihr sie für überflüssig gehalten habt oder wenn ihr Variablen umtypisiert habt o.ä..
Frage: Wie geht ihr in solch einer Situation vor? Habt ihr irgendwelche Vorkehrungen dafür, dass solch eine Situation nicht eintritt?
Zur Modulpool-Funktionsgruppen-Thematik
Ich habe bisher selbst noch keine Funktionsgruppe geschrieben, die einen Modulpool ersetzt. Ich komme aber auch selten in diese Situation. Bei der nächsten Gelegenheit wollte ich aber die Funktionsgruppe nutzen. Ein schlagendes Argument dafür kann ich nicht geben, aber da ich es bei den SAP-Programmen immer häufiger so sehe, wollte ich mich daran orientieren.
Zu Änderungen mehrerer Entwickler und den vielen Includes
Die Idee, pro Form-Routine ein Include zu nutzen, sehe ich auch zwiegespalten. Auf der einen Seite ordentlich, auf der anderen Seite unnötig.
Den Vorschlag, beim Einfügen eines neuen Includes sofort einen Transport mit dem Rahmenprogramm und dem leeren Include nach Produktion zu bringen, finde ich gut, jedoch denke ich, dass er nicht praktikabel ist, da zu viel manuelle Tätigkeiten nötig sind. Wenn das automatisch ginge, wäre es natürlich schön.
Wie sieht es denn hier mit Enhancement-Spots aus? Ich habe in kundeneigenen Programmen damit zwar keine Erfahrung, aber sie könnten doch auch funktionieren. Beim Anlegen eines neuen Programmes könnte ich doch sofort ein Dutzend Enhancement-Spots einfügen, die alle auf inaktiv stehen. Zwar habe ich somit die Includes nicht ersetzt, könnte aber während einer Weiterentwicklung die gesperrten Objekte transportieren ohne dass das Enhancement aktiviert ist.
Ich wollte hier mal die Thematik der Enhancements anregen. Bringen diese überhaupt etwas in kundeneigenen Entwicklungen?
Gruß Andy
erst einmal danke für die spannende Diskussion. Habe diesen interssanten Threat durchgelesen und werden nun einige Punkte bei den nächsten Entwicklungen hinerleuchten.
An so riesigen Projekten wie ihr arbeite ich zwar nicht, dennoch wollte ich auch mal meinen Senf dazu geben.
Zu eurer Geschichte mit dem Sperren der Objekte bzw. dem Reparaturtransport
Situation: Ihr arbeitet also in großen Projekten - unter anderem auch in welchen mit 500 Programmen und 2000 Includes. Nun tritt ein Fehler in der Produktivumgebung auf.
Problem: Ihr seid noch in der Realisierungsphase und habt noch keine Transporte freigeben. Demnach habt ihr auch noch keine Versionen erzeugt. Lieder habt ihr im entsprechenden Include leider schon an einigen Stellen etwas geändert. Da ihr zwar sauber programmiert und kommentiert, sind die Änderungsstellen leicht zu finden. Aber es ist schon eine ordentliche Arbeit, alle Stellen zurückzudrehen. Ein großes Problem ist es dann auch, wenn ihr Codezeilen gelöscht habt, weil ihr sie für überflüssig gehalten habt oder wenn ihr Variablen umtypisiert habt o.ä..
Frage: Wie geht ihr in solch einer Situation vor? Habt ihr irgendwelche Vorkehrungen dafür, dass solch eine Situation nicht eintritt?
Zur Modulpool-Funktionsgruppen-Thematik
Ich habe bisher selbst noch keine Funktionsgruppe geschrieben, die einen Modulpool ersetzt. Ich komme aber auch selten in diese Situation. Bei der nächsten Gelegenheit wollte ich aber die Funktionsgruppe nutzen. Ein schlagendes Argument dafür kann ich nicht geben, aber da ich es bei den SAP-Programmen immer häufiger so sehe, wollte ich mich daran orientieren.
Zu Änderungen mehrerer Entwickler und den vielen Includes
Die Idee, pro Form-Routine ein Include zu nutzen, sehe ich auch zwiegespalten. Auf der einen Seite ordentlich, auf der anderen Seite unnötig.
Den Vorschlag, beim Einfügen eines neuen Includes sofort einen Transport mit dem Rahmenprogramm und dem leeren Include nach Produktion zu bringen, finde ich gut, jedoch denke ich, dass er nicht praktikabel ist, da zu viel manuelle Tätigkeiten nötig sind. Wenn das automatisch ginge, wäre es natürlich schön.
Wie sieht es denn hier mit Enhancement-Spots aus? Ich habe in kundeneigenen Programmen damit zwar keine Erfahrung, aber sie könnten doch auch funktionieren. Beim Anlegen eines neuen Programmes könnte ich doch sofort ein Dutzend Enhancement-Spots einfügen, die alle auf inaktiv stehen. Zwar habe ich somit die Includes nicht ersetzt, könnte aber während einer Weiterentwicklung die gesperrten Objekte transportieren ohne dass das Enhancement aktiviert ist.
Ich wollte hier mal die Thematik der Enhancements anregen. Bringen diese überhaupt etwas in kundeneigenen Entwicklungen?
Gruß Andy
Hallo,
Jedes Jahr wechselt der Hype. Unter der Haube werkeln immer noch ein paar R/2-Programme. Und das ganze alte Zeug ernährt noch viele Jahre seinen Mann.
Gut, einen Modulpool wir man wohl nicht neu aufsetzen, aber jetzt gleich ein Webdynpro für alles und jedes aus dem Hut zaubern ...
Gruß
babap
naja, solche Aussagen erlebe ich seit über 15 Jahren alle paar Jahre.ralf.wenzel hat geschrieben:Ich habe mal meine Kontakte zur SAP spielen lassen. Über ein paar Ecken wurde ich an Thomas Jung weitergegeben, der mir sinngemäß und frei übersetzt schrieb:
Ist beides veraltet, Webdynpro ist die zeitgemäße Technik
Jedes Jahr wechselt der Hype. Unter der Haube werkeln immer noch ein paar R/2-Programme. Und das ganze alte Zeug ernährt noch viele Jahre seinen Mann.
Gut, einen Modulpool wir man wohl nicht neu aufsetzen, aber jetzt gleich ein Webdynpro für alles und jedes aus dem Hut zaubern ...
Gruß
babap
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Ich hatte vergessen, dazuzusagen, dass das ein längeres Mail ist, welches auf einen Satz zusammengefasst wurdebabap hat geschrieben:Gut, einen Modulpool wir man wohl nicht neu aufsetzen, aber jetzt gleich ein Webdynpro für alles und jedes aus dem Hut zaubern ...
Aber im OP ging es um eine komplette Neuentwicklung. Dass man alte Sachen nicht umbaut, ist schon klar.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hallo,
ich habe nach zwei Seiten Diskussion noch immer nicht die Frage verstanden.
Fragst du nach Dynpros? Fragst du nach der Benutzung von FORM/PERFORM? Fragst du nach dem Transportsystem?.....
Das einzige was ich weiss ist, das es hier bestimmt _nicht_ um DYNAMISCHE PROGRAMMIERUNG geht!
Ach ja, so ziemlich alles im R/3 ist alter Schrott. Für mich war der erste Kontakt vor drei/vier Jahren der absolute Schock. Natürlich ist R/3 oder ERP ein super Produkt aber man darf einfach nicht hinter die Kulissen schauen...
ich habe nach zwei Seiten Diskussion noch immer nicht die Frage verstanden.
Fragst du nach Dynpros? Fragst du nach der Benutzung von FORM/PERFORM? Fragst du nach dem Transportsystem?.....
Das einzige was ich weiss ist, das es hier bestimmt _nicht_ um DYNAMISCHE PROGRAMMIERUNG geht!
Ach ja, so ziemlich alles im R/3 ist alter Schrott. Für mich war der erste Kontakt vor drei/vier Jahren der absolute Schock. Natürlich ist R/3 oder ERP ein super Produkt aber man darf einfach nicht hinter die Kulissen schauen...
@uh
Sorry. aber solche Parolen kann nur jemand abgeben, der vom R/3 aber auch
wirklich gar nichts verstanden hat.
@airwaver
Nein, so gross (500/200) sind die Projekte nicht. Ich habe nur geschrieben, daß ich auch für diese Anzahl Programme jederzeit den produktiven Stand temporär im Entwicklungs- und Konsi-System bereitstellen kann. Das geht aber natürlich nicht mit den SAP-Mitteln, wir haben dafür eigene Werkzeuge entwickelt.
Back to Topic...
In anderen grösseren Installationen die mir persönlich bekannt sind, wird in den von die geschilderten Fällen im Produktivsystem repariert.
Wir holen den Stand kurz zurück - aber wie das mit SAP-Mitteln gehen soll ist mir schleierhaft.
Das Transportsystem ist geschaffen für die reine Softwareentwicklung, nicht für die Wartung eines produktiven Systems. Und genau da hat es auch seine Schwächen.
Enhancements sind eine sehr wertvolle Hilfe in den Standard-Programmen.
Für Kundeneigene Anwendungen sehe ich eigentlich keine Notwendigkeit.
Der springende Punkt ist doch der, daß ich Anpassungen vornehmen kann ohne den SAP-Code zu modifizieren. (Und für die SAP um Ihre Branchen-Lösungen mal konsistent zu machen).
Erst bei mandantenweiser Aktivierung sähe ich eine kleine Nische in der man diese Technik in eigenen Programmen nutzen kann. Das scheint aber nicht geplant zu sein, denn die Schalter werden zur Kompilierungszeit ausgewertet und der Mandant ist erst zur Laufzeit bekannt.
@babap
Gruss
Daniel
Warum spielst du dann nicht ein bischen mit Lego, das ist ischön bunt.Ach ja, so ziemlich alles im R/3 ist alter Schrott
Sorry. aber solche Parolen kann nur jemand abgeben, der vom R/3 aber auch
wirklich gar nichts verstanden hat.
@airwaver
Nein, so gross (500/200) sind die Projekte nicht. Ich habe nur geschrieben, daß ich auch für diese Anzahl Programme jederzeit den produktiven Stand temporär im Entwicklungs- und Konsi-System bereitstellen kann. Das geht aber natürlich nicht mit den SAP-Mitteln, wir haben dafür eigene Werkzeuge entwickelt.
Back to Topic...
Die Situation ist in der Realität wohl selten, denn oft sind Teile der Entwicklung bereits auf dem Konsi-System. Daher rührt ja auch die Inflation der Aufträge und das Problem der Reihenfolge beim Import in der Produktion.noch in der Realisierungsphase und habt noch keine Transporte freigeben
In anderen grösseren Installationen die mir persönlich bekannt sind, wird in den von die geschilderten Fällen im Produktivsystem repariert.
Wir holen den Stand kurz zurück - aber wie das mit SAP-Mitteln gehen soll ist mir schleierhaft.
Das Transportsystem ist geschaffen für die reine Softwareentwicklung, nicht für die Wartung eines produktiven Systems. Und genau da hat es auch seine Schwächen.
Genau das birgt die Gefahr, daß man einzelne Teile einer Entwicklung in die Produktion bringt, möglicherweise in der falschen Reihenfolge. Dann ist aber Holland in Not. Wir geben eine Entwicklung immer nur in einem einzigen Auftrag frei.beim Einfügen eines neuen Includes sofort einen Transport
Enhancements sind eine sehr wertvolle Hilfe in den Standard-Programmen.
Für Kundeneigene Anwendungen sehe ich eigentlich keine Notwendigkeit.
Der springende Punkt ist doch der, daß ich Anpassungen vornehmen kann ohne den SAP-Code zu modifizieren. (Und für die SAP um Ihre Branchen-Lösungen mal konsistent zu machen).
Erst bei mandantenweiser Aktivierung sähe ich eine kleine Nische in der man diese Technik in eigenen Programmen nutzen kann. Das scheint aber nicht geplant zu sein, denn die Schalter werden zur Kompilierungszeit ausgewertet und der Mandant ist erst zur Laufzeit bekannt.
@babap
Das unterschreibe ich mal so ...naja, solche Aussagen erlebe ich seit über 15 Jahren alle paar Jahre.
Jedes Jahr wechselt der Hype.
Gruss
Daniel
Kurz OT:Daniel hat geschrieben:@uhWarum spielst du dann nicht ein bischen mit Lego, das ist ischön bunt.Ach ja, so ziemlich alles im R/3 ist alter Schrott
Sorry. aber solche Parolen kann nur jemand abgeben, der vom R/3 aber auch
wirklich gar nichts verstanden hat.
Ich sehe keinen Grund persönlich oder beleidigend zu werden! Fühlst du dich angegriffen, weil du von Dingen schreibst (dynamische Programmierung) von denen du offensichtlich keine Ahnung hast? Hier ein Link:
http://de.wikipedia.org/wiki/Dynamische_Programmierung
Und meine Äußerung bezog sich auf die Softwaretechnik. Von der schreibst du doch selbst, dass sie noch aus R/2 Zeiten stammt.
Ich weiß nicht, in welchen System bzw. Frameworks du sonst noch deine Brötchen verdienst aber ich habe da schon deutlich modernere Systeme kennen gelernt. Ob besser kann und will ich hier nicht beurteilen aber das war auch nicht die Frage bzw. meine Aussage.
Hallo,
Brrrrr, nicht, daß die Pferde durchgehen.
Ich verdiene im SAP-Bereich meine Brötchen, viele andere hier auch.
Richtig gut ist man erst, wenn man nicht betriebsblind geworden ist, sondern alte und neue Technologie adäquat verwenden kann.
Wer nur auf die neuesten SAP-Hypes setzt, ist genauso out, wie derjenige, der nur bei der Listenprogrammierung stehengeblieben ist.
Aus meiner Sicht ist die gesamte SAP-Software das größte "Open-Source-Projekt" der Welt. Jeder kann reinsehen und für sich selbst entscheiden, ob er das so nachmacht (kopiert, abkupfert) oder besser macht.
Bei SAP war es vor jahren noch möglich, daß jemand, der eine gute Idee gleich so verwirklichte, daß man sie verkaufen konnte, sehr viel Erfolg hatte. Dabei zählte nicht die Eleganz hinter den Kulissen, auch nicht unbedingt die Eleganz der Maske oder Menüführung, sondern einzig und allein, daß es funktionierte und mit anderen, vorher bestehenden Sachen zusammenarbeitete.
Das SAP-Gui ist auch "heimlich" entwickelt worden, der ALV war erstmal bloß Privatvergnügen. Funktionsbausteine sind erweiterte FORMS, Abap-OO sind aufgepeppte Funktionsbausteine etc. Der Debugger ist auch eine Privatidee und so weiter und so fort.
Beim weiteren Fortschritt hat sich SAP darauf konzentriert, lieber neue Funktionen zu integrieren, statt an den alten herumzudoktern. Bis auf die alljährlich neuen Begrifflichkeiten und neuen Etiketten für alten Wein, hat sich diese Strategie bewährt.
Ich hoffe, das geht noch ein paar Jahre so, dann habe ich ordentlich was zu tun. Ich muß mich bloß regelmäßig im System umsehen, was es neues gibt, das Alte bleibt zum Glülck das Alte!!!
Gruß
babap
Brrrrr, nicht, daß die Pferde durchgehen.
Ich verdiene im SAP-Bereich meine Brötchen, viele andere hier auch.
Richtig gut ist man erst, wenn man nicht betriebsblind geworden ist, sondern alte und neue Technologie adäquat verwenden kann.
Wer nur auf die neuesten SAP-Hypes setzt, ist genauso out, wie derjenige, der nur bei der Listenprogrammierung stehengeblieben ist.
Aus meiner Sicht ist die gesamte SAP-Software das größte "Open-Source-Projekt" der Welt. Jeder kann reinsehen und für sich selbst entscheiden, ob er das so nachmacht (kopiert, abkupfert) oder besser macht.
Bei SAP war es vor jahren noch möglich, daß jemand, der eine gute Idee gleich so verwirklichte, daß man sie verkaufen konnte, sehr viel Erfolg hatte. Dabei zählte nicht die Eleganz hinter den Kulissen, auch nicht unbedingt die Eleganz der Maske oder Menüführung, sondern einzig und allein, daß es funktionierte und mit anderen, vorher bestehenden Sachen zusammenarbeitete.
Das SAP-Gui ist auch "heimlich" entwickelt worden, der ALV war erstmal bloß Privatvergnügen. Funktionsbausteine sind erweiterte FORMS, Abap-OO sind aufgepeppte Funktionsbausteine etc. Der Debugger ist auch eine Privatidee und so weiter und so fort.
Beim weiteren Fortschritt hat sich SAP darauf konzentriert, lieber neue Funktionen zu integrieren, statt an den alten herumzudoktern. Bis auf die alljährlich neuen Begrifflichkeiten und neuen Etiketten für alten Wein, hat sich diese Strategie bewährt.
Ich hoffe, das geht noch ein paar Jahre so, dann habe ich ordentlich was zu tun. Ich muß mich bloß regelmäßig im System umsehen, was es neues gibt, das Alte bleibt zum Glülck das Alte!!!
Gruß
babap
uh hat geschrieben:Natürlich ist R/3 oder ERP ein super Produkt aber man darf einfach nicht hinter die Kulissen schauen...
Ich denke, das kann man auch auf ERP-Systeme anwenden, oder...?Otto von Bismarck hat geschrieben: Je weniger die Leute davon wissen, wie Würste und Gesetze gemacht werden, desto besser schlafen sie
Ob jedes ERP, kann ich nicht sagen aber den Spruch merke ich mirewx hat geschrieben:[..]Ich denke, das kann man auch auf ERP-Systeme anwenden, oder...?
Das es hoffentlich die nächsten Jahre mit SAP so weiter geht, wünsche ich mir natürlich auch. Immerhin verdiene ich im Moment damit auch meine Brötchen.
Vergleichbare Themen
2
Antw.
Antw.
832
Views
Views
BAPI_HU_PI_READ liefert veraltete Daten
von RaCDigger » 20.01.2021 10:06 • Verfasst in ABAP® für Anfänger
von RaCDigger » 20.01.2021 10:06 • Verfasst in ABAP® für Anfänger
2
Antw.
Antw.
3053
Views
Views
kommunikation zwischen java und sap - veraltete Sachen?
von Gast » 10.04.2005 19:18 • Verfasst in Java & SAP®
von Gast » 10.04.2005 19:18 • Verfasst in Java & SAP®
2
Antw.
Antw.
3032
Views
Views
SALV - get_selected_rows( ) liefert veraltete Einträge
von zeWa » 20.06.2014 13:17 • Verfasst in ABAP® Core
von zeWa » 20.06.2014 13:17 • Verfasst in ABAP® Core
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.