Tabelle vom Typ einer lokalen Struktur an Importing Parameter meiner Methode übergeben
11 Beiträge
•
Seite 1 von 1
11 Beiträge
Seite 1 von 1
Hallo zusammen,
ich bin gerade dabei einen alten Report von mir möglichst ins objektorientierte zu überführen. In meinem alten Report lese ich eine JSON Datei ein und lege mir hierfür zunächst einen Type an (die Struktur ist tief und beinhaltet auch Tabellen, unten ist lediglich ein vereinfachtes Beispiel).
Types: begin of ts_complete_table,
wi_nummer TYPE tabelle1-wi_nummer,
wi_text TYPE tabelle1-wi_text,
ab_person TYPE tabelle2-ab_person,
cd_datum TYPE tabelle3-cd_datum,
end of ts_complete_table.
Nachdem die JSON über CALL TRANSFORMATION id SOURCE XML lv_asjson RESULT wi_nummer = lt_complete_table in eine lokale Tabelle vom Typ ts_complete_table geschrieben wurde, möchte ich die lt_complete_table an eine Mapping Methode überführen.
Nur kann ich in meiner Mapping Methode keinen Import-Parameter vom Typ meiner ts_complete_table anlegen? Wie kann ich hier Abhilfe schaffen? Muss ich tatsächlich alles in ein Dictionary Objekt überführen, sprich Tabelle mit Strukturen anlegen oder gibt es hier einen Trick, dies zu umgehen?
Vielen Dank und beste Grüße!
ich bin gerade dabei einen alten Report von mir möglichst ins objektorientierte zu überführen. In meinem alten Report lese ich eine JSON Datei ein und lege mir hierfür zunächst einen Type an (die Struktur ist tief und beinhaltet auch Tabellen, unten ist lediglich ein vereinfachtes Beispiel).
Types: begin of ts_complete_table,
wi_nummer TYPE tabelle1-wi_nummer,
wi_text TYPE tabelle1-wi_text,
ab_person TYPE tabelle2-ab_person,
cd_datum TYPE tabelle3-cd_datum,
end of ts_complete_table.
Nachdem die JSON über CALL TRANSFORMATION id SOURCE XML lv_asjson RESULT wi_nummer = lt_complete_table in eine lokale Tabelle vom Typ ts_complete_table geschrieben wurde, möchte ich die lt_complete_table an eine Mapping Methode überführen.
Nur kann ich in meiner Mapping Methode keinen Import-Parameter vom Typ meiner ts_complete_table anlegen? Wie kann ich hier Abhilfe schaffen? Muss ich tatsächlich alles in ein Dictionary Objekt überführen, sprich Tabelle mit Strukturen anlegen oder gibt es hier einen Trick, dies zu umgehen?
Vielen Dank und beste Grüße!
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Du kannst auch den Typen in einem Interface ablegen, und dann mit zif_types=>type darauf zugreifen.
Du musst den Typ im PUBLIC Bereich anlegen. Dann sollte das gehen.
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Die Lösung von Icke, dafür ein Interface zu verwenden, halte ich persönlich für besser anstatt das im Public-Bereich einer Klasse zu definieren.
1) Bei einem Zugriff darauf muss nicht die gesamte Klasse in den Speicher geladen werden.
2) Möchte man das später in einem anderen Kontext wiederverwenden, muss man nicht auf die "alte" Klasse referenzieren, die man dafür nicht verwenden möchte (oder kann).
Die beste Lösung, meines Erachtens, ist und bleibt aber, das im DDIC zu definieren. Damit ist man wirklich völlig losgelöst von jedeweder Programmlogik.
1) Bei einem Zugriff darauf muss nicht die gesamte Klasse in den Speicher geladen werden.
2) Möchte man das später in einem anderen Kontext wiederverwenden, muss man nicht auf die "alte" Klasse referenzieren, die man dafür nicht verwenden möchte (oder kann).
Die beste Lösung, meines Erachtens, ist und bleibt aber, das im DDIC zu definieren. Damit ist man wirklich völlig losgelöst von jedeweder Programmlogik.
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
a-dead-trousers hat geschrieben: ↑22.04.2022 07:31Die Lösung von Icke, dafür ein Interface zu verwenden, halte ich persönlich für besser anstatt das im Public-Bereich einer Klasse zu definieren.
Wenn ich den Typ zu der Klasse definiere, dann gehe ich davon aus, dass ich diesen Typ auch in und für die Klasse benötige. Also wird die Klasse eh immer geladen werden.a-dead-trousers hat geschrieben: ↑22.04.2022 07:311) Bei einem Zugriff darauf muss nicht die gesamte Klasse in den Speicher geladen werden.
In dem Fall ist ein Refactoring notwendig.a-dead-trousers hat geschrieben: ↑22.04.2022 07:312) Möchte man das später in einem anderen Kontext wiederverwenden, muss man nicht auf die "alte" Klasse referenzieren, die man dafür nicht verwenden möchte (oder kann).
So lange ich einen Typen nicht "außerhalb" benötige, sehe ich keinen Vorteil darin, diesen Im Dictionary zu definieren.a-dead-trousers hat geschrieben: ↑22.04.2022 07:31Die beste Lösung, meines Erachtens, ist und bleibt aber, das im DDIC zu definieren. Damit ist man wirklich völlig losgelöst von jedeweder Programmlogik.
Wobei man durchaus diskutieren kann, ob man nicht Typendefinitionen immer "unabhängig" definieren sollte/ könnte.
Beitrag
von ralf.wenzel (Top Expert / 3927 / 200 /
280
)
»
Ich habe Typen früher auch immer im DDIC angelegt und mache das inzwischen nicht mehr -- eigentlich nur noch für Felder, die auf irgendwelchen Dynpros gebraucht werden.
Ansonsten finde ich die INTF-Idee am Besten, weil man so den Typen schön von der Verwendung entkoppeln kann.
Ralf
Ansonsten finde ich die INTF-Idee am Besten, weil man so den Typen schön von der Verwendung entkoppeln kann.
Ralf
Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag:
a-dead-trousers
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Genau.
Deswegen habe ich hier auch unterstrichen, dass es sich um meine Meinung handelt und Meinungen sind immer diskutierbar. 😉
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
Beitrag
von black_adept (Top Expert / 4093 / 127 /
940
)
»
Der OP spricht von einem alten Report der aufgemotzt werden soll. Daher gehe ich davon aus, dass die Typdefinition nur in diesem Report und nicht außerhalb benötigt wird.ewx hat geschrieben: ↑22.04.2022 09:21So lange ich einen Typen nicht "außerhalb" benötige, sehe ich keinen Vorteil darin, diesen Im Dictionary zu definieren.a-dead-trousers hat geschrieben: ↑22.04.2022 07:31Die beste Lösung, meines Erachtens, ist und bleibt aber, das im DDIC zu definieren. Damit ist man wirklich völlig losgelöst von jedeweder Programmlogik.
Wobei man durchaus diskutieren kann, ob man nicht Typendefinitionen immer "unabhängig" definieren sollte/ könnte.
Daher stimme ich Ennos erstem Satz voll und ganz zu und widerspreche dem 2. entschieden wegen des "immer" - und selbst bei "meist" wäre die Meinung die Gleiche.
Ich mache das immer dann, wenn ich Zusatzinformationen benötige, die im DDIC mitgegeben werden können, die bei der Typdefinition im Programm fehlen ( Referenzinformationen für Mengen und Währungen, Fremdschlüssel, Suchhilfen ) oder wenn die Schnittstelle die Werte zwingend im DDIC benötigt ( [RFC]-FuBa ). Das sind wie - von Ralf angesprochen - meist Sachen die in Dynpros oder halt auch in ALV-Ausgabelisten auftauchenralf.wenzel hat geschrieben: ↑22.04.2022 12:11Ich habe Typen früher auch immer im DDIC angelegt und mache das inzwischen nicht mehr -- eigentlich nur noch für Felder, die auf irgendwelchen Dynpros gebraucht werden.
Beitrag
von black_adept (Top Expert / 4093 / 127 /
940
)
»
Die Verwendung via Interface hat aber auch seine Nachteile. Es ist nicht selten, dass ein Interface eine ganze Reihe von Typdefinitionen enthält. Und wenn man jetzt an einer davon eine Änderung vornimmt, werden alle Reports neu kompiliert, die auf dieses Interface oder eine Kompontente desselben referenzieren wohingegen bei Anlage via DDIC nur diejenigen Reports neu kompiliert werden, welche auf den benötigten Typ referenzieren. Desweiteren könnte man bei zentralen Interfaces Probleme mit parallelen Entwicklungen bekommen, die gleichzeitig an verschiedenen Objekten des Interfaces Änderungen machen möchten.ralf.wenzel hat geschrieben: ↑22.04.2022 12:11Ansonsten finde ich die INTF-Idee am Besten, weil man so den Typen schön von der Verwendung entkoppeln kann.
Ist wie immer ein Abwägen der Vor- und Nachteile...
Beitrag
von ralf.wenzel (Top Expert / 3927 / 200 /
280
)
»
Die ich sodann als „Paket“ mit einer einzigen Anweisung übernehmen kann, weil im Interface der logische Zusammenhang bestimmter Typen festgeschrieben ist.black_adept hat geschrieben: ↑22.04.2022 15:12Es ist nicht selten, dass ein Interface eine ganze Reihe von Typdefinitionen enthält.
Du siehst: Das muss kein Nachteil sein.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4093 / 127 /
940
)
»
Dem stimme ich ja grundsätzlich zu. Aber die Nachteile fallen einem halt eher auf, wenn sie einen stören als dass die Vorteile einem auffallen, wenn sie die Arbeit erleichtern.ralf.wenzel hat geschrieben: ↑22.04.2022 16:03Die ich sodann als „Paket“ mit einer einzigen Anweisung übernehmen kann, weil im Interface der logische Zusammenhang bestimmter Typen festgeschrieben ist.black_adept hat geschrieben: ↑22.04.2022 15:12Es ist nicht selten, dass ein Interface eine ganze Reihe von Typdefinitionen enthält.
Du siehst: Das muss kein Nachteil sein.
Ralf
Und ich hatte schon beides: DDIC-Objekte, bei denen ich mir nachträglich gewünscht hätte, sie in einem Interface gruppiert zu haben als auch in Interfaces definierte Typen, bei denen ich mir nachträglich gewünscht hätte, sie wären im DDIC angelegt worden.
Wie gesagt: Abwägen der Vor- und Nachteile. Und was ist am Ende besser? Ich denke je mehr Erfahrung man bekommt desto weniger oft wünscht man es sich nachher anders herum.
Seite 1 von 1
Vergleichbare Themen
3
Antw.
Antw.
4223
Views
Views
Weiß die Methode ob ein optionaler Parameter übergeben wurde
von OBOP » 05.04.2017 10:11 • Verfasst in ABAP Objects®
von OBOP » 05.04.2017 10:11 • Verfasst in ABAP Objects®
1
Antw.
Antw.
3993
Views
Views
interne Tabelle als Parameter zu übergeben?
von oo » 25.05.2006 10:46 • Verfasst in Web-Dynpro, BSP + BHTML
von oo » 25.05.2006 10:46 • Verfasst in Web-Dynpro, BSP + BHTML
5
Antw.
Antw.
3076
Views
Views
1
Antw.
Antw.
2020
Views
Views
9
Antw.
Antw.
19038
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 9 Stunden von ralf.wenzel 104 / 10051
vor 9 Stunden von ralf.wenzel 104 / 10051
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 9 Stunden von ralf.wenzel 104 / 10051
vor 9 Stunden von ralf.wenzel 104 / 10051