Lookup Tabelle in Methode lesen und erweitern
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.Hallo zusammen,
ich bin relativ neu in der ABAP Welt und sitze gerade an einem kleinen Problem. Vielleicht kann mir ja jemand weiterhelfen.
Ich möchte gerne eine Lookup-Tabelle in einer Methode benutzen, die über eine Feldroutine aufgerufen wird.
Die Methode soll checken, ob das Wertepaar wert_alt und wert_neu in der Tabelle vorhanden ist.
bisher ist mein Schlachtplan folgender:
Service-Klasse für diese Tabelle anlegen mit zwei Methoden
a. GETTER: Import-Parameter (Wert alt), Returning-Parameter (Wert neu)
SELECT von Lookup-Tabelle
b. SETTER: Import-Parameter (Wert alt und neu) UPDATE auf Tabelle
Jede Anonymisierungsroutine hat folgenden Ablauf:
1. GETTER: Ist das Wertepaar schon in der Tabelle vorhanden?
a. JA Ergebnis ist Wert neu
b. NEIN Anonymisierung durchführen und neues Wertepaar mittels SETTER in Tabelle schreiben
Muss ich die Tabelle im DDIC sowohl als DB-Tabelle als auch als Typ anlegen und dann in der Methode den Tabellentyp als Parameter definieren um darauf zugreifen zu können oder was ist die schlankeste Lösung für sowas?
Ich hoffe, dass mein Text einigermaßen verständlich ist und mir jemand vielleicht etwas weiterhelfen kann.
Viele Grüße
toni
ich bin relativ neu in der ABAP Welt und sitze gerade an einem kleinen Problem. Vielleicht kann mir ja jemand weiterhelfen.
Ich möchte gerne eine Lookup-Tabelle in einer Methode benutzen, die über eine Feldroutine aufgerufen wird.
Die Methode soll checken, ob das Wertepaar wert_alt und wert_neu in der Tabelle vorhanden ist.
bisher ist mein Schlachtplan folgender:
Service-Klasse für diese Tabelle anlegen mit zwei Methoden
a. GETTER: Import-Parameter (Wert alt), Returning-Parameter (Wert neu)
SELECT von Lookup-Tabelle
b. SETTER: Import-Parameter (Wert alt und neu) UPDATE auf Tabelle
Jede Anonymisierungsroutine hat folgenden Ablauf:
1. GETTER: Ist das Wertepaar schon in der Tabelle vorhanden?
a. JA Ergebnis ist Wert neu
b. NEIN Anonymisierung durchführen und neues Wertepaar mittels SETTER in Tabelle schreiben
Muss ich die Tabelle im DDIC sowohl als DB-Tabelle als auch als Typ anlegen und dann in der Methode den Tabellentyp als Parameter definieren um darauf zugreifen zu können oder was ist die schlankeste Lösung für sowas?
Ich hoffe, dass mein Text einigermaßen verständlich ist und mir jemand vielleicht etwas weiterhelfen kann.
Viele Grüße
toni
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Wenn Du die Datenbanktabelle anlegst, dann ist sie zugleich mit ihren Feldern als Typ vorhanden. Wenn Deine Datenbanktabelle z.B. TONI heißt, dann kannst Du ohne weitere Faxen in Deinem ABAP-Programm schreiben:
DATA tabellenzeile TYPE TONI.
Was Du mit "Anonymisierungsroutine" meinst, ist mir allerdings nicht klar.
DATA tabellenzeile TYPE TONI.
Was Du mit "Anonymisierungsroutine" meinst, ist mir allerdings nicht klar.
Danke schonmal für deine Antwort.
Also mein Plan ist folgender:
Das Geburtsdatum soll pseudonymisiert werden. Dafür hab ich schon eine Serviceklasse angelegt mit einer Methode, die über CL_ABAP_RANDOM_INT das eingehende Datum während einer Feldroutine mit einem Zufallswert überlagert. Das funktioniert auch soweit..
Um bei mehrmaliger Transformation zu verhindern, dass der Wert dann nochmal verfremdet wird, habe ich mir überlegt, eine Look-Up Tabelle anzulegen mit date_old und date_new.
Die Getter Methode nimmt date_old entgegen und schaut in der Look-up Tabelle ob es dafür schon einen neuen generierten Wert gibt:
Falls ja: gibt er den zugehörigen Wert datum_neu weiter
und falls nein: wird der Wert von date_old an die Methode übergeben, die den Wert verfremdet ( also eine Zufallszahl addiert ) und danach mittels Setter-Methode das Wertepaar date_old und date_new in die Tabelle geschrieben.
So weit, so complicated :) Momentan hänge ich noch daran einen Überblick über die geplante Ablauflogik und die Parameterisierung zu bekommen- bin noch ein ziemlicher noob.
liebe grüße und vielleicht bis später
Also mein Plan ist folgender:
Das Geburtsdatum soll pseudonymisiert werden. Dafür hab ich schon eine Serviceklasse angelegt mit einer Methode, die über CL_ABAP_RANDOM_INT das eingehende Datum während einer Feldroutine mit einem Zufallswert überlagert. Das funktioniert auch soweit..
Um bei mehrmaliger Transformation zu verhindern, dass der Wert dann nochmal verfremdet wird, habe ich mir überlegt, eine Look-Up Tabelle anzulegen mit date_old und date_new.
Die Getter Methode nimmt date_old entgegen und schaut in der Look-up Tabelle ob es dafür schon einen neuen generierten Wert gibt:
Falls ja: gibt er den zugehörigen Wert datum_neu weiter
und falls nein: wird der Wert von date_old an die Methode übergeben, die den Wert verfremdet ( also eine Zufallszahl addiert ) und danach mittels Setter-Methode das Wertepaar date_old und date_new in die Tabelle geschrieben.
So weit, so complicated :) Momentan hänge ich noch daran einen Überblick über die geplante Ablauflogik und die Parameterisierung zu bekommen- bin noch ein ziemlicher noob.
liebe grüße und vielleicht bis später
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Es wäre schön, wenn Du das tatsächliche Coding zum Besten geben könntest, das Du schon hast. Dann könnten wir Dir besser dabei helfen, die Puzzleteilchen zusammenzusetzen.
Außerdem ist die Sache mit der Pseudonymisierung mir nicht ganz klar. Willst Du gezielt Pseudonymisierung anstelle von Anonymisierung, soll heißen, willst Du die Möglichkeit schaffen, anhand Deiner Lookup-Tabelle das Originalgeburtsdatum wiederherzustellen? Dann müsstest Du aber ergänzend zu dem, was Du geschrieben hat, sicherstellen, dass die Zuordnung in der Lookup-Tabelle eineindeutig ist. Soll heißen, wenn Du den 25.02.2001 auf den 17.05.1988 pseudonymisierst, dann musst Du sicherstellen, dass Du kein anderes Geburtsdatum auch auf den 17.05.1988 pseudonymisierst. (Ergänzend solltest Du dann auch einen Sekundärindex auf Deiner Datenbanktabelle anlegen, damit die Suche in Rückrichtung effizient möglich ist.)
Wenn Dir aber auch eine Anonymisierung recht ist, dann würde ich den ganzen Aufwand mit der Lookup-Tabelle weglassen und einfach bei jeder einzelnen Person (Mitarbeiter?) ein individuell-zufälliges Geburtsdatum berechnen lassen.
Verstehe ich das richtig: Du möchtest eine komplette Datenbanktabelle anlegen und darauf bei jedem Geburtsdatum zugreifen, nur um nicht jedesmal CL_ABAP_RANDOM_INT rufen zu müssen? Datenbankzugriffe sind das Teuerste, was es in ABAP gibt. Insofern glaube ich nicht, dass die Rechnung aufgeht.Um bei mehrmaliger Transformation zu verhindern, dass der Wert dann nochmal verfremdet wird, habe ich mir überlegt, eine Look-Up Tabelle anzulegen mit date_old und date_new.
Außerdem ist die Sache mit der Pseudonymisierung mir nicht ganz klar. Willst Du gezielt Pseudonymisierung anstelle von Anonymisierung, soll heißen, willst Du die Möglichkeit schaffen, anhand Deiner Lookup-Tabelle das Originalgeburtsdatum wiederherzustellen? Dann müsstest Du aber ergänzend zu dem, was Du geschrieben hat, sicherstellen, dass die Zuordnung in der Lookup-Tabelle eineindeutig ist. Soll heißen, wenn Du den 25.02.2001 auf den 17.05.1988 pseudonymisierst, dann musst Du sicherstellen, dass Du kein anderes Geburtsdatum auch auf den 17.05.1988 pseudonymisierst. (Ergänzend solltest Du dann auch einen Sekundärindex auf Deiner Datenbanktabelle anlegen, damit die Suche in Rückrichtung effizient möglich ist.)
Wenn Dir aber auch eine Anonymisierung recht ist, dann würde ich den ganzen Aufwand mit der Lookup-Tabelle weglassen und einfach bei jeder einzelnen Person (Mitarbeiter?) ein individuell-zufälliges Geburtsdatum berechnen lassen.
Die Tabelle soll eigentlich nur dazu dienen, zu gewährleisten, dass es für jedes Geburtsdatum nur ein neues Zufallsdatum gibt, welches ihm zugeordnet ist. Also dass bei erneuter Beladung oder Transformation im weiteren Datenfluss verhindert wird, dass einem date_old ein anderes date_new zugeordnet wird, als zuvor.
Bis jetzt habe ich einen Aufrufer in die Routine eingebaut, der folgenden FuBa aufruft:
der soll den Wert an die folgende Methode weitergeben:
das löst aber momentan im debugging noch einen Dump aus, weil das Feldsymbol noch nicht zugewiesen ist...was fehlt denn?
Wie (in-)performant die ganze Geschichte ist, wage ich nicht zu beurteilen, aber das war erstmal die Aufgabe, die ich so in Angriff nehmen sollte.
vielleicht kann ja trotzdem jemand einem verzweifelten anfänger unter die Arme greifen^^
Bis jetzt habe ich einen Aufrufer in die Routine eingebaut, der folgenden FuBa aufruft:
Code: Alles auswählen.
CALL METHOD /xxx/cl_ano_service_map_date=>get_date
EXPORTING
iv_date = IV_SOURCE
RECEIVING
rv_date_new = EV_RESULT
.
der soll den Wert an die folgende Methode weitergeben:
Code: Alles auswählen.
CLASS /xxx/CL_ANO_SERVICE_MAP_DATE IMPLEMENTATION.
* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Static Public Method /xxx/CL_ANO_SERVICE_MAP_DATE=>GET_DATE
* +-------------------------------------------------------------------------------------------------+
* | [--->] IV_DATE TYPE DATS
* | [<-()] RV_DATE_NEW TYPE DATS
* +--------------------------------------------------------------------------------------</SIGNATURE>
METHOD get_date.
DATA: it_maptable TYPE SORTED TABLE OF /xxx/ano_dat_map WITH NON-UNIQUE KEY date_old.
IF it_maptable IS INITIAL.
SELECT date_old date_new
FROM /xxx/ano_dat_map
INTO TABLE it_maptable.
ENDIF.
READ TABLE it_maptable ASSIGNING FIELD-SYMBOL(<ls_map>)
WITH TABLE KEY date_old = rv_date_new.
IF sy-subrc = 0.
rv_date_new = <ls_map>-date_new.
Wie (in-)performant die ganze Geschichte ist, wage ich nicht zu beurteilen, aber das war erstmal die Aufgabe, die ich so in Angriff nehmen sollte.
vielleicht kann ja trotzdem jemand einem verzweifelten anfänger unter die Arme greifen^^
kann zum rest wenig beitragen, gerade weil ich, wie vermutlich jeder andere, sehr verwirrt über den kontext und sinn bin ..
ABER zum Feldsymbol folgendes... prüfe nicht auf sy-subrc ob es zugewiesen ist sondern "if <ls_map> is assigned." dann dürfte das problem wenigstens behoben sein.
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Nein, das wäre nur Doktern an den Symptomen. Er prüft ja auf den SUBRC, und der READ TABLE setzt den SUBRC, also sollte sein Ansatz genauso gut sein.SaskuAc hat geschrieben:ABER zum Feldsymbol folgendes... prüfe nicht auf sy-subrc ob es zugewiesen ist sondern "if <ls_map> is assigned." dann dürfte das problem wenigstens behoben sein.
Bleib entspannt; ich bin doch schon dabei.vielleicht kann ja trotzdem jemand einem verzweifelten anfänger unter die Arme greifen^^
Mir ging es bei meinen Fragen weniger um die Performance und mehr um den Sinn des Ganzen. Aber wenn es natürlich eine Übungsaufgabe ist, dann stellt sich die Frage nach dem Sinn nicht.Wie (in-)performant die ganze Geschichte ist, wage ich nicht zu beurteilen, aber das war erstmal die Aufgabe, die ich so in Angriff nehmen sollte.
Das habe ich verstanden. Und genau daraus haben sich für mich die Fragen ergeben, die ich in meiner vorigen Antwort gestellt habe. Weshalb ist es wichtig, dass es für jedes Geburtsdatum nur ein neues Zufallsdatum gibt? (Außer die Frage ist irrelevant, weil die Aufgabe halt so lautet.)Die Tabelle soll eigentlich nur dazu dienen, zu gewährleisten, dass es für jedes Geburtsdatum nur ein neues Zufallsdatum gibt, welches ihm zugeordnet ist. Also dass bei erneuter Beladung oder Transformation im weiteren Datenfluss verhindert wird, dass einem date_old ein anderes date_new zugeordnet wird, als zuvor.
Das kann eigentlich nicht sein, denn Du fragst ja den SY-SUBRC des READ TABLE ab. Allerdings hast Du da einen Syntaxfehler drin. Bei WITH TABLE KEY erwartet ABAP einen explizit benannten Schlüssel. Du gibst aber einfach nur die Schlüsselbedingung basierend auf Deinem Primärschlüssel an. Das ist zulässig, aber dann musst Du WITH KEY statt WITH TABLE KEY schreiben!das löst aber momentan im debugging noch einen Dump aus, weil das Feldsymbol noch nicht zugewiesen ist...
Im übrigen benutzt Du die ungarische Notation falsch. Ich würde Dir ja raten, ganz darauf zu verzichten (die SAP empfiehlt sie nicht mehr, siehe https://github.com/SAP/styleguides/blob ... d-prefixes ), aber wenn Du sie trotzdem noch nutzen möchtest, dann mach es richtig. Wenn ein Tabellenname mit IT anfängt, dann heißt das "Imported Table". Die Tabelle müsste also dann Bestandteil Deiner Methodenparameter sein. Da sie das nicht ist, wäre stattdessen LT ("Local Table") richtig. Wobei ich Dir, wie gesagt, empfehle, ganz von dieser antiquierten Notation Abstand zu nehmen (auch wenn sie leider nach wie vor sehr verbreitet ist und ich mir daher auch vorstellen kann, dass sie verschiedentlich noch gelehrt wird).
Ferner funktioniert Dein Codeabschnitt
Code: Alles auswählen.
IF it_maptable IS INITIAL.
SELECT date_old date_new
FROM /xxx/ano_dat_map
INTO TABLE it_maptable.
ENDIF.Was Du offensichtlich willst, ist die Werte nur beim ersten Methodenaufruf von der Datenbank einlesen und dann bei jedem weiteren Methodenaufruf Deiner internen Tabelle entnehmen, um die Performance zu verbessern. Das ist gut, aber dann musst Du STATICS anstelle von DATA schreiben. Nur dann bleiben die Werte in der Tabelle über das Ende des Methodenaufrufs hinaus erhalten.
Und schließlich hast Du mit Deinem ASSIGNING FIELD-SYMBOL geoutet, dass Du auf einem Release >= 7.40 sitzt. Dann aber solltest Du ohnehin eine modernere Syntax anstelle des weitgehend antiquierten READ TABLE einsetzen.
Warum ersetzt Du nicht den ganzen Block
Code: Alles auswählen.
READ TABLE it_maptable ASSIGNING FIELD-SYMBOL(<ls_map>)
WITH TABLE KEY date_old = rv_date_new.
IF sy-subrc = 0.
rv_date_new = <ls_map>-date_new.Code: Alles auswählen.
rv_date_new = VALUE #( it_maptable[ date_old = rv_date_new ]-date_new DEFAULT rv_date_new ).Wobei Du natürlich in dem Fall Deinen Zufallswert erzeugen möchtest. Also könntest Du z.B. schreiben:
Code: Alles auswählen.
rv_date_new = VALUE #( it_maptable[ date_old = rv_date_new ]-date_new OPTIONAL ).
IF rv_date_new IS INITIAL.
" Generate new mapping value here
ENDIF.Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
black_adept
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Jetzt antwortet er nicht mehr... *kopfschüttel*
sorry @deathandpain, ich saß mittwoch noch kopfrauchend an der Aufgabe ( leider bisher ohne Erfolg, irgendwas gefällt ihm mit dem Feldsymbol nicht ) und gestern und vorgestern stress mit Hausarbeit schreiben und Junior hüten, da ist eine Antwort leider etwas hinten runter gefallen- mea culpa..
ich danke dir natürlich sehr für die ausführlichen tipps und erläuterungen. wie gesagt, irgendetwas scheint im programmablauf noch zu fehlen oder nicht deklariert zu sein, ich setze mich montag mal mit unserer entwicklerin ran und berichte, an was es lag :)
deine anregungen habe ich auf jeden fall so eingebaut und verinnerlicht und mit der neuen notation werde ich mich mal auseinandersetzen.
also dann, nicht böse sein. ich schätze die hilfe von euch überaus.
ich wünsche schonmal ein schönes wochenende.
ich danke dir natürlich sehr für die ausführlichen tipps und erläuterungen. wie gesagt, irgendetwas scheint im programmablauf noch zu fehlen oder nicht deklariert zu sein, ich setze mich montag mal mit unserer entwicklerin ran und berichte, an was es lag :)
deine anregungen habe ich auf jeden fall so eingebaut und verinnerlicht und mit der neuen notation werde ich mich mal auseinandersetzen.
also dann, nicht böse sein. ich schätze die hilfe von euch überaus.
ich wünsche schonmal ein schönes wochenende.
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Also das einzige, was mir da einfallen würde, wäre, dass ihr doch noch kein SAP-Release >= 7.40 habt. Dann geht nämlich die ganze Syntax ASSIGNING FIELD-SYMBOL() nicht, sondern dann musst Du das Feldsymbol auf herkömmliche Weise mit dem FIELD-SYMBOLS-Befehl am Anfang des Programms deklarieren. In dem Fall würden meine übrigen Syntaxvorschläge größtenteils natürlich auch nicht funktionieren.( leider bisher ohne Erfolg, irgendwas gefällt ihm mit dem Feldsymbol nicht )
Wäre aber schade, wenn Du dadurch gezwungen werden würdest, Dir den alten Kram anzugewöhnen. Die neue Syntax ist bedeutend besser!
EDIT: Wozu brauchst Du das Feldsymbol überhaupt noch? Wenn Du tatsächlich meinen Vorschlag umsetzt, erübrigt es sich!
wir haben ein release >7.40. mittlerweile hab ich auch alle dumps beseitigt, aber komischerweise weist er den wert date_new nicht zu, obwohl es das entsprechende wertepaar in der lookup tabelle gibt...sehr komisch, aber ich komm schon noch dahinter :)
ich danke euch auf jeden fall für eure hilfe!
lg
ich danke euch auf jeden fall für eure hilfe!
lg
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Ich schätze dein Problem liegt daran, dass
zwar syntaktisch korrekt ist, aber du nicht rv_date_new als Tabellenschlüssel suchst ( weil das zu dem Zeitpunkt immer noch nicht zugewiesen ( also initial ) ist sondern iv_date
Code: Alles auswählen.
READ TABLE it_maptable ASSIGNING FIELD-SYMBOL(<ls_map>)
WITH TABLE KEY date_old = rv_date_new.
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Syntaktisch korrekt ist es nicht, da es wie oben schon erwähnt an dieser Stelle WITH KEY statt WITH TABLE KEY heißen muss. Aber das, was Du geschrieben hast, stimmt natürlich obendrein.
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Dann poste jetzt wenigstens nochmal den finalen Code, damit er noch nach Schönheitskriterien beleuchtet werden kann. 😊
Vergleichbare Themen
1
Antw.
Antw.
8637
Views
Views
Programmname einer Methode ermitteln für Lesen Source Code
von polle » 03.01.2007 10:51 • Verfasst in ABAP® Core
von polle » 03.01.2007 10:51 • Verfasst in ABAP® Core
2
Antw.
Antw.
1019
Views
Views
2
Antw.
Antw.
1927
Views
Views
7
Antw.
Antw.
1031
Views
Views
2
Antw.
Antw.
4165
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1151
vor 2 Tagen von DeathAndPain 4 / 1151
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
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1151
vor 2 Tagen von DeathAndPain 4 / 1151