Strukturerweiterung - kritisch für bestehende Programme, Schnittstellen, etc.??
3 Beiträge
•
Seite 1 von 1
3 Beiträge
Seite 1 von 1
Ich stelle mir die Frage ob Strukturerweiterungen kritisch für bestehende Programme, Schnittstellen, etc. sind?
Ich möchte die Erweiterung COOPA003 implementieren, um den Innenauftrag um kundenspezifische Felder zu erweitern.
Dabei wird die Struktur CI_AUFK erweitert, welches ein Include der Tabelle AUFK ist und die kundeneigene Felder enthält.
Reicht es, wenn ich nun über CMOD die Erweiterung vornehme und die Struktur CI_AUFK um neue Felder erweitere? Ich habe Bedenken, dass existierende Implementierungen, die die Struktur verwenden auf die Bretter gehen. Sind meine Bedenken hier gerechtfertigt?
Ich möchte die Erweiterung COOPA003 implementieren, um den Innenauftrag um kundenspezifische Felder zu erweitern.
Dabei wird die Struktur CI_AUFK erweitert, welches ein Include der Tabelle AUFK ist und die kundeneigene Felder enthält.
Reicht es, wenn ich nun über CMOD die Erweiterung vornehme und die Struktur CI_AUFK um neue Felder erweitere? Ich habe Bedenken, dass existierende Implementierungen, die die Struktur verwenden auf die Bretter gehen. Sind meine Bedenken hier gerechtfertigt?
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Grundsätzlich sind ja die CI-Strukturen dafür da, um Tabellen erweitern zu können. Wir nutzen dies z.B. bei der Tabelle DPSOB. Wenn überall sauber programmiert ist, brauchst du hier keine großen Bedenken zu haben. Im Innenauftrag stecke ich jetzt nicht soweit drin. Die DPSOB jedenfalls wird u.a. über BAPI's bedient. Die BAPI's haben eine EXTENSIONIN und EXTENSIONOUT. Wenn man bei dem EXTENSIONIN z.B. die CI-Felder leer mitgibt, weil sie vorher nicht sauber von der DB gelesen hat, werden diese auf der DB gelöscht - logisch.
Auch könnte es sein, dass vielleicht Einzelfelder beim Speichern gemappt werden und dann die CI-Felder vergessen wurden. Die SAP sollte dies aber richtig gemacht haben - z.B. mit MOVE-CORRESPONDING. Bleibt also ggf. noch kundeneigener Code.
Das meine ich mit unsauber programmiert.
Edit: Ich habe noch einmal bei uns im System geschaut, da ist die AUFK auch erweitert. Die CI-Felder werden im Standard in generierten Code (z.B. GBTE1COJ) verwendet. D.h., wenn du da was erweiterst, sollte auch die SAP den Code neu generieren. Darum dauert das Aktivieren hier immer etwas länger.
Auch könnte es sein, dass vielleicht Einzelfelder beim Speichern gemappt werden und dann die CI-Felder vergessen wurden. Die SAP sollte dies aber richtig gemacht haben - z.B. mit MOVE-CORRESPONDING. Bleibt also ggf. noch kundeneigener Code.
Das meine ich mit unsauber programmiert.
Edit: Ich habe noch einmal bei uns im System geschaut, da ist die AUFK auch erweitert. Die CI-Felder werden im Standard in generierten Code (z.B. GBTE1COJ) verwendet. D.h., wenn du da was erweiterst, sollte auch die SAP den Code neu generieren. Darum dauert das Aktivieren hier immer etwas länger.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Nachsatz:
Vorsicht ist bei nicht-zeichenartigen Datentypen (I, F, P usw.) oder Datentypen mit variabler Länge (String) gegeben. Das macht nämlich den Unterschied zwischen einer "flachen" und "tiefen" Struktur aus.
Wenn die erweiterte Struktur irgendwo in Standardprogrammen z.B. als TABLES verwendet wird, hat man dann völlig unbedarft einen Syntaxfehler am Hals. Dasselbe gilt übrigens auch für TABLES in Funktionsbausteinen.
Normalerweise sollte darüber ja die "Erweiterungskategorie" Aufschluss geben. Nur ist die, meiner Erfahrung nach, nicht immer sauber gepflegt.
Vorsicht ist bei nicht-zeichenartigen Datentypen (I, F, P usw.) oder Datentypen mit variabler Länge (String) gegeben. Das macht nämlich den Unterschied zwischen einer "flachen" und "tiefen" Struktur aus.
Wenn die erweiterte Struktur irgendwo in Standardprogrammen z.B. als TABLES verwendet wird, hat man dann völlig unbedarft einen Syntaxfehler am Hals. Dasselbe gilt übrigens auch für TABLES in Funktionsbausteinen.
Normalerweise sollte darüber ja die "Erweiterungskategorie" Aufschluss geben. Nur ist die, meiner Erfahrung nach, nicht immer sauber gepflegt.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
ST22
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Seite 1 von 1
Vergleichbare Themen
4
Antw.
Antw.
4976
Views
Views
0
Antw.
Antw.
2751
Views
Views
Schnittstellen Dokumentationstool (PI / ALE)
von MilkShake » 30.01.2014 14:50 • Verfasst in Exchange Infrastructure
von MilkShake » 30.01.2014 14:50 • Verfasst in Exchange Infrastructure
4
Antw.
Antw.
2906
Views
Views
3
Antw.
Antw.
2350
Views
Views
ALV - neue Einträge hinzufügen, bestehende ändern
von LosPablos » 10.08.2005 17:04 • Verfasst in ABAP® Core
von LosPablos » 10.08.2005 17:04 • 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.