Referenzhandbuch: Berichts-Anwendungen

In Semiramis werden Dokumente über den Semiramis Output Manager (SOM) mit Hilfe von Berichten ausgegeben. Es gibt Berichte für die Ausgabe von Belegdokumenten und Berichte für die Ausgabe von Berichtsdokumenten. Die Menge der Parameter, die Art der Datenbeschaffung und das Layout der Ausgabe werden dabei durch Berichts-Dateien definiert. Berichts-Dateien können mit Hilfe con „Crystal Reports“ erfasst und verändert werden.
Mit Semiramis 4 hat der Umfang der Daten und der Berechtigungen, die beim Design von Berichten berücksichtig werden müssen stark zugenommen. Die Möglichkeiten, die durch Multisite, den Suchkontext und virtuelle Tabellen eröffnet werden, können nicht mehr vollständig durch die Daten in den Berichts-Dateien bzw. durch die Metadaten im Entwicklungs- bzw. Systemobjekt „Bericht“ abgedeckt werden. Um diesem Umstand Rechnung zu tragen, wurde die  besondere Verwendung „Berichtsdokument“ für Dialog-Anwendungen eingeführt. Anwendungen mit dieser besonderen Verwendung werden als „Berichts-Anwendungen“ bezeichnet. Berichts-Anwendungen können ein Framework von Klassen verwenden, welches die Realisierung von komplexen Abfragefeldern und den zugehörigen Prüfungen ermöglicht. Dieses Framework liefert insbesondere Unterstützung im Zusammenhang mit der Verwendung von virtuellen Tabellen.

Dadurch, dass Berichts-Anwendungen eigene Anwendungen sind, ergeben sich einige Vorteile gegenüber der Verwendung von Berichten in der Anwendung „Berichtsdokumente ausgeben“:

  • Die Vergabe von Berechtigungen erfolgt ausschließlich auf der Ebene der Anwendung.
  • Die Sichtbarkeit der Anwendung kann auf Basis von Lizenzierung, Customizing, aktiven Datenbanken und den dem Benutzer zugeordneten Organisationen gesteuert werden.
  • Anwendungsbezogene Funktionen wie Oberflächenelement-Berechtigungen funktionieren korrekt.
  • Direkthilfe und Online-Hilfe werden als normale Anwendungs-Dokumentation erstellt.

Aus diesem Grund sind ab Semiramis 4.2 Berichts-Anwendungen der Standardweg, um Berichte nutzbar zu machen.

Dieses Dokument beschreibt, wie Berichts-Anwendungen erstellt werden.

1                     Zielgruppe

  • Entwickler
  • Technische Berater

2                     Begriffsbestimmung

Belegdokumente

Die Ausgabe eines Beleges auf ein Ausgabegerät, wie zum Beispiel einem Drucker, oder in eine Datei erzeugt ein Belegdokument. Das Belegdokument kann archiviert oder zum Beispiel als Fax oder per E-Mail an einen Partner übermittelt werden.

Berichte

Mit einem Bericht lassen sich Daten, die in Semiramis erfasst sind, in übersichtlicher Form ausgeben. Ein Bericht lässt sich beliebig oft und auf Basis der aktuell vorhandenen Daten ausgeben.

Berichte werden in Berichts- und Belegdokumente unterschieden. Berichte vom Dokumenttyp „Berichtsdokument“ können auf Basis von beliebigen Daten aus Semiramis erstellt werden. Sie besitzen im Allgemeinen die Form einer Liste und können in der Anwendung „Berichtsdokumente ausgeben“ ausgegeben werden. Belegdokumente können in den jeweiligen fachlichen Anwendungen, in denen Belege entstehen, ausgegeben werden. Sie beinhalten im Allgemeinen nur die Daten zu einem einzelnen Beleg.

Berichte können als System- oder als Entwicklungsobjekt angelegt werden. Ein Bericht als Entwicklungsobjekt hat den Vorteil, dass er in einem Entwicklungssystem verändert, versionisiert abgelegt und als Softwareaktualisierung in andere Systeme übertragen werden kann. Um Berichte auch in Nicht-Entwicklungssystem erstellen und verändern zu können bietet die Anwendung „Berichte“ die Möglichkeit sie als Systemobjekt anzulegen. Systemobjekte können nicht in andere Systeme transportiert werden.

Berichte enthalten ein oder mehrere Berichts-Dateien, die das Layout eines Berichts bestimmen.

Berichtsdokument

Die Ausgabe eines Berichts auf ein Ausgabegerät, wie einem Drucker, oder in eine Datei erzeugt ein Berichtsdokument oder ein Belegdokument. Das Berichtsdokument enthält eine Liste von Objekten, beispielsweise eine Liste von Adressen. Ein Belegdokument umfasst stets ein Objekt, beispielsweise einen Vertriebsauftrag. Die Dokumente können archiviert oder zum Beispiel als Fax oder per E-Mail an einen Partner übermittelt werden.

3                     Voraussetzungen

Für die Entwicklung von Berichts-Anwendungen wird die Kenntnis zur Erstellung von Berichten mit Crystal Reports vorausgesetzt.

4                     Entwicklung

Dieses Kapitel beschreibt die Entwicklung von neuen Berichts-Anwendungen. Eine Berichts-Anwendung ist eine Dialog-Anwendung mit der besonderen Verwendung „Berichtsdokument“, welche die nachfolgend beschriebenen Schnittstellen verwendet. Die Berichts-Anwendung wird in sechs Schritten erstellt:

  • Entwicklungsobjekt Bericht erfassen
  • Entwicklungsobjekt Java-Klasse erfassen
  • Entwicklungsobjekt Anwendung erfassen
  • Erstellen einer Berichts-Anwendung
  • Berichts-Anwendung testen
  • Berichts-Anwendung dokumentieren

Die einzelnen Schritte werden in den folgenden Kapiteln detailliert beschrieben.

4.1               Entwicklungsobjekt Bericht erfassen

Zu einer Berichts-Anwendung muss mindestens ein Bericht vorhanden sein. Der Bericht für die Berichts-Anwendungen muss in einem „rpt“-Namensraum erstellt werden. Aus dem Bericht soll der Name des Business-Entity enthalten sein. Die Bezeichnung des Berichts ist die Bezeichnung des Business-Entitys in der Mehrzahl. Beispiel:

Business Entity:
Name:          com.cisag.sys.configuration.obj.UserGroup
Bezeichnung: Benutzergruppe

Bericht:
Name:          com.cisag.sys.configuration.rpt.UserGroup
Bezeichnung: Benutzergruppen

Berichte für Berichts-Anwendungen sind vom Dokumenttyp „Anwendungsdokument“. Das Attribut „Anzeige“ muss den Wert „Nein“ enthalten, da die Berichte zu Berichts-Anwendungen nie in der Anwendung „Berichtsdokumente ausgeben“ angezeigt werden.

4.2               Entwicklungsobjekt Java-Klasse erfassen

Für die Berichts-Anwendung wird eine Java-Klasse benötigt. Die Java-Klasse muss in einen Namensraum liegen, der mit „ui“ endet. Sie sollte denselben Namen haben, wie die Anwendung. Die Anwendung sollte den Namen des Berichts, ohne Namensraum, enthalten und endet mit „ReportOutput“. Aus dem Namen soll das Business-Entity erkennbar sein.

4.3               Entwicklungsobjekt Anwendung erfassen

Eine Berichts-Anwendung ist eine Dialog-Anwendung. Die Anwendung muss folglich in einem „ui“-Namenraum erfasst werden. Der Name der Anwendung enthält den Namen des Business-Entitys oder des Berichts, der ausgegeben wird, und endet mit „ReportOutput“. Die Bezeichnung enthält die Bezeichnung des Business-Entities und endet mit „ausgeben“. Beispiel (Beschaffungs-Artikel):

Bericht:
Name:          com.cisag.app.purchasing.rpt.PurchaseItem
Bezeichnung: Beschaffungs-Artikel

Anwendung: (hier mit leicht abweichendem Namensraum)
Name:          com.cisag.app.general.item.ui.PurchaseItemReportOutput
Bezeichnung: Beschaffungs-Artikel ausgeben

Berichtsanwendungen sind vom Typ „Dialog“ mit der „Besonderen Verwendung“ „Berichtsdokument“. Die „Anzeige- und Wartungseinstellung“ muss auf „Anzeige, Wartung“ gestellt sein, damit die Berichts-Anwendung im Navigator sichtbar ist. Der „Berechtigungsmodus“ sollte auf „Prüfung durchführen“ eingestellt werden. Es muss die „benötigte aktive Datenbank“ korrekt eingestellt werden. Dies ist i.A. die OLTP-Datenbank. Für Berichte, die Business Objects auf der OLAP-Datenbank verwenden ist zusätzlich die OLAP-Datenbank eine benötigte aktive Datenbank.

4.4               Erstellen einer Berichts-Anwendung

Beim Erstellen einer Berichts-Anwendung gibt es verschiedene Szenarien. Im einfachen Fall kann der Bericht zuerst und anschließend die Berichts-Anwendung erstellt werden. In den komplexeren Szenarien müssen der Bericht, die Anwendung und eine virtuelle Tabelle parallel erstellt werden. Es auch möglich, dass dieselbe Berichts-Anwendung, abhängig von den Abfrageparametern oder dem Customizing eine bestimmten Bericht automatisch auswählt. Alle Berichte, die durch die Berichts-Anwendung ausgegeben werden können, müssen dieselben Berichtsparameter besitzen. Ein Beispiel hierfür ist die Anwendung „Änderungsjournal ausgeben“.

Die Schnittstelle, die für eine Berichts-Anwendung zur Verfügung steht, befindet sich im Namensraum „com.cisag.pgm.services.output“. Die wichtigste Klasse ist „ReportOutputApplication“. Alle Berichts-Anwendungen müssen Unterklassen der Java-Klasse „ReportOutputApplication“ sein. Die Java-Klassen der Schnittstelle sind:

  • Java-Klasse „ReportOutputApplication“
    Basisklasse für alle Berichts-Anwendungen.
  • Java-Klasse „ReportOutputData“
    Datencontainer für die Parameterwerte.
  • Java-Klasse „ReportOutputParameterData“
    Hilfsstruktur zum Erzeugen der Abfragefelder für die Berichtsparameter.

4.4.1          Java-Klasse „ReportOutputParameterData“

Die Klasse „ReportOutputParameterData“ enthält Metadaten für einen Berichtsparameter, d.h. die Daten die im Bericht bzw. der Berichts-Datei für die Parameter erfasst sind. Die Klasse ist nicht final, darf aber nicht beerbt werden. In den meisten Fällen wird zu einem Berichtsparameter genau ein Abfragefeld in der Berichts-Anwendung erzeugt. Sie wird in weiter unten beschriebenen der Methode „createParameterField(ReportOutputParameterData parameterData)“ verwendet.

Methode „createParameterData(String name,String fieldGuid,String fieldPath,boolean selectionMode)“

Erzeugt eine neue Instanz der Parameterdaten. Mit dieser Instanz kann in der „ReportOutputApplication“ ein GUI-Feld erzeugt werden. Sie benötigen diese Methode nicht direkt, sie wird nur von der Basisklasse „ReportOutputApplication“ verwendet.

Methode „getName()“

Liefert den Namen des Berichtsparameters, für den das GUI-Feld erzeugt werden soll.

Methode „getFieldGuid()“

Liefert die GUID, mit der das GUI-Feld erzeugt werden soll.

Methode „getFieldPath()“

Liefert den Pfad zur Data-Description des logischen Datentypen, mit dem das GUI-Feld erzeugt werden soll. Bei automatisch erzeugten GUI-Feldern bestimmt der logische Datentyp zusammen mit dem Selektionsmodus, was für ein GUI-Feld erzeugt wird.

Methode „isSelectionMode()“

Bestimmt, ob das GUI-Feld im Selektionsmodus erstellt wird, oder nicht.

4.4.2          Java-Klasse „ReportOutputData“

Die Klasse „ReportOutputApplication“ ist ein Datencontainer mit den Parameterwerten für die Ausgabe des Berichts. Der Datencontainer wird von der Klasse „ReportOutputApplication“ korrekt initialisiert, wenn bei der Initialisierung ein Bericht über den Aufruf der Methode „initReport(String reportName)“ erfolgreich gesetzt wird. Für jeden Berichtsparameter muss der Pfad zu einer Data-Description für einen logischen Datentyp registriert und der Wert initialisiert werden. Mit den folgenden Methoden können die Pfade der Data-Descriptions der Parameter definiert bzw. abgefragt werden:

Methode „setPath(String parameterName,String absPath)“

Weist den Pfad zur Data-Description für einen Parameter zu. Anschließend muss noch ein Wert gesetzt werden, bevor der Parameter verwendet werden kann.

Methode „getPath(String parameterName)“

Liefert den Pfad zur Data-Description des logischen Datentypen, der dem Parameter zugeordnet ist.

Der Datencontainer hat Methoden, um die, von Berichten, unterstützen Datentypen zu setzen und abzufragen. Dabei wird zwischen einem konkreten Wert und einer Auswahl („…Selection“) unterschieden. Parameter für virtuelle Tabellen müssen in vielen Fällen in einem neutralen Format, d.h. unverändert und ohne Prüfungen durch Crystal Reports, durch den Bericht an den ODBC-Treiber und die virtuelle Tabelle übergeben werden. Diese Berichtsparameter müssen von Typ „String“ sein. An der Klasse „ReportOutputData“ gibt es zudem spezielle „get…FromString“ bzw. „set…AsString“ Methoden.

4.4.3          Java-Klasse „ReportOutputApplication“

Die Java-Klasse „ReportOutputApplication“ ist die Basisklasse für alle Berichts-Anwendungen. Sie ermöglicht es, unterschiedliche Stufen der Komplexität beim Design von Berichts-Anwendungen umzusetzen. Im einfachsten Fall verhält sich die Berichts-Anwendung wie die Anwendung „Berichtsdokumente ausgeben“. Das Aussehen und das Verhalten der Anwendung sind vollständig durch den Bericht definiert und kann durch Verändern des Berichts verändert werden. Durch das Verwenden von Vorschlagswerten, das Einführen von Prüfungen für die Berichtsparameter und neuen GUI-Feldern, bis hin zum Einführen von Anwendungsparametern, die die Berichts-Anwendung in das Kontextmenü von Business Entitys einbinden, kann der Funktionsumfang der Berichts-Anwendung schrittweise an die, im Styleguide beschriebenen Anforderungen an einer normale Dialog-Anwendung, angepasst werden.

Dabei ist jeweils abzuwägen, welche Anpassungen an der Berichts-Datei die Berichts-Anwendung noch automatisch erkennen und behandeln können soll. Der Aufwand, für neuen Anforderungen eine zweite Bericht-Anwendung mit einen neuen Bericht zu erstellen ist im allgemeinen geringer, als der Aufwand die Bericht-Anwendung auf alle Eventualitäten einer Anpassung in der Berichts-Datei (z.B. neue Parameter, gelöschte Parameter, geänderte Datentypen) anzupassen. Wenn die Anwendung Anpassungen an den Berichtsparametern erlaubt, sollte dies explizit in der Dokumentation zur Anwendung aufgeführt werden.

Einfache Berichts-Anwendungen

In diesem Abschnitt werden sechs Beispiele für das Erstellen einer Berichts-Anwendung beschrieben:

  • Einfache Berichts-Anwendung
  • Vorschlagswerte für Berichtsparameter setzen
  • Zusätzliche Prüfungen für Berichtsparameter
  • Berichts-Anwendung mit eigenen GUI-Feldern
  • Berichtsparameter als Anwendungsparameter
  • Dynamische Bestimmung des Berichts

Die Beispiele können auch miteinander kombiniert werden. Die Namen von Konstanten sind in den Beispielen in der Form “Number” angegeben. In echten Berichts-Anwendungen sollten für die Namen von Anwendungs- bzw. die Berichtsparameter Konstanten deklariert werden. Den Beispielen folgt die Auflistung der Methoden.

Komplexe Berichts-Anwendungen

Die aufgeführten Beispiele verwenden den Datencontainer „ReportOutputData“ direkt für die Speicherung der Werte aus den Abfragefeldern. Dies ist für die meisten einfachen Fälle ausreichend. Allerdings ist der Datencontainer „ReportOutputData“ auf die direkte Übergabe von Werten an den Bericht bzw. an virtuelle Tabellen ausgelegt und verwendet im Allgemeinen String für die Repräsentation der Werte. In komplexeren Fällen ist es sinnvoll, in der Berichts-Anwendung eigene Datencontainer zu verwenden um mit ihrer Hilfe die Methoden „dataFromUi()“, „dataToUi()“ und die Prüfungen der Eingaben, z.B. der GUIDs von Fremdschlüsseln und inhaltsbezogene Berechtigungen, zu realisieren. In diesem Fällen findet das Berechnen des Berichts sowie das Initialisieren und Füllen des Datencontainers „ReportOutputData“ erst unmittelbar vor der eigentlichen Ausgabe statt, nachdem die Prüfungen auf dem spezifischen Datencontainer erfolgreich waren. Ein Beispiel für diese Art von Berichts-Anwendung ist die Anwendung „Änderungsjournal ausgeben“ („com.cisag.app.system.modificationjournal.ui.ModificationJournalReportOutput“).

In diesem Dokument ebenfalls nicht ausgeführt sind die allgemeinen Möglichkeiten, die Sichtbarkeit der Berichts-Anwendungen durch Funktionen, Customizing oder die Organisations-Zuordnungen zu beschränken. Hier können für Berichts-Anwendung die gleichen Möglichkeiten genutzt werden, wie für alle anderen Dialog-Anwendungen, z.B. die Angabe, welchen internen bzw. externen Organisationstypen der Benutzer zugeordnet sein muss, um die Anwendung öffnen zu können.

4.4.3.1      Einfache Berichts-Anwendung

Die einfache Berichts-Anwendung zeichnet sich dadurch aus, dass nur der Bericht zugeordnet werden muss:

  • Methode „initModel()“
    Es muss der Bericht durch Aufruf der Methode „initReport(String reportName)“ zugeordnet werden. Beispiel:
    protected void initModel() {
    initReport(“com.cisag.app.purchasing.rpt.PurchaseItem”);
    }

4.4.3.2      Vorschlagswerte für Berichtsparameter setzen

Eine Berichts-Anwendung, die die Vorschlagswerte kontextabhängig füllt, muss folgende Methoden implementieren:

  • Methode „initModel()“
    Es muss der Bericht durch Aufruf der Methode „initReport(String reportName)“ zugeordnet werden.
  • Methode „applyDefaults()“
    In „ReportOuputData“ werden die Vorschlagswerte für die Berichtsparameter gesetzt. Beispiel:
    protected void applyDefaults(){
    getReportOutputData().setStringSelection(“Number”, “A*”);
    }

4.4.3.3      Zusätzliche Prüfungen für Berichtsparameter

  • Methode „initModel()“
    Es muss der Bericht durch Aufruf der Methode „initReport(String reportName)“ zugeordnet werden.
  • Methode „initUserInterface()“
    Nach Aufruf von „initUserInterface()“ müssen die „MessageIds“ an den GUI-Feldern registriert werden. Beispiel:
    protected void initUserInterface() {
    super.initUserInterface();
    itemField.registerMessage(1);
    }
  • Methode „createParameterField(ReportOutputParameterData parameterData)“
    Das GUI-Feld wird durch Aufruf von „createParameterField(parameterData)“ erzeugt. Wenn es ein GUI-Feld ist, für das eine zusätzliche Prüfung erfolgen soll, so wird das GUI-Feld einer Variablen zugeordnet. Beispiel:
    protected Field createParameterField(ReportOutputParameterData parameterData) {
    Field result = super.createParameterField(parameterData);
    if (parameterData.getName().equals(“Number”)){
    itemField = result;
    }
    return result;
    }
  • Methode „validateReportParameters()“
    Die zusätzlichen Prüfungen werden in dieser Methode erstellt. Beispiel:
    protected boolean validateReportParameters() {
    boolean result = true;
    ReportOutputData data = getReportOutputData();
    if (!data.getStringSelection(“Number”).startsWith(“A”)) {
    result = false;
    setProgramMessageId(1);
    mm.sendMessage…
    }
    return result;
    }

4.4.3.4      Berichts-Anwendung mit eigenen GUI-Feldern

Wenn ein anderes GUI-Feld als das GUI-Feld der Standardimplementierung verwendet werden soll, so müssen folgende Methoden implementiert werden:

  • Methode „initModel()“
    Es muss der Bericht durch Aufruf der Methode „initReport(String reportName)“ zugeordnet werden.
  • Methode „applyDefaults()“
    In „ReportOuputData“ werden die Vorschlagswerte für die Berichtsparameter gesetzt. Beispiel:
    protected void applyDefaults(){
    getReportOutputData().setStringSelection(“Number”, “A*”);
    }
  • Methode „createParameterField(ReportOutputParameterData parameterData)“
    Für das Business-Entity wird ein eigenes GUI-Feld erzeugt. Das selbst erzeugte Feld wird einer Variablen zugeordnet. Alle anderen GUI-Felder werden durch Aufruf von „createParameterField(parameterData)“ erzeugt. Beispiel:
    protected Field createParameterField(ReportOutputParameterData parameterData) {
    Field result =null;
    if (parameterData.getName().equals(“Number”)){
    itemField = new ItemField( parameterData.getFieldGuid(), parameterData.getFieldPath() );
    itemField.setSelectionMode(parameterData.isSelectionMode());
    }
    else {
    result = super.createParameterField(parameterData);
    }
    return result;
    }
  • Methode „dataFromUi()“
    Der Wert der GUI-Felder muss in den Datencontainer kopiert werden.
  • Methode „dataToUi()“
    Der Wert aus dem Datencontainer muss in die GUI-Felder kopiert werden.

4.4.3.5      Berichtsparameter als Anwendungsparameter

Um Anwendungsparameter zu unterstützen, müssen im Entwicklungsobjekt die Anwendungsparameter erfasst und typisiert werden. Die GUI-Felder müssen mit dem Namen des Anwendungsparameters an der „SelectionGroup“ registriert werden. Da die GUI-Felder standardmäßig schon unter dem Namen des Berichtsparameters registriert sind, müssen die GUI-Felder erst entfernt und dann mit dem neuen Namen registriert werden. Dieses Beispiel erweitert das Beispiel Berichts-Anwendung mit eigenen GUI-Feldern und benötigt deshalb nur eine weitere Methode:

  • Methode „prepareParameterFields()“
    protected void prepareParameterFields() {
    getSelectionGroup().remove(“Number”);
    getSelectionGroup().add(“PurchaseItem”, itemField);
    }

4.4.3.6      Dynamische Bestimmung des Berichts

Dieses Beispiel beschreibt, wie eine Berichts-Anwendung erstellt werden muss, die erst anhand der Benutzereingaben den Bericht bestimmt. Alle verwendeten Berichte haben dabei dieselben Parameter.

  • Methode „initModel()“
    Am „ReportOuputData“ müssen die Parameter durch Aufruf der Methode „setPath(String parameterName,String absPath)“ definiert werden. Alternativ kann ein ausgezeichneter Bericht als Repräsentant über den Aufruf der Methode „initReport(String reportName)“ gesetzt werden.
  • Methode „applyDefaults()“
    Zuweisen der Vorschlagswerte.
  • Methode „dataFromUi()“
    Der Wert des GUI-Feldes muss in den Datencontainer kopiert werden.
  • Methode „dataToUi()“
    Der Wert aus dem Datencontainer muss ins GUI-Feld kopiert werden.
  • Methode „validateReportParameters()“
    Der tatsächlich auszuführende Bericht ist zu setzen. Zusätzlich müssen die Beziehungen zwischen den GUI-Feldern und dem Berichtsparameter definiert werden. Dafür stehen die Methode „initReport(String reportName)“ und die Methode „registerFieldMessages(String reportParameterName, VisualElement element)“ zur Verfügung.

4.4.3.7      Methoden der Java-Klasse „ReportOutputApplication“

Es folgt eine alphabetische Auflistung der Methoden und ihrer Bedeutung.

Methode „applyDefaults()“

Dient der Initialisierung der Parameterwerte. Die Werte müssen in den Datencontainer und nicht in die GUI-Felder gesetzt werden. Der Standard-Datencontainer ist mit der Methode „getReportOutputData()“ abfragbar. Wenn ein eigener Datencontainer verwendet wird, so sind die Werte in diesem zu setzen und in der Methode „validateReportParameters()“ in den Standard-Datencontainer zu kopieren.

Methode „createParameterField(ReportOutputParameterData parameterData)“

Wird von der Methode „initUserInterface()“ aufgerufen, um die GUI-Felder zu erzeugen. Wenn für einen Parameter ein anderes GUI-Feld erzeugt werden soll, so kann diese Methode überschrieben werden. Für alle GUI-Felder, die durch die Standardimplementierung erzeugt werden, wird der Datencontainer initialisiert. Zum Erzeugen der GUI-Felder kann die GUID, die Data-Description des logischen Datentyps und der Schalter für den Selektionsmodus aus dem „ReportOutputParameterData“ berücksichtigt werden, damit sich die Anwendung bei Anpassungen am Bericht automatisch anpasst. Wenn eigene GUI-Felder instanziiert werden, sollte diese statische GUIDs im Java-Source erhalten, da diese bei Anpassungen am Bericht dann gleich bleiben und so beispielsweise bereits erfasste Oberflächenelement-Berichtigungen weiterhin funktionieren. Ein GUI-Feld ist ein Pflichtfeld, wenn der Berichtsparameter ein Pflichtparameter ist oder das GUI-Feld als Pflichtfeld gekennzeichnet ist.

Methode „createReportTitleField()“

Wenn die Standardmechanismen zur Erzeugung der GUI-Felder nicht verwendet wird, kann mit dieser Methode das GUI-Feld für den Titel erzeugt werden. Das GUI-Feld wird automatisch initialisiert.

Methode „dataFromUi()“

Dient dazu, die Benutzereingaben aus den GUI-Feldern in den Datencontainer zu kopieren.

Methode „dataToUi()“

Setzt die Werte aus dem Datencontainer in die GUI-Felder.

Methode „getReportOutputData()“

Zugriffmethode auf den Datencontainer, der die Berichtsparameter und ihre Werte enthält.

Methode „getReportParametersView()“

Zugriffsmethode auf den „View“, in dem alle GUI-Felder hinzugefügt werden. Der „View“ hat ein einspaltiges „StandardLayout“.

Methode „initModel()“

Bei der Initialisierung der Anwendung kann durch überschreiben dieser Methode der Bericht gesetzt werden. Wenn durch Aufruf der Methode „initReport(String reportName)“ ein Bericht gesetzt wird, werden in der Methode „initUserInterface()“ die GUI-Felder automatisch erzeugt.

Methode „initReport(String reportName)“

Durch Aufruf dieser Methode wird der Bericht für die Ausführung zugewiesen. Es gibt zwei Zeitpunkte, an denen der Bericht zugewiesen werden kann. Der erste Zeitpunkt ist die Initialisierung der Anwendung und kann durch überschreiben der Methode „initModel()“ beeinflusst werden. Spätestens nach dem erfolgreichen Überprüfen der Werte in der Methode „validateReportParameters()“ muss der Bericht zugewiesen werden und anschließend die Werte im Datencontainer „ReportOutputData“ gesetzt werden.

Hinweis: Beachten Sie, dass anstatt des übergebenen Berichts zur Laufzeit ein angepasster Bericht vom Berichtstyp „Systemobjekt“ verwendet wird, wenn er existiert. Welcher Bericht tatsächlich geöffnet wurde, wird von der Methode „initReport(String)“ als Informationsmeldung zurückgeliefert.

Hinweis: Beachten Sie, dass die Methode „initReport(String)“ auch Fehlermeldungen liefern kann, z.B. falls der Bericht nicht existiert oder fehlerhaft ist. In diesem Fall muss gegebenenfalls in der Berichts-Anwendung reagiert werden, um Folgefehler und Exceptions zu vermeiden.

Methode „initUserInterface()“

Diese Methode wird aufgerufen, um die grafische Benutzer Oberfläche zu erzeugen. Die Standardimplementierung erzeugt die GUI-Felder für alle Parameter des Berichts, der in der Methode „initModel()“ zugewiesen wurde. Die GUI-Felder werden in der Reihenfolge der Berichtsparameter erzeugt. Das Erzeugen findet in drei Schritten statt. Als erstes werden alle GUI-Felder durch Aufruf der Methode „createParameterField(ReportOutputParameterData parameterData)“ erstellt. Alle erstellten GUI-Felder werden der „SelectionGroup“ der Anwendung, unter dem Namen des Berichtsparameters, hinzugefügt. Zusätzlich wird für jedes GUI-Feld die Methode „registerFieldMessages(String reportParameterName, VisualElement element)“ aufgerufen. Als zweites wird die Methode „prepareParameterFields()“ aufgerufen, um die GUI-Felder zu initialisieren. Dann werden die GUI-Felder dem „View“ hinzugefügt.

In diese Methode können auch eigen Aktionen der Standard-Symbolleiste hinzugefügt werden. Die bestehenden Aktionen in der Standard-Symbolleiste dürfen von den Unterklassen nicht verändert werden.

Methode „performActionInternal(Action action)“

Diese Methode wird aufgerufen, wenn die Methode „perfomAction(Action action)“ für eine Aktion aufgerufen wurden, die in der Basisklassen nicht behandelt wird. Dies sind beispielsweise eigene Aktionen in der Standard-Symbolleiste.

Methode „prepareParameterFields()“

Durch Überschreiben dieser Methode können an den GUI-Feldern Initialisierungen vorgenommen werden, die vor dem Hinzufügen der GUI_Felder zu dem „View“ erfolgen. Es können z.B. die GUI-Felder für die Auftragsart und die Auftragsnummer miteinander verknüpft werden. Zusätzlich kann die Registrierung eines GUI-Feldes an der „SelectionGroup“ verändert werden.

Methode „registerFieldMessages(String reportParameterName, VisualElement element)“

In dieser Methode wird ein Berichtsparameter mit einem GUI-Feld verknüpft. An diesem GUI-Feld werden bei der Validierung der Berichtsparameter in der Methode „validateReportParameters()“ die Fehlermeldungen gehängt. Die von den Prüfungen der Berichtsparameter verwendeten „MessageIds“ der GUI-Felder beginnen ab 4200.

Methode „setReportParameters(CisParameterList pl)“

Diese Methode wird beim Öffnen der Berichts-Anwendung aufgerufen, wenn die Berichts-Anwendung mit Parametern aufgerufen wurde. Durch das Überschreiben diese Methode können beispielsweise die Werte aus der Parameterliste in die spezifischen GUI-Felder der Anwendung übertragen werden. Nach dem Aufruf von der Methode „setReportParameters()“ wird die Methode „dataFromUi()“ aufgerufen. Die Standardimplementierung setzt die Parameterwerte mit Hilfe der SelectionGroup. Wenn die Methode überschrieben wird, muss sichergestellt werden, dass alle Parameterwerte in die entsprechenden GUI-Felder kopiert werden.

Methode „validateReportParameters()“

In dieser Methode können die Eingaben des Benutzers überprüft werden. Wenn in der Methode „initModel()“ kein Bericht zugewiesen wurde, so muss das in „validateReportParameters()“ erfolgen. Zusätzlich muss festgelegt werden, an welchem GUI-Feld die Fehlermeldungen für die Berichtsparameter angezeigt werden. Die erfolgt durch den Aufruf der Methode „registerFieldMessages(String reportParameterName, VisualElement element)“.

4.5               Berichts-Anwendung testen

Um eine Berichts-Anwendung zu testen kann sie wie jede Dialog-Anwendung aus dem Navigator oder aus der Anwendung „Entwicklungsobjekte“ heraus geöffnet werden. Beachten Sie, dass anstatt des übergebenen Berichts zur Laufzeit ein angepasster Bericht vom Berichtstyp „Systemobjekt“ verwendet wird, wenn er existiert. Welcher Bericht tatsächlich geöffnet wurde, wird von der Methode „initReport(String)“ als Informationsmeldung zurückgeliefert.

4.6               Berichts-Anwendung dokumentieren

Um die Berichts-Anwendung zu dokumentieren, muss ein Entwicklungsobjekt von Typ Hilfe-Objekt erstellt werden. Das Hilfe-Objekt soll denselben Namen haben, wie die Berichts-Anwendung. Die Berichts-Anwendung muss dem Hilfe-Objekt auf dem Karteireiter „Entwicklungsobjekte“ mit der Gewichtung „Standard“ zugeordnet werden.

Czy ten artykuł był pomocny?

Wyślij opnie