Ich brauche bitte mal einen kreativen Lösungsansatz
13 Beiträge
•
Seite 1 von 1
13 Beiträge
Seite 1 von 1
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Folgendes Problem (das sich in meinem Fall auf Personalnummern bezieht, dem Grunde nach aber modulübergreifend ist, da es genauso Materialien, Kunden, Kreditoren oder was auch immer betreffen könnte):
Ein Sachbearbeiter pflegt eine Personalnummer. Dabei sperrt seine Pflegetransaktion logischerweise jene Personalnummer.
Jetzt wird durch seine Tätigkeit ein User Exit von mir ausgelöst, der im Hintergrund einen anderen Aspekt der Personalnummer pflegen soll. Obwohl der User Exit aus der pflegenden Transaktion aufgerufen wird, ist das jedoch so gekapselt, dass er deren Sperre nicht mitbenutzen kann. Unter Nutzung der für die Personalnummernpflege vorgesehenen Standard-SAP-Funktionsbausteine kann er also in dem Moment seinen Job nicht machen, da die Personalnummer gesperrt ist. (Das hat im HCM bestimmte technische Gründe, die hier aber zu weit führen würden.) Der Aspekt, der im Hintergrund gepflegt werden soll, ist timingunkritisch. Es macht also nichts, wenn das erst eine halbe Stunde später drin ist.
Als Lösung habe ich mir jetzt einfallen lassen, dass der User Exit einen kleinen, separaten Report für sofortige Ausführung einplant. Dieser Report wartet (per Befehl WAIT UP TO...), bis er die Personalnummer erfolgreich sperren kann (der Sachbearbeiter also mit seiner Arbeit fertig ist). Dann führt er die Änderung durch und endet. Von dieser Sorte habe ich mehrere Mini-Reports gebaut.
Nun hatte ich heute erstmals real das Problem, dessen Möglichkeit ich schon lange befürchtet habe: Ein Sachbearbeiter hat so viele wartende Mini-Reports erzeugt, dass die Background-Taskprozesse alle zu waren. Man konnte nichts mehr ins Produktivsystem importieren.
Zuerst dachte ich, der müsste in ganz vielen Modi mehrere Personalnummern gleichzeitig gepflegt und die Fenster alle im Ändern-Modus stehengelassen haben. Ich fand aber nur einen. Offenbar hat er an derselben Personalnummer mehrmals hintereinander geändert und jedesmal einen neuen Hintergrundprozess erzeugt, ohne die Personalnummer zwischendurch mal freizugeben.
Klar, sowas kann passieren. Anscheinend hat mein Lösungsansatz Schwächen. Jetzt suche ich nach Alternativen. Reicht es, statt WAIT UP TO den FB RZL_SLEEP zu verwenden, damit während des Wartens kein Hintergrundprozess blockiert wird? Oder wäre es ein sinnvoller Ansatz, wenn solch Mini-Report angesichts der Tatsache, dass die zu ändernde Personalnummer gesperrt ist, nicht einfach wartet, sondern sich selbst für einen späteren Zeitpunkt einplant und dann terminiert? Das würde aber Massen an Joblogs erzeugen, wenn der Sachbearbeiter die Nummer zwei Stunden im Ändern-Modus vergisst und der Job alle 5 Minuten sein Glück versucht und sich jeweils neu für 5 Minuten später einplant. Oder konnte man so einplanen, dass kein Job Log hinterlassen wird?
Eine andere Idee wäre, ein Framework zu bauen, bei dem all solche Änderungen in eine Z-Tabelle eingetragen werden, und einmal die Stunde startet ein Report und versucht, die Einträge abzuarbeiten. Letztlich wäre das so eine Art selbstgebauter asynchroner Verbucher. Wäre aber aufwendig.
Hat jemand noch andere Ideen? Gibt es Best Practices für das Problem?
Ein Sachbearbeiter pflegt eine Personalnummer. Dabei sperrt seine Pflegetransaktion logischerweise jene Personalnummer.
Jetzt wird durch seine Tätigkeit ein User Exit von mir ausgelöst, der im Hintergrund einen anderen Aspekt der Personalnummer pflegen soll. Obwohl der User Exit aus der pflegenden Transaktion aufgerufen wird, ist das jedoch so gekapselt, dass er deren Sperre nicht mitbenutzen kann. Unter Nutzung der für die Personalnummernpflege vorgesehenen Standard-SAP-Funktionsbausteine kann er also in dem Moment seinen Job nicht machen, da die Personalnummer gesperrt ist. (Das hat im HCM bestimmte technische Gründe, die hier aber zu weit führen würden.) Der Aspekt, der im Hintergrund gepflegt werden soll, ist timingunkritisch. Es macht also nichts, wenn das erst eine halbe Stunde später drin ist.
Als Lösung habe ich mir jetzt einfallen lassen, dass der User Exit einen kleinen, separaten Report für sofortige Ausführung einplant. Dieser Report wartet (per Befehl WAIT UP TO...), bis er die Personalnummer erfolgreich sperren kann (der Sachbearbeiter also mit seiner Arbeit fertig ist). Dann führt er die Änderung durch und endet. Von dieser Sorte habe ich mehrere Mini-Reports gebaut.
Nun hatte ich heute erstmals real das Problem, dessen Möglichkeit ich schon lange befürchtet habe: Ein Sachbearbeiter hat so viele wartende Mini-Reports erzeugt, dass die Background-Taskprozesse alle zu waren. Man konnte nichts mehr ins Produktivsystem importieren.
Zuerst dachte ich, der müsste in ganz vielen Modi mehrere Personalnummern gleichzeitig gepflegt und die Fenster alle im Ändern-Modus stehengelassen haben. Ich fand aber nur einen. Offenbar hat er an derselben Personalnummer mehrmals hintereinander geändert und jedesmal einen neuen Hintergrundprozess erzeugt, ohne die Personalnummer zwischendurch mal freizugeben.
Klar, sowas kann passieren. Anscheinend hat mein Lösungsansatz Schwächen. Jetzt suche ich nach Alternativen. Reicht es, statt WAIT UP TO den FB RZL_SLEEP zu verwenden, damit während des Wartens kein Hintergrundprozess blockiert wird? Oder wäre es ein sinnvoller Ansatz, wenn solch Mini-Report angesichts der Tatsache, dass die zu ändernde Personalnummer gesperrt ist, nicht einfach wartet, sondern sich selbst für einen späteren Zeitpunkt einplant und dann terminiert? Das würde aber Massen an Joblogs erzeugen, wenn der Sachbearbeiter die Nummer zwei Stunden im Ändern-Modus vergisst und der Job alle 5 Minuten sein Glück versucht und sich jeweils neu für 5 Minuten später einplant. Oder konnte man so einplanen, dass kein Job Log hinterlassen wird?
Eine andere Idee wäre, ein Framework zu bauen, bei dem all solche Änderungen in eine Z-Tabelle eingetragen werden, und einmal die Stunde startet ein Report und versucht, die Einträge abzuarbeiten. Letztlich wäre das so eine Art selbstgebauter asynchroner Verbucher. Wäre aber aufwendig.
Hat jemand noch andere Ideen? Gibt es Best Practices für das Problem?
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hallo,
bitte mal prüfen ob da eine Lösung möglich ist:
https://blog.hr-manager.de/2015/06/pa-a ... 0-auf.html
Gruß Wolfgang
bitte mal prüfen ob da eine Lösung möglich ist:
https://blog.hr-manager.de/2015/06/pa-a ... 0-auf.html
Gruß Wolfgang
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Mikroreport schreiben, der deinen Userexit aufruft und die zu übergebenden Daten mittels Parametern auf dem Bildschirm entgegen nimmt.
Im Programm nun anstatt des direkten Aufrufs einen Job anlegen und dann in diesen den Mikroreport mit den wesentlichen Daten einfügen und dann den Job mit Starttermin +10 Minuten abschließen.
Im Programm nun anstatt des direkten Aufrufs einen Job anlegen und dann in diesen den Mikroreport mit den wesentlichen Daten einfügen und dann den Job mit Starttermin +10 Minuten abschließen.
Mein Vorschlag wäre folgender:
Wenn dein User-Exit getriggered wird könntest du die geänderten Personalnummern in eine Tabelle schreiben. Dann machen mehrere Änderungen an derselben Nummer nichts aus.
Die Nummern kannst du dann in einem Job lesen, der jede Nacht läuft und deine Pflege tätigt.
Wenn dein User-Exit getriggered wird könntest du die geänderten Personalnummern in eine Tabelle schreiben. Dann machen mehrere Änderungen an derselben Nummer nichts aus.
Die Nummern kannst du dann in einem Job lesen, der jede Nacht läuft und deine Pflege tätigt.
( SAP ECC 6.0, NetWeaver 7.0, ohne unicode, ohne support/enhancement packages )
DeathAndPain hat geschrieben:
Eine andere Idee wäre, ein Framework zu bauen, bei dem all solche Änderungen in eine Z-Tabelle eingetragen werden, und einmal die Stunde startet ein Report und versucht, die Einträge abzuarbeiten. Letztlich wäre das so eine Art selbstgebauter asynchroner Verbucher. Wäre aber aufwendig.
Hat jemand noch andere Ideen? Gibt es Best Practices für das Problem?
Ist ja beides im Prinzip das gleiche.Legxis hat geschrieben:Mein Vorschlag wäre folgender:
Wenn dein User-Exit getriggered wird könntest du die geänderten Personalnummern in eine Tabelle schreiben. Dann machen mehrere Änderungen an derselben Nummer nichts aus.
Die Nummern kannst du dann in einem Job lesen, der jede Nacht läuft und deine Pflege tätigt.
und um ehrlich zu sein, halte ich das für die beste Idee. Bzw. weiß ich dass das ganz gut funktioniert, weil wir exakt diese Lösung bei uns im Einsatz haben. Um alle zeitunkritischen Sachen, also Sachen die 1x pro Tag laufen können haben wir in eine Z-Tabelle geschrieben. Aufgrund von verschiedenen Abhängigkeiten bei verschiedenen Ländern haben wir hier auch Uhrzeiten ( bzw. die jeweilige Stunde ) wann der Report die jeweilige Änderung ausführen soll. Dann geht ein Report stündlich drüber, der die Änderung dann ausführt.
Der Report selber ist tatsächlich relativ einfach gestrikt, der liest einfach die Tabelle mit den Spalten "Aktion" "Uhrzeit" und "Parameter" ( Parameter ist ein XML String ) - dann ruft der Report einen BAdi auf der als Parameter die "Aktion" hat, anhand dieser Aktion wird dann die implementierung mit der "do_changes" Methode aufgerufen, welche als Parameter den XML String erwartet. Dort können dann Personalnummer, Infotyp, sonstiges hinterlegt sein. ( geht natürlich auch mit Materialnummern, etc. )
So behält man einen relativ guten Überblick für welche Zwecke was getan wird und hat keinen allzu großen Implementierungsaufwand.
Unterm strich also, ein Z-Report der einen Select auf eine Z-Tabelle macht und einen BAdi aufruft
Eine Z-Tabelle mit den Spalten "Aktion", "Uhrzeit", "Parameter" ( XML String )
Einen BAdi mit den Implementierungen was eigentlich gemacht werden soll
Und die User-Exits, BAdis oder sonstiges die du Anfangs auch implementiert hast, welche aber dieses Problem verursachen. Diese werden also abgeändert auf - Schreibe in die "Z-Tabelle" was gemacht werden soll
Mehr ist das bei uns nicht. Hoffentlich konnte ich dir damit weiterhelfen.
PS: Vergiss nicht die jeweiligen Aktionen zu dokumentieren, ansonsten darf man irgendwann mühevoll heraussuchen was für was genau war... und das will man niemals tun, insbesondere nicht, wenn man 20 - 30 solcher Fälle hat
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
@Wolfgang: Vielen Dank für den Tipp. Das lasse ich gerade von unserem HR prüfen, inwieweit das für die praktikabel wäre. Teilweise hat es ja Gründe, dass man mitten in einer Pflegetransaktion (z.B. Neuen Mitarbeiter einstellen) unterbrechen muss, weil einem noch Informationen fehlen. Aber vielleicht ist das tatsächlich eine Option. Wäre natürlich bequem für mich.
@Daniel: Der Standard-SAP-FB, mit dem man das pflegt, macht im Hintergrund einen batch-input-fähigen Dialog, der genauso in die Sperre läuft, auch wenn ich ihm mitgebe, dass er das nicht sofort verbuchen soll.
@black_adept: Das ist genau die Lösung, die ich derzeit implementiert habe. Wie im Haupttext geschildert, hatte ich jetzt den Fall, dass zu viele dieser Mikroreports auf das Freiwerden der Personalnummer gewartet haben und mir damit alle Hintergrundprozesse des Servers dichtgemacht haben.
@Legxis: Das wäre die von mir erwähnte Lösung der selbstprogrammierten asynchronen Verbuchung. Ist sicherlich am elegantesten, wenn sie erst einmal steht, aber halt Arbeit zu implementieren. Ich sage nicht, dass ich nicht bereit wäre, die zu investieren, aber zunächst bin ich noch dabei, meine Optionen auszuloten, und dabei für euren Input dankbar.
@Daniel: Der Standard-SAP-FB, mit dem man das pflegt, macht im Hintergrund einen batch-input-fähigen Dialog, der genauso in die Sperre läuft, auch wenn ich ihm mitgebe, dass er das nicht sofort verbuchen soll.
@black_adept: Das ist genau die Lösung, die ich derzeit implementiert habe. Wie im Haupttext geschildert, hatte ich jetzt den Fall, dass zu viele dieser Mikroreports auf das Freiwerden der Personalnummer gewartet haben und mir damit alle Hintergrundprozesse des Servers dichtgemacht haben.
@Legxis: Das wäre die von mir erwähnte Lösung der selbstprogrammierten asynchronen Verbuchung. Ist sicherlich am elegantesten, wenn sie erst einmal steht, aber halt Arbeit zu implementieren. Ich sage nicht, dass ich nicht bereit wäre, die zu investieren, aber zunächst bin ich noch dabei, meine Optionen auszuloten, und dabei für euren Input dankbar.
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
So ähnlich wie SaskuAc mache ich das auch meist - allerdings wird nach dem Eintrag in die Z-Tabelle üblicherweise der Verarbeitungsreport für genau den aktuell eingetragenen Schlüssel explizit 1x aufgerufen, damit die Verarbeitung quasi synchron erfolgt. Der periodische Aufräumjob ist dann nur noch der Staubsauger für alle Fälle, wo der 1. Versuch - aus was für Gründen auch immer - nicht geklappt hatte bzw. als Reportingtool, wo dann manuell mal nachgeschaut werden kann, was aktuell schief geht ( da ich in der Tabelle auch die letzte Fehlermeldung bei nicht erfolgreicher Verarbeitung mit ablege ).
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Dann müsste ich aber ein Coding schreiben, dass XML parsen kann, und das treibt den Entwicklungsaufwand wieder nach oben. Oder gibt es dafür in SAP vorgefertigte Lösungen? Mit XML-Strings habe ich noch so gut wie gar nicht gearbeitet.SaskuAc hat geschrieben:Der Report selber ist tatsächlich relativ einfach gestrikt, der liest einfach die Tabelle mit den Spalten "Aktion" "Uhrzeit" und "Parameter" ( Parameter ist ein XML String ) - dann ruft der Report einen BAdi auf der als Parameter die "Aktion" hat, anhand dieser Aktion wird dann die implementierung mit der "do_changes" Methode aufgerufen, welche als Parameter den XML String erwartet. Dort können dann Personalnummer, Infotyp, sonstiges hinterlegt sein. ( geht natürlich auch mit Materialnummern, etc. )
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Ein recht einfacher Ansatz ist im Tricktresor beschrieben: http://www.tricktresor.de/blog/serialize-me/ wo man eigentlich nur ein paar wenige Zeilen Code benötigt um das zu machen.DeathAndPain hat geschrieben:Dann müsste ich aber ein Coding schreiben, dass XML parsen kann, und das treibt den Entwicklungsaufwand wieder nach oben. Oder gibt es dafür in SAP vorgefertigte Lösungen? Mit XML-Strings habe ich noch so gut wie gar nicht gearbeitet.
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Danke, das werde ich mir mal zu Gemüte führen. Der Hammer war allerdings dieses freimütige Eingeständnis im Tricktresor-Text:
Das obige Zitat ist hinsichtlich des mit "Nutzen" überschriebenen Absatzes vollständig. Mit anderen Worten, da wurde aufwendig was implementiert, obwohl gar nicht klar ist, wozu es nütze sein soll, aber vielleicht brauchst Du es ja mal, dann wirst Du es wissen!Nutzen
Wozu die Serialisierung und Deserialisierung tatsächlich nützlich ist, wird man wahrscheinlich erst wissen, wenn man es braucht. Daher ist es in jedem Fall gut zu wissen, dass es funktioniert.
Beitrag
von a-dead-trousers (Top Expert / 4414 / 224 /
1186
)
»
Naja...DeathAndPain hat geschrieben:Danke, das werde ich mir mal zu Gemüte führen. Der Hammer war allerdings dieses freimütige Eingeständnis im Tricktresor-Text:Das obige Zitat ist hinsichtlich des mit "Nutzen" überschriebenen Absatzes vollständig. Mit anderen Worten, da wurde aufwendig was implementiert, obwohl gar nicht klar ist, wozu es nütze sein soll, aber vielleicht brauchst Du es ja mal, dann wirst Du es wissen!Nutzen
Wozu die Serialisierung und Deserialisierung tatsächlich nützlich ist, wird man wahrscheinlich erst wissen, wenn man es braucht. Daher ist es in jedem Fall gut zu wissen, dass es funktioniert.
De-/Serialisierung wird in vielen (allen? wichtigen?) Programmiersprachen bereits eingesetzt und hat eine meines Erachtens sehr wichtige Daseinsberechtigung. z.B. "Objektorientierte" Kommunikation zwischen zwei (Netzwerk-)Knoten aka Webservices.
Also ein etwas modernerer Ansatz als die alten Protokolle ala FTP usw. wo nur Zeichenketten hin und hergeschickt wurden und der Empfänger wissen musste, dass z.B. an Offset 6 die Parameter des Befehls übergeben werden.
Die SAP hat hier somit etwas "aufwändiges" implementiert, was es in anderen Programmiersprachen auch schon gibt und sich inzwischen meines Erachtes auch durchgesetzt und gut bewährt hat.
Ein Beispiel für eine meines Erachtens gute Nutzbarkeit in SAP abseits von Webservices:
Wenn man z.B. ein "Ereignis" protokollieren möchte, kann man das zugrundeliegende "Objekt" mitsamt einer allfälligen "Konfiguration" ohne viel aufhebens in einer Protokolltabelle abspeichern ohne sich Gedanken machen zu müssen um welchen Objekttyp es sich handelt usw. Natürlich muss man das Ganze dann noch um z.B. allgemeine Interfaces auffetten, damit man sich beim Auslesen der Information dann etwas leichter tut, aber das machen doch eh alle.
EDIT: Der Artikel ist übrigens über zwei Jahre alt. Enno dürfte inzwischen schon etwas anders denken. (hoffe ich zumindest
)
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 / 4103 / 128 /
945
)
»
Close Reading! "Enno" <> "man"a-dead-trousers hat geschrieben: Enno dürfte inzwischen schon etwas anders denken. (hoffe ich zumindest
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
2192
Views
Views
Verarbeitung T588Z 'debuggen' bzw. Lösungsansatz
von SkyHobbit » 12.09.2007 14:07 • Verfasst in Human Resources
von SkyHobbit » 12.09.2007 14:07 • Verfasst in Human Resources
2
Antw.
Antw.
1794
Views
Views
SAP Fiori on Premise oder den Lösungsansatz von Adesso SE nutzen
von LittleStudent » 28.03.2023 18:41 • Verfasst in Fiori, UI5, JavaScript
von LittleStudent » 28.03.2023 18:41 • Verfasst in Fiori, UI5, JavaScript
5
Antw.
Antw.
1935
Views
Views
2
Antw.
Antw.
1460
Views
Views
0
Antw.
Antw.
825
Views
Views
ich brauche Funktionbausteine für FI-Buchung
von Jimmy Chandra » 04.11.2005 15:31 • Verfasst in ABAP® Core
von Jimmy Chandra » 04.11.2005 15:31 • Verfasst in ABAP® Core
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
SAPScript Formular Fertigungspapiere doppelseitig Drucken
vor einer Woche von Abap_neuling 14 / 3047
vor einer Woche von Abap_neuling 14 / 3047
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor einer Woche von a-dead-trousers 5 / 2699
vor einer Woche von a-dead-trousers 5 / 2699
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
SAPScript Formular Fertigungspapiere doppelseitig Drucken
vor einer Woche von Abap_neuling 14 / 3047
vor einer Woche von Abap_neuling 14 / 3047
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor einer Woche von a-dead-trousers 5 / 2699
vor einer Woche von a-dead-trousers 5 / 2699