Lookup Tabelle in Methode lesen und erweitern Thema ist als GELÖST markiert

Die Objektorientierung mit ABAP®: Vererbung, Dynamische Programmierung, GUI Controls (u.a. ALV im OO).
19 Beiträge Seite 1 von 2 (current) Nächste
19 Beiträge Seite 1 von 2 (current) Nächste

Lookup Tabelle in Methode lesen und erweitern

Beitrag von toni89 (ForumUser / 12 / 0 / 0 ) » 17. Sep 2019 12:41

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


Re: Lookup Tabelle in Methode lesen und erweitern

Beitrag von DeathAndPain (Top Expert / 1135 / 128 / 242 ) » 17. Sep 2019 18:30

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.

Re: Lookup Tabelle in Methode lesen und erweitern

Beitrag von toni89 (ForumUser / 12 / 0 / 0 ) » 18. Sep 2019 09:14

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

Re: Lookup Tabelle in Methode lesen und erweitern

Beitrag von DeathAndPain (Top Expert / 1135 / 128 / 242 ) » 18. Sep 2019 12:15

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.
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.
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.

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.

Re: Lookup Tabelle in Methode lesen und erweitern

Beitrag von toni89 (ForumUser / 12 / 0 / 0 ) » 18. Sep 2019 12:53

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:

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.


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^^

Re: Lookup Tabelle in Methode lesen und erweitern

Beitrag von SaskuAc (Specialist / 286 / 29 / 36 ) » 18. Sep 2019 13:16

toni89 hat geschrieben:
18. Sep 2019 12:53
das löst aber momentan im debugging noch einen Dump aus, weil das Feldsymbol noch nicht zugewiesen ist...was fehlt denn?
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.

Re: Lookup Tabelle in Methode lesen und erweitern

Beitrag von DeathAndPain (Top Expert / 1135 / 128 / 242 ) » 18. Sep 2019 13:47

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.
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.
vielleicht kann ja trotzdem jemand einem verzweifelten anfänger unter die Arme greifen^^
Bleib entspannt; ich bin doch schon dabei.
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.
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.
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 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.)
das löst aber momentan im debugging noch einen Dump aus, weil das Feldsymbol noch nicht zugewiesen ist...
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!

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.
nicht wunschgemäß, denn it_maptable wird IMMER initial sein. Dies ist syntaktisch garantiert, da die Tabelle ja direkt vor dem IF per DATA deklariert wird, und DATA initialisiert die damit deklarierten Felder bei jedem Aufruf Deiner Methode.

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.
durch ein schlichtes

Code: Alles auswählen.

rv_date_new = VALUE #( it_maptable[ date_old = rv_date_new ]-date_new DEFAULT rv_date_new ).
Dann wird rv_date_new zum Wert aus der (löblicherweise als sortierte Tabelle definierten, aber tadelnswerterweise per NON-UNIQUE KEY definierten, obwohl Du doch gerade eine eindeutige Zuordnung bauen möchtest) internen Tabelle, sofern dieser existiert, ansonsten behält es seinen Wert (bzw. wird sich selber zugewiesen, was auf dasselbe hinausläuft).

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 (23. Sep 2019 15:16)


Re: Lookup Tabelle in Methode lesen und erweitern

Beitrag von DeathAndPain (Top Expert / 1135 / 128 / 242 ) » 20. Sep 2019 12:19

Jetzt antwortet er nicht mehr... *kopfschüttel*

Re: Lookup Tabelle in Methode lesen und erweitern

Beitrag von toni89 (ForumUser / 12 / 0 / 0 ) » 20. Sep 2019 12:51

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.

Re: Lookup Tabelle in Methode lesen und erweitern

Beitrag von DeathAndPain (Top Expert / 1135 / 128 / 242 ) » 20. Sep 2019 16:40

( leider bisher ohne Erfolg, irgendwas gefällt ihm mit dem Feldsymbol nicht )
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.

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!

Re: Lookup Tabelle in Methode lesen und erweitern

Beitrag von toni89 (ForumUser / 12 / 0 / 0 ) » 23. Sep 2019 14:46

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

Re: Lookup Tabelle in Methode lesen und erweitern

Beitrag von black_adept (Top Expert / 3304 / 58 / 601 ) » 23. Sep 2019 15:14

Ich schätze dein Problem liegt daran, dass

Code: Alles auswählen.

 READ TABLE it_maptable ASSIGNING FIELD-SYMBOL(<ls_map>)
    WITH TABLE KEY date_old = rv_date_new.
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
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Lookup Tabelle in Methode lesen und erweitern

Beitrag von DeathAndPain (Top Expert / 1135 / 128 / 242 ) » 24. Sep 2019 08:08

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.

Re: Lookup Tabelle in Methode lesen und erweitern

Beitrag von toni89 (ForumUser / 12 / 0 / 0 ) » 24. Sep 2019 12:23

jetzt läuft alles. ich danke euch für eure hilfe!

Re: Lookup Tabelle in Methode lesen und erweitern

Beitrag von DeathAndPain (Top Expert / 1135 / 128 / 242 ) » 24. Sep 2019 14:38

Dann poste jetzt wenigstens nochmal den finalen Code, damit er noch nach Schönheitskriterien beleuchtet werden kann. 😊

Seite 1 von 2 (current) Nächste

Aktuelle Forenbeiträge

Web Service Restful API
vor 11 Stunden von Tron 2 / 32
Entwurfsmuster in ABAP / OO
vor 2 Tagen von Maximus 16 / 2132
VA01, Kundenauftragserfassung Preisdatum
vor 2 Tagen von SAP_ENTWICKLER 1 / 53
Rabax Fehlermeldung
vor 2 Tagen von zzcpak 2 / 84
Aufgabe Programm/- Tabellenerstellung
vor 2 Tagen von SaskuAc 3 / 84

Unbeantwortete Forenbeiträge

VA01, Kundenauftragserfassung Preisdatum
vor 2 Tagen von SAP_ENTWICKLER 1 / 53
HANA Audit Trail
vor einer Woche von JohnLocklay 1 / 97
Halber Tag Urlaub
vor einer Woche von SO4SAP 1 / 61
Funktionsbausteine BAPI_INCOMINGINVOICE*****
vor einer Woche von Rabea1103 1 / 70
S4/HANA in der Cloud / 14 Tage Trial
vor 3 Wochen von Tron 1 / 101