Show Menu
ARGOMENTI×

Sviluppo di report

AEM offre una selezione di rapporti Generazione rapporti standard, la maggior parte dei quali basati su un framework di reporting.
Utilizzando il framework è possibile estendere questi rapporti standard o sviluppare rapporti personalizzati completamente nuovi. Il framework di reporting si integra strettamente con i concetti e i principi esistenti di CQ5, in modo che gli sviluppatori possano utilizzare la conoscenza già acquisita di CQ5 come piattaforma di sviluppo per lo sviluppo di rapporti.
Per i rapporti standard forniti con AEM:
L'esercitazione Creazione di un report personalizzato - Un esempio mostra anche quanti dei principi riportati di seguito possono essere utilizzati.
Puoi anche fare riferimento ai rapporti standard per vedere altri esempi di implementazione.
Negli esempi e nelle definizioni seguenti è utilizzata la seguente notazione:
  • Ogni riga definisce un nodo o una proprietà in cui:
  • N:<name> [<nodeType>]
    Descrive un nodo con il nome <*name*> e il tipo di nodo di <*nodeType*> .
  • P:<name> [<propertyType]
    Descrive una proprietà con il nome <*name*> e un tipo di proprietà di <*propertyType*> .
  • P:<name> = <value>
    Descrive una proprietà <name> che deve essere impostata sul valore di <value> .
  • Il rientro mostra le dipendenze gerarchiche tra i nodi.
  • Elementi separati da| indica un elenco di possibili elementi; ad esempio, tipi o nomi:
Ad esempio, String|String[] la proprietà può essere String o String #.
  • [] rappresenta un array; come Stringa # o un array di nodi come nella definizione della query.
Salvo diversa indicazione, i tipi predefiniti sono:
  • Nodes - nt:unstructured
  • Proprietà - String

Framework di reporting

Il quadro di riferimento per le relazioni si basa sui seguenti principi:
  • È interamente basato su set di risultati restituiti da una query eseguita da CQ5 QueryBuilder.
  • Il set di risultati definisce i dati visualizzati nel rapporto. Ogni riga del set di risultati corrisponde a una riga nella visualizzazione tabulare del rapporto.
  • Le operazioni disponibili per l'esecuzione sul set di risultati sono simili ai concetti RDBMS; principalmente raggruppamento e aggregazione .
  • La maggior parte del recupero e dell'elaborazione dei dati è effettuata sul lato server.
  • Il cliente è l'unico responsabile della visualizzazione dei dati preelaborati. Solo le attività di elaborazione secondarie (ad esempio, la creazione di collegamenti nel contenuto delle celle) vengono eseguite sul lato client.
Il framework di reporting (illustrato dalla struttura di un report standard) utilizza i seguenti blocchi predefiniti, alimentati dalla coda di elaborazione:

Pagina report

La pagina del rapporto:

Base report

Il componente costituisce la base di qualsiasi rapporto:
  • Contiene la definizione della query che fornisce il set di risultati sottostante di dati.
  • È un sistema paragrafo adattato che conterrà tutte le colonne ( columnbase ) aggiunte al rapporto.
  • Definisce i tipi di grafico disponibili e quelli attualmente attivi.
  • Definisce la finestra di dialogo Modifica, che consente all’utente di configurare alcuni aspetti del rapporto.

Base colonna

Ogni colonna è un’istanza del columnbase che:
  • È un paragrafo, utilizzato dal parsys ( reportbase ) del rispettivo rapporto.
  • Definisce il collegamento al set di risultati sottostante; ad esempio, definisce i dati specifici a cui si fa riferimento all'interno di questo set di risultati e come viene elaborato.
  • contiene definizioni supplementari; quali gli aggregati e i filtri disponibili, insieme a eventuali valori predefiniti.

Query e recupero dati

Query:
  • È definito come parte del reportbase componente.
  • Si basa su CQ QueryBuilder .
  • Recupera i dati utilizzati come base del rapporto. Ogni riga del set di risultati (tabella) è associata a un nodo come restituito dalla query. Da questo set di dati vengono quindi estratte informazioni specifiche per singole colonne .
  • In genere si compone di:
    • Un percorso radice.
      Specifica la struttura ad albero secondaria del repository in cui effettuare la ricerca.
      Per ridurre al minimo l'impatto sulle prestazioni, è consigliabile (provare) limitare la query a un sottoalbero specifico del repository. Il percorso principale può essere predefinito nel modello di rapporto o impostato dall'utente nella finestra di dialogo Finestra di dialogo Configurazione Configurazione (Modifica).
    • che sono imposti per produrre l'insieme (iniziale) di risultati; includono, ad esempio, limitazioni relative al tipo di nodo o vincoli di proprietà.
Il punto chiave qui è che ogni singolo nodo restituito nel set di risultati della query viene utilizzato per generare una singola riga nel report (ovvero una relazione 1:1).
Lo sviluppatore deve assicurarsi che la query definita per un report restituisca un set di nodi appropriato per quel report. Tuttavia, il nodo stesso non deve contenere tutte le informazioni richieste, ma può anche essere derivato dai nodi padre e/o figlio. Ad esempio, la query utilizzata per il report Report utente utente seleziona i nodi in base al tipo di nodo (in questo caso rep:user ). Tuttavia, la maggior parte delle colonne del rapporto non riceve i dati direttamente da questi nodi, ma dai nodi secondari profile .

Coda di elaborazione

La query restituisce un set di risultati di dati da visualizzare come righe nel report. Ogni riga del set di risultati viene elaborata (lato server), in più fasi , prima di essere trasferita al client per la visualizzazione nel report.
Questo consente di:
  • Estrazione e derivazione di valori dal set di risultati sottostante.
    Ad esempio, consente di elaborare due valori di proprietà come valore singolo calcolando la differenza tra i due.
  • risoluzione dei valori estratti; questo può essere fatto in diversi modi.
    Ad esempio, i percorsi possono essere mappati su un titolo (come nel contenuto leggibile dall'utente della rispettiva proprietà jcr:title ).
  • Applicazione di filtri in diversi punti.
  • Se necessario, create dei valori composti.
    Ad esempio, costituito da un testo visualizzato all'utente, un valore da utilizzare per l'ordinamento e un URL aggiuntivo utilizzato (sul lato client) per creare un collegamento.

Flusso di lavoro della coda di elaborazione

Il seguente flusso di lavoro rappresenta la coda di elaborazione:

Fasi della coda di elaborazione

Laddove le fasi e gli elementi dettagliati siano:
  1. Trasforma i risultati restituiti dalla query iniziale (base di report) nel set di risultati di base utilizzando gli estrattori di valore.
    Gli estrattori di valore vengono scelti automaticamente a seconda del tipo di colonna. Sono utilizzati per leggere i valori dalla query JCR sottostante e creare un set di risultati da essi; dopo di che può essere successivamente applicato un ulteriore trattamento. Ad esempio, per il diff tipo, l'estrattore di valori legge due proprietà, calcola il singolo valore che viene quindi aggiunto al set di risultati. Impossibile configurare gli estrattori di valore.
  2. A quel set di risultati iniziale, contenente dati non elaborati, viene applicato il filtraggio Definizioni specifiche delle colonne iniziale (fase non elaborata).
  3. I valori sono preelaborati ; come definito per la fase di applicazione .
  4. Il filtraggio (assegnato alla fase preelaborata ) viene eseguito sui valori preelaborati.
  5. I valori sono risolti; secondo il risolutore definito .
  6. Il filtraggio (assegnato alla fase risolta ) viene eseguito sui valori risolti.
  7. I dati della matrice vengono risolti convertendola in un elenco (basato su stringhe).
    Si tratta di un passaggio implicito che converte un risultato con più valori in un elenco che può essere visualizzato; è richiesto per i valori delle celle (non aggregati) basati su proprietà JCR con più valori.
  8. I valori sono nuovamente preelaborati ; come definito per la fase afterApply .
  9. I dati sono ordinati.
  10. I dati elaborati vengono trasferiti al client.
La query iniziale che restituisce il set di risultati dei dati di base è definita per il reportbase componente.
Altri elementi della coda di elaborazione sono definiti sui columnbase componenti.

Costruzione e configurazione dei report

Per creare e configurare un rapporto sono necessari i seguenti elementi:

Posizione dei componenti del report

I componenti di reporting predefiniti sono contenuti in /libs/cq/reporting/components .
Tuttavia, si consiglia vivamente di non aggiornare tali nodi, ma di creare nodi componenti personalizzati sotto /apps/cq/reporting/components o se più appropriato /apps/<yourProject>/reports/components .
Dove (ad esempio):
N:apps 
    N:cq [nt:folder]
        N:reporting|reports [sling:Folder]
            N:components [sling:Folder]

In questo modo si crea il livello principale per il rapporto e sotto di esso, il componente base del rapporto e i componenti di base delle colonne:
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

Componente pagina

Una pagina di report deve utilizzare il sling:resourceType simbolo di /libs/cq/reporting/components/reportpage .
Nella maggior parte dei casi, non deve essere necessario personalizzare un componente pagina.

Componente base report

Ogni tipo di rapporto richiede un componente contenitore derivato da /libs/cq/reporting/components/reportbase .
Questo componente funge da contenitore per il rapporto nel suo insieme e fornisce informazioni per:
N:<reportname> [cq:Component]
    P:sling:resourceSuperType = "cq/reporting/components/reportbase"
    N:charting
    N:dialog [cq:Dialog]
    N:queryBuilder

Definizione query

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
    Può essere utilizzato per limitare il set di risultati a nodi con proprietà specifiche con valori specifici. Se vengono specificati più vincoli, il nodo deve soddisfare tutti questi vincoli (operazione AND).
    Ad esempio:
    N:propertyConstraints
     [
     N:0
     P:sling:resourceType
     P:foundation/components/textimage
     N:1
     P:jcr:modifiedBy
     P:admin
     ]
    
    
    Restituisce tutti textimage i componenti modificati per l'ultima volta dall' admin utente.
  • nodeTypes
    Utilizzato per limitare il set di risultati ai tipi di nodo specificati. È possibile specificare più tipi di nodi.
  • mandatoryProperties
    Può essere utilizzato per limitare il set di risultati ai nodi con tutte le proprietà specificate. Il valore delle proprietà non viene preso in considerazione.
Tutte le opzioni sono facoltative e possono essere combinate come necessario, ma è necessario definirne almeno una.

Definizioni grafico

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
    Contiene le definizioni per i grafici attivi.
    • active
      Poiché è possibile definire più impostazioni, è possibile utilizzarle per definire quali sono attualmente attive. Questi sono definiti da una serie di nodi (non esiste una convenzione di denominazione obbligatoria per questi nodi, ma i report standard spesso utilizzano 0 , 1 .. x ), ciascuna con la seguente proprietà:
      • id
        Identificazione dei grafici attivi. Deve corrispondere all'ID di uno dei grafici definitions .
  • definitions
    Definisce i tipi di grafico potenzialmente disponibili per il rapporto. Le definitions active impostazioni specificate verranno utilizzate.
    Le definizioni vengono specificate utilizzando un array di nodi (spesso denominati 0 , 1 .. x ), ciascuna con le seguenti proprietà:
    • id
      Identificazione del grafico.
    • type
      Tipo di grafico disponibile. Seleziona da:
      • pie Grafico a torta. Generato solo dai dati correnti.
      • lineseries Serie di linee (punti di connessione che rappresentano le istantanee effettive). Generato solo dai dati storici.
    • A seconda del tipo di grafico sono disponibili ulteriori proprietà:
      • per il tipo di grafico pie :
        • maxRadius ( Double/Long )
          Raggio massimo consentito per il grafico a torta; pertanto la dimensione massima consentita per il grafico (senza legenda). Ignorato se fixedRadius è definito.
        • minRadius ( Double/Long )
          Raggio minimo consentito per il grafico a torta. Ignorato se fixedRadius è definito.
        • fixedRadius ( Double/Long )Definisce un raggio fisso per il grafico a torta.
      • per il tipo di grafico lineseries :
        • totals ( Boolean )
          True se deve essere visualizzata una riga aggiuntiva che mostra il Totale . impostazione predefinita: false
        • series ( Long )
          Numero di righe/serie da visualizzare. default: 9 (è anche il massimo consentito)
        • hoverLimit ( Long )
          Numero massimo di istantanee aggregate (punti visualizzati su ogni linea orizzontale, che rappresentano valori distinti) per le quali devono essere visualizzati i pop-up, ossia quando l'utente passa il puntatore del mouse su un valore distinto o un'etichetta corrispondente nella legenda del grafico.
          default: 35 (ossia, se per le impostazioni correnti del grafico sono applicabili più di 35 valori distinti, non vengono visualizzati alcun pop.)
          Esiste un ulteriore limite di 10 popup che possono essere mostrati in parallelo (più popup possono essere mostrati quando il mouse sopra i testi della legenda).

Finestra di dialogo Configurazione

Ogni rapporto può avere una finestra di dialogo di configurazione, che consente all'utente di specificare vari parametri per il rapporto. Questa finestra di dialogo è accessibile tramite il pulsante Modifica quando la pagina del rapporto è aperta.
Questa finestra di dialogo è una finestra standard di CQ e può essere configurata come tale (per ulteriori informazioni, vedere CQ.Dialog ).
Esempio di finestra di dialogo:
<?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>

Sono disponibili diversi componenti preconfigurati; è possibile fare riferimento a tali elementi nella finestra di dialogo utilizzando la xtype proprietà con un valore di cqinclude :
  • title
    /libs/cq/reporting/components/commons/title
    Campo di testo per definire il titolo del rapporto.
  • description
    /libs/cq/reporting/components/commons/description
    Area di testo per definire la descrizione del rapporto.
  • processing
    /libs/cq/reporting/components/commons/processing
    Selettore per la modalità di elaborazione del rapporto (caricamento manuale o automatico dei dati).
  • scheduling
    /libs/cq/reporting/components/commons/scheduling
    Selettore per la pianificazione di istantanee per il grafico storico.
I componenti di riferimento devono essere inclusi utilizzando il .infinity.json suffisso (vedere l'esempio precedente).

Percorso directory principale

È inoltre possibile definire un percorso radice per il report:
  • rootPath
    Questo limita il rapporto a una determinata sezione (struttura ad albero o sottostruttura) del repository, consigliata per l'ottimizzazione delle prestazioni. Il percorso principale è specificato dalla rootPath proprietà del report nodo di ciascuna pagina di report (tratto dal modello al momento della creazione della pagina).
    Può essere specificato da:
    • il modello di report (come valore fisso o come valore predefinito per la finestra di dialogo di configurazione).
    • l'utente (utilizzando questo parametro)

Componente base colonna

Ogni tipo di colonna richiede un componente derivato da /libs/cq/reporting/components/columnbase .
Un componente per colonna definisce una combinazione di:
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

Query specifica per la colonna

Definisce l’estrazione dati specifica (dal set di risultati dei dati del rapporto) da utilizzare nella singola colonna.
N:definitions 
    N:queryBuilder
        P:property [String|String[]] 
        P:subPath
        P:secondaryProperty [String|String[]]
        P:secondarySubPath

  • property
    Definisce la proprietà da utilizzare per calcolare il valore effettivo della cella.
    Se la proprietà è definita come Stringa # , vengono scansionate più proprietà (in sequenza) per trovare il valore effettivo.
    Ad esempio, nel caso di:
    property = [ "jcr:lastModified", "jcr:created" ]
    L'estrattore di valore corrispondente (qui sotto il comando):
    • Verificate che sia disponibile una proprietà jcr:lastModified e, in tal caso, utilizzatela.
    • Se non è disponibile alcuna proprietà jcr:lastModified, verrà utilizzato il contenuto di jcr:created.
  • subPath
    Se il risultato non si trova sul nodo restituito dalla query, subPath definisce la posizione effettiva della proprietà.
  • secondaryProperty
    definisce una seconda proprietà che deve essere utilizzata anche per calcolare il valore effettivo della cella; questo verrà utilizzato solo per alcuni tipi di colonna (diff e sortable).
    Ad esempio, nel caso del report Istanze flusso di lavoro, la proprietà specificata viene utilizzata per memorizzare il valore effettivo della differenza di tempo (in millisecondi) tra l'ora iniziale e quella finale.
  • secondarySubPath
    Simile a subPath, se secondaryProperty utilizzato.
Nella maggior parte dei casi, property verrà utilizzato solo.

Filtro client

Il filtro client estrae le informazioni da visualizzare dai dati restituiti dal server.
Questo filtro viene eseguito sul lato client, dopo che è stata applicata l'intera elaborazione sul lato server.
N:definitions
    N:data
        P:clientFilter [String]

clientFilter è definita come funzione JavaScript che:
  • come input, riceve un parametro; i dati restituiti dal server (così preelaborati)
  • come output, restituisce il valore filtrato (elaborato); i dati estratti o derivati dalle informazioni di input
L’esempio seguente estrae il percorso di pagina corrispondente da un percorso di componente:
function(v) {
    var sepPos = v.lastIndexOf('/jcr:content');
    if (sepPos < 0) {
        return v;
    }
    return v.substring(sepPos + '/jcr:content'.length, v.length);
}

Risolutori e pre-elaborazione

La coda di elaborazione definisce i vari risolutori e configura la preelaborazione:
N:definitions
    N:data
        P:resolver
        N:resolverConfig
        N:preprocessing
            N:apply
            N:applyAfter

  • resolver
    Definisce il risolutore da utilizzare. Sono disponibili i seguenti risolutori:
    • const
      Mappa i valori ad altri valori; ad esempio, viene utilizzato per risolvere costanti come en il valore equivalente English .
    • default
      Il risolutore predefinito. Questo è un risolutore fittizio che in realtà non risolve nulla.
    • page
      risolve un valore di percorso al percorso della pagina appropriata; più precisamente, al jcr:content nodo corrispondente. Ad esempio, /content/.../page/jcr:content/par/xyz è risolto in /content/.../page/jcr:content .
    • path
      Risolve un valore di percorso aggiungendo facoltativamente un percorso secondario e prendendo il valore effettivo da una proprietà del nodo (come definita da resolverConfig ) nel percorso risolto. Ad esempio, una path di /content/.../page/jcr:content queste proprietà può essere risolta nel contenuto della jcr:title proprietà, il che significa che il percorso di pagina viene risolto nel titolo della pagina.
    • pathextension
      Risolve un valore anteponendo un percorso e prendendo il valore effettivo da una proprietà del nodo nel percorso risolto. Ad esempio, un valore de potrebbe essere preceduto da un percorso, ad esempio /libs/wcm/core/resources/languages , che estrae il valore dalla proprietà language , per risolvere il codice del paese de alla descrizione della lingua German .
  • resolverConfig
    Fornisce le definizioni per il risolutore; le opzioni disponibili dipendono dalla resolver selezione:
    • const
      Utilizzare le proprietà per specificare le costanti per la risoluzione. Il nome della proprietà definisce la costante da risolvere; il valore della proprietà definisce il valore risolto.
      Ad esempio, una proprietà con Name = 1 e Value =One verrà risolta da 1 a 1.
    • default
      Nessuna configurazione disponibile.
    • page
      • propertyName (facoltativo)
        Definisce il nome della proprietà da utilizzare per risolvere il valore. Se non viene specificato, viene utilizzato il valore predefinito jcr:title (titolo della pagina); per il page risolutore, questo significa che prima il percorso viene risolto sul percorso della pagina, quindi ulteriormente risolto nel titolo della pagina.
    • path
      • propertyName (facoltativo)
        Specifica il nome della proprietà da utilizzare per risolvere il valore. Se non viene specificato, jcr:title viene utilizzato il valore predefinito di.
      • subPath (facoltativo)
        Questa proprietà può essere utilizzata per specificare un suffisso da aggiungere al percorso prima della risoluzione del valore.
    • pathextension
      • path (mandatory)
        Definisce il percorso da anteporre.
      • propertyName (mandatory)
        Definisce la proprietà sul percorso risolto in cui si trova il valore effettivo.
      • i18n (facoltativo; type Boolean)
        Stabilisce se il valore risolto deve essere internazionalizzato (ad es. utilizzando i servizi di internazionalizzazione di CQ5).
  • preprocessing
    La preelaborazione è facoltativa e può essere associata (separatamente) alle fasi di elaborazione applicata o applicataDopo :

Resolver

I risolutori vengono utilizzati per estrarre le informazioni richieste. Alcuni esempi di risolutori sono:
Contenuti
Di seguito viene risolto un valore di contenuto pari VersionCreated alla stringa New version created .
Vedi /libs/cq/reporting/components/auditreport/typecol/definitions/data .
N:data
    P:resolver=const
    N:resolverConfig
        P:VersionCreated="New version created"

Pagina
Risolve un valore di percorso alla proprietà jcr:description sul nodo jcr:content (figlio) della pagina corrispondente.
Vedi /libs/cq/reporting/components/compreport/pagecol/definitions/data .
N:data
    P:resolver=page
    N:resolverConfig
        P:propertyName="jcr:description"

Percorso
Di seguito viene risolto un percorso /content/.../page al contenuto della jcr:title proprietà, il che significa che il percorso di pagina viene risolto nel titolo della pagina.
Vedi /libs/cq/reporting/components/auditreport/pagecol/definitions/data .
N:data
    P:resolver=path
    N:resolverConfig
        P:propertyName="jcr:title"
        P:subPath="/jcr:content"

Estensione percorso
Di seguito viene anteposto un valore de con l'estensione percorso /libs/wcm/core/resources/languages , quindi il valore della proprietà language , per risolvere il codice del paese de alla descrizione della lingua German .
Vedi /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"

Pre-elaborazione

La preprocessing definizione può essere applicata a:
  • valore originale:
    La definizione di preelaborazione per il valore originale viene specificata su apply e/o applyAfter direttamente.
  • nel suo stato aggregato:
    Se necessario, è possibile fornire una definizione separata per ogni aggregazione.
    Per specificare la preelaborazione esplicita per i valori aggregati, le definizioni di preelaborazione devono risiedere su un rispettivo nodo aggregated secondario ( apply/aggregated , applyAfter/aggregated ). Se è richiesta la preelaborazione esplicita per aggregati distinti, la definizione di preelaborazione è collocata su un nodo secondario con il nome del rispettivo aggregato (ad esempio apply/aggregated/min/max o altri aggregati).
Durante la preelaborazione potete specificare una delle seguenti opzioni:
  • trova e sostituisce i pattern Una volta trovati, il pattern specificato (definito come espressione regolare) viene sostituito da un altro pattern; ad esempio, può essere utilizzato per estrarre una sottostringa dell'originale.
  • Converte un valore numerico in una stringa relativa; ad esempio, il valore "che rappresenta una differenza di ora di 1 ora" viene risolto in una stringa come 1:24PM (1 hour ago) .
Ad esempio:
N:definitions
    N:data
        N:preprocessing
            N:apply|applyAfter
                P:pattern         // regex
                P:replace         // replacement for regex
                // and/or
                P:format          // data type formatter

Pre-elaborazione - Trova e sostituisci pattern

Per la preelaborazione è possibile specificare un pattern (definito come espressione Regular_expression regolare o regex) che si trova e quindi viene sostituito dal replace pattern:
  • pattern
    Espressione regolare utilizzata per individuare una sottostringa.
  • replace
    Stringa o rappresentazione della stringa che verrà utilizzata come sostituzione della stringa originale. Spesso questo rappresenta una sottostringa della stringa situata nell'espressione regolare pattern .
Un esempio di sostituzione può essere suddiviso come:
  • Per il nodo definitions/data/preprocessing/apply con le due seguenti proprietà:
    • pattern : (.*)(/jcr:content)(/|$)(.*)
    • replace : $1
  • Stringa in arrivo come:
    • /content/geometrixx/en/services/jcr:content/par/text
  • Saranno suddivise in quattro sezioni:
    • $1 - (.*) - /content/geometrixx/en/services
    • $2 - (/jcr:content) - /jcr:content
    • $3 - (/|$) - /
    • $4 - (.*) - par/text
  • E sostituito con la stringa rappresentata da $1 :
    • /content/geometrixx/en/services

Pre-elaborazione - Tipo di dati

Questi formati convertono un valore numerico in una stringa relativa.
Ad esempio, può essere utilizzato per una colonna temporale che consente min , avg e max aggrega. Gli aggregati min / avg / max vengono visualizzati come una differenza di ** tempo (ad esempio 10 days ago ) richiedono un formattatore di dati. A questo scopo, viene applicato un datedelta formattatore ai valori min / avg / max aggregati. Se è disponibile anche un count 'aggregazione, non è necessario un formattatore, né il valore originale.
Attualmente i formati dei tipi di dati disponibili sono:
  • format
    Formattatore tipo dati:
    • duration
      La durata è l'intervallo di tempo tra due date definite. Ad esempio, l’inizio e la fine di un’azione del flusso di lavoro che richiedeva 1 ora, a partire dalle 13/13/11 11:23 e fino a un’ora dopo alle 13/13/11 12:23.
      Converte un valore numerico (interpretato come millisecondi) in una stringa di durata; ad esempio, 30000 è formattato come * 30s .*
    • datedelta
      Datadelta è l'intervallo di tempo tra una data passata e quella "ora" (quindi avrà un risultato diverso se il rapporto viene visualizzato in un momento successivo).
      Converte il valore numerico (interpretato come differenza di ora in giorni) in una stringa data relativa. Ad esempio, 1 è formattato come 1 giorno fa.
L'esempio seguente definisce datedelta la formattazione per min e max gli aggregati:
N:definitions
    N:data
        N:preprocessing
            N:apply
                N:aggregated
                    N:min
                        P:format = "datedelta"
                    N:max
                        P:format = "datedelta"

Definizioni specifiche delle colonne

Le definizioni specifiche della colonna definiscono i filtri e gli aggregati disponibili per quella colonna.
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
    Sono disponibili le seguenti opzioni standard:
    • string
    • number
    • int
    • date
    • diff
    • timeslot
      Viene utilizzato per estrarre parti di una data necessarie per l'aggregazione (ad esempio, gruppi per anno per ottenere i dati aggregati per ogni anno).
    • sortable
      Viene utilizzato per i valori che utilizzano valori diversi (ricavati da proprietà diverse) per l'ordinamento e la visualizzazione. Inoltre. uno dei valori di cui sopra può essere definito come valore multiplo; ad esempio, string[] definisce un array di stringhe.
    L'estrattore di valori viene scelto in base al tipo di colonna. Se per un tipo di colonna è disponibile un estrattore di valori, viene utilizzato questo estrattore. In caso contrario viene utilizzato l'estrattore di valore predefinito.
    Un tipo può (facoltativamente) accettare un parametro. Ad esempio, timeslot:year estrae l'anno da un campo data. Tipi con i relativi parametri:
    • timeslot - I valori sono paragonabili alle costanti corrispondenti di java.utils.Calendar .
      • 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
    Definisce se il rapporto può essere raggruppato per questa colonna.
  • filters
    Definizioni dei filtri.
    • filterType
      I filtri disponibili sono:
      • string
        Filtro basato su stringa.
    • id
      Identificatore filtro.
    • phase
      Fasi disponibili:
      • raw
        Il filtro viene applicato ai dati non elaborati.
      • preprocessed
        Il filtro viene applicato ai dati preelaborati.
      • resolved
        Il filtro viene applicato ai dati risolti.
  • aggregates
    Aggrega definizioni.
    • text
      Nome testuale dell'aggregazione. Se non text viene specificato, verrà utilizzata la descrizione predefinita dell'aggregato; ad esempio, minimum verrà utilizzata per l' min aggregazione.
    • type
      Tipo di aggregazione. Gli aggregati disponibili sono:
      • count
        Conta il numero di righe.
      • count-nonempty
        Conta il numero di righe non vuote.
      • min
        Fornisce il valore minimo.
      • max
        Fornisce il valore massimo.
      • average
        Fornisce il valore medio.
      • sum
        Fornisce la somma di tutti i valori.
      • median
        Fornisce il valore medio.
      • percentile95
        Prende il 95° percentile di tutti i valori.

Valori predefiniti colonna

Viene utilizzato per definire i valori predefiniti per la colonna:
N:defaults
    P:aggregate

Eventi e azioni

Edit Configuration (Modifica configurazione) definisce gli eventi necessari ai listener per rilevare e le azioni da applicare dopo che si sono verificati tali eventi. Per informazioni di base, consultate l' introduzione allo sviluppo di componenti.
È necessario definire i seguenti valori per garantire che tutte le azioni richieste siano soddisfatte:
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"

Colonne generiche

Le colonne generiche sono un'estensione in cui (la maggior parte) le definizioni di colonna sono memorizzate nell'istanza del nodo di colonna (anziché nel nodo del componente).
Usano una finestra di dialogo (standard), personalizzata, per il singolo componente generico. Questa finestra di dialogo consente all'utente del rapporto di definire le proprietà delle colonne di una colonna generica nella pagina del rapporto (utilizzando l'opzione di menu Proprietà colonna... ).
Un esempio è la colonna Generico del report ​utente; vedi /libs/cq/reporting/components/userreport/genericcol .
Per creare una colonna generica:
  • Impostare la type proprietà del definition nodo della colonna su generic .
    Vedi /libs/cq/reporting/components/userreport/genericcol/definitions
  • Specificate una definizione di finestra di dialogo (standard) sotto il definition nodo della colonna.
    Vedi /libs/cq/reporting/components/userreport/genericcol/definitions/dialog
    • I campi della finestra di dialogo devono fare riferimento agli stessi nomi della proprietà del componente corrispondente (incluso il percorso).
      Ad esempio, se si desidera rendere configurabile il tipo di colonna generica tramite la finestra di dialogo, utilizzare un campo con il nome di ./definitions/type .
    • Le proprietà definite mediante l’interfaccia o la finestra di dialogo hanno la precedenza su quelle definite per il columnbase componente.
  • Definite Edit Configuration (Modifica configurazione).
    Vedi /libs/cq/reporting/components/userreport/genericcol/cq:editConfig
  • Utilizzate metodologie standard AEM per definire (ulteriori) proprietà delle colonne.
    Tenere presente che per le proprietà definite nelle istanze di componenti e colonne, il valore nell’istanza di colonna ha la precedenza.
    Le proprietà disponibili per una colonna generica sono:
    • jcr:title - nome colonna
    • definitions/aggregates - aggregati
    • definitions/filters - filtri
    • definitions/type - il tipo di colonna (deve essere definito nella finestra di dialogo, utilizzando un selettore/una casella di controllo o un campo nascosto)
    • definitions/data/resolver e definitions/data/resolverConfig (ma non definitions/data/preprocessing o .../clientFilter ) - il risolutore e la configurazione
    • definitions/queryBuilder - la configurazione del generatore di query
    • defaults/aggregate - aggregato predefinito
    Nel caso di una nuova istanza della colonna generica nel report ​utente, le proprietà definite con la finestra di dialogo vengono mantenute in:
    /etc/reports/userreport/jcr:content/report/columns/genericcol/settings/generic

Progettazione report

La struttura definisce i tipi di colonna disponibili per la creazione di un rapporto. Definisce inoltre il sistema paragrafo a cui vengono aggiunte le colonne.
Si consiglia vivamente di creare una singola progettazione per ciascun rapporto. Ciò garantisce la massima flessibilità. Vedere anche Definizione del nuovo rapporto .
I componenti di reporting predefiniti sono contenuti in /etc/designs/reports .
La posizione dei rapporti può dipendere dalla posizione in cui si trovano i componenti:
  • /etc/designs/reports/<yourReport> è adatto se il rapporto è situato sotto /apps/cq/reporting
  • /etc/designs/<yourProject>/reports/<*yourReport*> per report che utilizzano il /apps/<yourProject>/reports pattern
Le proprietà di progettazione richieste sono registrate jcr:content/reportpage/report/columns (ad esempio, /etc/designs/reports/<reportName>/jcr:content/reportpage/report/columns ) in:
  • components
    Qualsiasi componente e/o gruppo di componenti consentiti nel rapporto.
  • sling:resourceType
    Proprietà con valore cq/reporting/components/repparsys .
Un frammento di progettazione di esempio (tratto dalla progettazione del rapporto sul componente) è:
<!-- ... -->
    <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>
<!-- ... -->

Non è necessario specificare le strutture per singole colonne. Le colonne disponibili possono essere definite in modalità di progettazione.
È consigliabile non apportare modifiche alle strutture dei rapporti standard. In questo modo si evita di perdere eventuali modifiche durante l'aggiornamento o l'installazione degli hotfix.
Per personalizzare un rapporto standard, copiate il rapporto e la relativa progettazione.
Le colonne predefinite possono essere create automaticamente quando viene creato un rapporto. Questi sono specificati nel modello.

Modello rapporto

Ogni tipo di rapporto deve fornire un modello. Si tratta di modelli Modelli CQ standard e possono essere configurati come tali.
Il modello deve:
  • imposta sling:resourceType su cq/reporting/components/reportpage
  • indicare la progettazione da utilizzare
  • creare un nodo report secondario che faccia riferimento al componente contenitore ( reportbase ) tramite la sling:resourceType proprietà
Un frammento di modello di esempio (tratto dal modello di rapporto dei componenti) è:
<!-- ... -->
    <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>
<!-- .. -->

Un frammento di modello di esempio che mostra la definizione del percorso principale (tratto dal modello di rapporto utente) è:
<!-- ... -->
    <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>
<!-- .. -->

I modelli di reporting predefiniti sono disponibili in /libs/cq/reporting/templates .
Tuttavia, si consiglia vivamente di non aggiornare tali nodi, ma di creare nodi componenti personalizzati sotto /apps/cq/reporting/templates o se più appropriato /apps/<yourProject>/reports/templates .
Dove, ad esempio (vedere anche Posizione dei componenti per report):
N:apps 
    N:cq [nt:folder]
        N:reporting|reports [sling:Folder]
            N:templates [sling:Folder]

In questa sezione viene creata la directory principale per il modello:
N:apps 
    N:cq [nt:folder]
        N:reporting|reports [sling:Folder]
            N:templates [sling:Folder]
                N:<reportname> [sling:Folder]

Creazione Di Un Rapporto Personale - Un Esempio

Definizione del nuovo rapporto

Per definire un nuovo rapporto è necessario creare e configurare:
  1. Radice per i componenti del report.
  2. Il componente base del report.
  3. Uno o più componenti a base di colonna.
  4. La struttura del report.
  5. Livello principale per il modello di rapporto.
  6. Modello di rapporto.
Per illustrare questi passaggi, l'esempio seguente definisce un rapporto in cui sono elencate tutte le configurazioni OSGi all'interno del repository; ovvero tutte le istanze del sling:OsgiConfig nodo.
Copiare un rapporto esistente e quindi personalizzare la nuova versione è un metodo alternativo.
  1. Crea il nodo principale per il nuovo report.
    Ad esempio, sotto /apps/cq/reporting/components/osgireport .
    N:cq [nt:folder]
        N:reporting [sling:Folder]
            N:components [sling:Folder]
                N:osgireport [sling:Folder]
    
    
  2. Definite la base di report. Ad esempio osgireport[cq:Component] sotto /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"
    
    
    Definisce un componente base di report che:
    • cerca tutti i nodi di tipo sling:OsgiConfig
    • visualizza sia pie che lineseries grafici
    • fornisce una finestra di dialogo che consente all'utente di configurare il rapporto
  3. Definire il primo componente di colonna (columnbase). Ad esempio bundlecol[cq:Component] sotto /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"
    
    
    Definisce un componente base di colonna che:
    • cerca e restituisce il valore ricevuto dal server; in questo caso, la proprietà jcr:path per ogni sling:OsgiConfig nodo
    • fornisce l' count aggregazione
    • non raggruppabile
    • ha il titolo Bundle (titolo della colonna all'interno della tabella)
    • si trova nel gruppo della barra laterale OSGi Report
    • aggiorna in corrispondenza di eventi specificati
    In questo esempio non esistono definizioni di N:data e P:clientFilter . Questo perché il valore ricevuto dal server viene restituito su base 1:1, che è il comportamento predefinito.
    Si tratta delle stesse definizioni:
    N:data [nt:unstructured]
      P:clientFilter [String] = "function(v) { return v; }"
    
    
    Se la funzione restituisce semplicemente il valore ricevuto.
  4. Definite la struttura del rapporto. Ad esempio osgireport[cq:Page] sotto /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. Crea il nodo principale per il nuovo modello di rapporto.
    Ad esempio, sotto /apps/cq/reporting/templates/osgireport .
    N:cq [nt:folder]
        N:reporting [sling:Folder]
            N:templates [sling:Folder]
                N:osgireport [cq:Template]
    
    
  6. Definite il modello di rapporto. Ad esempio osgireport[cq:Template] sotto /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]
    
    
    Definisce un modello che:
    • definisce i rapporti allowedPaths risultanti, nel caso precedente in qualsiasi punto della sezione /etc/reports
    • fornisce titoli e descrizioni per il modello
    • fornisce un'immagine in miniatura da utilizzare nell'elenco dei modelli (la definizione completa di questo nodo non è elencata sopra - è più semplice copiare un'istanza di thumbnail.png da un report esistente).

Creazione di un'istanza del nuovo rapporto

È ora possibile creare un'istanza del nuovo rapporto:
  1. Open the Tools console.
  2. Selezionate Rapporti nel riquadro a sinistra.
  3. Poi Nuovo... dalla barra degli strumenti. Definite un titolo e un nome , selezionate il nuovo tipo di rapporto (il modello di rapporto OSGi) dall’elenco dei modelli, quindi fate clic su Crea .
  4. La nuova istanza di report verrà visualizzata nell'elenco. Fate doppio clic su questo per aprire.
  5. Trascinate un componente (ad esempio, Bundle nel gruppo di rapporti ​OSGi) dalla barra laterale per creare la prima colonna e avviare la definizione del rapporto.
    Poiché in questo esempio non sono presenti colonne raggruppabili, i grafici non saranno disponibili. Per visualizzare i grafici, impostate groupable su true :
    N:osgireport [sling:Folder]
    N:bundlecol [cq:Component]
    N:definitions [nt:unstructured]
    P:groupable [Boolean] = true
    
    

Configurazione dei servizi del framework di report

Questa sezione descrive le opzioni di configurazione avanzate per i servizi OSGi che implementano il framework dei report.
Per visualizzarli, usate il menu Configurazione della console Web (disponibile ad esempio in http://localhost:4502/system/console/configMgr ). When working with AEM there are several methods of managing the configuration settings for such services; see Configuring OSGi for more details and the recommended practices.

Servizio di base (Configurazione del reporting di CQ Day)

  • Fuso orario definisce i dati storici relativi al fuso orario per cui vengono creati. In questo modo, il grafico storico visualizzerà gli stessi dati per ogni utente in tutto il mondo.
  • Le impostazioni internazionali definiscono le impostazioni internazionali da utilizzare insieme al Fuso orario per i dati storici. Le impostazioni internazionali vengono utilizzate per determinare alcune impostazioni di calendario specifiche per le impostazioni internazionali, ad esempio se il primo giorno di una settimana è domenica o lunedì.
  • Il percorso dell'istantanea definisce il percorso principale in cui sono memorizzate le istantanee dei grafici storici.
  • Il percorso dei rapporti definisce il percorso in cui si trovano i rapporti. Questo viene utilizzato dal servizio di snapshot per determinare i report per i quali eseguire effettivamente delle istantanee.
  • Le istantanee giornaliere definiscono l'ora di ogni giorno in cui vengono scattate le istantanee giornaliere. L'ora specificata è nel fuso orario locale del server.
  • Le istantanee orarie definiscono il minuto di ogni ora in cui vengono scattate le istantanee orarie.
  • Righe (max) definisce il numero massimo di righe memorizzate per ogni snapshot. Tale valore dovrebbe essere scelto in modo ragionevole; se è troppo alto, questo influirà sulle dimensioni del repository, se troppo basso, i dati potrebbero non essere precisi a causa del modo in cui vengono gestiti i dati storici.
  • I dati falsi, se attivati, possono essere creati falsi dati storici utilizzando il fakedata selettore; se disabilitato, l'utilizzo del fakedata selettore genererà un'eccezione.
    Poiché i dati sono falsi, devono essere utilizzati solo a scopo di test e debug.
    L'utilizzo del fakedata selettore finirà implicitamente il rapporto, in modo che tutti i dati esistenti andranno persi; i dati possono essere ripristinati manualmente, ma questo può richiedere molto tempo.
  • Utente snapshot definisce un utente facoltativo che può essere utilizzato per scattare istantanee.
    In sostanza, vengono effettuate istantanee per l’utente che ha completato il rapporto. Potrebbero verificarsi situazioni (ad esempio in un sistema di pubblicazione, in cui l’utente non esiste in quanto il suo account non è stato replicato) in cui si desidera specificare un utente fallback da utilizzare.
    Inoltre, la specifica di un utente potrebbe comportare un rischio per la sicurezza.
  • Applica agli utenti snapshot, se abilitata, tutte le istantanee verranno scattate con l'utente specificato in Utente ** snapshot. Questo potrebbe avere gravi conseguenze sulla sicurezza se non gestito correttamente.

Impostazioni cache (cache di reporting di CQ Day)

  • Abilita consente di abilitare o disabilitare la memorizzazione nella cache dei dati del rapporto. Se si abilita la cache dei report, i dati dei report rimarranno in memoria durante diverse richieste. Ciò può migliorare le prestazioni, ma comporta un maggiore consumo di memoria e, in circostanze estreme, può causare una perdita di memoria.
  • TTL definisce il tempo (in secondi) per il quale i dati del rapporto vengono memorizzati nella cache. Un numero più elevato aumenterà le prestazioni, ma potrebbe anche restituire dati imprecisi se i dati cambiano nel periodo di tempo.
  • Il numero massimo di voci definisce il numero massimo di rapporti da memorizzare nella cache contemporaneamente.
I dati del rapporto possono essere diversi per ciascun utente e lingua. Pertanto, i dati del rapporto sono memorizzati nella cache per rapporto, utente e lingua. Ciò significa che un valore Max immette i dati nella cache 2 di uno dei due elementi:
  • un rapporto per due utenti con impostazioni di lingua diverse
  • un utente e due rapporti