Ideensammlung für Apps/Reports

Re: Ideensammlung für Apps/Reports

Re: Ideensammlung für Apps/Reports

• Das Reminder-Framework. Ich weiß nicht, wie das in anderen Modulen ist, aber im HCM steht man häufig vor dem Problem, dass man bei Vorliegen bestimmter Bedinungen automatisierte Emails verschicken muss, z.B. Jubiläums-Emails (Mitarbeiter ist 5 Jahre im Unternehmen), automatische Email an die Abteilung, die für die Firmentickets zuständig ist, wenn ein Mitarbeiter das Unternehmen verlässt, Vorlageerinnerung für die Immatrikulationsbescheinigung bei Werkstudenten usw. Ich könnte mir vorstellen, dass auch in anderen Modulen die Notwendigkeit vorkommt, bestimmten Kräften Erinnerungs- oder sogar Warn-Emails zu verschicken. Ein nächtlicher Job führt die automatischen Prüfungen durch und verschickt dann die Emails.
  
  Anfangs habe ich für jeden solchen Reminder einen eigenen Report geschrieben und als Job eingeplant. Aber die Liste wurde nicht nur in der SM37 immer länger und unübersichtlicher (auch mit der Startzeitplanung, damit nicht alle gleichzeitig loslaufen), sondern ich fand mich auch in der Situation wieder, das Rad für Coding für Aufbau und Versand der Emails immer von vorne erfinden zu müssen. Da habe ich irgendwann eine Tabelle gemacht, in der jede Zeile ein Reminder war, mit Namen und zugehörigem Funktionsbaustein. Das Coding für Lesen eines Standardtextes (mit Ersetzungsvariablen), Aufbau und Versand der Emails wahlweise mit oder ohne HTML (oder sogar mit HTML mit eingebundener Grafik) kam in ein zentrales Frameworkprogramm. Nur dieses wurde nachts eingeplant und ist dann durch die Tabelle gerast und hat nacheinander jeden Reminder-Funktionsbaustein aufgerufen (heute würde ich stattdessen eine statische Klasse nehmen wegen der schöneren Schnittstelle). Die Funktionsbausteine hatten eine genau definierte Schnittstelle, über die sie eine interne Tabelle der zu versendenden Emails mit Email-Typ (plain text/HTML/HTML mit Grafik), Absender, Empfänger zurückliefern konnten, und das Framework hat sich um den Versand gekümmert.
  
  In der Remindertabelle hatte man stets einen Überblick, welche Reminder es alles gibt und was sie tun (dank einer Spalte für eine kurze textuelle Beschreibung). Außerdem habe ich eine boolesche Spalte "aktiv" eingebaut, die man anhaken konnte oder auch nicht. So konnte man Reminder nach Bedarf an- und abschalten (was über die SM37 auch viel unübersichtlicher zu bewerkstelligen wäre).
• Das andere Projekt war das Verbucher-Framework. Ich habe mich öfter in der Situation wiedergefunden, in einem User Exit oder BADI einen Vorgang anstoßen zu müssen, der dort technisch nicht ablaufen konnte (im Extremfall deswegen, weil sich der BADI mitten in einem COMMIT befand und daher ein weiterer COMMIT zu einem Dump geführt hätte. Auch Emails etc. kann man nicht aus jedem Verbuchungsvorgang heraus verschicken oder Daten ändern, die direkt mit dem Verbuchungsvorgang des BADIs oder User Exits zusammenhängen und daher gesperrt sind). Anfangs habe ich für solche Zwecke jeweils einen kleinen Report geschrieben und den dann aus dem BADI heraus als Hintergrundjob eingeplant. Der Hintergrundjob hat dann ggf. gewartet, bis die zu ändernden Daten nicht mehr gesperrt waren (was auch mal eine Stunde dauern konnte, wenn der Benutzer das Bild im Änderungsmodus stehen ließ und in einem anderen Modus weitergearbeitet hat).
  
  Irgendwann lief ich in Probleme, weil die Hintergrundprozesse alle dicht waren. Sie haben zwar ordentliche WAITs ausgeführt und insofern keine Rechenzeit geschluckt, aber es ging halt nicht weiter und es konnte auch nichts Neues mehr als Hintergrundjob starten. Die Sache war also aus dem Ruder gelaufen.
  
  Daraufhin habe ich ein Verbucher-Framework erfunden. Es ist eine statische Klasse, deren Hauptmethode alle paar Minuten als Hintergrundjob eingeplant wird. Im BADI mache ich nicht mehr, als eine neue Zeile in eine Verbuchertasktabelle auf der Datenbank zu schreiben. Dabei gebe ich eine Klasse und Methode an, die die Hintergrundaufgabe erfüllen soll und hinterlege auch die Parameter, mit denen sie gefüttert werden soll. (Letzterer Punkt war etwas trickreich, weil ich die Parameter, die in Anzahl und Typ ja höchst unterschiedlich sein können, serialisieren musste, um sie in der Verbuchertasktabelle ablegen zu können. GZIP-komprimiert habe ich sie auch. 😊)
  
  Der Verbuchertask, der alle paar Minuten läuft, rast jetzt durch diese Tabelle und startet nacheinander alle Einträge, die in ihrer Statusspalte den Status "Auszuführen" haben. Die gerufene Methode (die man dafür natürlich jeweils programmiert haben muss) führt dann die Hintergrundaufgabe aus und liefert ggf. eine Fehlermeldung zurück, beispielsweise "Daten noch gesperrt". In dem Fall lässt das Verbucherprogramm die Zeile im Status "Auszuführen", so dass sie beim nächsten Lauf in ein paar Minuten wieder drankommt. Das Ganze war mit einem Timeout versehen: wenn die Methode nach einigen Stunden immer noch eine Fehlermeldung zurücklieferte, wurde der Status "Failed" gesetzt und nicht mehr versucht sie aufzurufen.
  
  War die Fehlermeldung leer, wurde die Zeile in den Status "Complete" gesetzt.
  
  Das Verbucherframework hat sich vor jedem Methodenstart durch einen Vermerk in der Datenbank gemerkt, welche Methode es gerade gestartet hat. Ist die Methode abgeschmiert und hat die Kontrolle nicht mehr zurück an das Verbucherframework übergeben, wurde dies beim nächsten Lauf (ein paar Minuten später also) festgestellt und die Zeile in den Status "Crashed" gesetzt und nicht wieder ausgeführt.
  
  Dazu gab es eine Admin-Methode, die die Verbuchertabelle als übersichtliches ALV auf den Bildschirm gezaubert hat. Hier konnte man sehen, wann was gelaufen ist und welche Failed- oder Crashed- Einträge es ggf. gegeben hat. In diesem Admin-ALV konnte man dann solch Zeile markieren und über einen "Retry"-Button neu zur Verbuchung einplanen.
  
  In der SM37 habe ich bei dem Aufruf der Verbucherklasse als zweiten Step einen Report von der SAP eingeplant, der jeweils das Log der vorhergehenden Ausführung löscht. So wurde einem das Protokoll der SM37 nicht mit den ganzen Verbucheraufrufen (alle drei Minuten) vollgemüllt. Das echte Log der Verbucherklasse (mit dem man auch tatsächlich was anfangen konnte) konnte man ja in der Admin-Methode begutachten.
  
  Das Ganze hat superelegant und auch performant funktioniert (was auch daran gelegen hat, dass ich sehr darauf geachtet habe, sowohl die Framework-Klasse als auch alle von ihr aufgerufenen Verbuchungsklassen performant zu programmieren). Wichtig ist, dass alle Verbuchungsmethoden dahingehend stabil sind, dass sie auch bei wiederholtem Aufruf nichts Falsches machen. Sie dürfen also eine Konsistenz nach definierten Kriterien herstellen (die dann halt bei einem erneuten Aufruf bereits besteht) oder einen definierten Sollzustand herstellen (einen konkreten Wert in ein Feld schreiben). Blöd wäre eine Methode, die z.B. einen Datenbankwert um 1 erhöht, weil das dann bei einem erneuten Aufruf der Methode (wegen eines Fehlers oder warum auch immer) zu einer ungewollten zweiten Erhöhung führen würde.

Re: Ideensammlung für Apps/Reports