Entwickeln von Berichten

AEM bietet eine Auswahl von Standardberichten, von denen die meisten auf einem Berichte-Framework basieren.

Mithilfe des Frameworks können Sie diese Standardberichte erweitern oder Ihre eigenen Berichte entwickeln. Das Framework für die Berichterstellung setzt auf den bestehenden CQ5-Konzepten und -Prinzipien auf, sodass Entwickler ihre vorhandenen CQ5-Kenntnisse als Grundlage für die Entwicklung von Berichten nutzen können.

Für die mit AEM gelieferten Standardberichte:

• Die folgenden Berichte basieren auf dem Framework für die Berichterstellung:

  • Komponentenbericht
  • Seitenaktivitätsbericht
  • Benutzerbericht
  • Bericht der Workflow-Instanz

• Die folgenden Berichte basieren auf speziellen Prinzipien und können daher nicht erweitert werden:

  • Speichernutzung
  • Konsistenzprüfung
  • Workflow-Bericht

Framework für die Berichterstellung

Dem Framework für die Berichterstellung liegen die folgenden Prinzipien zugrunde:

• Es basiert vollständig auf Ergebnissätzen, die von einer vom CQ5-QueryBuilder ausgeführten Abfrage zurückgegeben werden.

• Der Ergebnissatz definiert die im Bericht angezeigten Daten. Jede Zeile des Ergebnissatzes entspricht einer Zeile in der Tabellenansicht des Berichts.

• Die für die Ausführung für den Ergebnissatz zur Verfügung stehenden Vorgänge ähneln RDBMS-Konzepten, allen voran die Gruppierung und Aggregation.

• Der Datenabruf und die Datenverarbeitung erfolgen größtenteils serverseitig.

• Der Client ist allein für die Anzeige der vorverarbeiteten Daten zuständig. Nur kleinere Verarbeitungsaufgaben (z. B. das Erstellen von Links im Zellinhalt) werden clientseitig ausgeführt.

Das Framework für die Berichterstellung (am Beispiel der Struktur eines Standardberichts veranschaulicht) nutzt die folgenden Bausteine, die von der Verarbeitungswarteschlange gespeist werden:

Berichtseite

Die Berichtseite:

• ist eine CQ5-Standardseite.
• basiert auf einer CQ5-Standardvorlage, die für den Bericht konfiguriert wurde.

Die reportbase-Komponente

Die reportbase-Komponente bildet die Grundlage eines jeden Berichts:

• Sie enthält die Definition der Abfrage, die den zugrunde liegenden Ergebnissatz an Daten liefert.

• Sie ist ein angepasstes Absatzsystem, das alle Spalten (columnbase) enthält, die dem Bericht hinzugefügt werden.

• Sie legt fest, welche Diagrammtypen zur Verfügung stehen und welche gerade aktiv sind.

• Sie definiert das Dialogfeld für die Bearbeitung, über das die Benutzer bestimmte Aspekte des Berichts konfigurieren können.

Die columnbase-Komponente

Jede Spalte ist eine Instanz der columnbase-Komponente:

• Sie ist ein Absatz, der vom Absatzsystem (reportbase) des entsprechenden Berichts verwendet wird.
• Sie definiert den Link zum zugrunde liegenden Ergebnissatz, d. h. sie definiert die spezifischen Daten, auf die im Ergebnissatz verwiesen wird, und wie diese verarbeitet werden.
• Sie enthält neben jeglichen Standardwerten zusätzliche Definitionen, beispielsweise die verfügbaren Aggregate und Filter.

Die Abfrage und der Datenabruf

Die Abfrage:

• ist als Teil der reportbase-Komponente definiert.

• basiert auf dem QueryBuilder von CQ.

• ruft die Daten ab, die als Grundlage für den Bericht dienen. Jede Zeile des Ergebnissatzes (Tabelle) ist an einen Knoten gebunden, der von der Abfrage zurückgegeben wird. Aus diesem Datensatz werden dann spezifische Informationen für einzelne Spalten extrahiert.

• besteht meist aus:

  • einem Stammpfad.

    Dieser gibt die Unterbaumstruktur des zu durchsuchenden Repositorys an.

    Um eine Beeinträchtigung der Leistung zu vermeiden, empfiehlt es sich, die Abfrage wenn möglich auf eine bestimmte Unterbaumstruktur des Repositorys zu beschränken. Der Stammpfad kann entweder in der Berichtsvorlage vordefiniert oder vom Benutzer im Konfigurationsdialogfeld („Bearbeiten“) vordefiniert werden.

  • einem Kriterium oder mehreren Kriterien.

    Diese werden angewendet, um den (anfänglichen) Ergebnissatz zu generieren. Sie umfassen u. a. Einschränkungen hinsichtlich des Knotentyps oder Eigenschaftsbeschränkungen.

Entscheidend hierbei ist, dass jeder einzelne im Ergebnissatz der Abfrage zurückgegebene Knoten verwendet wird, um eine einzelne Zeile im Bericht zu generieren (also eine 1:1-Beziehung).

Der Entwickler muss sicherstellen, dass die für einen Bericht definierte Abfrage eine für diesen Bericht geeignete Knotengruppe zurückgibt. Der Knoten selbst muss jedoch nicht alle erforderlichen Informationen enthalten, diese können auch von über- und/oder untergeordneten Knoten abgeleitet werden. Beispielsweise wählt die für den Benutzerbericht verwendete Abfrage Knoten auf Basis des Knotentyps aus (in diesem Fall rep:user). Die meisten Spalten dieses Berichts beziehen ihre Daten jedoch nicht direkt von diesen Knoten, sondern vom Unterknoten profile…

Verarbeitungswarteschlange

Die Abfrage gibt einen Ergebnissatz von Daten zurück, die als Zeilen im Bericht angezeigt werden. Jede Zeile des Ergebnissatzes wird (serverseitig) in mehreren Phasen verarbeitet, bevor sie an den Client zur Anzeige im Bericht übergeben wird.

Dies ermöglicht Folgendes:

• das Extrahieren und Ableiten von Werten aus dem zugrunde liegenden Ergebnissatz.

  Beispielsweise lassen sich zwei Eigenschaftswerte als Einzelwert verarbeiten, indem die Differenz zwischen beiden berechnet wird.

• das Auflösen der extrahierten Werte. Dies kann auf unterschiedliche Weise erfolgen.

  Beispielsweise können Pfade einem Titel zugeordnet werden (wie im menschenlesbareren Inhalt der entsprechenden Eigenschaft jcr:title).

• das Anwenden von Filtern an verschiedenen Stellen.

• das Erstellen zusammengesetzter Werte, falls erforderlich.

  Beispielsweise Werte, die aus einem Text bestehen, der den Benutzern angezeigt wird, einem Wert, nach dem sortiert werden soll, und einer zusätzlichen URL, die (clientseitig) zum Erstellen eines Links verwendet wird.

Workflow der Verarbeitungswarteschlange

Der folgende Workflow stellt die Verarbeitungswarteschlange dar:

Phasen der Verarbeitungswarteschlange

Die Schritte und Elemente lauten im Detail:

1. Wandelt die von der initialen Abfrage (reportbase) zurückgegebenen Ergebnisse mithilfe von Wertextraktoren in die grundlegende Ergebnismenge um.

   Die Werteextraktionsfunktionen werden automatisch abhängig vom Spaltentyp ausgewählt. Sie dienen dazu, Werte aus der zugrunde liegenden JCR-Abfrage zu lesen und daraus einen Ergebnissatz zu erstellen. Danach kann eine weitere Verarbeitung erfolgen. Beispielsweise liest die Werteextraktionsfunktion für den Typ diff zwei Eigenschaften und berechnet den Einzelwert, der dann zum Ergebnissatz hinzugefügt wird. Die Werteextraktionsfunktionen können nicht konfiguriert werden.

2. Auf diesen ersten Ergebnissatz, der Rohdaten enthält, wird eine anfängliche Filterung (Phase raw) angewendet.

3. Die Werte werden vorverarbeitet, wie für die Phase apply definiert.

4. Die vorverarbeiteten Werte werden (während der Phase preprocessed) gefiltert.

5. Die Werte werden entsprechend dem definierten Resolver aufgelöst.

6. Die aufgelösten Werte werden (während der Phase resolved) gefiltert.

7. Die Daten werden gruppiert und aggregiert.

8. Array-Daten werden durch Konvertierung in eine (zeichenfolgenbasierte) Liste aufgelöst.

   Dies ist ein impliziter Schritt, bei dem ein mehrwertiges Ergebnis in eine anzeigbare Liste umgewandelt wird. Dies ist für (nicht aggregierte) Zellwerte erforderlich, die auf mehrwertigen JCR-Eigenschaften basieren.

9. Die Werte werden wieder vorverarbeitet, wie für die Phase afterApply definiert.

10. Die Daten werden sortiert.

11. Die verarbeiteten Daten werden an den Client übertragen.

Aufbau und Konfiguration von Berichten

Um einen Bericht zu erstellen und zu konfigurieren, wird Folgendes benötigt:

• Ein Speicherort für die Definition Ihrer Berichtskomponenten
• a reportbase-Komponente
• Mindestens eine columnbase-Komponente
• Eine Seitenkomponente
• Ein Bereichtsdesign
• Eine Berichtsvorlage

Speicherort von Berichtskomponenten

Die Standardkomponenten für Berichte befinden sich unter /libs/cq/reporting/components.

Es wird jedoch dringend empfohlen, diese Knoten nicht zu aktualisieren, sondern eigene Komponentenknoten unter /apps/cq/reporting/components oder, falls zutreffend, /apps/<yourProject>/reports/components zu erstellen.

Wobei (beispielsweise):

N:apps 
    N:cq [nt:folder]
        N:reporting|reports [sling:Folder]
            N:components [sling:Folder]

Darunter legen Sie den Stamm für Ihren Bericht an und darunter die reportbase-Komponente und die columnbase-Komponenten:

N:apps 
    N:cq [nt:folder]
        N:reporting|reports [sling:Folder]
            N:components [sling:Folder]
                N:<reportname> [sling:Folder]
                        N:<reportname> [cq:Component]  // report base component
                        N:<columnname> [cq:Component]  // column base component

Seitenkomponente

Eine Berichtsseite muss die sling:resourceType von /libs/cq/reporting/components/reportpage verwenden.

Eine benutzerdefinierte Seitenkomponente sollte (in den meisten Fällen) nicht erforderlich sein.

reportbase-Komponente

Für jeden Berichtstyp ist eine von /libs/cq/reporting/components/reportbase abgeleitete Container-Komponente erforderlich.

Diese Komponente dient als Container für den gesamten Bericht und stellt Informationen für Folgendes bereit:

• Die Abfragedefinition
• Ein (optionales) Dialogfeld für die Konfiguration des Berichts
• Sämtliche in den Bericht eingebundenen Diagramme

N:<reportname> [cq:Component]
    P:sling:resourceSuperType = "cq/reporting/components/reportbase"
    N:charting
    N:dialog [cq:Dialog]
    N:queryBuilder

Abfragedefinition

N:queryBuilder
    N:propertyConstraints
    [
        N:<name> // array of nodes (name irrelevant), each with the following properties:
            P:name
            P:value
    ]
    P:nodeTypes [String|String[]] 
    P:mandatoryProperties [String|String[]
  ]

• propertyConstraints

  Kann verwendet werden, um den Ergebnissatz auf Knoten zu beschränken, die bestimmte Eigenschaften mit bestimmten Werten aufweisen. Wenn mehrere Beschränkungen angegeben sind, muss der Knoten allen Beschränkungen entsprechen (AND-Vorgang).

  Beispiel:

  N:propertyConstraints
   [
   N:0
   P:sling:resourceType
   P:foundation/components/textimage
   N:1
   P:jcr:modifiedBy
   P:admin
   ]
  

  Gibt alle textimage-Komponenten zurück, die zuletzt vom admin-Benutzer geändert wurden.

• nodeTypes

  Wird verwendet, um den Ergebnissatz auf die angegebenen Knotentypen zu beschränken. Es können mehrere Knotentypen angegeben werden.

• mandatoryProperties

  Kann verwendet werden, um den Ergebnissatz auf Knoten zu beschränken, die alle der angegebenen Eigenschaften aufweisen. Der Wert der Eigenschaften wird nicht berücksichtigt.

Alle Definitionen sind optional und können beliebig kombiniert werden, aber Sie müssen mindestens eine davon definieren.

Diagrammdefinitionen

N:charting
    N:settings
        N:active [cq:WidgetCollection]
        [
            N:<name> // array of nodes, each with the following property
                P:id   // must match the id of a child node of definitions 
        ]
    N:definitions [cq:WidgetCollection]
    [
        N:<name> // array of nodes, each with the following properties
            P:id
            P:type
            // additional, chart type specific configurations
    ]

• settings

  Enthält Definitionen für die aktiven Diagramme.

  • active

    Da sich mehrere Einstellungen definieren lassen, können Sie damit festlegen, welche gerade aktiv sind. Diese werden durch ein Array von Knoten definiert (es gibt keine obligatorische Benennungskonvention für diese Knoten, für die Standardberichte wird aber häufig 0, 1… x verwendet), die jeweils die folgende Eigenschaft aufweisen:

    • id

      Identifizierung der aktiven Diagramme. Dies muss mit der ID eines Diagramms definitions übereinstimmen.

• definitions

  Definiert die Diagrammtypen, die für den Bericht verfügbar sein können. Die zu verwendenden definitions werden durch die active-Einstellungen angegeben.

  Die Definitionen werden mithilfe eines Arrays von Knoten angegeben (auch in diesem Fall meist mit dem Namen 0, 1… x), die jeweils die folgenden Eigenschaften aufweisen:

  • id

    Die Diagrammkennung.

  • type

    Der verfügbare Diagrammtyp. Die folgenden Optionen stehen zur Auswahl:

    • pie
      Kreisdiagramm. Wird nur aus aktuellen Daten generiert.

    • lineseries
      Eine Reihe von Linien (die Punkte verbinden, welche die eigentlichen Momentaufnahmen darstellen). Wird nur aus Verlaufsdaten generiert.

  • Je nach Diagrammtyp stehen weitere Eigenschaften zur Verfügung:

    • für den Diagrammtyp pie:

      • maxRadius ( Double/Long)

        Der maximal zulässige Radius für das Kreisdiagramm, daher die maximal zulässige Größe für das Diagramm (ohne Legende). Wird ignoriert, wenn fixedRadius definiert ist.

      • minRadius ( Double/Long)

        Der für das Kreisdiagramm zulässige Mindestradius. Wird ignoriert, wenn fixedRadius definiert ist.

      • fixedRadius ( Double/Long) Definiert einen festen Radius für das Kreisdiagramm.

    • für den Diagrammtyp lineseries:

      • totals ( Boolean)

        "True", wenn eine zusätzliche Zeile mit Total angezeigt werden soll.
        default: false

      • series ( Long)

        Anzahl der anzuzeigenden Zeilen/Reihen.
        Standardwert: 9 (dies ist auch der maximal zulässige Wert)

      • hoverLimit ( Long)

        Maximale Anzahl aggregierter Momentaufnahmen (Punkte auf jeder horizontalen Linie, die für unterschiedliche Werte stehen), für die Popups angezeigt werden sollen, wenn Benutzer mit der Maus über einen bestimmten Wert oder eine entsprechende Beschriftung in der Legende des Diagramms fahren.

        Standardwert: 35 (d. h. es werden überhaupt keine Popups angezeigt, wenn mehr als 35 verschiedene Werte für die aktuellen Diagrammeinstellungen gelten).

        Es gilt zusätzlich eine maximale Anzahl von 10 Popups, die parallel angezeigt werden können (es können mehrere Popups angezeigt werden, wenn mit der Maus über die Legendentexte gefahren wird).

Konfigurationsdialogfeld

Jeder Bericht kann ein Konfigurationsdialogfeld aufweisen, in dem die Benutzer verschiedene Parameter für den Bericht angeben können. Auf dieses Dialogfeld kann über die Schaltfläche Bearbeiten zugegriffen werden, wenn die Berichtseite geöffnet ist.

Dieses Dialogfeld ist ein CQ-Standarddialogfeld und kann als solches konfiguriert werden (weitere Informationen finden Sie unter CQ.Dialog).

Ein Dialogfeld kann beispielsweise wie folgt aussehen:

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
    jcr:primaryType="cq:Dialog"
    height="{Long}424">
    <items jcr:primaryType="cq:WidgetCollection">
        <props jcr:primaryType="cq:Panel">
            <items jcr:primaryType="cq:WidgetCollection">
                <title
                    jcr:primaryType="cq:Widget"
                    path="/libs/cq/reporting/components/commons/title.infinity.json"
                    xtype="cqinclude"/>
                <description
                    jcr:primaryType="cq:Widget"
                    path="/libs/cq/reporting/components/commons/description.infinity.json"
                    xtype="cqinclude"/>
                <rootPath
                    jcr:primaryType="cq:Widget"
                    fieldLabel="Root path"
                    name="./report/rootPath"
                    rootPath=""
                    rootTitle="Repository root"
                    xtype="pathfield"/>
                <processing
                    jcr:primaryType="cq:Widget"
                    path="/libs/cq/reporting/components/commons/processing.infinity.json"
                    xtype="cqinclude"/>
                <scheduling
                    jcr:primaryType="cq:Widget"
                    path="/libs/cq/reporting/components/commons/scheduling.infinity.json"
                    xtype="cqinclude"/>
            </items>
        </props>
    </items>
</jcr:root>

Es stehen mehrere vorkonfigurierte Komponenten zur Verfügung, auf die im Dialogfeld über die Eigenschaft xtype mit dem Wert cqinclude verwiesen werden kann:

• title

  /libs/cq/reporting/components/commons/title

  Textfeld zum Definieren des Berichttitels.

• description

  /libs/cq/reporting/components/commons/description

  Textarea zur Definition der Berichtsbeschreibung.

• processing

  /libs/cq/reporting/components/commons/processing

  Selektor für den Verarbeitungsmodus des Berichts (manuell/automatisch Daten laden).

• scheduling

  /libs/cq/reporting/components/commons/scheduling

  Selektor zum Planen von Schnappschüssen für das historische Diagramm.

Stammverzeichnis

Zusätzlich kann ein Stammpfad für den Bericht definiert werden:

• rootPath

  Damit wird der Bericht auf einen bestimmten Abschnitt (Baum oder Unterbaumstruktur) des Repositorys beschränkt, was sich zur Leistungsoptimierung empfiehlt. Der Stammpfad wird durch die Eigenschaft rootPath des Knotens report jeder Berichtseite angegeben (wird bei der Seitenerstellung aus der Vorlage übernommen).

  Er kann durch Folgendes angegeben werden:

  • Die Berichtsvorlage (entweder als fester Wert oder als Standardwert für das Konfigurationsdialogfeld).
  • Den Benutzer (mithilfe dieses Parameters).

columnbase-Komponente

Für jeden Spaltentyp ist eine Komponente erforderlich, die von /libs/cq/reporting/components/columnbase abgeleitet wird.

Eine Spaltenkomponente definiert eine Kombination folgender Elemente:

• Die Konfiguration der spaltenspezifischen Abfrage.
• Die Resolver und die Vorverarbeitung.
• Die spaltenspezifischen Definitionen (beispielsweise Filter und Aggregate; untergeordneter Knoten definitions).
• Spaltenstandardwerte.
• Den Client-Filter, der die anzuzeigenden Informationen aus den vom Server zurückgegebenen Daten extrahiert.
• Darüber hinaus muss eine Spaltenkomponente eine geeignete Instanz von cq:editConfig bereitstellen, um nach Bedarf Ereignisse und Aktionen zu definieren.
• Die Konfiguration für generische Spalten.

N:<columnname> [cq:Component]
    P:componentGroup
    P:jcr:title
    P:sling:resourceSuperType = "cq/reporting/components/columnbase"
    N:cq:editConfig [cq:EditConfig] // <a href="#events-and-actions">Events and Actions</a>
    N:defaults // <a href="#column-default-values">Column Default Values</a>
    N:definitions
      N:queryBuilder // <a href="#column-specific-query">Column Specific Query</a>
        P:property [String|String[]] // Column Specific Query
        P:subPath // Column Specific Query
        P:secondaryProperty [String|String[]] // Column Specific Query
        P:secondarySubPath // Column Specific Query
      N:data
        P:clientFilter [String] // <a href="#client-filter">Client Filter</a>
        P:resolver // <a href="#resolvers-and-preprocessing">Resolvers and Preprocessing</a>
        N:resolverConfig // Resolvers and Preprocessing
        N:preprocessing // Resolvers and Preprocessing
      P:type // <a href="#column-specific-definitions">Column Specific Definitions</a>
      P:groupable [Boolean] // Column Specific Definitions
      N:filters [cq:WidgetCollection] // Column Specific Definitions
      N:aggregates [cq:WidgetCollection] // Column Specific Definitions

Siehe auch Definieren neuer Berichte.

Spaltenspezifische Abfrage

Diese definiert die spezifische Datenextraktion (aus dem Datenergebnissatz des Berichts) für die Verwendung in der jeweiligen Spalte…

N:definitions 
    N:queryBuilder
        P:property [String|String[]] 
        P:subPath
        P:secondaryProperty [String|String[]]
        P:secondarySubPath

• property

  Definiert die Eigenschaft, die für die Berechnung des tatsächlichen Zellwerts verwendet werden soll.

  Wenn die Eigenschaft als String[] definiert ist, werden mehrere Eigenschaften (in der Sequenz) gescannt, um den tatsächlichen Wert zu finden.

  Beispiel:

  property = [ "jcr:lastModified", "jcr:created" ]

  Die entsprechende Wertextrahierung (die hier gesteuert wird) wird:

  • Er prüft, ob eine jcr:lastModified-Eigenschaft verfügbar ist. Falls ja, verwendet er sie.
  • Wenn keine jcr:lastModified-Eigenschaft verfügbar ist, wird stattdessen der Inhalt von „jcr:created“ verwendet.

• subPath

  Wenn sich das Ergebnis nicht auf dem Knoten befindet, der von der Abfrage zurückgegeben wird, definiert subPath, wo sich die Eigenschaft tatsächlich befindet.

• secondaryProperty

  Definiert eine zweite Eigenschaft, die auch für die Berechnung des tatsächlichen Zellwerts verwendet werden muss. Diese wird nur für bestimmte Spaltentypen („diff“ und „sortable“) verwendet.

  Beispielsweise wird beim Bericht der Workflow-Instanz die angegebene Eigenschaft verwendet, um den tatsächlichen Wert der Zeitdifferenz (in Millisekunden) zwischen Start- und Endzeit zu speichern.

• secondarySubPath

  Ähnlich wie subPath, wenn secondaryProperty verwendet wird.

In den meisten Fällen wird nur property verwendet.

Client-Filter

Der Client-Filter extrahiert die anzuzeigenden Informationen aus den vom Server zurückgegebenen Daten.

N:definitions
    N:data
        P:clientFilter [String]

clientFilter ist als JavaScript-Funktion definiert, die:

• als Eingabe einen Parameter erhält – die vom Server zurückgegebenen Daten (also vollständig vorverarbeitet).
• als Ausgabe den gefilterten (verarbeiteten) Wert zurückgibt – die aus den Eingabeinformationen extrahierten oder abgeleiteten Daten.

Im folgenden Beispiel wird der entsprechende Seitenpfad aus einem Komponentenpfad extrahiert:

function(v) {
    var sepPos = v.lastIndexOf('/jcr:content');
    if (sepPos < 0) {
        return v;
    }
    return v.substring(sepPos + '/jcr:content'.length, v.length);
}

Resolver und Vorverarbeitung

Die Verarbeitungswarteschlange definiert die verschiedenen Resolver und konfiguriert die Vorverarbeitung:

N:definitions
    N:data
        P:resolver
        N:resolverConfig
        N:preprocessing
            N:apply
            N:applyAfter

• resolver

  Definiert den zu verwendenden Auflöser. Die folgenden Resolver sind verfügbar:

  • const

    Ordnet Werte anderen Werten zu, beispielsweise um Konstanten wie en in den entsprechenden Wert English aufzulösen.

  • default

    Der Standardauflöser. Dies ist ein Platzhalter-Resolver, der eigentlich nichts auflöst.

  • page

    Löst einen Pfadwert zum Pfad der entsprechenden Seite auf, genauer gesagt zum entsprechenden Knoten jcr:content. Beispiel: /content/.../page/jcr:content/par/xyz wird in /content/.../page/jcr:content aufgelöst.

  • path

    Löst einen Pfadwert auf, indem optional ein Unterpfad angehängt und der aktuelle Wert aus einer Eigenschaft des Knotens (wie durch resolverConfig definiert) unter dem aufgelösten Pfad übernommen wird. Beispiel: Ein path von /content/.../page/jcr:content kann bis zum Inhalt der jcr:title-Eigenschaft aufgelöst werden. Dies bedeutet, dass ein Seitenpfad bis zum Seitentitel aufgelöst wird.

  • pathextension

    Löst einen Wert auf, indem ein Pfad vorangestellt wird und der aktuelle Wert aus einer Eigenschaft des Knotens unter dem aufgelösten Pfad übernommen wird. Beispielsweise könnte einem Wert de ein Pfad wie /libs/wcm/core/resources/languages vorangestellt werden, wobei der Wert der Eigenschaft language verwendet wird, um den Ländercode de zur Sprachbeschreibung German aufzulösen.

• resolverConfig

  Enthält Definitionen für den . Die verfügbaren Optionen hängen vom gewählten resolverResolver ab:.

  • const

    Verwenden Sie Eigenschaften, um die Konstanten zum Auflösen anzugeben. Der Name der Eigenschaft definiert die aufzulösende Konstante. Der Wert der Eigenschaft definiert den aufgelösten Wert.

    Beispiel: Eine Eigenschaft mit Name= 1 und Wert =One löst 1 zu 1 auf.

  • default

    Keine Konfiguration verfügbar.

  • page

    • propertyName (optional)

      Definiert den Namen der Eigenschaft, die für die Auflösung des Werts verwendet werden soll. Wenn kein Wert angegeben ist, wird der Standardwert jcr:title (der Seitentitel) verwendet. Für den Resolver page bedeutet dies, dass der Pfad zuerst zum Seitenpfad, dann weiter zum Seitentitel aufgelöst wird.

  • path

    • propertyName (optional)

      Gibt den Namen der Eigenschaft an, die für die Auflösung des Werts verwendet werden soll. Wenn kein Wert angegeben ist, wird der Standardwert jcr:title verwendet.

    • subPath (optional)

      Mit dieser Eigenschaft kann ein Suffix angegeben werden, das an den Pfad angehängt wird, bevor der Wert aufgelöst wird.

  • pathextension

    • path (mandatory)

      Definiert den vorzuzeigenden Pfad.

    • propertyName (obligatorisch)

      Definiert die Eigenschaft auf dem aufgelösten Pfad, in dem sich der tatsächliche Wert befindet.

    • i18n (fakultativ) Boolescher Typ)

      Bestimmt, ob der gelöste Wert internationalisiert sein soll (z. B. unter Verwendung der Internationalisierungsdienste von CQ5).

• preprocessing

  Die Vorverarbeitung ist optional und kann (separat) an die Verarbeitungsphasen apply oder applyAfter gebunden werden:

  • apply

    Die anfängliche Vorverarbeitungsphase (Schritt 3 in der Darstellung der Verarbeitungswarteschlange).

  • applyAfter

    Zum Anwenden nach der Vorverarbeitung (Schritt 9 in der Darstellung der Verarbeitungswarteschlange).

Resolver

Die Resolver werden verwendet, um die erforderlichen Informationen zu extrahieren. Beispiele für die verschiedenen Resolver:

Const

Im Folgenden wird der Inhaltswert VersionCreated in die Zeichenfolge New version created aufgelöst.

Siehe /libs/cq/reporting/components/auditreport/typecol/definitions/data.

N:data
    P:resolver=const
    N:resolverConfig
        P:VersionCreated="New version created"

Seite

Löst einen Pfadwert zur Eigenschaft „jcr:description“ des Knotens „jcr:content“ (untergeordnet) der entsprechenden Seite auf.

Siehe /libs/cq/reporting/components/compreport/pagecol/definitions/data.

N:data
    P:resolver=page
    N:resolverConfig
        P:propertyName="jcr:description"

Pfad

Im Folgenden wird ein Pfad von /content/.../page zum Inhalt der jcr:title-Eigenschaft aufgelöst. Dies bedeutet, dass ein Seitenpfad bis zum Seitentitel aufgelöst wird.

Siehe /libs/cq/reporting/components/auditreport/pagecol/definitions/data.

N:data
    P:resolver=path
    N:resolverConfig
        P:propertyName="jcr:title"
        P:subPath="/jcr:content"

Pfaderweiterung

Im Folgenden wird einem Wert de mit der Pfaderweiterung /libs/wcm/core/resources/languages vorangestellt und anschließend der Wert aus der Eigenschaft language genommen, um den Ländercode de zur Sprachbeschreibung German aufzulösen.

Siehe /libs/cq/reporting/components/userreport/languagecol/definitions/data.

N:data
    P:resolver=pathextension
    N:resolverConfig
        P:path="/libs/wcm/core/resources/languages"
        P:propertyName="language"

Vorverarbeitung

Die Definition preprocessing kann wahlweise auf Folgendes angewendet werden:

• Originalwert:

  Die Vorverarbeitungsdefinition für den Originalwert wird direkt auf apply und/oder applyAfter angegeben.

• Wert in seinem aggregierten Zustand:

  Bei Bedarf kann für jede Aggregation eine eigene Definition bereitgestellt werden.

  Um eine explizite Vorverarbeitung für aggregierte Werte anzugeben, müssen sich die Vorverarbeitungsdefinitionen auf einem entsprechenden untergeordneten Knoten ( apply/aggregated, applyAfter/aggregated) befinden. aggregated Wenn eine explizite Vorverarbeitung für verschiedene Aggregate erforderlich ist, befindet sich die Vorverarbeitungsdefinition auf einem untergeordneten Knoten mit dem Namen des jeweiligen Aggregates (z. B. apply/aggregated/min/max oder anderen Aggregaten).

Sie können eine der folgenden bei der Vorverarbeitung zu verwendenden Optionen angeben:

• Muster zum Suchen und Ersetzen Wenn das angegebene Muster gefunden wird (das als regulärer Ausdruck definiert ist), wird es durch ein anderes Muster ersetzt. Dieses kann z. B. verwendet werden, um eine Teilzeichenfolge des ursprünglichen Musters zu extrahieren.

• Datentypformatierung

  Wandelt einen numerischen Wert in eine relative Zeichenfolge um; Beispielsweise würde der Wert "für eine Zeitdifferenz von 1 Stunde"in eine Zeichenfolge wie 1:24PM (1 hour ago) aufgelöst.

Beispiel:

N:definitions
    N:data
        N:preprocessing
            N:apply|applyAfter
                P:pattern         // regex
                P:replace         // replacement for regex
                // and/or
                P:format          // data type formatter

Vorverarbeitung – Muster zum Suchen und Ersetzen

Bei der Vorverarbeitung können Sie einen pattern (definiert als regulärer Ausdruck oder regex) angeben, der sich befindet und dann durch das replace-Muster ersetzt wird:

• pattern

  Der reguläre Ausdruck, der verwendet wird, um eine Teilzeichenfolge zu finden.

• replace

  Die Zeichenkette oder Darstellung der Zeichenkette, die als Ersatz für die ursprüngliche Zeichenkette verwendet wird. Häufig handelt es sich dabei um eine Teilzeichenfolge der Zeichenfolge, die durch den regulären Ausdruck pattern gefunden wird.

Ein Ersetzungsmuster kann beispielsweise wie folgt aufgeschlüsselt werden:

• Für den Knoten definitions/data/preprocessing/apply mit den folgenden beiden Eigenschaften:

  • pattern: (.*)(/jcr:content?lang=de)(/|$?lang=de)(.*)
  • replace: $1

• Eine Zeichenfolge, die wie folgt vorliegt:

  • /content/geometrixx/en/services/jcr:content/par/text

• wird in vier Abschnitte unterteilt:

  • $1 - (.*) - /content/geometrixx/en/services
  • $2 - (/jcr:content?lang=de) - /jcr:content
  • $3 - (/|$?lang=de) - /
  • $4 - (.*) - par/text

• Ersetzt durch die Zeichenfolge $1:

  • /content/geometrixx/en/services

Vorverarbeitung – Datentypformatierer

Diese Formatierer konvertieren einen numerischen Wert in eine relative Zeichenfolge.

Dies kann beispielsweise für eine Zeitspalte verwendet werden, die min-, avg- und max-Aggregat zulässt. Als min/ avg/ max Aggregat werden als Zeitdifferenz (z.B. 10 days ago), benötigen sie einen Datenformatierer. Hierfür wird ein datedelta-Formatierer auf die aggregierten Werte min/ avg/ max angewendet. Wenn auch ein Aggregat count verfügbar ist, dann ist dafür kein Formatierer erforderlich, ebenso wenig wie für den ursprünglichen Wert…

Derzeit sind die folgenden Datentypformatierer verfügbar:

• format

  Datentypformatierung:

  • duration

    Die Dauer ist der Zeitraum zwischen zwei definierten Daten. Beispiel: Beginn und Ende einer Workflow-Aktion, die eine Stunde gedauert hat – sie hat am 13.02.11 um 11:23 Uhr begonnen und endete eine Stunde später am 13.02.11 um 12:23 Uhr.

    Es wandelt einen numerischen Wert (in Millisekunden) in eine Zeichenfolge für die Dauer um. Beispiel: 30000 ist als * 30s formatiert.*

  • datedelta

    Ein Datendelta ist die Zeitspanne zwischen einem in der Vergangenheit liegenden Datum und dem jetzigen Zeitpunkt (entsprechend fällt das Ergebnis anders aus, wenn der Bericht zu einem späteren Zeitpunkt angezeigt wird).

    Es konvertiert den numerischen Wert (interpretiert als Zeitdifferenz in Tagen) in eine relative Datumszeichenfolge. Beispielsweise wird „1“ als „1 day ago“ formatiert.

Im folgenden Beispiel wird die Formatierung für min- und max-Aggregat definiert:datedelta

N:definitions
    N:data
        N:preprocessing
            N:apply
                N:aggregated
                    N:min
                        P:format = "datedelta"
                    N:max
                        P:format = "datedelta"

Spaltenspezifische Definitionen

Die spaltenspezifischen Definitionen definieren die für diese Spalte verfügbaren Filter und Aggregate.

N:definitions
    P:type
    P:groupable [Boolean]
    N:filters [cq:WidgetCollection] 
    [
        N:<name> // array of nodes (names irrelevant) with the following properties:
            P:filterType
            P:id
            P:phase
    ]
    N:aggregates [cq:WidgetCollection]
    [
        N:<name> // array of nodes (names irrelevant) with the following properties:
            P:text
            P:type
    ]

• type

  Die folgenden Optionen sind standardmäßig verfügbar:

  • string

  • number

  • int

  • date

  • diff

  • timeslot

    Diese Option wird verwendet, um Teile eines Datums zu extrahieren, das für die Aggregation benötigt wird (gruppieren Sie beispielsweise nach Jahr, um die Daten für die einzelnen Jahre zu aggregieren).

  • sortable

    Diese Option wird für Werte verwendet, die unterschiedliche Werte (aus unterschiedlichen Eigenschaften) zum Sortieren und Anzeigen verwenden.
    Zusätzlich kann die oben genannten Werte können als "Mehrwert"definiert werden; Zum Beispiel definiert string[] ein Zeichenfolgen-Array.

  Der Werte-Extractor wird durch den Spaltentyp ausgewählt. Wenn für einen Spaltentyp ein Werte-Extractor verfügbar ist, dann wird dieser verwendet. Andernfalls wird der standardmäßige Werte-Extractor verwendet.

  Ein Typ kann (optional) einen Parameter heranziehen. Beispielsweise extrahiert timeslot:year das Jahr aus einem Datumsfeld. Typen mit ihren Parametern:

  • timeslot – Die Werte sind mit den entsprechenden Konstanten von java.utils.Calendar vergleichbar.

    • timeslot:year - Calendar.YEAR
    • timeslot:month-of-year - Calendar.MONTH
    • timeslot:week-of-year - Calendar.WEEK_OF_YEAR
    • timeslot:day-of-month - Calendar.DAY_OF_MONTH
    • timeslot:day-of-week - Calendar.DAY_OF_WEEK
    • timeslot:day-of-year - Calendar.DAY_OF_YEAR
    • timeslot:hour-of-day - Calendar.HOUR_OF_DAY
    • timeslot:minute-of-hour - Calendar.MINUTE

• groupable

  Legt fest, ob der Bericht nach dieser Spalte gruppiert werden kann.

• filters

  Filterdefinitionen.

  • filterType

    Verfügbare Filter sind:

    • string

      Ein zeichenfolgenbasierter Filter.

  • id

    Filter-ID.

  • phase

    Verfügbare Phasen:

    • raw

      Filter wird auf Rohdaten angewendet.

    • preprocessed

      Filter wird auf vorverarbeitete Daten angewendet.

    • resolved

      Filter wird auf gelöste Daten angewendet.

• aggregates

  Aggregat-Definitionen.

  • text

    Textname des Aggregats. Wenn text nicht angegeben ist, dann wird die Standardbeschreibung des Aggregats verwendet, beispielsweise wird minimum für das Aggregat min verwendet.

  • type

    Aggregat. Die verfügbaren Aggregate sind:

    • count

      Zählt die Anzahl der Zeilen.

    • count-nonempty

      Zählt die Anzahl der nicht leeren Zeilen.

    • min

      Stellt den Mindestwert bereit.

    • max

      Stellt den Maximalwert bereit.

    • average

      Stellt den Durchschnittswert bereit.

    • sum

      Stellt die Summe aller Werte bereit.

    • median

      Stellt den Medianwert bereit.

    • percentile95

      Zieht das 95. Perzentil aller Werte heran.

Spaltenstandardwerte

Hiermit werden Standwerte für die Spalte definiert:

N:defaults
    P:aggregate

• aggregate

  Gültige aggregate-Werte sind dieselben wie für type unter aggregates (siehe Spaltenspezifische Definitionen (Definitionen - Filter/Aggregat) ).

Ereignisse und Aktionen

Die Bearbeitungskonfiguration definiert sowohl die erforderlichen Ereignisse, die die Listener erkennen müssen, als auch die Aktionen, die nach dem Auftreten dieser Ereignisse ausgeführt werden sollen. Weitere Informationen finden Sie in der Einführung zur Komponentenentwicklung.

Die folgenden Werte müssen definiert werden, um sicherzustellen, dass alle erforderlichen Aktionen berücksichtigt werden:

N:cq:editConfig [cq:EditConfig] 
    P:cq:actions [String[]] = "insert", "delete" 
    P:cq:dialogMode = "floating"
    P:cq:layout = "auto"
    N:cq:listeners [cq:EditListenersConfig]
        P:aftercreate = "REFRESH_INSERTED"
        P:afterdelete = "REFRESH_SELF"
        P:afteredit = "REFRESH_SELF"
        P:afterinsert = "REFRESH_INSERTED"
        P:aftermove = "REFRESH_SELF"
        P:afterremove = "REFRESH_SELF"

Generische Spalten

Generische Spalten sind eine Erweiterung, bei der (die meisten) Spaltendefinitionen auf der Instanz des Spaltenknotens (und nicht auf dem Komponentenknoten) gespeichert werden.

Sie weisen ein (standardmäßiges) Dialogfeld auf, das Sie für eine einzelne generische Komponente anpassen. Über dieses Dialogfeld können Berichtsbenutzer die Spalteneigenschaften einer generischen Spalte auf der Berichtsseite definieren (über den Menüpunkt Spalteneigenschaften).

Ein Beispiel ist die Spalte Generisch des Benutzerberichts; siehe /libs/cq/reporting/components/userreport/genericcol.

Gehen Sie wie folgt vor, um eine Spalte als generisch zu definieren:

• Legen Sie die type-Eigenschaft des definition-Knotens der Spalte auf generic fest.

  Siehe /libs/cq/reporting/components/userreport/genericcol/definitions

• Geben Sie eine für das (standardmäßige) Dialogfeld unter dem Knoten definitiondefinition der Spalte an.

  Siehe /libs/cq/reporting/components/userreport/genericcol/definitions/dialog

  • Die Felder des Dialogfelds müssen sich auf die gleichen Namen beziehen wie die entsprechende Komponenteneigenschaft (einschließlich ihres Pfads).

    Wenn Sie beispielsweise den Typ der generischen Spalte über das Dialogfeld als konfigurierbar festlegen möchten, verwenden Sie ein Feld mit dem Namen ./definitions/type

  • Eigenschaften, die über die Benutzeroberfläche/das Dialogfeld definiert wurden, haben Vorrang vor denen, die in der columnbase-Komponente definiert wurden.

• Definieren Sie die Bearbeitungskonfiguration.

  Siehe /libs/cq/reporting/components/userreport/genericcol/cq:editConfig

• Verwenden Sie AEM Standardmethoden, um (zusätzliche) Spalteneigenschaften zu definieren.

  Beachten Sie, dass bei Eigenschaften, die sowohl für die Komponenten- als auch für Spalteninstanz definiert sind, der Wert für die Spalteninstanz Vorrang hat.

  Die für eine generische Spalte zur Verfügung stehenden Eigenschaften lauten:

  • jcr:title - Spaltenname
  • definitions/aggregates - Aggregate
  • definitions/filters - filters
  • definitions/type – – der Typ der Spalte (dieser muss über das Dialogfeld definiert werden, entweder über eine Auswahl/ein Kombinationsfeld oder ein ausgeblendetes Feld)
  • definitions/data/resolver und definitions/data/resolverConfig (aber nicht definitions/data/preprocessing oder .../clientFilter) - der Auflöser und die Konfiguration
  • definitions/queryBuilder - Abfrage Builder-Konfiguration
  • defaults/aggregate - das Standard-Aggregat

  Bei einer neuen Instanz der generischen Spalte im Benutzerbericht bleiben die mit dem Dialogfeld definierten Eigenschaften erhalten unter:

  /etc/reports/userreport/jcr:content/report/columns/genericcol/settings/generic

Berichtsdesign

Mit dem Design wird festgelegt, welche Spaltentypen für die Erstellung eines Berichts zur Verfügung stehen. Außerdem wird damit das Absatzsystem definiert, dem die Spalten hinzugefügt werden.

Es wird dringend empfohlen, für jeden Bericht ein eigenes Design zu erstellen. Damit ist eine umfassende Flexibilität gewährleistet. Siehe auch Definieren neuer Berichte.

Die Standardkomponenten für Berichte befinden sich unter /etc/designs/reports.

Der Speicherort für Ihre Berichte ist ggf. davon abhängig, wo sich Ihre Komponenten befinden:

• /etc/designs/reports/<yourReport> ist geeignet, wenn der Bericht unter /apps/cq/reporting

• /etc/designs/<yourProject>/reports/<*yourReport*> für Berichte mit /apps/<yourProject>/reports Mustern

Erforderliche Designeigenschaften werden unter jcr:content/reportpage/report/columns registriert (z. B. /etc/designs/reports/<reportName>/jcr:content/reportpage/report/columns):

• components

  Alle Komponenten und/oder Komponentengruppen, die für den Bericht zulässig sind.

• sling:resourceType

  Eigenschaft mit dem Wert cq/reporting/components/repparsys.

Ein Beispiel für ein Designsnippet (aus dem Design des Komponentenberichts):

<!-- ... -->
    <jcr:content
        jcr:primaryType="nt:unstructured"
        jcr:title="Component Report"
        sling:resourceType="wcm/core/components/designer">
        <reportpage jcr:primaryType="nt:unstructured">
            <report jcr:primaryType="nt:unstructured">
                <columns
                    jcr:primaryType="nt:unstructured"
                    sling:resourceType="cq/reporting/components/repparsys"
                    components="group:Component Report"/>
            </report>
        </reportpage>
    </jcr:content>
<!-- ... -->

Die Angabe von Designs für einzelne Spalten ist nicht erforderlich. Verfügbare Spalten können im Designmodus definiert werden.

Berichtsvorlage

Jeder Berichtstyp muss eine Vorlage bereitstellen. Dabei handelt es sich um die standardmäßigen CQ-Vorlagen, die auch als solche konfiguriert werden können.

Die Vorlage muss:

• setzen Sie sling:resourceType auf cq/reporting/components/reportpage

• das zu verwendende Design angeben.

• Erstellen Sie einen untergeordneten Knoten report, der mithilfe der sling:resourceType-Eigenschaft auf die Container-Komponente ( reportbase) verweist.

Ein Beispiel für ein Vorlagensnippet (aus der Komponentenberichtsvorlage):

<!-- ... -->
    <jcr:content
        cq:designPath="/etc/designs/reports/compreport"
        jcr:primaryType="cq:PageContent"
        sling:resourceType="cq/reporting/components/reportpage">
        <report
            jcr:primaryType="nt:unstructured"
            sling:resourceType="cq/reporting/components/compreport/compreport"/>
    </jcr:content>
<!-- .. -->

Beispiel für ein Vorlagensnippet, das die Definition des Stammpfads (aus der Benutzerberichtsvorlage) zeigt:

<!-- ... -->
    <jcr:content
        cq:designPath="/etc/designs/reports/userreport"
        jcr:primaryType="cq:PageContent"
        sling:resourceType="cq/reporting/components/reportpage">
        <report
            jcr:primaryType="nt:unstructured"
            rootPath="/home/users"
            sling:resourceType="cq/reporting/components/compreport/compreport"/>
    </jcr:content>
<!-- .. -->

Die Standardvorlagen für Berichte befinden sich unter /libs/cq/reporting/templates.

Es wird jedoch dringend empfohlen, diese Knoten nicht zu aktualisieren, sondern eigene Komponentenknoten unter /apps/cq/reporting/templates oder, falls zutreffend, /apps/<yourProject>/reports/templates zu erstellen.

Dabei gilt beispielsweise Folgendes (siehe auch Speicherort von Berichtskomponenten):

N:apps 
    N:cq [nt:folder]
        N:reporting|reports [sling:Folder]
            N:templates [sling:Folder]

Darunter erstellen Sie den Stamm für Ihre Vorlage:

N:apps 
    N:cq [nt:folder]
        N:reporting|reports [sling:Folder]
            N:templates [sling:Folder]
                N:<reportname> [sling:Folder]

Erstellen eigener Berichte – Beispiel

Definieren neuer Berichte

Um einen neuen Bericht zu definieren, müssen Sie Folgendes erstellen und konfigurieren:

1. den Stamm für Ihre Berichtskomponenten.
2. die reportbase-Komponente.
3. mindestens eine columnbase-Komponente.
4. das Berichtsdesign.
5. den Stamm für Ihre Berichtsvorlage.
6. die Berichtsvorlage.

Um diese Schritte zu veranschaulichen, wird im folgenden Beispiel ein Bericht definiert, der alle OSGi-Konfigurationen im Repository aufführt, d. h. alle Instanzen des Knotens sling:OsgiConfig.

1. Erstellen Sie den Stammknoten für Ihren neuen Bericht.

   Beispiel: Unter /apps/cq/reporting/components/osgireport.

   N:cq [nt:folder]
       N:reporting [sling:Folder]
           N:components [sling:Folder]
               N:osgireport [sling:Folder]
   

2. Definieren Sie Ihren Berichtsstamm. Beispiel: osgireport[cq:Component] unter /apps/cq/reporting/components/osgireport.

   N:osgireport [sling:Folder]
       N:osgireport [cq:Component]
           P:sling:resourceSuperType [String] = "cq/reporting/components/reportbase"
           N:charting [nt:unstructured]
               N:settings [nt:unstructured]
                   N:active [cq:WidgetCollection]
                       N:0 [nt:unstructured]
                           P:id [String] = "pie"
                       N:1 [nt:unstructured]
                           P:id [String] = "lineseries"
               N:definitions [cq:WidgetCollections]
                   N:0 [nt:unstructured]
                       P:id [String] = "pie"
                       P:maxRadius [Long] = 180
                       P:type [String] = "pie"
                   N:1 [nt:unstructured]
                       P:id [String] = "lineseries"
                       P:type [String] = "lineseries"
           N:dialog [cq:Dialog]
               P:height [Long] = 424
               N:items [cq:WidgetCollection]
                   N:props [cq:Panel]
                       N:items [cq:WidgetCollection]
                           N:title [cq:Widget]
                               P:path [String] = "/libs/cq/reporting/components/commons/title.infinity.json"
                               P:xtype [String] = "cqinclude"
                           N:description [cq:Widget]
                               P:path [String] = "/libs/cq/reporting/components/commons/description.infinity.json"
                               P:xtype [String] = "cqinclude"
                           N:rootPath [cq:Widget]
                               P:fieldLabel [String] = "Root path"
                               P:name [String] = "./report/rootPath"
                               P:xtype [String] = "pathfield"
                           N:processing [cq:Widget]
                               P:path [String] = "/libs/cq/reporting/components/commons/processing.infinity.json"
                               P:xtype [String] = "cqinclude"
                           N:scheduling [cq:Widget]
                               P:path [String] = "/libs/cq/reporting/components/commons/scheduling.infinity.json"
                               P:xtype [String] = "cqinclude"
           N:queryBuilder [nt:unstructured]
               P:nodeTypes [String[]] = "sling:OsgiConfig"
   

   Damit wird eine reportbase-Komponente definiert, die:

   • sucht nach allen Knoten des Typs sling:OsgiConfig
   • zeigt sowohl pie- als auch lineseries-Diagramme an
   • den Benutzern ein Dialogfeld zum Konfigurieren des Berichts bereitstellt.

3. Definieren Sie Ihre erste Spaltenkomponente („columnbase“). Beispiel: bundlecol[cq:Component] unter /apps/cq/reporting/components/osgireport.

   N:osgireport [sling:Folder]
       N:bundlecol [cq:Component]
           P:componentGroup [String] = "OSGi Report"
           P:jcr:title = "Bundle"
           P:sling:resourceSuperType [String] = "cq/reporting/components/columnbase"
           N:cq:editConfig [cq:EditConfig]
               P:cq:actions [String[]] = "insert", "delete"
               P:cq:dialogMode [String] = "floating"
               P:cq:layout [String] = "auto"
               N:cq:listeners [cq:EditListenersConfig]
                   P:aftercreate [String] "REFRESH_INSERTED"
                   P:afterdelete [String] "REFRESH_SELF"
                   P:afteredit [String] "REFRESH_SELF"
                   P:afterinsert [String] "REFRESH_INSERTED"
                   P:aftermove [String] "REFRESH_SELF"
                   P:afterremove [String] "REFRESH_SELF"
           N:defaults [nt:unstructured]
               P:aggregate [String] = "count"
           N:definitions [nt:unstructured]
               P:groupable [Boolean] = false
               P:type [String] = "string"
               N:queryBuilder [nt:unstructured]
                   P:property [String] = "jcr:path"
   

   Damit wird eine columnbase-Komponente definiert, die:

   • den Wert sucht und zurückgibt, den sie vom Server erhält. In diesem Fall die Eigenschaft jcr:path für jeden Knoten sling:OsgiConfig.
   • stellt das Aggregat count bereit
   • nicht gruppierbar ist.
   • den Titel Bundle aufweist (Spaltentitel in der Tabelle)
   • befindet sich in der Sidekick-Gruppe OSGi Report
   • bei bestimmten Ereignissen aktualisiert wird.
   HINWEIS

   In diesem Beispiel gibt es keine Definitionen von N:data und P:clientFilter. Das liegt daran, dass der vom Server empfangene Wert 1:1 zurückgegeben wird – dies ist das Standardverhalten.

   Dies entspricht den Definitionen:

   N:data [nt:unstructured]
   P:clientFilter [String] = "function(v) { return v; }"
   

   Dabei gibt die Funktion einfach den Wert zurück, den sie erhält.

4. Definieren Sie Ihr Berichtsdesign. Beispiel: osgireport[cq:Page] unter /etc/designs/reports.

   N:osgireport [cq:Page]
       N:jcr:content [nt:unstructured]
           P:jcr:title [String] = "OSGi report"
           P:sling:resourceType [String] = "wcm/core/components/designer"
           N:reportpage [nt:unstructured]
               N:report [nt:unstructured]
                   N:columns [nt:unstructured]
                       P:components [String] = "group:OSGi Report"
                       P:sling:resourceType [String] = "cq/reporting/components/repparsys"
   

5. Erstellen Sie den Stammknoten für Ihre neue Berichtsvorlage.

   Beispiel: Unter /apps/cq/reporting/templates/osgireport.

   N:cq [nt:folder]
       N:reporting [sling:Folder]
           N:templates [sling:Folder]
               N:osgireport [cq:Template]
   

6. Definieren Sie Ihre Berichtsvorlage. Beispiel: osgireport[cq:Template] unter /apps/cq/reporting/templates.

   N:osgireport [cq:Template]
       P:allowedPaths [String[]] = "/etc/reports(/.*)?"
       P:jcr:description [String] = "Use this report generator to create a new OSGi report."
       P:jcr:title [String] = "OSGi Report Template"
       P:ranking [Long] = 100
       P:shortTitle [String] = "OSGi Report"
       N:jcr:content [cq:PageContent]
           P:cq:designPath [String] = "/etc/designs/reports/osgireport"
           P:sling:resourceType [String] = "cq/reporting/components/reportpage"
           N:report [nt:unstructured]
               P:rootPath [String] = "/"
               P:sling:resourceType [String] = "cq/reporting/components/osgireport/osgireport"
       N:thumbnail.png [nt:file]
   

   Damit wird eine Vorlage definiert, die:

   • definiert das allowedPaths für die resultierenden Berichte - in diesem Fall an einer beliebigen Stelle unter /etc/reports
   • Titel und Beschreibungen für die Vorlage bereitstellt.
   • eine Miniaturansicht für die Verwendung in der Vorlagenliste bereitstellt (die vollständige Definition dieses Knotens ist oben nicht aufgeführt – am einfachsten lässt sich eine Instanz von „thumbnail.png“ aus einem vorhandenen Bericht kopieren).

Erstellen von Instanzen neuer Berichte

Sie können nun eine Instanz Ihres neuen Berichts erstellen:

1. Öffnen Sie die Tools-Konsole.

2. Wählen Sie im linken Bedienfeld Berichte aus.

3. Klicken Sie dann in der Symbolleiste auf Neu. Definieren Sie einen Titel und Namen, wählen Sie Ihren neuen Berichtstyp (die OSGi-Berichtsvorlage) aus der Liste der Vorlagen aus und klicken Sie anschließen auf Erstellen.

4. Ihre neue Berichtsinstanz wird in der Liste angezeigt. Doppelklicken Sie darauf, um sie zu öffnen.

5. Ziehen Sie eine Komponente (in diesem Beispiel Bundle in der Gruppe OSGi Report) aus dem Sidekick, um die erste Spalte zu erstellen, und beginnen Sie mit dem Definieren des Berichts…

   HINWEIS

   Da bei diesem Beispiel keine gruppierbaren Spalten gibt, sind die Diagramme nicht verfügbar. Um Diagramme anzuzeigen, setzen Sie groupable auf true:

   N:osgireport [sling:Folder]
   N:bundlecol [cq:Component]
   N:definitions [nt:unstructured]
   P:groupable [Boolean] = true
   

Konfigurieren der Dienste für das Framework für die Berichterstellung

In diesem Abschnitt werden die erweiterten Konfigurationsoptionen für die OSGi-Dienste beschrieben, die das Framework für die Berichterstellung implementieren.

Diese können über das Konfigurationsmenü der Webkonsole angezeigt werden (verfügbar z. B. unter http://localhost:4502/system/console/configMgr). Bei AEM können Sie die Konfigurationseinstellungen für Dienste dieser Art auf unterschiedliche Weise vornehmen. Informationen zur empfohlenen Vorgehensweise finden Sie unter Konfigurieren von OSGi.

Grundlegender Dienst („Day CQ Reporting Configuration“)

• Zeitzone definiert die Zeitzone, für die Verlaufsdaten erstellt werden. Damit soll sichergestellt werden, dass das Diagramm mit den Verlaufsdaten für jeden Benutzer weltweit dieselben Daten anzeigt.

• Gebietsschema definiert das Gebietsschema, das in Verbindung mit der Zeitzone für Verlaufsdaten verwendet werden soll. Das Gebietsschema wird verwendet, um einige gebietsschemaspezifische Kalendereinstellungen festzulegen (z. B. ob der erste Tag der Woche Sonntag oder Montag ist).

• Momentaufnahmenpfad definiert den Stammpfad, unter dem Momentaufnahmen für Diagramme mit Verlaufsdaten gespeichert werden.

• Pfad zu Berichten definiert den Pfad, unter dem sich die Berichte befinden. Dieser wird vom Momentaufnahmendienst verwendet, um die Berichte zu bestimmen, für die tatsächlich Momentaufnahmen erstellt werden sollen.

• Tägliche Momentaufnahmen definiert die Stunde jedes Tages, in der die täglichen Momentaufnahmen gemacht werden. Die angegebene Stunde bezieht sich auf die lokale Zeitzone des Servers.

• Stündliche Momentaufnahmen definiert die Minute jeder Stunde, in der stündliche Momentaufnahmen gemacht werden.

• Zeilen (max.) definiert die maximale Anzahl von Zeilen, die für jede Momentaufnahme gespeichert werden. Dieser Wert sollte mit Bedacht gewählt werden. Wenn er zu hoch ist, wirkt sich dies auf die Größe des Repositorys aus, wenn er zu niedrig ist, können Daten aufgrund der Art und Weise, wie Verlaufsdaten verarbeitet werden, ungenau sein.

• Falsche Daten – wenn diese Option aktiviert ist, können falsche Verlaufsdaten mithilfe der fakedata-Auswahl erstellt werden. Wenn diese Option deaktiviert ist, wird bei Verwendung der fakedata-Auswahl eine Ausnahme ausgelöst.

  Da es sich um falsche Daten handelt, dürfen sie ausschließlich zu Test- und Debugging-Zwecken verwendet werden.

  Bei Verwendung der fakedata-Auswahl wird die Berichterstellung implizit beendet, sodass alle vorhandenen Daten verloren gehen. Daten können manuell wiederhergestellt werden, aber dies kann sehr zeitaufwendig sein.

• Momentaufnahmenbenutzer definiert einen optionalen Benutzer, der für die Aufnahme von Momentaufnahmen verwendet werden kann.

  Grundsätzlich werden Momentaufnahmen für den Benutzer erstellt, der die Berichterstellung beendet hat. Unter Umständen (beispielsweise in einem Veröffentlichungssystem, in dem dieser Benutzer nicht existiert, da das Konto nicht repliziert wurde) empfiehlt es sich, einen Ausweichbenutzer anzugeben, der stattdessen verwendet wird.

  Darüber hinaus kann die Angabe eines Benutzers ein Sicherheitsrisiko darstellen.

• Momentaufnahmenbenutzer erzwingen – wenn diese Option aktiviert ist, werden alle Momentaufnahmen mit dem unter Momentaufnahmenbenutzer angegebenen Benutzer gemacht. Dies kann schwerwiegende Auswirkungen auf die Sicherheit haben, wenn es nicht richtig gehandhabt wird.

Cache-Einstellungen (Day CQ-Berichte-Cache)

• Aktivieren ermöglicht es Ihnen, das Caching von Berichtsdaten zu aktivieren bzw. zu deaktivieren. Das Aktivieren des Berichtcaches hält die Berichtsdaten während mehrerer Anforderungen im Speicher vor. Damit lässt sich zwar die Leistung steigern, allerdings wird auch mehr Speicherplatz beansprucht, was in unter extremen Umständen zu Speicherausfällen führen kann.
• TTL definiert die Zeit (in Sekunden), für die Berichtsdaten zwischengespeichert werden. Mit einem höheren Wert wird zwar die Leistung gesteigert, ggf. werden dann aber ungenaue Daten zurückgegeben, wenn sich die Daten innerhalb des Zeitraums ändern.
• Max. Anzahl an Einträgen definiert die maximale Anzahl an Berichten, die gleichzeitig zwischengespeichert werden.