Ich arbeite seit über 18 Jahren mit Oracle EBS und habe die vollständige Entwicklung von 11i bis R12 miterlebt. Während dieser langen Karriere war die Entwicklung kundenspezifischer Berichte schon immer eine zentrale und unvermeidbare Aufgabe. Im Zusammenhang mit dieser Arbeit tauchen bestimmte Probleme Jahr für Jahr wieder auf, ohne jemals grundlegend gelöst worden zu sein.
Ich arbeite seit über 18 Jahren mit Oracle EBS und habe die vollständige Entwicklung von 11i bis R12 miterlebt. Während dieser langen Karriere war die Entwicklung kundenspezifischer Berichte schon immer eine zentrale und unvermeidbare Aufgabe. Im Zusammenhang mit dieser Arbeit tauchen bestimmte Probleme Jahr für Jahr wieder auf, ohne jemals grundlegend gelöst worden zu sein.
Dieser Artikel soll keine Geschichte erzählen. Er dokumentiert lediglich die Probleme, die ich im Laufe der Jahre beobachtet und erlebt habe, sowie die Versuche, die ich zu ihrer Lösung unternommen habe. Ich hoffe, dass er als Referenz für Kollegen dienen kann, die vor ähnlichen Herausforderungen stehen.
Im EBS-Ökosystem gibt es einen festgelegten Ablauf zwischen dem Abschluss der SQL-Erstellung und dem Zeitpunkt, an dem ein Bericht von Endbenutzern ausgeführt werden kann. Dieser Prozess ist im Rahmen des EBS-Designs sinnvoll und notwendig – er gewährleistet Sicherheit, Multi-Organization-Isolation, Parametervalidierung und Anfragenplanung. Aus Sicht der Entwicklungseffizienz sind seine Kosten jedoch tatsächlich hoch.
Konkret müssen Entwickler nach Abschluss der SQL-Erstellung und -Tests nacheinander die folgenden Operationen durchführen:
Diese Schritte beinhalten keine komplexe Geschäftslogik – sie sind reine Konfigurationsaufgaben. Aber für einen einfachen, möglicherweise einmaligen Ad-hoc-Bericht sind die Anlaufkosten dieses Prozesses übermäßig hoch. Ein Bericht, dessen SQL-Erstellung nur 20 Minuten dauert, erfordert oft über eine Stunde für den gesamten Prozess, wobei die meiste Zeit durch Menü-Navigation, Feldausfüllen und Warten auf Seitenantworten verbraucht wird.
Noch kritischer: Wenn der Bericht nach Tests Anpassungen der SQL-Logik oder Parameterdefinitionen erfordert, muss ein erheblicher Teil der oben genannten Schritte wiederholt werden. Dies stellt ein erhebliches Effizienzproblem für Entwicklungsszenarien dar, die schnelle Iterationen erfordern.
Dies ist aus meiner Sicht das Kernproblem, das die Benutzererfahrung am stärksten beeinträchtigt.
Das native Ausgabeformat von EBS Concurrent Programs ist eine Textdatei (typischerweise .out oder .txt). Ob es sich um einen mit Report Builder entwickelten .rdf-Bericht oder die Ausgabe einer PL/SQL-gespeicherten Prozedur handelt, was den Benutzern letztendlich geliefert wird, ist im Wesentlichen ein Text mit fester Breite oder durch Trennzeichen getrennt.
Was Geschäftsanwender jedoch in ihrer täglichen Arbeit benötigen, ist fast ausnahmslos das Excel-Datenformat. Dies schafft einen seit langem bestehenden "Zwischenschritt": Benutzer müssen den Inhalt der Textdatei in Excel kopieren und einfügen und dann die Funktion "Text in Spalten" verwenden, um ihn in mehrere Spalten aufzuteilen.
Dieser Schritt beinhaltet mehrere spezifische technische Probleme:
Erstens, Feldbreitenprobleme. Berichtsentwickler müssen für jedes Ausgabefeld eine Anzeigebreite vorgeben. Überschreitet die tatsächliche Datenlänge eines Feldes diese vorgegebene Breite (z.B. bei Freitextfeldern wie Artikelbeschreibungen oder Lieferantennamen), behandelt EBS dies durch automatischen Zeilenumbruch, indem es ein Zeilenumbruchzeichen in die Textdatei einfügt. Dieser Zeilenumbruch erscheint in einem Textbetrachter normal – der Inhalt wird einfach in einer neuen Zeile angezeigt. Wenn Benutzer jedoch den gesamten Text in Excel kopieren und die Text-in-Spalten-Funktion ausführen, erkennt Excel diesen Zeilenumbruch als Zeilenabschlusszeichen, wodurch ein einzelner Datensatz fälschlicherweise in zwei oder mehr Zeilen aufgeteilt wird. Die Spaltenausrichtung aller nachfolgenden Datensätze wird dadurch vollständig zerstört. Benutzer müssen diese Fehler manuell lokalisieren und beheben oder die Feldbreiten des Berichts anpassen und die Anfrage erneut einreichen.
Zweitens, Zeichenkodierungsprobleme. Das Standardkodierungsformat der Textdatei stimmt oft nicht mit der Standardkodierung von Excel zum Öffnen von Dateien überein. Dies ist besonders problematisch bei der Verarbeitung von Mehrbyte-Zeichen wie Chinesisch oder Japanisch, was häufig zu verstümmeltem Text führt. Benutzer müssen beim Öffnen der Textdatei manuell die richtige Kodierung auswählen oder beim Excel-Import das Kodierungsformat angeben. Für nicht-technische Geschäftsanwender ist dies eine zusätzliche und unnötige Belastung.
Drittens, die Behandlung von Zahlen- und Datumsformaten. In Textdateien exportierte Zahlen und Daten liegen normalerweise im Klartextformat vor. Nach dem Einfügen in Excel müssen Benutzer manuell Zellenformate festlegen, bevor sie Berechnungen wie Summen oder Durchschnitte durchführen können. Wenn Tausendertrennzeichen, Dezimalgenauigkeit oder Datumsanzeigeformate involviert sind, sind zusätzliche manuelle Anpassungsschritte erforderlich.
Viertens, die Verarbeitungseffizienz bei großen Datenmengen. Wenn ein Bericht große Datenmengen zurückgibt (z.B. über 10.000 Zeilen), wird die Kopieren-Einfügen-plus-manuelle-Spaltenaufteilung selbst sehr zeitaufwändig. Darüber hinaus ist die Leistung von Excel beim Einfügen großer Textmengen nicht immer stabil, was häufig zu Verzögerungen oder fehlender Reaktionsfähigkeit führt.
Diese Probleme treten sowohl bei EBS-Standardberichten als auch bei kundenspezifischen Berichten häufig auf. Streng genommen ist dies kein "Bug" – es ist eine Designentscheidung aus der Zeit, in der EBS entwickelt wurde, als Textausgabe die vorherrschende Methode für den plattformübergreifenden Datenaustausch war. Aber in der heutigen Geschäftsumgebung ist diese Designentscheidung von den tatsächlichen Nutzungsszenarien der Benutzer gravierend entkoppelt.
Fachabteilungen generieren in ihrem täglichen Betrieb häufig nicht-periodische Datenanalyseanforderungen. Zum Beispiel:
Die Merkmale solcher Anforderungen sind: relativ klare SQL-Logik, begrenzter Datenumfang, hohe Anforderungen an die Aktualität und eine hohe Wahrscheinlichkeit, nur einmal verwendet zu werden.
Unter dem Standardentwicklungspfad von EBS muss selbst ein einmaliger Ad-hoc-Bericht den vollständigen Registrierungsprozess von der Definition einer ausführbaren Datei bis zur Einbindung in eine Anforderungsgruppe durchlaufen. Dies bedeutet, dass Entwickler bei jeder Reaktion auf solche Ad-hoc-Anforderungen konfigurative Aufgaben wiederholen müssen, die nichts mit der Geschäftslogik zu tun haben.
Ein weiterer häufiger Workaround besteht darin, dass Entwickler SQL direkt in Datenbanktools (wie PL/SQL Developer oder Toad) ausführen, die Ergebnisse kopieren und sie den Benutzern in Excel senden. Dieser Ansatz umgeht den EBS-Registrierungsprozess und ist erheblich schneller, aber er umgeht auch die Multi-Organization Access Control und die Datenberechtigungsprüfung von EBS, was potenzielle Datensicherheitsrisiken birgt. Er kann auch nicht den Concurrent Manager für eine einheitliche Planung und Protokollierung nutzen.
Die oben beschriebenen Probleme sind nicht neu. Tatsächlich sind diese Herausforderungen in der EBS-Benutzergemeinschaft und unter Praktikern seit langem ein offenes Geheimnis. Im Laufe der Jahre haben sich die Branchenlösungen jedoch hauptsächlich auf die folgenden Ansätze konzentriert, die alle nur begrenzt wirksam waren:
Keiner dieser Ansätze verändert das EBS-Berichtsentwicklungsmodell grundlegend. Entwickler müssen weiterhin sowohl auf der Ebene der SQL-Erstellung als auch der Systemkonfiguration investieren, und Benutzer müssen weiterhin zusätzliche Zeit für die Datenerfassung und -bereinigung aufwenden.
Basierend auf den oben genannten Problemen habe ich versucht, eine unabhängige Berichtstool-Ebene zu entwickeln, die ich SQLVantage genannt habe. Ihre Positionierung besteht nicht darin, den EBS-Concurrent-Manager zu ersetzen, sondern als komplementäre Schicht für schnelle Reaktionen zu dienen, die folgende Szenarien abdeckt:
Die zentrale Design-Philosophie dieses Tools ist: Die zeitaufwändigsten, aber geschäftslogisch irrelevanten prozeduralen Arbeiten in der EBS-Berichtsentwicklung zu eliminieren, damit sich Entwickler direkt auf die beiden Kernelemente – SQL und Parameterkonfiguration – konzentrieren können.
Der spezifische Ansatz ist wie folgt:
Auf der Entwicklerseite müssen Entwickler nur den Berichtsnamen eingeben, die SQL-Anweisung schreiben und die Abfrageparameter (Parametername, Datentyp, Anzeigebezeichnung, Standardwert) im Tool definieren. Nach dem Speichern ist der Bericht sofort verfügbar. Es ist nicht erforderlich, eine ausführbare Datei zu definieren, ein Concurrent Program zu registrieren, Value Sets zu konfigurieren oder Request Groups zu mounten. Der gesamte Konfigurationsprozess kann innerhalb von 3 bis 5 Minuten abgeschlossen werden.
In Bezug auf die Datensicherheit verwendet das Tool den EBS-Benutzerauthentifizierungsmechanismus wieder, um sicherzustellen, dass nur Benutzer mit den entsprechenden EBS-Verantwortlichkeiten auf Berichte zugreifen und sie ausführen können. Die Multi-Organization Access Control (MOAC)-Logik, die in SQL-Abfragen involviert ist, bleibt in den SQL-Anweisungen selbst erhalten und wird von den Entwicklern gemäß den tatsächlichen Geschäftsanforderungen gesteuert.
In Bezug auf das Ausgabeformat generiert das Tool direkt .xlsx-Excel-Dateien. Jedes Abfrageergebnisfeld entspricht einer Excel-Spalte, und jede Datenzeile entspricht einer Excel-Zeile. Die Feldbreiten werden automatisch an den Inhalt angepasst, und lange Textinhalte verursachen keine Zeilenumbrüche, die die Daten beschädigen würden. Zahlen, Daten und andere Datentypen behalten beim Export ihre ursprünglichen Datentypattribute bei, sodass Benutzer beim Öffnen der Excel-Datei sofort sortieren, filtern und Berechnungen durchführen können.
In Bezug auf die Erweiterbarkeit unterstützt das Tool neben Excel auch die JSON-Ausgabe, was die Integration mit externen Datenplattformen oder BI-Systemen erleichtert.
Nach einer Phase der internen Nutzung hat dieses Tool in folgenden Bereichen tatsächlich Effizienzverbesserungen gebracht:
Gleichzeitig muss ich auch auf die Grenzen dieses Tools hinweisen:
Seit 18 Jahren ist EBS eine Unternehmens-Anwendungsplattform, deren grundlegende architektonische Stabilität und Strenge außer Frage stehen. Aber gerade wegen dieser Stabilität wirken einige Designentscheidungen, die zu ihrer Zeit vernünftig waren, in den heutigen Nutzungsszenarien schwerfällig und langsam.
Die Prozesskosten der Berichtsentwicklung, das textbasierte Ausgabeformat, der Reaktionsweg für Ad-hoc-Anforderungen – diese Probleme sind nicht erst heute entstanden. Es ist nur so, dass in der heutigen Umgebung ihre Kosten deutlicher spürbar geworden sind. Die Geschäftsrhythmen beschleunigen sich, die Anforderungen der Unternehmen an die Datenreaktionsfähigkeit steigen, und die Werkzeuge und Prozesse, die wir verwenden, sind in einer vergangenen Ära stecken geblieben.
SQLVantage ist ein Versuch, den ich auf der Grundlage dieser Probleme unternommen habe. Es ist nicht wirklich eine Innovation, sondern eher eine Vereinfachung und Neuorganisation bestehender Prozesse. Wenn dieser Artikel bei einigen Kollegen Anklang findet oder eine Referenzperspektive für diejenigen bietet, die über ähnliche Probleme nachdenken, hat er seinen Zweck erfüllt.
Ich möchte dies nicht als "Erfolgsgeschichte" verpacken. Es ist einfach jemand, der in bestimmten Arbeitsszenarien wiederholt von bestimmten Problemen geplagt wurde und versucht, diese Probleme auf seine eigene Weise zu verbessern. Wie weit dieser Weg führen kann, muss in der Praxis weiter getestet werden. Aber zumindest ist die Richtung richtig – Entwickler zum SQL selbst zurückkehren zu lassen, Benutzer zu den Daten selbst zurückkehren zu lassen und die unnötigen Dinge dazwischen dem Tool zu überlassen.