Ideensammlung für Apps/Reports

Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Getting started ... Alles für einen gelungenen Start.
7 Beiträge • Seite 1 von 1
7 Beiträge Seite 1 von 1

Ideensammlung für Apps/Reports

Beitrag von BecomingAnAbapGuru (ForumUser / 83 / 31 / 3 ) »
Hallo,

habt ihr irgendwelche Apps entwickelt in euren Firmen oder bei Kunden, die hilfreich wären?

Eventuell können wir hier einige Ideen austauschen.

Danke

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Ideensammlung für Apps/Reports

Beitrag von black_adept (Top Expert / 4080 / 125 / 934 ) »
Minesweeper?

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
deejey

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Ideensammlung für Apps/Reports

Beitrag von JHM (Top Expert / 1197 / 1 / 197 ) »
BecomingAnAbapGuru hat geschrieben:
11.07.2024 16:33
habt ihr irgendwelche Apps entwickelt in euren Firmen oder bei Kunden, die hilfreich wären?

Nur Apps oder auch klassische Reports?

ZALV_EXTRACTOR:
Report der andere Reports, die eine ALV Ausgabe haben, per SUBMIT incl. Variante aufruft, die ALV Ausgabe "abfängt" und diese dann in eine Datei umwandlet (XLSX, CSV,...). Die erzeugte Datei kann dann auf Front-/Backend abgelegt oder per Mail versendet werden. Dateiausgabe entsprechend über SelScreen wählbar bzw. Mailparamter (Sender, Empfänger, Betreff, Mailtext) via SelScreen vorbelegbar.

Einmal programmiert hat man so für viele existierende Programme einen universellen Extractor. Selbst Querries kann man so einfach per Job in Dateien umleiten.

Folgende Benutzer bedankten sich beim Autor JHM für den Beitrag:
wreichelt

Gruß Hendrik

Re: Ideensammlung für Apps/Reports

Beitrag von DeathAndPain (Top Expert / 1933 / 252 / 410 ) »
Ich habe zwei Frameworks gebaut, die sich sehr bewährt haben:
  • 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.

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
whaslbeck


Re: Ideensammlung für Apps/Reports

Beitrag von ewx (Top Expert / 4842 / 310 / 638 ) »
Das Reminder-Framework hört sich interessant an! Gute Idee 👍

Re: Ideensammlung für Apps/Reports

Beitrag von ewx (Top Expert / 4842 / 310 / 638 ) »
Ich sammle meine seit kurzem hier (Achtung Werbung 😉 ):
https://www.appknight.de/

Re: Ideensammlung für Apps/Reports

Beitrag von IHe (Specialist / 150 / 35 / 49 ) »
Spannendes Thema, viele eigene Themen und Anforderungen findet man hier wieder.

Eine Mail-Reminderfunktion bzw. eher eine Mail-Alert-Funktion habe ich momentan noch jeweils produktspezifisch umgesetzt mit gekapselter Kernfunktionalität im Framework. Die Funktion wird allerdings auch nicht von uns selbst und nicht massenhaft genutzt, sondern vom Produktanwender einmalig im jeweiligen Produktkontext.

Ein Transport-von-Kopien-Werkzeug haben wir ebenfalls, sehr hilfreich bei der Entwicklung in Kundensystemen. Bei der Entwicklung in eigenen Systemen haben wir eine Jira-SAP-Integration entwickelt, welche Transporte anlegt und u.a. bei Statuswechsel diese freigibt und in die Folgesysteme importiert.

Dazu gibt es noch einen SAP-internen Transport-Statusmonitor, in welchem man die Transporte nach Produkt und Status differenziert aufgelistet bekommt inkl. Jira-Vorwärtsnavigation, Anpassung, Freigabe und Zurücksetzen von Transporten, Dokumentation, etc.

Andere kleine Reports sind z.B.:
- Erzeugung von Löschtransporten
- Originalsystem von Objekten in Paketen ändern
- Application-Log-Framework/Klasseninterface
- Massen-RFC-Checks / Monitoring
Ingo Hoffmann

ECC|S/4HANA|BTP
dbh SAP Solutions

Seite 1 von 1

Vergleichbare Themen

7
Antw.
4462
Views
Reports zum Löschen unbenötigter Reports
von Tunoto » 28.02.2006 16:45 • Verfasst in ABAP® für Anfänger
14
Antw.
1843
Views
Fiori Apps verändern
von Bright4.5 » 04.05.2023 12:27 • Verfasst in ABAP® für Anfänger
0
Antw.
856
Views
manifest.json bei Fiori Apps
von Bright4.5 » 05.06.2023 16:14 • Verfasst in ABAP® für Anfänger
0
Antw.
986
Views
ABAP RAP Apps auf Fiori Launchpad
von retsch » 18.05.2023 06:06 • Verfasst in ABAP® für Anfänger
4
Antw.
2501
Views
Welche Möglichkeiten Apps Offline zu gestalten?
von tekko » 09.09.2020 12:08 • Verfasst in Fiori, UI5, JavaScript

Über diesen Beitrag



Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Unbeantwortete Forenbeiträge

aRFC im OO-Kontext
vor 4 Wochen von ralf.wenzel 1 / 1515
Hilfe bei SWEC/SWE2
letzen Monat von retsch 1 / 8128