ABAP Memory ID
10 Beiträge
•
Seite 1 von 1
10 Beiträge
Seite 1 von 1
Hallo,
letzter Zeit verwende ich oft EXPORT/IMPORTY MEMORY ID zwischen BADIs oder andere Erweiterungsmöglichkeiten.. Funktioniert auch gut.
Nun frage ich mich, ob etwas dagegen spricht?
Gibt es andere/bessere Möglichkeiten?
Ich möchte die Meinungen von erfahrenen Entwicklern, damit ich daraus was lernen kann :)
Danke
PS:
Mitkommentieren bei EXPORT/IMPORT ist für mich Pflicht!
letzter Zeit verwende ich oft EXPORT/IMPORTY MEMORY ID zwischen BADIs oder andere Erweiterungsmöglichkeiten.. Funktioniert auch gut.
Nun frage ich mich, ob etwas dagegen spricht?
Gibt es andere/bessere Möglichkeiten?
Ich möchte die Meinungen von erfahrenen Entwicklern, damit ich daraus was lernen kann :)
Danke
PS:
Mitkommentieren bei EXPORT/IMPORT ist für mich Pflicht!
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4396 / 223 /
1182
)
»
Ich persönlich finde, dass EXPORT/IMPORT tunlichst vermieden werden sollte.
1) Man findest die einzelnen Stellen, wo darauf zugegriffen wird, nicht per Verwendungsnachweis sondern nur mit einem teuren Codescan.
2) Die Verwendung zeugt von einem schlechtem Programmierstiel und dass man sich kein Gedanken darüber gemacht hat, wie man Daten zwischen Programmeinheiten austauschen können soll (sowohl auf Seiten von SAP als auch auf Seiten desjenigen der es einsetzt)
3) Man kann den Zugriff darauf nicht unterbinden oder irgendwie beschränken (ala PRIVATE/PROTECTED/PUBLIC) was auch ein großes Sicherheitsrisiko birgt.
4) Kommt es zwischen EXPORT und IMPORT zu einem Reload der Programmeinheiten (z.B. wegen Transport) können die gespeicherten Daten womöglich nicht mehr gelesen werden und sind somit verloren.
Alternative:
Wenn man sich im selben Programmstack bewegt, ist der Datenaustausch auch über statische Klassenattribute möglich. Hier kann man dank PRIVATE und eingener PUBLIC GET- und SET-Methoden die Daten vor "unberechtigten" Zugriffen effektiver schützen sowie gegebenenfalls auch protokollieren.
Selbst wenn ich über den Programmstack hinweg Daten austauschen muss, verwende ich dieselbe Vorgehensweise auch wenn ich die Daten dann trotzdem ins Memory stellen muss. Sie sind zwar dann nicht mehr so gut geschützt, aber zumindest habe ich mit den GET- und SET-Methoden einen Anhaltspunkt für den Verwendungsnachweis.
1) Man findest die einzelnen Stellen, wo darauf zugegriffen wird, nicht per Verwendungsnachweis sondern nur mit einem teuren Codescan.
2) Die Verwendung zeugt von einem schlechtem Programmierstiel und dass man sich kein Gedanken darüber gemacht hat, wie man Daten zwischen Programmeinheiten austauschen können soll (sowohl auf Seiten von SAP als auch auf Seiten desjenigen der es einsetzt)
3) Man kann den Zugriff darauf nicht unterbinden oder irgendwie beschränken (ala PRIVATE/PROTECTED/PUBLIC) was auch ein großes Sicherheitsrisiko birgt.
4) Kommt es zwischen EXPORT und IMPORT zu einem Reload der Programmeinheiten (z.B. wegen Transport) können die gespeicherten Daten womöglich nicht mehr gelesen werden und sind somit verloren.
Alternative:
Wenn man sich im selben Programmstack bewegt, ist der Datenaustausch auch über statische Klassenattribute möglich. Hier kann man dank PRIVATE und eingener PUBLIC GET- und SET-Methoden die Daten vor "unberechtigten" Zugriffen effektiver schützen sowie gegebenenfalls auch protokollieren.
Selbst wenn ich über den Programmstack hinweg Daten austauschen muss, verwende ich dieselbe Vorgehensweise auch wenn ich die Daten dann trotzdem ins Memory stellen muss. Sie sind zwar dann nicht mehr so gut geschützt, aber zumindest habe ich mit den GET- und SET-Methoden einen Anhaltspunkt für den Verwendungsnachweis.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
Haubi
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 sap_enthusiast (ForumUser / 95 / 25 /
23
)
»
Hallo a-dead-trousers,a-dead-trousers hat geschrieben: ↑23.06.2022 07:35Alternative:
Wenn man sich im selben Programmstack bewegt, ist der Datenaustausch auch über statische Klassenattribute möglich. Hier kann man dank PRIVATE und eingener PUBLIC GET- und SET-Methoden die Daten vor "unberechtigten" Zugriffen effektiver schützen sowie gegebenenfalls auch protokollieren.
Selbst wenn ich über den Programmstack hinweg Daten austauschen muss, verwende ich dieselbe Vorgehensweise auch wenn ich die Daten dann trotzdem ins Memory stellen muss. Sie sind zwar dann nicht mehr so gut geschützt, aber zumindest habe ich mit den GET- und SET-Methoden einen Anhaltspunkt für den Verwendungsnachweis.
ich wäre gespannt, wie du so was in der Praxis gelöst hast.
Wenn möglich, könntest einen Code-Teil als Beispiel hier veröffentlichen?
Danke!
sap_enthusiast
Beitrag
von a-dead-trousers (Top Expert / 4396 / 223 /
1182
)
»
Code: Alles auswählen.
CLASS zcl_global_customer DEFINITION
PUBLIC
CREATE PUBLIC .
PUBLIC SECTION.
CLASS-METHODS set_customer
IMPORTING
!is_customer TYPE kna1 OPTIONAL.
CLASS-METHODS get_customer
RETURNING VALUE(rs_customer) TYPE kna1.
CLASS-METHODS set_customer_memory
IMPORTING
!is_customer TYPE kna1 OPTIONAL.
CLASS-METHODS get_customer_memory
RETURNING VALUE(rs_customer) TYPE kna1.
PRIVATE SECTION.
CONSTANTS co_customer_memory TYPE memory_id VALUE 'ZCUSTOMER'. "#EC NOTEXT
CLASS-DATA ss_customer TYPE kna1.
ENDCLASS.
CLASS zcl_global_customer IMPLEMENTATION.
METHOD set_customer.
ss_customer = is_customer.
ENDMETHOD.
METHOD get_customer.
rs_customer = ss_customer.
ENDMETHOD.
METHOD set_customer_memory.
IF is_customer IS INITIAL.
FREE MEMORY ID co_customer_memory.
ELSE.
TRY.
EXPORT customer FROM is_customer TO MEMORY ID co_customer_memory.
CATCH cx_root INTO DATA(lx_root).
ENDTRY.
ENDIF.
ENDMETHOD.
METHOD get_customer_memory.
TRY.
IMPORT customer TO rs_customer FROM MEMORY ID co_customer_memory.
CATCH cx_root INTO DATA(lx_root).
ENDTRY.
ENDMETHOD.
ENDCLASS.Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
sap_enthusiast
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 / 4090 / 127 /
940
)
»
Moin a-d-t,a-dead-trousers hat geschrieben: ↑23.06.2022 07:35Alternative:
Wenn man sich im selben Programmstack bewegt, ist der Datenaustausch auch über statische Klassenattribute möglich. Hier kann man dank PRIVATE und eingener PUBLIC GET- und SET-Methoden die Daten vor "unberechtigten" Zugriffen effektiver schützen sowie gegebenenfalls auch protokollieren.
Selbst wenn ich über den Programmstack hinweg Daten austauschen muss, verwende ich dieselbe Vorgehensweise auch wenn ich die Daten dann trotzdem ins Memory stellen muss. Sie sind zwar dann nicht mehr so gut geschützt, aber zumindest habe ich mit den GET- und SET-Methoden einen Anhaltspunkt für den Verwendungsnachweis.
ich frage mich die ganze Zeit wogegen du denn Daten bei "EXPORT/IMPORT TO MEMORY" schützt. Und was genau bei deinem Ansatz denn "Angriffe" aushebelt.
Hast du dafür auch ein Prosa-Beispiel?
Beitrag
von a-dead-trousers (Top Expert / 4396 / 223 /
1182
)
»
Dass mein Ansatz "Angriffe" aushebelt, hab ich ja nicht behauptet 😉black_adept hat geschrieben: ↑23.06.2022 20:47Moin a-d-t,
ich frage mich die ganze Zeit wogegen du denn Daten bei "EXPORT/IMPORT TO MEMORY" schützt. Und was genau bei deinem Ansatz denn "Angriffe" aushebelt.
Hast du dafür auch ein Prosa-Beispiel?
Nur, dass man damit die SETTER und GETTER dank Verwendungsnachweis leichter finden kann.
Ich bezog mich auch nicht auf "Angriffe" im allgemeinen Sinn, sondern mehr auf "unerlaubtes" (oder unbekanntes) Ändern in "großen" Programmen bzw. Transaktionen. ("Wo ist das verdammte EXPORT, dass mir diesen Mist ins Memory reingekübelt hat? Argh!")
Wenn man Daten nur innerhalb des selben Programmstacks austauschen muss, dann sollten statische Attribute das Mittel der Wahl sein. Da drauf kann man wenigstens noch mit einem Watchpoint Änderungen debuggen. Besser geht es natürlich mit einer GETTER und SETTER Methode. Sobald der Datenaustausch auch über Modi-Grenzen hinweg funktionieren soll, hat man eh keine Wahl und muss auf das MEMORY (oder andere Dinge wie die Datenbank) zurückgreifen. Dann sollte man es sich halt angewöhnen die IMPORT/EXPORT Aufrufe zu kapseln. Das zukünftige Ich wird einem dankbar sein.
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 / 4090 / 127 /
940
)
»
Full ACKa-dead-trousers hat geschrieben: ↑23.06.2022 22:15Wenn man Daten nur innerhalb des selben Programmstacks austauschen muss, dann sollten statische Attribute das Mittel der Wahl sein.
Über Modi-Grenzen geht MEMORY eben nicht. Aber über "internal sessions" des gleichen Modus, die bei CALL TRANSACTION und SUBMIT aufgemacht werden. Das ist m.E. der einzige Fall, wo ich diese Technik als das Mittel der Wahl sehen würde.a-dead-trousers hat geschrieben: ↑23.06.2022 22:15Sobald der Datenaustausch auch über Modi-Grenzen hinweg funktionieren soll, hat man eh keine Wahl und muss auf das MEMORY (oder andere Dinge wie die Datenbank) zurückgreifen.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
a-dead-trousers
Beitrag
von a-dead-trousers (Top Expert / 4396 / 223 /
1182
)
»
Ok, ich hatte grad eine Diskussion mit einem Kollegen und da haben wir das dann mit den Memory Grenzen auch nochmal getestet, weil jeder von uns was anderes behauptet bzw. geglaubt hatte.black_adept hat geschrieben: ↑24.06.2022 09:01Über Modi-Grenzen geht MEMORY eben nicht. Aber über "internal sessions" des gleichen Modus, die bei CALL TRANSACTION und SUBMIT aufgemacht werden. Das ist m.E. der einzige Fall, wo ich diese Technik als das Mittel der Wahl sehen würde.
Ich könnte aber trotzdem schwören, dass es mal wirklich so war, dass man das MEMORY setzen und danach bei einem mit CALL FUNCTION ... STARTING NEW TASK aufgerufenen Funktionsbaustein darauf zugreifen konnte. Ich weiß sogar noch die Stelle im Standardcode nur unsere Versionshistory reicht nicht mehr soweit zurück wie mein vermeintliches Gedächtnis. Na jedenfalls funktioniert das jetzt nicht mehr.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
black_adept
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
2
Antw.
Antw.
2732
Views
Views
1
Antw.
Antw.
1476
Views
Views
Problem mit Memory-Spiel ( Controls & ABAP OO )
von olli-x » 20.07.2006 17:57 • Verfasst in ABAP Objects®
von olli-x » 20.07.2006 17:57 • Verfasst in ABAP Objects®
21
Antw.
Antw.
4961
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
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.