Abbruch der Starttransaktion
8 Beiträge
•
Seite 1 von 1
8 Beiträge
Seite 1 von 1
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
hi!
Mal wieder ein kniffliges Thema bei dem ich nicht weiterkomme:
Wie kann man die Starttransaktion eines Benutzers "abbrechen" oder verhindern?
Ich beziehe mich hier auf jene Transaktionen die bei einer SAP-Verknüpfung hinterlegt sind.
Wir versuchen nämlich mittels Userexit EXIT_SAPLSUSF_001 einen Warndialog zu hinterlegen um unsere Benutzer auf ein bald ablaufendes Kennwort hinzuweisen, wobei der Benutzer die Möglichkeit haben soll dieses gleich zu ändern. In einer späteren Ausbauphase soll dies uU um weitere Prüfungen erweitert werden können.
Derzeit sieht es so aus, dass sobald der SAP-Gui ein Dynpro erhällt (CALL SCREEN) "selbstständig" die Transaktion des Users startet, da im Debugger zwar unser Code durchlaufen wird, aber plötzlich die von der Verknüpfung angegebene Transaktion startet.
Wir haben schon versucht mit CL_GUI_CFW=>SET_NEW_OK_CODE dem GUI etwas anderes unter zu jubeln, aber bislang kein Erfolg.
Natürlich wäre es dann auch noch toll zu wissen, welche Transaktion eigentlich aufgerufen werden sollte um sie nach Abschluss unseres Programms zu starten.
Das Ganze soll dann ähnlich dem "normalen" Anmelden am SAP funktionieren, wenn man eine Starttransaktion hinterlegt hat.
In diesem Fall wird nämlich unser Programm zuerst aufgerufen und dann danach erst die andere Transaktion.
lg ADT
Mal wieder ein kniffliges Thema bei dem ich nicht weiterkomme:
Wie kann man die Starttransaktion eines Benutzers "abbrechen" oder verhindern?
Ich beziehe mich hier auf jene Transaktionen die bei einer SAP-Verknüpfung hinterlegt sind.
Wir versuchen nämlich mittels Userexit EXIT_SAPLSUSF_001 einen Warndialog zu hinterlegen um unsere Benutzer auf ein bald ablaufendes Kennwort hinzuweisen, wobei der Benutzer die Möglichkeit haben soll dieses gleich zu ändern. In einer späteren Ausbauphase soll dies uU um weitere Prüfungen erweitert werden können.
Derzeit sieht es so aus, dass sobald der SAP-Gui ein Dynpro erhällt (CALL SCREEN) "selbstständig" die Transaktion des Users startet, da im Debugger zwar unser Code durchlaufen wird, aber plötzlich die von der Verknüpfung angegebene Transaktion startet.
Wir haben schon versucht mit CL_GUI_CFW=>SET_NEW_OK_CODE dem GUI etwas anderes unter zu jubeln, aber bislang kein Erfolg.
Natürlich wäre es dann auch noch toll zu wissen, welche Transaktion eigentlich aufgerufen werden sollte um sie nach Abschluss unseres Programms zu starten.
Das Ganze soll dann ähnlich dem "normalen" Anmelden am SAP funktionieren, wenn man eine Starttransaktion hinterlegt hat.
In diesem Fall wird nämlich unser Programm zuerst aufgerufen und dann danach erst die andere Transaktion.
lg ADT
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
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
Hallo a-d-t,
wie wäre es mit einem ganz pragmatischen Ansatz - wenn ihr schon nicht die Starttransaktion verhindern könnt, nutzt dieses Feature selber.
Automatisierter Job:
Nächtens allen Usern deren Kennwort bald abläuft die Starttransaktion auslesen, in einer eigenen Tabelle merken und die Starttransaktion gegen euer Hinweisprogramm austauschen.
User loggt sich ein:
a) Falls der User sein Passwort immer noch nicht ausgetauscht hat --> Hinweis ausgeben
b) Falls der User brav war --> Die Starttransaktion aus eurer Merktabelle zurückschreiben in die Tabelle AGR_DATEU
Danach in die gemerkte Transaktion weiterverzweigen.
wie wäre es mit einem ganz pragmatischen Ansatz - wenn ihr schon nicht die Starttransaktion verhindern könnt, nutzt dieses Feature selber.
Automatisierter Job:
Nächtens allen Usern deren Kennwort bald abläuft die Starttransaktion auslesen, in einer eigenen Tabelle merken und die Starttransaktion gegen euer Hinweisprogramm austauschen.
User loggt sich ein:
a) Falls der User sein Passwort immer noch nicht ausgetauscht hat --> Hinweis ausgeben
b) Falls der User brav war --> Die Starttransaktion aus eurer Merktabelle zurückschreiben in die Tabelle AGR_DATEU
Danach in die gemerkte Transaktion weiterverzweigen.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
hi!
Sowas in der Art verwenden wir ja schon.
Es soll dann weiter ausgebaut werden zu einer Art Info-Center mit z.B. der Ankündigung des nächsten Wartungsfensters usw.
Mit der vom User eingestellten Starttransaktion gibts ja eh keine Probleme, sondern mit der in einer SAP-Verknüpfung eingestellten Transaktion.
So wie es aussieht, überschreibt der GUI hierbei, sobald ein Dynpro an ihn ausgeliefert wird, die aktuelle Transaktion. Denn es wird zwar das PBO Modul von unserem Dynpro aufgerufen, aber wenn es dann fertig ist und das Dynpro eigentlich angezeigt werden sollte, wird plötzlich die Transaktion aufgerufen die in der SAP-Verknüpfung angegeben war. Auch im Debugger sieht man, dass mit einem Mal die neue Transaktion abgearbeitet wird.
Unseren Usern beizubringen, dass sie in Verknüpfungen nur unsere Transaktion eintragen dürfen, schaffen wir nicht zu schulen. Außerdem überschreibt ja die Verknüpfung auch die Starttransaktion, also bringt es nichts hier alles über diese abzuwickeln, da bei Verwendungen von Verknüpfungen wieder der gleiche Effekt eintritt wie beim Userexit.
lg ADT
Sowas in der Art verwenden wir ja schon.
Es soll dann weiter ausgebaut werden zu einer Art Info-Center mit z.B. der Ankündigung des nächsten Wartungsfensters usw.
Mit der vom User eingestellten Starttransaktion gibts ja eh keine Probleme, sondern mit der in einer SAP-Verknüpfung eingestellten Transaktion.
So wie es aussieht, überschreibt der GUI hierbei, sobald ein Dynpro an ihn ausgeliefert wird, die aktuelle Transaktion. Denn es wird zwar das PBO Modul von unserem Dynpro aufgerufen, aber wenn es dann fertig ist und das Dynpro eigentlich angezeigt werden sollte, wird plötzlich die Transaktion aufgerufen die in der SAP-Verknüpfung angegeben war. Auch im Debugger sieht man, dass mit einem Mal die neue Transaktion abgearbeitet wird.
Unseren Usern beizubringen, dass sie in Verknüpfungen nur unsere Transaktion eintragen dürfen, schaffen wir nicht zu schulen. Außerdem überschreibt ja die Verknüpfung auch die Starttransaktion, also bringt es nichts hier alles über diese abzuwickeln, da bei Verwendungen von Verknüpfungen wieder der gleiche Effekt eintritt wie beim Userexit.
lg ADT
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 / 4087 / 126 /
940
)
»
Ach - du meinst du etwa diese Verknüpfungen die man auf dem Desktop ablegen kann? ( mit .sap-Endung )
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Genau!
Sorry wenn ich mich etwas unklar ausgedrückt habe
(Habs mir selber nochmal durchgelesen und ja ich hätts wahrscheinlich auch verwechselt)
Ne, ich mein wirklich die .sap-Dateien und die dort hinterlegte Transaktion.
Ob man diesen Aufruf irgendwie abfangen und erst im Anschluss zu unserer Starttransaktion (im SAP-System hinterlegt) oder eben dem UserExit durchführen kann.
lg ADT
Sorry wenn ich mich etwas unklar ausgedrückt habe
(Habs mir selber nochmal durchgelesen und ja ich hätts wahrscheinlich auch verwechselt)
Ne, ich mein wirklich die .sap-Dateien und die dort hinterlegte Transaktion.
Ob man diesen Aufruf irgendwie abfangen und erst im Anschluss zu unserer Starttransaktion (im SAP-System hinterlegt) oder eben dem UserExit durchführen kann.
lg ADT
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 / 4087 / 126 /
940
)
»
Hi A-D-T,
ich hatte eher ungenau gelesen.
Aber nichsdestotrotz - ich hätte da was, auch wenn die GUI bestimmt ganz traurig ist, wenn man ihr ihr Ziel unter den Füßen wegzieht.
Du hast ja schon gemerkt, dass die GUI den in der Verknüpfung eingestellten Modus automatisch startet, sobald das 1. Bildchen aufgeblendet wird, indem sie sowas wie "/n<transaktionscode>" ausführt.
Schau dir mal folgendes Coding an, welches dem User als Starttransaktion untergejubelt werden kann, sobald das Passwort bald zu ändern ist. Das sollte dafür sorgen, dass dem User das vorgegaukelt wird, was du haben möchtest. Wenn du rausfinden möchtest, welche Tx der User wirklich aufrufen wollte, damit du ihn später dort hinführen kannst, müsstest du den Startmodus aus eurer Transaktion heraus abschießen und dort ein klein wenig warten bis dir TH_LONG_USR_INFO verrät, was er eigentlich machen wollte.
ich hatte eher ungenau gelesen.
Aber nichsdestotrotz - ich hätte da was, auch wenn die GUI bestimmt ganz traurig ist, wenn man ihr ihr Ziel unter den Füßen wegzieht.
Du hast ja schon gemerkt, dass die GUI den in der Verknüpfung eingestellten Modus automatisch startet, sobald das 1. Bildchen aufgeblendet wird, indem sie sowas wie "/n<transaktionscode>" ausführt.
Schau dir mal folgendes Coding an, welches dem User als Starttransaktion untergejubelt werden kann, sobald das Passwort bald zu ändern ist. Das sollte dafür sorgen, dass dem User das vorgegaukelt wird, was du haben möchtest. Wenn du rausfinden möchtest, welche Tx der User wirklich aufrufen wollte, damit du ihn später dort hinführen kannst, müsstest du den Startmodus aus eurer Transaktion heraus abschießen und dort ein klein wenig warten bis dir TH_LONG_USR_INFO verrät, was er eigentlich machen wollte.
Code: Alles auswählen.
CALL FUNCTION 'TH_CREATE_MODE'
EXPORTING
transaktion = 'ZSPEZIALTRANSAKTION.
CALL FUNCTION 'TH_DELETE_MODE'.
* EXPORTING
* mode =
* mode = -1 --> lösche aktuellen Modus (default)
* mode = n --> lösche Modus n+1Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
a-dead-trousers
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Schaut ja verboten aus 
Erstmal Danke!
Werds morgen dann mal ausprobieren.
lg ADT
Erstmal Danke!
Werds morgen dann mal ausprobieren.
lg ADT
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 a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Zur Info:
Wir haben das ganze jetzt mit CALL FUNCTION ... STARTING NEW TASK ... PERFORMING ... ON END OF TASK, RECEIVE RESULTS FROM FUNCTION ... und WAIT UNTIL ... gelöst.
Alle anderen Varianten (mit TH_CREATE_MODE und TH_DELETE_MODE bzw. CL_IMC_MODE) haben leider nicht zuverlässig in allen Situationen funktioniert.
lg ADT
Wir haben das ganze jetzt mit CALL FUNCTION ... STARTING NEW TASK ... PERFORMING ... ON END OF TASK, RECEIVE RESULTS FROM FUNCTION ... und WAIT UNTIL ... gelöst.
Alle anderen Varianten (mit TH_CREATE_MODE und TH_DELETE_MODE bzw. CL_IMC_MODE) haben leider nicht zuverlässig in allen Situationen funktioniert.
lg ADT
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
5
Antw.
Antw.
706
Views
Views
2
Antw.
Antw.
2348
Views
Views
PY: Abbruch der Abr. in Funktion DST ABF (Zuflussprinzip)
von SSchmidt » 16.07.2008 08:53 • Verfasst in Human Resources
von SSchmidt » 16.07.2008 08:53 • Verfasst in Human Resources
2
Antw.
Antw.
412
Views
Views
Abbruch des Aufrufes der URL zum PRD-System
von Julia.hrtm » 12.11.2024 08:05 • Verfasst in SAP - Allgemeines
von Julia.hrtm » 12.11.2024 08:05 • Verfasst in SAP - Allgemeines
0
Antw.
Antw.
1113
Views
Views
SupportPackage SAPKH46C52 -> Abbruch
von Pitzy007 » 21.12.2006 12:01 • Verfasst in SAP - Allgemeines
von Pitzy007 » 21.12.2006 12:01 • Verfasst in SAP - Allgemeines
Frage die ABAP Experten
Über diesen Beitrag
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 / 1045
vor 2 Tagen von DeathAndPain 4 / 1045
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 / 1045
vor 2 Tagen von DeathAndPain 4 / 1045