Dyn. Maßnahme PSAVE nutzen
10 Beiträge
•
Seite 1 von 1
10 Beiträge
Seite 1 von 1
Hey,
Ich möchte in einer dynamischen Maßnahme eine Funktion aufrufen welche u.a. die alten Werte nutzt und prüft.
Hierzu habe ich folgendes gefunden:
Leider funktioniert der ASSIGN aber scheinbar nicht, da ich den Fehler bekomme dass das FIELD-SYMBOL noch nicht
zugeteilt wude.
Kann mir jemand weiterhelfen wie ich auf die Werte aus PSAVE zugreife und wo hier mein Fehler steckt?
Danke und Grüße
Ich möchte in einer dynamischen Maßnahme eine Funktion aufrufen welche u.a. die alten Werte nutzt und prüft.
Hierzu habe ich folgendes gefunden:
Code: Alles auswählen.
DATA: lv_var TYPE string,
lt_p2001 TYPE p2001.
lv_var = '(MP200000)PSAVE'.
ASSIGN (lv_var) TO FIELD-SYMBOL(<psave>).
CALL METHOD cl_hr_pnnnn_type_cast=>prelp_to_pnnnn
EXPORTING
prelp = <psave>
IMPORTING
pnnnn = lt_p2001
zugeteilt wude.
Kann mir jemand weiterhelfen wie ich auf die Werte aus PSAVE zugreife und wo hier mein Fehler steckt?
Danke und Grüße
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Naja, das liegt schlichtweg daran, dass du hier nichts der Feldvariable zuweißt.
Dein Assign geht ins leere, weil in der Variable lv_var kein ABAP-Objekt ( ich meine das jetzt nicht im OO-Kontext ) sitzt was hier zugewiesen werden könnte.
Könntest du bitte etwas genauer erklären, was du hier versuchst? So ist das jetzt leider ( für mich ) nicht erkenntlich.
Dein Assign geht ins leere, weil in der Variable lv_var kein ABAP-Objekt ( ich meine das jetzt nicht im OO-Kontext ) sitzt was hier zugewiesen werden könnte.
Könntest du bitte etwas genauer erklären, was du hier versuchst? So ist das jetzt leider ( für mich ) nicht erkenntlich.
Hey,
Danke für die Rückmeldung.
Hmm ...
Also Ziel ist es die PSAVE in eine Infotyptabelle umzuwandeln,
so dass ich mit dieser dann arbeiten kann.
Diese sollte ja die alten Werte des Infotyps enthalten die gerade geändert wurden.
Ich hatte schon mal an einer anderen Stelle einen String zusammengefügt und mit ASSIGN zugewiesen.
Irgendwas übersehe ich hier noch oder ist mir nicht bewusst ...
Danke und Grüße
Dominic
Danke für die Rückmeldung.
Hmm ...
Also Ziel ist es die PSAVE in eine Infotyptabelle umzuwandeln,
so dass ich mit dieser dann arbeiten kann.
Diese sollte ja die alten Werte des Infotyps enthalten die gerade geändert wurden.
Ich hatte schon mal an einer anderen Stelle einen String zusammengefügt und mit ASSIGN zugewiesen.
Irgendwas übersehe ich hier noch oder ist mir nicht bewusst ...
Code: Alles auswählen.
CONCATENATE 'ls_p9010-vprnr' lv_index INTO lv_fieldname.
ASSIGN (lv_fieldname) TO <vprnr>.Dominic
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Ist das Programm MP200000, von dem du versuchst die Variable PSAVE auszulesen, im Speicher auch geladen?Dominic hat geschrieben:Irgendwas übersehe ich hier noch oder ist mir nicht bewusst ...Code: Alles auswählen.
lv_var = '(MP200000)PSAVE'. ASSIGN (lv_var) TO FIELD-SYMBOL(<psave>).
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 DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Zunächst mal an alle Nicht-HCM-ler: "Dynamische Maßnahmen" sind eine HCM-Besonderheit, die man kennen muss. Eine recht altertümliche Technik, jedoch meines Wissens mangels vernünftiger Alternative nicht von der SAP als "veraltet" eingestuft. Das ist so eine Art Pseudo-Programmiersprache, mit der man in der Personaldatenpflege den normalen Ablauf erweitern kann. U.a. bietet diese auch die Möglichkeit, eine eigene (hoffentlich in einem "Subroutinenpool" untergebrachte) Formroutine aufzurufen, um dort irgendwas zu veranstalten, was Dynamische Maßnahmen von Hause aus nicht leisten können.
Innerhalb der Dynamischen Maßnahmen (also der Pseudo-Programmiersprache) steht eine Reihe von Feldleisten zur Verfügung, die SAP-seitig mit den im betreffenden Vorgang richtigen Werten zur Verfügung gestellt werden, so dass man sie nutzen und damit arbeiten kann. PSAVE ist eine davon. Offenbar möchte Dominic diese auch in seiner Formroutine nutzen. Deswegen will er sich den Wert per Dirty Assign aus dem SAP-Standard-Programm erschleichen, das den Interpreter für die Dynamische-Maßnahmen-Sprache darstellt und dementsprechend auch das Programm ist, das seine Formroutine aufruft.
Nur sollte er dabei auch das richtige Programm erwischen. Dominic, ich habe gerade mal eine Dynamische Maßnahme debuggt, und das rufende Programm, in dem PSAVE definiert ist, ist MP000000 und nicht MP200000. Darin dürfte Dein Fehler liegen.
Generell finde ich den Ansatz aber reizvoll und nützlich. Den werde ich vielleicht auch mal in einer eigenen Dynamischen Maßnahme brauchen können.
@SaskuAc: Er hat die Variable doch in der vorhergehenden Zeile zugewiesen?!
Innerhalb der Dynamischen Maßnahmen (also der Pseudo-Programmiersprache) steht eine Reihe von Feldleisten zur Verfügung, die SAP-seitig mit den im betreffenden Vorgang richtigen Werten zur Verfügung gestellt werden, so dass man sie nutzen und damit arbeiten kann. PSAVE ist eine davon. Offenbar möchte Dominic diese auch in seiner Formroutine nutzen. Deswegen will er sich den Wert per Dirty Assign aus dem SAP-Standard-Programm erschleichen, das den Interpreter für die Dynamische-Maßnahmen-Sprache darstellt und dementsprechend auch das Programm ist, das seine Formroutine aufruft.
Nur sollte er dabei auch das richtige Programm erwischen. Dominic, ich habe gerade mal eine Dynamische Maßnahme debuggt, und das rufende Programm, in dem PSAVE definiert ist, ist MP000000 und nicht MP200000. Darin dürfte Dein Fehler liegen.
Generell finde ich den Ansatz aber reizvoll und nützlich. Den werde ich vielleicht auch mal in einer eigenen Dynamischen Maßnahme brauchen können.
@SaskuAc: Er hat die Variable doch in der vorhergehenden Zeile zugewiesen?!
Hey,
Danke für den Tipp.
Aber mit dem Modulpool MP000000 hat es auch nicht funktioniert.
Der IT8 hat wie es aussieht sogar einen eigenen Modulpool aber auch mit dem (MP000800) klappt es nicht.
Irgendwo hab ich einen Denkfehler drin.
Ich melde mich wenn ich meinen Fehler gefunden habe.
Wenn jemanden noch etwas auffällt gerne melden.
Danke und Grüße
Danke für den Tipp.
Aber mit dem Modulpool MP000000 hat es auch nicht funktioniert.
Der IT8 hat wie es aussieht sogar einen eigenen Modulpool aber auch mit dem (MP000800) klappt es nicht.
Irgendwo hab ich einen Denkfehler drin.
Ich melde mich wenn ich meinen Fehler gefunden habe.
Wenn jemanden noch etwas auffällt gerne melden.
Danke und Grüße
Ok die Lösung ist dann doch recht simpel.
Im Grund kann man denke ich sogar über das Field-Symbol <psave> auf die Daten zugreifen.
Möchte man eine "Infotyp-Tabelle" muss man das Field-Symbol erstmal in eine prelp Struktur umwandeln
und DANN kann ich diese verwenden um sie in eine IT0008-Struktur umzuwandeln.
Das wäre zumindest eine Variante um auf die "alten" Werte des gerade veränderten Satzes zu kommen.
Vielleicht hilft das ja künftig jemandem.
Grüße
Dominic
Im Grund kann man denke ich sogar über das Field-Symbol <psave> auf die Daten zugreifen.
Möchte man eine "Infotyp-Tabelle" muss man das Field-Symbol erstmal in eine prelp Struktur umwandeln
und DANN kann ich diese verwenden um sie in eine IT0008-Struktur umzuwandeln.
Das wäre zumindest eine Variante um auf die "alten" Werte des gerade veränderten Satzes zu kommen.
Vielleicht hilft das ja künftig jemandem.
Code: Alles auswählen.
TABLES: p0008.
DATA: lv_var TYPE string.
DATA: ls_p0008_old TYPE p0008.
DATA: ls_prelp TYPE prelp.
FIELD-SYMBOLS: <psave> TYPE prelp.
FORM process_at_change.
lv_var = '(MP000800)PSAVE'.
ASSIGN (lv_var) TO FIELD-SYMBOL(<psave>) .
CALL METHOD cl_hr_pnnnn_type_cast=>pnnnn_to_prelp
EXPORTING
pnnnn = <psave>
IMPORTING
prelp = ls_prelp.
CALL METHOD cl_hr_pnnnn_type_cast=>prelp_to_pnnnn
EXPORTING
prelp = ls_prelp
IMPORTING
pnnnn = ls_p0008_old.
ENDFORM.Dominic
Folgende Benutzer bedankten sich beim Autor Dominic für den Beitrag:
DeathAndPain
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Ja, natürlich, ich Trottel, da hätte ich auch dran denken können. Jeder Infotyp hat für seine Dynprodarstellung ein Steuerprogramm, das MPxxxx00 heißt, wobei xxxx die Infotypnummer ist. Bei meinem Debuggertest habe ich eine Dynamische Maßnahme im IT 0 ausgelöst, deshalb war es bei mir MP000000. Du pfuschelst im IT 8 rum, also ist es bei Dir MP000800. Das sind Sachen, die ich eigentlich im Schlaf kann.Danke für den Tipp.
Aber mit dem Modulpool MP000000 hat es auch nicht funktioniert.
Der IT8 hat wie es aussieht sogar einen eigenen Modulpool
Dass man den PSAVE erst PRELPen und anschließend sofort wieder de-PRELPen muss, kommt mir aber zweifelhaft vor. Klar, er muss auf die Infotypstruktur des IT 8 gecastet werden, da <psave> nicht über die Struktur eines bestimmten Infotyps definiert ist. Aber probier doch anstelle der beiden Methodenaufrufe einfach mal ein simples
Code: Alles auswählen.
ls_p0008_old = <psave>.Kleiner Tipp am Rande: Es gibt Infotypen, die haben noch ein zusätzliches Anhängsel dran, genannt "SECONDARY_INFOTYPE". Das Tückische dabei: dieses Anhängsel wird nur bei bestimmten Ländern genutzt. Solange Du nur in Deutschland bleibst, pflegt Dein CL_HR_PNNNN_TYPE_CAST=>PRELP_TO_PNNNN dennoch zu funktionieren, denn im Secondary Infotype sitzen typischerweise länderspezifische Ergänzungsfelder zum Land des Mitarbeiters. Sobald Du aber einen entsprechenden ausländischen Mitarbeiter im System hast, fliegt Dir das um die Ohren, weil dann die Zusatzfelder verlorengehen bzw. seltsamst mutieren, sobald Du die Daten wieder zurückschreibst.
In diesen Fällen musst Du stattdessen die Methode CL_HR_PNNNN_TYPE_CAST=>PRELP_TO_VIEW verwenden, die Dir sowohl den Hauptinfotyp als auch die zugehörigen Zusatzdaten des Secondary Infotype sauber extrahiert. In der Rückrichtung dementsprechend CL_HR_PNNNN_TYPE_CAST=>VIEW_TO_PRELP anstelle von CL_HR_PNNNN_TYPE_CAST=>PNNNN_TO_PRELP.
Ob es zum Land des Mitarbeiters den Sekundärinfotyp gibt, erfährst Du in der Tabelle T582V in Verbindung mit T582W.
In der Praxis sieht das so aus (am Beispiel des IT 16):
Code: Alles auswählen.
DATA: VINFT LIKE T582V-VINFT,
IXXXX TYPE REF TO DATA,
SECONDARY_INFOTYPE LIKE T582W-INFTY,
STRUCTURE_OF_SECONDARY_INFTY(5) TYPE C.
CLEAR: VINFT, SECONDARY_INFOTYPE.
SELECT SINGLE VINFT INTO VINFT FROM T582V
WHERE MOLGA = T001P-MOLGA " hier muss die MOLGA zum Personalteilbereich des Mitarbeiters angegeben werden, siehe Tabelle T001P
AND INFTY = '0016'.
IF SY-SUBRC = 0.
SELECT SINGLE INFTY INTO SECONDARY_INFOTYPE FROM T582W
WHERE VINFT = VINFT
AND SEQNR = '02'.
ENDIF.
IF SY-SUBRC = 0. " wenn aus einem der beiden vorangegangenen SELECTS ein SY-SUBRC <> 0 kommt, gehen wir von einem IT ohne Infotypview aus.
STRUCTURE_OF_SECONDARY_INFTY = 'P' && SECONDARY_INFOTYPE. " && sind zwei Ampersands; da spinnt das Code-Tag hier im Forum rum
* <IXXXX> mit der Struktur des in VINFT bezeichneten Infotyps typisieren
CREATE DATA IXXXX TYPE (STRUCTURE_OF_SECONDARY_INFTY).
ASSIGN IXXXX->* TO <IXXXX>.
* Umwandeln PRELP nach Infotypview
CALL METHOD CL_HR_PNNNN_TYPE_CAST=>PRELP_TO_VIEW
EXPORTING
PRELP = INNNN "Puffer Personalstammdaten
SECONDARY_INFTY = SECONDARY_INFOTYPE
IMPORTING
PRIMARY_RECORD = P0016
SECONDARY_RECORD = <IXXXX>.
ELSE. " Land, bei dem kein Viewinfotyp hinten dranhängt
CALL METHOD CL_HR_PNNNN_TYPE_CAST=>PRELP_TO_PNNNN
EXPORTING PRELP = INNNN
IMPORTING PNNNN = P0016.
ENDIF.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag (Insgesamt 2):
abuma • Dominic
Danke nochmal für die ausführliche Erklärung und Erläuterung des Falls mit dem Auslandsmitarbeiter.
Habe es mal versucht wie beschrieben mit:
In der Tat funktioniert das auch.
Werde das vermutlich für die Umsetzung nun auch so verwenden
Grüße
Dominic
Habe es mal versucht wie beschrieben mit:
Code: Alles auswählen.
ls_p0008_old = <psave>.Werde das vermutlich für die Umsetzung nun auch so verwenden
Grüße
Dominic
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Rein informativ: Das ganze GePRELPe kenne ich eigentlich aus einer ganz anderen Ecke. Du benutzt es für Deinen Dirty Assign mit PSAVE, aber im wesentlichen braucht man es, wenn man die beiden User Exits ZXPADU01 und ZXPADU02 verwendet. Mit diesen kann man im PBO (ZXPADU01) und im PAI (ZXPADU02) beliebiger Infotypen eigenen Code unterbringen, z.B. Felder vorbelegen oder Feldwerte prüfen. Alles, was ich oben gesagt habe, gilt auch für diese User Exits, wobei bei diesen eben auch die Wandlung in Rückrichtung (also CL_HR_PNNNN_TYPE_CAST=>PRELP_TO_PNNNN statt CL_HR_PNNNN_TYPE_CAST=>PNNNN_TO_PRELP) wichtig ist, wenn man Feldwerte ändern und wieder zurückschreiben möchte.
Manche sagen, dass diese User Exits veraltet seien, da es ja auch den BADI HRPAD00INFTY gibt, aber man kann mit dem BADI nicht alles machen, was mit dem User Exit geht. Man kann darin nur Prüfungen machen, aber eben keine Felder ändern, weswegen ich die o.g. User Exits nach wie vor sehr nützlich finde. (PRELPen muss man in dem BADI übrigens auch
)
Manche sagen, dass diese User Exits veraltet seien, da es ja auch den BADI HRPAD00INFTY gibt, aber man kann mit dem BADI nicht alles machen, was mit dem User Exit geht. Man kann darin nur Prüfungen machen, aber eben keine Felder ändern, weswegen ich die o.g. User Exits nach wie vor sehr nützlich finde. (PRELPen muss man in dem BADI übrigens auch
)
Seite 1 von 1
Vergleichbare Themen
3
Antw.
Antw.
3750
Views
Views
5
Antw.
Antw.
2909
Views
Views
8
Antw.
Antw.
6194
Views
Views
3
Antw.
Antw.
919
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.