Sviluppo di rapporti developing-reports
Adobe Experience Manager (AEM) offre una selezione di rapporti standard la maggior parte di essi si basa su un framework di reporting.
Utilizzando il framework è possibile estendere questi rapporti standard o sviluppare nuovi rapporti personalizzati. Il framework di reporting si integra strettamente con i concetti e i principi CQ5 esistenti in modo che gli sviluppatori possano utilizzare le loro conoscenze esistenti di CQ5 come trampolino di lancio per lo sviluppo di rapporti.
Per le relazioni standard trasmesse con l’AEM:
-
Questi rapporti si basano sul framework di reporting:
-
Le seguenti relazioni si basano su singoli principi e pertanto non possono essere estese:
-
Ogni riga definisce un nodo o una proprietà in cui:
N:<name> [<nodeType>]
: descrive un nodo denominato<*name*>
e tipo di nodo di<*nodeType*>
.P:<name> [<propertyType]
: descrive una proprietà denominata<*name*>
e un tipo di proprietà di<*propertyType*>
.P:<name> = <value>
: descrive una proprietà<name>
che deve essere impostato 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[]
indica che la proprietà può essere String o String[]. -
[]
rappresenta un array, ad esempio Stringa[] o un array di nodi come in Definizione query.
- Nodi -
nt:unstructured
- Proprietà -
String
Framework di reporting reporting-framework
Il quadro di riferimento per le relazioni si basa sui seguenti principi:
-
È interamente basato su set di risultati restituiti da una query eseguita dal QueryBuilder CQ5.
-
Il set di risultati definisce i dati visualizzati nel rapporto. Ogni riga del set di risultati corrisponde a una riga nella vista a tabella del rapporto.
-
Le operazioni disponibili per l'esecuzione sul set di risultati assomigliano a concetti RDBMS; principalmente raggruppamento e aggregazione.
-
La maggior parte del recupero e dell’elaborazione dei dati viene effettuata lato server.
-
Il cliente è l’unico responsabile della visualizzazione dei dati preelaborati. Solo le attività di elaborazione minori (ad esempio, la creazione di collegamenti nel contenuto delle celle) vengono eseguite sul lato client.
Il framework di reporting (illustrato dalla struttura di un rapporto standard) utilizza i seguenti blocchi predefiniti, alimentati dalla coda di elaborazione:
Pagina report report-page
La pagina del rapporto è:
- Una pagina CQ5 standard.
- Basato su modello CQ5 standard, configurato per il rapporto.
Base rapporto report-base
Il reportbase
componente costituisce la base di qualsiasi rapporto in quanto:
-
Mantiene la definizione del query che fornisce il set di risultati sottostante dei dati.
-
Si tratta di un sistema paragrafo adattato che contiene tutte le colonne (
columnbase
) aggiunto al report. -
Definisce quali tipi di grafico sono disponibili e quali sono attualmente attivi.
-
Definisce la finestra di dialogo Modifica, che consente all'utente di configurare alcuni aspetti del report.
Base colonna column-base
Ogni colonna è un’istanza del columnbase
componente che:
- È un paragrafo, utilizzato dal parsys (
reportbase
) della rispettiva relazione. - Definisce il collegamento al set di risultati sottostante. In altre parole, definisce i dati specifici a cui si fa riferimento all’interno di questo set di risultati e il modo in cui vengono elaborati.
- Mantiene definizioni aggiuntive, ad esempio gli aggregati e i filtri disponibili, insieme a eventuali valori predefiniti.
Query e recupero dati the-query-and-data-retrieval
La query:
-
è definito come parte della
reportbase
componente. -
È basato 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. Informazioni specifiche per singole colonne viene quindi estratto da questo set di dati.
-
Di solito è costituito da:
-
Un percorso di directory principale.
Specifica la sottostruttura del repository in cui eseguire la ricerca.
Per ridurre al minimo l’impatto sulle prestazioni, è consigliabile (provare a) limitare la query a una sottostruttura specifica dell’archivio. Il percorso della directory principale può essere predefinito nel modello di report o impostato dall’utente in Finestra di dialogo Configurazione (Modifica).
-
Questi vengono imposti per produrre il set di risultati (iniziale); includono, ad esempio, restrizioni sul tipo di nodo o vincoli di proprietà.
-
Il punto chiave in questo caso è che ogni singolo nodo restituito nel set di risultati della query viene utilizzato per generare una singola riga sul report (quindi 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, che possono anche essere derivate dai nodi padre e/o figlio. Ad esempio, la query utilizzata per Report utente seleziona i nodi in base al tipo di nodo (in questo caso rep:user
). Tuttavia, la maggior parte delle colonne in questo report non prende i propri dati direttamente da questi nodi, ma dai nodi figlio profile
.
Coda di elaborazione processing-queue
Il 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 diverse fasi, prima di essere trasferito al client per la visualizzazione nel report.
Ciò consente di:
-
Estrazione e derivazione dei valori dal set di risultati sottostante.
Ad esempio, ti consente di elaborare due valori di proprietà come un singolo valore calcolando la differenza tra i due.
-
Risoluzione dei valori estratti; questa operazione può essere eseguita in vari modi.
Ad esempio, i percorsi possono essere mappati su un titolo (come nel contenuto più leggibile degli jcr:title proprietà ).
-
Applicazione di filtri in vari punti.
-
Se necessario, create i valori composti.
Ad esempio, costituito da un testo visualizzato dall’utente, da un valore da utilizzare per l’ordinamento e da un URL aggiuntivo utilizzato (sul lato client) per la creazione di un collegamento.
Flusso di lavoro della coda di elaborazione workflow-of-the-processing-queue
Il seguente flusso di lavoro rappresenta la coda di elaborazione:
Fasi della coda di elaborazione phases-of-the-processing-queue
Se le fasi e gli elementi dettagliati sono:
-
Trasforma i risultati restituiti da query iniziale (reportbase) nel set di risultati di base utilizzando gli estrattori di valore.
Gli estrattori di valore vengono scelti automaticamente in base al tipo di colonna. Vengono utilizzati per leggere i valori dalla query JCR sottostante e creare un set di risultati da essi; dopo di che è possibile applicare ulteriori elaborazioni. Ad esempio, per
diff
testo, l'estrattore di valore legge due proprietà, calcola il singolo valore che viene quindi aggiunto al set di risultati. Impossibile configurare gli estrattori di valore. -
A tale set di risultati iniziale, contenente dati non elaborati, filtro iniziale (raw fase di sviluppo).
-
I valori sono pre-elaborato; come definito per applica fase.
-
Filtraggio (assegnato al pre-elaborato fase) viene eseguito sui valori preelaborati.
-
I valori vengono risolti in base alla resolver definito.
-
Filtraggio (assegnato al risolto fase) viene eseguito sui valori risolti.
-
I dati sono raggruppati e aggregati.
-
I dati della matrice vengono risolti convertendoli in un elenco (basato su stringhe).
Questo è un passaggio implicito che converte un risultato con più valori in un elenco che può essere visualizzato; è obbligatorio per i valori delle celle (non aggregati) basati su proprietà JCR con più valori.
-
I valori sono di nuovo pre-elaborato; come definito per afterApply fase.
-
I dati sono ordinati.
-
I dati elaborati vengono trasferiti al client.
reportbase
componente.columnbase
componenti.Costruzione e configurazione dei rapporti report-construction-and-configuration
Per creare e configurare un rapporto sono necessari i seguenti elementi:
Posizione dei componenti del rapporto location-of-report-components
Le componenti di reporting predefinite sono detenute sotto /libs/cq/reporting/components
.
Tuttavia, si consiglia di non aggiornare questi nodi, ma di creare nodi di componenti personalizzati in /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 caso, puoi creare la directory principale del report e, sotto, il componente base del report e i componenti base della colonna:
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 page-component
Una pagina di report deve utilizzare sling:resourceType
di /libs/cq/reporting/components/reportpage
.
Un componente pagina personalizzato non dovrebbe essere necessario (in genere).
Componente base rapporto report-base-component
Ogni tipo di report richiede un componente contenitore derivato da /libs/cq/reporting/components/reportbase
.
Questo componente funge da contenitore per il rapporto nel suo complesso e fornisce informazioni per:
- Il definizione query.
- Un (facoltativo) finestra di dialogo per la configurazione del rapporto.
- Qualsiasi Grafici che sono integrati con il rapporto.
N:<reportname> [cq:Component]
P:sling:resourceSuperType = "cq/reporting/components/reportbase"
N:charting
N:dialog [cq:Dialog]
N:queryBuilder
Definizione query query-definition
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
Limita il set di risultati ai nodi con proprietà specifiche con valori specifici. Se sono specificati più vincoli, il nodo deve soddisfare tutti (operazione AND).
Ad esempio:
code language-none N:propertyConstraints [ N:0 P:sling:resourceType P:foundation/components/textimage N:1 P:jcr:modifiedBy P:admin ]
Restituirebbe tutto
textimage
componenti che sono stati modificati l’ultima volta daadmin
utente. -
nodeTypes
Utilizzato per limitare il set di risultati ai tipi di nodo specificati. È possibile specificare più tipi di nodo.
-
mandatoryProperties
Limita il set di risultati ai nodi con tutto le proprietà specificate. Il valore delle proprietà non è considerato per.
Tutti sono facoltativi e possono essere combinati in base alle necessità, ma è necessario definirne almeno uno.
Definizioni del grafico chart-definitions
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 un array di nodi (non esiste una convenzione di denominazione obbligatoria per questi nodi, ma i rapporti standard utilizzano spesso
0
,1
…x
), aventi ciascuna le seguenti 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 report. Il
definitions
da utilizzare è specificato daactive
impostazioni.Le definizioni vengono specificate utilizzando un array di nodi (di nuovo spesso denominati
0
,1
…x
), ciascuno dei quali presenta 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 collegamento che rappresentano gli snapshot effettivi). Generato solo da dati storici.
-
-
Sono disponibili proprietà aggiuntive, a seconda del tipo di grafico:
-
per il tipo di grafico
pie
:-
maxRadius
(Double/Long
)Raggio massimo consentito per il grafico a torta, quindi 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 viene visualizzata una riga aggiuntiva contenente Totale devono essere visualizzati.
impostazione predefinita:false
-
series
(Long
)Numero di righe/serie da visualizzare.
impostazione predefinita:9
(questo è 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 popup. ovvero quando l'utente passa il mouse su un valore distinto o su un'etichetta corrispondente nella legenda del grafico.
impostazione predefinita:
35
In altre parole, non vengono visualizzati pop-up se sono applicabili più di 35 valori distinti per le impostazioni correnti del grafico.Esiste un limite aggiuntivo di dieci pop-up che possono essere visualizzati in parallelo (è possibile visualizzare più pop-up quando si passa il mouse sui testi delle legende).
-
-
-
Finestra di dialogo di configurazione configuration-dialog
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 Modifica quando la pagina del report è aperta.
Questa finestra di dialogo è un CQ standard finestra di dialogo e può essere configurato come tale (vedi CQ.Dialog per ulteriori informazioni).
Di seguito è riportato un 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 a cui è possibile fare riferimento nella finestra di dialogo utilizzando xtype
proprietà con valore 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/automatico dei dati).
-
scheduling
/libs/cq/reporting/components/commons/scheduling
Selettore per la pianificazione di snapshot per il grafico cronologico.
.infinity.json
(vedi esempio precedente).Percorso directory principale root-path
Inoltre, è possibile definire un percorso principale per il rapporto:
-
rootPath
Questo limita il report a una determinata sezione (albero o sottoalbero) dell’archivio, consigliata per l’ottimizzazione delle prestazioni. Il percorso della directory principale è specificato da
rootPath
proprietà delreport
di ogni pagina di rapporto (tratto dal modello al momento della creazione della pagina).Può essere specificato da:
- il modello di report (come valore fisso o predefinito per la finestra di dialogo di configurazione).
- utente (utilizzando questo parametro)
Componente base colonna column-base-component
Ogni tipo di colonna richiede un componente derivato da /libs/cq/reporting/components/columnbase
.
Un componente colonna definisce una combinazione dei seguenti elementi:
- Il Query specifica per colonna configurazione.
- Il Resolver e pre-elaborazione.
- Il Definizioni specifiche delle colonne (ad esempio filtri e aggregati;
definitions
nodo figlio). - Valori predefiniti colonna.
- Il Filtro client per estrarre le informazioni per la visualizzazione dai dati restituiti dal server.
- Inoltre, un componente colonna deve fornire un’istanza appropriata di
cq:editConfig
. per definire Eventi e azioni obbligatorio. - Configurazione per colonne generiche.
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
Vedi anche Definizione del nuovo rapporto.
Query specifica per colonna column-specific-query
Questo definisce l’estrazione di dati specifica (dalla set di risultati dei dati del rapporto) da utilizzare nelle singole colonne.
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 una proprietà è definita come stringa[], vengono analizzate più proprietà (in sequenza) per trovare il valore effettivo.
Ad esempio, se è presente:
property = [ "jcr:lastModified", "jcr:created" ]
L’estrattore di valore corrispondente (che si trova qui sotto controllo):
- Verifica se è disponibile una proprietà jcr:lastModified e, in tal caso, utilizzarla.
- Se non è disponibile alcuna proprietà jcr:lastModified, viene utilizzato il contenuto di jcr:created.
-
subPath
Se il risultato non si trova nel nodo restituito dalla query,
subPath
definisce dove si trova la proprietà. -
secondaryProperty
Una seconda proprietà che deve essere utilizzata per calcolare il valore effettivo della cella. Questa definizione viene utilizzata solo per alcuni tipi di colonna (differenze e ordinamento).
Ad esempio, se è presente il rapporto Istanze flusso di lavoro, la proprietà specificata viene utilizzata per memorizzare il valore effettivo della differenza di tempo (in millisecondi) tra l'ora di inizio e l'ora di fine.
-
secondarySubPath
Simile a subPath, quando
secondaryProperty
viene utilizzato.
Di solito, solo property
viene utilizzato.
Filtro client client-filter
Il filtro client estrae le informazioni da visualizzare dai dati restituiti dal server.
N:definitions
N:data
P:clientFilter [String]
Il clientFilter
è una funzione JavaScript che:
- come input, riceve un parametro; i dati restituiti dal server (completamente preelaborati)
- come output, restituisce il valore filtrato (elaborato); i dati estratti o derivati dalle informazioni di input
L’esempio seguente estrae il percorso della 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);
}
Resolver e pre-elaborazione resolvers-and-preprocessing
Il 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 su altri valori; ad esempio, viene utilizzato per risolvere costanti come
en
al suo valore equivalenteEnglish
. -
default
Il resolver predefinito. Questo è un risolutore fittizio che in realtà non risolve nulla.
-
page
Risolve un valore di percorso per il percorso della pagina appropriata; più precisamente, per il corrispondente
jcr:content
nodo. 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 definito da
resolverConfig
) nel percorso risolto. Ad esempio, unpath
di/content/.../page/jcr:content
può essere risolto nel contenuto deljcr:title
, ciò significa che il percorso di una 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 come/libs/wcm/core/resources/languages
, prendendo il valore dalla proprietàlanguage
, per risolvere il codice paesede
alla descrizione della linguaGerman
.
-
-
resolverConfig
Fornisce le definizioni per il resolver. Le opzioni disponibili dipendono dal
resolver
selezionato:-
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.
Una proprietà con Nome=
1
e Valore=One
risolve da 1 a 1. -
default
Nessuna configurazione disponibile.
-
page
-
propertyName
(facoltativo)Definisce il nome della proprietà da utilizzare per la risoluzione del valore. Se non viene specificato, il valore predefinito è jcr:title (titolo della pagina); per
page
resolver, significa che prima il percorso viene risolto nel percorso della pagina, quindi ulteriormente risolto nel titolo della pagina.
-
-
path
-
propertyName
(facoltativo)Specifica il nome della proprietà da utilizzare per la risoluzione del valore. Se non viene specificato, il valore predefinito è
jcr:title
viene utilizzato. -
subPath
(facoltativo)Questa proprietà può essere utilizzata per specificare un suffisso da aggiungere al percorso prima che il valore venga risolto.
-
-
pathextension
-
path
(obbligatorio)Definisce il percorso da anteporre.
-
propertyName
(obbligatorio)Definisce la proprietà nel percorso risolto in cui si trova il valore effettivo.
-
i18n
(facoltativo; tipo booleano)Determina se il valore risolto deve essere internazionalizzato (ovvero, utilizzando Servizi di internazionalizzazione di CQ5).
-
-
-
preprocessing
La pre-elaborazione è facoltativa e può essere associata (separatamente) alle fasi di elaborazione applica o applyAfter:
-
apply
Fase di pre-elaborazione iniziale (passaggio 3 nella rappresentazione della coda di elaborazione).
-
applyAfter
Applica dopo la pre-elaborazione (passaggio 9 nella rappresentazione della coda di elaborazione).
-
Resolver resolvers
I resolver vengono utilizzati per estrarre le informazioni necessarie. Esempi dei vari risolutori sono:
Const
Di seguito viene risolto un valore costante di VersionCreated
alla stringa New version created
.
Consulta /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 per la proprietà jcr:description nel nodo jcr:content (figlio) della pagina corrispondente.
Consulta /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 di /content/.../page
al contenuto del jcr:title
, ciò significa che il percorso di una pagina viene risolto nel titolo della pagina.
Consulta /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 è riportato un valore preceduto da de
con l’estensione del percorso /libs/wcm/core/resources/languages
, quindi prende il valore dalla proprietà language
, per risolvere il codice paese de
alla descrizione della lingua German
.
Consulta /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"
Preelaborazione preprocessing
Il preprocessing
La definizione può essere applicata:
-
valore originale:
La definizione di pre-elaborazione per il valore originale è specificata in
apply
e/oapplyAfter
direttamente. -
valore allo stato aggregato:
Se necessario, è possibile fornire una definizione distinta per ciascuna aggregazione.
Per specificare una pre-elaborazione esplicita per i valori aggregati, le definizioni di pre-elaborazione devono trovarsi su un
aggregated
nodo figlio (apply/aggregated
,applyAfter/aggregated
). Se è richiesta una pre-elaborazione esplicita per aggregati distinti, la definizione della pre-elaborazione si trova su un nodo figlio con il nome del rispettivo aggregato (ad esempio,apply/aggregated/min/max
o altri aggregati).
È possibile specificare una delle seguenti opzioni da utilizzare durante la pre-elaborazione:
-
trovare e sostituire i pattern
Quando viene trovato, il pattern specificato (definito come espressione regolare) viene sostituito da un altro pattern; ad esempio, questo 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 temporale di un’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 preprocessing-find-and-replace-patterns
Per la pre-elaborazione è possibile specificare pattern
(definito come espressione regolare o regex) che è localizzato e poi sostituito dal replace
pattern:
-
pattern
Espressione regolare utilizzata per individuare una sottostringa.
-
replace
Stringa, o rappresentazione della stringa, utilizzata come sostituzione della stringa originale. Spesso rappresenta una sottostringa della stringa che si trova nell’espressione regolare
pattern
.
Un esempio di sostituzione può essere suddiviso come:
-
Per il nodo
definitions/data/preprocessing/apply
con le due proprietà seguenti:pattern
:(.*)(/jcr:content)(/|$)(.*)
replace
:$1
-
Stringa in arrivo come:
/content/geometrixx/en/services/jcr:content/par/text
-
Suddiviso 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
Preelaborazione - Tipo di dati per gli argomenti preprocessing-data-type-formatters
Questi formattatori convertono un valore numerico in una stringa relativa.
Ad esempio, può essere utilizzato per una colonna di tempo che consente min
, avg
e max
aggregati. As min
/ avg
/ max
gli aggregati vengono visualizzati come differenza di tempo (ad esempio, 10 days ago
), richiedono un formattatore di dati. Per questo, un datedelta
il formattatore viene applicato al min
/ avg
/ max
valori aggregati. Se un count
aggregato è disponibile anche, questo non richiede un formattatore, così come il valore originale.
Al momento i formattatori dei tipi di dati disponibili sono:
-
format
Formattatore tipo di 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 ha richiesto un’ora, a partire dalle 11:23h del 2/13/11 e con termine un’ora dopo alle 12:23h del 2/13/11.
Converte un valore numerico (interpretato come millisecondi) in una stringa di durata; ad esempio,
30000
è formattato come *30s
.* -
datedelta
L’intervallo di tempo tra una data passata e "ora" è quindi diverso (se il rapporto viene visualizzato in un momento successivo).
Converte il valore numerico (interpretato come differenza temporale in giorni) in una stringa di data relativa. Ad esempio, 1 è stato formattato come un giorno fa.
-
L’esempio che segue definisce datedelta
formattazione per min
e max
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 column-specific-definitions
Le definizioni specifiche della colonna definiscono i filtri e gli aggregati disponibili per tale 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
Di seguito sono riportate le opzioni standard disponibili:
-
string
-
number
-
int
-
date
-
diff
-
timeslot
Utilizzato per estrarre parti di una data necessarie per l’aggregazione (ad esempio, raggruppare per anno per ottenere i dati aggregati per ogni anno).
-
sortable
Utilizzato per valori che utilizzano valori diversi (come estratti da proprietà diverse) per l’ordinamento e la visualizzazione.
Inoltre, qualsiasi valore di cui sopra può essere definito come valore multiplo; ad esempio,
string[]
definisce un array di stringhe.L'estrattore di valore viene scelto dal tipo di colonna. Se per un tipo di colonna è disponibile un estrattore di valore, viene utilizzato tale estrattore. In caso contrario, viene utilizzato il valore di default dell'estrattore.
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 dijava.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 report può essere raggruppato per questa colonna.
-
filters
Definizioni dei filtri.
-
filterType
I filtri disponibili sono:
-
string
Un filtro basato su stringhe.
-
-
id
Identificatore del 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
Definizioni aggregate.
-
text
Nome testuale dell’aggregato. Se
text
non è specificato, verrà utilizzata la descrizione predefinita dell'aggregato. Ad esempio:minimum
viene utilizzato permin
aggregato. -
type
Tipo aggregato. 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 mediano.
-
percentile95
Utilizza il 95° percentile di tutti i valori.
-
-
Valori predefiniti colonna column-default-values
Definisce i valori predefiniti per la colonna:
N:defaults
P:aggregate
-
aggregate
Valido
aggregate
i valori sono gli stessi ditype
inaggregates
(vedere Definizioni specifiche per colonna (definizioni - filtri/aggregati) ).
Eventi e azioni events-and-actions
Modifica configurazione definisce gli eventi necessari che i listener devono rilevare e le azioni da applicare dopo che si sono verificati. Consulta la introduzione allo sviluppo di componenti per informazioni di base.
Devono essere definiti 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 generic-columns
Le colonne generiche sono un’estensione in cui la maggior parte delle definizioni delle colonne è memorizzata nell’istanza del nodo della colonna (anziché nel nodo del componente).
Utilizzano una finestra di dialogo (standard) che potete personalizzare per il singolo componente generico. Questa finestra di dialogo consente all'utente del report di definire le proprietà di una colonna generica nella pagina del report (utilizzando l'opzione di menu Proprietà colonna…).
Un esempio è il Generico colonna del Report utente. Consulta /libs/cq/reporting/components/userreport/genericcol
.
Per rendere una colonna generica:
-
Imposta il
type
proprietà della colonnadefinition
nodo ageneric
.Consulta
/libs/cq/reporting/components/userreport/genericcol/definitions
-
Specifica una definizione di finestra di dialogo (standard) sotto il
definition
nodo.Consulta
/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 relativo percorso.
Ad esempio, se desideri che il tipo della colonna generica possa essere configurato tramite la finestra di dialogo, utilizza un campo con il nome
./definitions/type
. -
Le proprietà definite tramite l’interfaccia utente/la finestra di dialogo hanno la precedenza su quelle definite nella
columnbase
componente.
-
-
Definisci la configurazione di modifica.
Consulta
/libs/cq/reporting/components/userreport/genericcol/cq:editConfig
-
Utilizza metodologie AEM standard per definire proprietà di colonna (aggiuntive).
Per le proprietà definite sia sulle istanze del componente che su quelle della colonna, il valore sull’istanza della colonna ha la precedenza.
Le proprietà disponibili per una colonna generica sono:
jcr:title
- nome colonnadefinitions/aggregates
- aggregatidefinitions/filters
- filtridefinitions/type
- il tipo di colonna (deve essere definito nella finestra di dialogo, utilizzando un selettore o una casella combinata oppure un campo nascosto)definitions/data/resolver
edefinitions/data/resolverConfig
(ma nondefinitions/data/preprocessing
o.../clientFilter
) - il resolver e la configurazionedefinitions/queryBuilder
: configurazione del generatore di querydefaults/aggregate
- aggregato predefinito
Se è presente una nuova istanza della colonna generica nella 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 report-design
La progettazione definisce quali tipi di colonna sono disponibili per la creazione di un rapporto. Definisce inoltre il sistema paragrafo a cui vengono aggiunte le colonne.
L’Adobe consiglia di creare una singola progettazione per ogni rapporto. In questo modo si garantisce la massima flessibilità. Consulta Definizione del nuovo rapporto.
Le componenti di reporting predefinite sono detenute sotto /etc/designs/reports
.
La posizione dei rapporti può dipendere dalla posizione dei componenti:
-
/etc/designs/reports/<yourReport>
è adatto se il rapporto è sotto/apps/cq/reporting
-
/etc/designs/<yourProject>/reports/<*yourReport*>
per i rapporti che utilizzano/apps/<yourProject>/reports
pattern
Le proprietà di progettazione richieste sono registrate il jcr:content/reportpage/report/columns
(ad esempio, /etc/designs/reports/<reportName>/jcr:content/reportpage/report/columns
):
-
components
Qualsiasi componente e/o gruppo di componenti consentito nel rapporto.
-
sling:resourceType
Proprietà con valore
cq/reporting/components/repparsys
.
Un esempio di frammento di progettazione (tratto dalla progettazione del rapporto del 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 progettazioni per le singole colonne. Le colonne disponibili possono essere definite in modalità progettazione.
Modello di rapporto report-template
Ogni tipo di rapporto deve fornire un modello. Questi sono standard Modelli CQ e possono essere configurati come tali.
Il modello deve:
-
imposta
sling:resourceType
acq/reporting/components/reportpage
-
indicare il progetto da utilizzare
-
creare un
report
nodo figlio che fa riferimento al contenitore (reportbase
) consling:resourceType
proprietà
Un esempio di frammento di modello (tratto dal modello di report del componente) è:
<!-- ... -->
<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 esempio di frammento di modello, che mostra la definizione del percorso principale (tratto dal modello di report 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, l’Adobe consiglia di non aggiornare questi nodi. Puoi invece creare nodi di componenti personalizzati in /apps/cq/reporting/templates
o se più appropriato /apps/<yourProject>/reports/templates
.
Dove, ad esempio (vedi anche Posizione dei componenti del rapporto):
N:apps
N:cq [nt:folder]
N:reporting|reports [sling:Folder]
N:templates [sling:Folder]
In questo caso, crea 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 personalizzato: un esempio creating-your-own-report-an-example
Definizione del nuovo rapporto defining-your-new-report
Per definire un rapporto, crea e configura:
- La directory principale dei componenti del rapporto.
- Il componente base del rapporto.
- Uno o più componenti base per colonne.
- Progettazione del report.
- Directory principale del modello di report.
- Il modello di report.
Per illustrare questi passaggi, l’esempio seguente definisce un rapporto che elenca tutte le configurazioni OSGi all’interno dell’archivio. Ovvero, tutte le istanze del sling:OsgiConfig
nodo.
-
Crea il nodo principale per il nuovo rapporto.
Ad esempio, in
/apps/cq/reporting/components/osgireport
.code language-xml N:cq [nt:folder] N:reporting [sling:Folder] N:components [sling:Folder] N:osgireport [sling:Folder]
-
Definire la base di rapporti. Ad esempio:
osgireport[cq:Component]
in/apps/cq/reporting/components/osgireport
.code language-xml 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 per il rapporto che:
- cerca tutti i nodi di tipo
sling:OsgiConfig
- visualizza entrambi
pie
elineseries
grafici - fornisce una finestra di dialogo che consente all’utente di configurare il rapporto
- cerca tutti i nodi di tipo
-
Definisci il componente della prima colonna (columnbase). Ad esempio:
bundlecol[cq:Component]
in/apps/cq/reporting/components/osgireport
.code language-xml 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 columnbase che:
- cerca e restituisce il valore ricevuto dal server; in questo caso la proprietà
jcr:path
per ognisling:OsgiConfig
nodo - fornisce
count
aggregato - non è raggruppabile
- ha il titolo
Bundle
(titolo della colonna nella tabella) - è nel gruppo della barra laterale
OSGi Report
- aggiorna in base agli eventi specificati
note note NOTE In questo esempio, non vi sono definizioni di N:data
eP:clientFilter
. Questo perché il valore ricevuto dal server viene restituito in rapporto 1:1, che è il comportamento predefinito.Questo è lo stesso delle definizioni: code language-none N:data [nt:unstructured] P:clientFilter [String] = "function(v) { return v; }"
Dove la funzione restituisce semplicemente il valore ricevuto. - cerca e restituisce il valore ricevuto dal server; in questo caso la proprietà
-
Definisci la struttura del rapporto. Ad esempio:
osgireport[cq:Page]
in/etc/designs/reports
.code language-xml 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"
-
Crea il nodo principale per il nuovo modello di rapporto.
Ad esempio, in
/apps/cq/reporting/templates/osgireport
.code language-xml N:cq [nt:folder] N:reporting [sling:Folder] N:templates [sling:Folder] N:osgireport [cq:Template]
-
Definisci il modello di rapporto. Ad esempio:
osgireport[cq:Template]
in/apps/cq/reporting/templates
.code language-xml N:osgireport [cq:Template] P:allowedPaths [String[]] = "/etc/reports(/.*)?" P:jcr:description [String] = "Use this report generator to create an 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]
Questo definisce un modello che:
- definisce la
allowedPaths
per i rapporti risultanti: nel caso di cui sopra, in qualsiasi punto sotto/etc/reports
- fornisce titoli e descrizioni per il modello
- fornisce un’immagine 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 rapporto esistente).
- definisce la
Creazione di un’istanza del nuovo rapporto creating-an-instance-of-your-new-report
È ora possibile creare un’istanza del nuovo rapporto:
-
Apri Strumenti console.
-
Seleziona Rapporti nel riquadro di sinistra.
-
Then Nuovo… dalla barra degli strumenti. Definisci un Titolo e Nome, seleziona il nuovo tipo di rapporto (il Modello per report OSGi) dall’elenco dei modelli, quindi fai clic su Crea.
-
La nuova istanza di report viene visualizzata nell’elenco. Fare doppio clic per aprire.
-
Trascina un componente (per questo esempio: Bundle nel Rapporto OSGi ) dalla barra laterale per creare la prima colonna e avvia la definizione del rapporto.
note note NOTE Poiché questo esempio non contiene colonne raggruppabili, i grafici non sono disponibili. Per visualizzare i grafici, impostare groupable
atrue
:code language-none N:osgireport [sling:Folder] N:bundlecol [cq:Component] N:definitions [nt:unstructured] P:groupable [Boolean] = true
Configurazione dei servizi di Report Framework configuring-the-report-framework-services
In questa sezione vengono descritte le opzioni di configurazione avanzate per i servizi OSGi che implementano il framework di report.
Questi possono essere visualizzati utilizzando il menu Configuration della console web (disponibile all’indirizzo http://localhost:4502/system/console/configMgr
, ad esempio). Quando si lavora con l’AEM, esistono diversi metodi per gestire le impostazioni di configurazione per tali servizi; vedi Configurazione di OSGi per ulteriori dettagli e le pratiche consigliate.
Servizio di base (configurazione di reporting Day CQ) basic-service-day-cq-reporting-configuration
-
Fuso orario definisce il fuso orario per il quale vengono creati i dati storici. In questo modo, il grafico cronologico mostrerà gli stessi dati per ogni utente in tutto il mondo.
-
Lingua definisce le impostazioni locali da utilizzare con Fuso orario per i dati storici. Le impostazioni internazionali vengono utilizzate per determinare alcune impostazioni di calendario specifiche delle impostazioni internazionali, ad esempio se il primo giorno della settimana è domenica o lunedì.
-
Percorso snapshot definisce il percorso principale in cui vengono archiviati gli snapshot per i grafici storici.
-
Percorso per i rapporti definisce il percorso in cui si trovano i rapporti. Viene utilizzato dal servizio snapshot per determinare i report per i quali eseguire effettivamente le snapshot.
-
Snapshot giornalieri definisce l'ora di ogni giorno in cui vengono eseguite le istantanee giornaliere. L'ora specificata si trova nel fuso orario locale del server.
-
Snapshot ogni ora definisce il minuto di ogni ora in cui vengono eseguite le istantanee orarie.
-
Righe (max) definisce il numero massimo di righe archiviate per ogni snapshot. Questo valore dovrebbe essere scelto in modo ragionevole. Se è troppo alta, influisce sulle dimensioni dell’archivio; se è troppo bassa, i dati potrebbero non essere accurati a causa del modo in cui vengono gestiti i dati storici.
-
Dati falsi, se abilitata, è possibile creare dati storici falsi utilizzando
fakedata
; se è disattivato, utilizza ilfakedata
il selettore genera un’eccezione.Poiché i dati sono falsi, è necessario solo essere utilizzato a scopo di test e debug.
Utilizzo di
fakedata
Il selettore completa il rapporto in modo implicito, quindi tutti i dati esistenti vengono persi. I dati possono essere ripristinati manualmente, ma questo processo può richiedere tempo. -
Utente snapshot definisce un utente facoltativo che può essere utilizzato per creare snapshot.
In pratica, vengono create istantanee per l'utente che ha terminato il report. In alcuni casi (ad esempio, in un sistema di pubblicazione in cui l’utente non esiste in quanto l’account non è stato replicato) puoi specificare un utente di fallback da utilizzare in alternativa.
Inoltre, la specifica di un utente potrebbe comportare un rischio per la sicurezza.
-
Imponi utente snapshot, se attivate, tutte le istantanee vengono scattate con l'utente specificato in Utente snapshot. Questo potrebbe avere un grave impatto sulla sicurezza se non viene gestito correttamente.
Impostazioni cache (Day CQ Reporting Cache) cache-settings-day-cq-reporting-cache
- Abilita consente di abilitare o disabilitare la memorizzazione nella cache dei dati del rapporto. L’abilitazione della cache dei rapporti mantiene i dati del rapporto in memoria durante diverse richieste. Questo può aumentare le prestazioni, ma porta a un maggiore consumo di memoria e, in circostanze estreme, può portare a situazioni di memoria insufficiente.
- TTL definisce il tempo (in secondi) per il quale i dati del rapporto vengono memorizzati in cache. Un numero più elevato migliora le prestazioni, ma può anche restituire dati imprecisi se i dati cambiano entro il periodo di tempo.
- Max voci definisce il numero massimo di rapporti da memorizzare in cache contemporaneamente.
2
memorizza nella cache i dati per:- un rapporto per due utenti con impostazioni di lingua diverse
- un utente e due rapporti