Élaborer des rapports developing-reports
CQ propose une sélection de rapports standard, basés majoritairement sur un framework de création de rapports.
Cette framework vous permet soit d’étendre ces rapports standard, soit de développer vos propres rapports en partant de zéro. Le framework de création de rapports s’intègre parfaitement dans les concepts et principes CQ5 existants. Les développeurs peuvent ainsi mettre à profit leurs connaissances actuelles de la plateforme CQ5 pour développer des rapports.
Pour les rapports standard fournis avec AEM :
-
Ces rapports reposent sur le framework de création de rapports :
-
Les rapports suivants sont basés sur des principes individuels et ne peuvent donc pas être étendus :
-
Chaque ligne définit un nœud ou une propriété où :
-
N:<name> [<nodeType>]
Décrit un noeud portant le nom de
<*name*>
et type de noeud de<*nodeType*>
. -
P:<name> [<propertyType]
Décrit une propriété avec le nom de
<*name*>
et un type de propriété de<*propertyType*>
. -
P:<name> = <value>
Décrit une propriété
<name>
qui doit être défini sur la valeur de<value>
.
-
-
La mise en retrait indique les dépendances hiérarchiques entre les nœuds.
-
Éléments séparés par | indique une liste d’éléments possibles ; par exemple, types ou noms :
Par exemple :
String|String[]
signifie que la propriété peut être String ou String.[]. -
[]
représente une série, par exemple String[], ou une série de nœuds, comme dans la Définition de requête.
- Nodes -
nt:unstructured
- Propriétés -
String
Framework de reporting reporting-framework
Le framework de reporting fonctionne sur les principes suivants :
-
Elle est entièrement basée sur les ensembles de résultats renvoyés par une requête exécutée par CQ5 QueryBuilder.
-
Le jeu de résultats définit les données affichées dans le rapport. Chaque ligne du jeu de résultats correspond à une ligne de la vue tabulaire du rapport.
-
Les opérations pouvant être exécutées sur le jeu de résultats ressemblent aux concepts SGBDR ; il s’agit principalement du regroupement et de l’agrégation.
-
La plupart des opérations de récupération et de traitement des données s’effectuent du côté serveur.
-
Le client est seul responsable de l’affichage des données prétraitées. Seules les tâches de traitement mineures (par exemple, la création de liens dans le contenu des cellules) sont exécutées côté client.
La structure de création de rapports (illustrée par la structure d’un rapport standard) utilise les blocs de création suivants, alimentés par la file d’attente de traitement :
Page du rapport report-page
La page du rapport :
- Est une page CQ5 standard.
- Est basé sur un modèle CQ5 standard, configuré pour le rapport.
Base du rapport report-base
Le composant reportbase
constitue la base de tout rapport, dans la mesure où il :
-
contient la définition de la requête qui fournit le jeu de résultats de données sous-jacent ;
-
s’agit d’un système de paragraphes personnalisé contenant toutes les colonnes (
columnbase
) ajoutées au rapport ; -
définit les types de graphique disponibles et actuellement actifs ;
-
définit la boîte de dialogue de modification, qui permet à l’utilisateur de configurer certains aspects du rapport.
Base de colonne column-base
Chaque colonne est une instance du composant columnbase
qui :
- est un paragraphe, utilisé par le système de paragraphes (parsys) (
reportbase
) du rapport correspondant ; - Définit le lien vers la variable jeu de résultats sous-jacent; c’est-à-dire qu’il définit les données spécifiques référencées dans ce jeu de résultats et la manière dont il est traité.
- contient des définitions supplémentaires ; tels que les agrégats et filtres disponibles, ainsi que toute valeur par défaut.
Requête et récupération de données the-query-and-data-retrieval
La requête :
-
est définie comme faisant partie du composant
reportbase
; -
Est basé sur la variable CQ QueryBuilder.
-
Récupère les données utilisées comme base du rapport. Chaque ligne du jeu de résultats (tableau) est liée à un noeud tel qu’il est renvoyé par la requête. Des informations spécifiques pour les différentes colonnes sont ensuite extraites de ce jeu de données.
-
Se compose généralement des éléments suivants :
-
Chemin d’accès racine.
Ce chemin spécifie la sous-arborescence du référentiel dans lequel la recherche doit être effectuée.
Pour contribuer à réduire l’impact sur les performances, il est conseillé de limiter (dans la mesure du possible) la requête à une sous-arborescence spécifique du référentiel. Le chemin d’accès racine peut soit être prédéfini dans le modèle de rapport, soit être défini dans la boîte de dialogue Configuration (Modifier).
-
Ils sont imposés pour générer le jeu de résultats (initial) ; il s’agit, par exemple, de restrictions concernant le type de nœud ou des contraintes de propriété.
-
Le point clé ici est que chaque noeud unique renvoyé dans le jeu de résultats de la requête est utilisé pour générer une seule ligne sur le rapport (relation 1:1, par conséquent).
Le développeur doit s’assurer que la requête définie pour un rapport renvoie un jeu de noeuds approprié pour ce rapport. Cependant, le noeud lui-même ne doit pas contenir toutes les informations requises, elles peuvent également être dérivées des noeuds parents et/ou enfants. Par exemple, la requête utilisée pour le Rapport utilisateur sélectionne des nœuds en fonction de leur type (dans ce cas : rep:user
). Toutefois, la plupart des colonnes de ce rapport ne prélèvent pas directement leurs données de ces nœuds, mais des nœuds enfants profile
.
File d’attente de traitement processing-queue
Le query renvoie un jeu de résultats de données à afficher sous forme de lignes sur le rapport. Chaque ligne du jeu de résultats est traitée (côté serveur), en plusieurs phases, avant d’être transférée vers le client en vue d’un affichage dans le rapport.
Cela permet d’effectuer les opérations suivantes :
-
Extraire et déduire des valeurs du jeu de résultats sous-jacent.
Cela vous permet, par exemple, de traiter deux valeurs de propriété comme s’il s’agissait d’une seule en calculant la différence entre les deux.
-
Résoudre les valeurs extraites ; cela peut être réalisé de différentes manières.
Par exemple, des chemins d’accès peuvent être mappés sur un titre (comme dans le contenu plus lisible de la propriété jcr:title correspondante).
-
Application de filtres à différents points.
-
Créer des valeurs composites, si nécessaire.
Par exemple, dans le cas d’un texte présenté à l’utilisateur, une valeur à utiliser pour le tri et une URL supplémentaire utilisée (du côté client) pour créer un lien.
Workflow de la file d’attente de traitement workflow-of-the-processing-queue
Le workflow suivant représente la file d’attente de traitement :
Phases de la file d’attente de traitement phases-of-the-processing-queue
Emplacement des étapes détaillées et des éléments :
-
Transforme les résultats renvoyés par la requête initiale (reportbase) en jeu de résultats de base à l’aide d’extracteurs de valeurs.
Les extracteurs de valeurs sont sélectionnés automatiquement en fonction du type de colonne. Ils sont utilisés pour lire les valeurs extraites de la requête JCR sous-jacente et pour créer un jeu de résultats à partir de celles-ci ; un traitement plus approfondi peut ensuite être appliqué. Pour le type
diff
, par exemple, l’extracteur de valeurs lit deux propriétés et calcule la valeur unique qui est ensuite ajoutée au jeu de résultats. Les extracteurs de valeurs ne peuvent pas être configurés. -
à ce jeu de résultats initial, contenant des données brutes, filtrage initial (raw ) est appliquée.
-
Les valeurs sont prétraité; comme défini pour la variable apply phase.
-
Filtrage (affectée à la variable prétraité phase) est exécutée sur les valeurs prétraitées.
-
Les valeurs sont résolues ; selon la variable résolveur défini.
-
Filtrage (affectée à la variable resolved phase) est exécutée sur les valeurs résolues.
-
Les données sont regroupés et agrégés.
-
Les données de tableau sont résolues en les convertissant en liste (chaîne).
Il s’agit d’une étape implicite qui convertit un résultat à plusieurs valeurs dans une liste qui peut être affichée ; cela s’avère nécessaire pour les valeurs de cellule (non agrégées) qui sont basées sur des propriétés JCR à plusieurs valeurs.
-
Les valeurs sont à nouveau prétraité; comme défini pour la variable afterApply phase.
-
Les données sont triées.
-
Les données traitées sont transférées au client.
reportbase
.columnbase
.Conception et configuration des rapports report-construction-and-configuration
Les éléments suivants sont nécessaires pour construire et configurer un rapport :
Emplacement des composants de rapport location-of-report-components
Les composants de création de rapports par défaut sont conservés sous /libs/cq/reporting/components
.
Cependant, il est vivement conseillé de ne pas mettre à jour ces nœuds, mais de créer vos propres nœuds de composant sous /apps/cq/reporting/components
ou, le cas échéant, sous /apps/<yourProject>/reports/components
.
Où (à titre d’exemple) :
N:apps
N:cq [nt:folder]
N:reporting|reports [sling:Folder]
N:components [sling:Folder]
En dessous, vous créez la racine de votre rapport et, au niveau inférieur, le composant de base de rapport et les composants de base de 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
Composant de page page-component
Une page de rapport doit utiliser le sling:resourceType
/libs/cq/reporting/components/reportpage
.
Un composant de page personnalisé ne doit pas être nécessaire (dans la plupart des cas).
Composant de base de rapports report-base-component
Chaque type de rapport nécessite un composant de conteneur provenant de /libs/cq/reporting/components/reportbase
.
Ce composant agit comme un conteneur pour le rapport dans son ensemble et fournit des informations pour les éléments suivants :
- Le définition de requête.
- Un (facultatif) boîte de dialogue pour configurer le rapport.
- Quelconque Graphiques intégré dans le rapport.
N:<reportname> [cq:Component]
P:sling:resourceSuperType = "cq/reporting/components/reportbase"
N:charting
N:dialog [cq:Dialog]
N:queryBuilder
Définition de requête 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
Peut être utilisé pour limiter le jeu de résultats aux nœuds ayant des propriétés spécifiques avec des valeurs spécifiques. Si plusieurs contraintes sont spécifiées, le nœud doit toutes les respecter (opération AND).
Par exemple :
code language-none N:propertyConstraints [ N:0 P:sling:resourceType P:foundation/components/textimage N:1 P:jcr:modifiedBy P:admin ]
Renvoie tous les composants
textimage
qui ont été modifiés pour la dernière fois par l’utilisateuradmin
. -
nodeTypes
Utilisé pour limiter le jeu de résultats aux types de nœud spécifiés. Plusieurs types de nœud peuvent être spécifiés.
-
mandatoryProperties
Peut être utilisé pour limiter le jeu de résultats aux nœuds dont toutes les propriétés sont spécifiées. La valeur des propriétés n’est pas prise en compte.
Tous sont facultatifs et peuvent être combinés suivant les besoins, mais vous devez en définir au moins un.
Définitions de graphique 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
Contient les définitions des graphiques actifs.
-
active
Comme plusieurs paramètres peuvent être définis, vous pouvez utiliser cette option pour définir ceux qui sont actuellement actifs. Ceux-ci sont définis par un tableau de nœuds (il n’existe pas de convention de nommage obligatoire pour ces nœuds, mais les rapports standard utilisent généralement
0
,1
…x
), chacun ayant la propriété suivante :-
id
L’identification des graphiques actifs. Elle doit correspondre à l’identification de l’une des
definitions
de diagramme.
-
-
-
definitions
Définit les types de graphiques qui peuvent être disponibles pour le rapport. Les
definitions
à utiliser seront spécifiées par les paramètresactive
.Les définitions sont spécifiées à l’aide d’un tableau de nœuds (nommés généralement
0
,1
…x
), chacun ayant les propriétés suivantes :-
id
L’identification du graphique.
-
type
Le type de graphique disponible. Faites un choix parmi les éléments suivants :
-
pie
Graphique en secteurs. Généré uniquement à partir des données actuelles. -
lineseries
Série de lignes (points reliés représentant les instantanés). Généré à partir de données historiques uniquement.
-
-
D’autres propriétés sont disponibles, selon le type de graphique :
-
pour le type de graphique
pie
:-
maxRadius
(Double/Long
)Rayon maximum autorisé pour le graphique en secteurs et donc la taille maximale autorisée pour le graphique (sans légende). Ignoré si
fixedRadius
est défini. -
minRadius
(Double/Long
)Rayon minimum autorisé pour le graphique en secteurs. Ignoré si
fixedRadius
est défini. -
fixedRadius
(Double/Long
)
Définit un rayon fixe pour le graphique en secteurs.
-
-
pour le type de graphique
lineseries
:-
totals
(Boolean
)True si une ligne supplémentaire affichant le Total doit être présentée.
par défaut :false
-
series
(Long
)Nombre de lignes/séries à afficher.
Valeur par défaut :9
(il s’agit également du maximum autorisé) -
hoverLimit
(Long
)Nombre maximum d’instantanés agrégés (points affichés sur chaque ligne horizontale, représentant des valeurs distinctes) pour les fenêtres contextuelles qui doivent être affichées ; c’est-à-dire lorsque l’utilisateur fait passer le pointeur de la souris sur une valeur distincte ou un libellé correspondant dans la légende du graphique.
Valeur par défaut :
35
(en d’autres termes, aucune fenêtre contextuelle n’est affichée si plus de 35 valeurs distinctes sont applicables pour les paramètres actuels du graphique).Il existe une limite supplémentaire de 10 fenêtres contextuelles pouvant être affichées en parallèle (plusieurs fenêtres contextuelles peuvent être affichées lorsque l’utilisateur fait passer le pointeur de la souris sur le texte de la légende).
-
-
-
Boîte de dialogue de configuration configuration-dialog
Chaque rapport peut comporter une boîte de dialogue de configuration, qui permet à l’utilisateur de spécifier différents paramètres pour le rapport. Cette boîte de dialogue est accessible au moyen du bouton Modifier lorsque la page du rapport est ouverte.
Il s’agit d’une boîte de dialogue CQ standard qui peut être configurée comme telle (pour plus d’informations, voir CQ.Dialog).
Voici un exemple de boîte de dialogue :
<?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>
Plusieurs composants préconfigurés sont fournis ; ils peuvent être référencés dans la boîte de dialogue, à l’aide de la propriété xtype
avec une valeur cqinclude
:
-
title
/libs/cq/reporting/components/commons/title
Champ de texte pour définir le titre du rapport.
-
description
/libs/cq/reporting/components/commons/description
Zone de texte pour définir la description du rapport.
-
processing
/libs/cq/reporting/components/commons/processing
Sélecteur du mode de traitement du rapport (chargement manuel/automatique des données).
-
scheduling
/libs/cq/reporting/components/commons/scheduling
Sélecteur de planification des instantanés pour le graphique historique.
.infinity.json
(voir l’exemple ci-dessus).Chemin d’accès racine root-path
En outre, un chemin racine peut être défini pour le rapport :
-
rootPath
Limite le rapport à une certaine section (arborescence ou sous-arborescence) du référentiel, ce qui est recommandé dans le cadre de l’optimisation des performances. Le chemin d’accès racine est spécifié par la propriété
rootPath
du nœudreport
de chaque page du rapport (extrait du modèle lors de la création de la page).Il peut être spécifié par :
- la valeur modèle de rapport (valeur fixe ou valeur par défaut de la boîte de dialogue de configuration).
- l’utilisateur (à l’aide de ce paramètre)
Composant de base de colonne column-base-component
Chaque type de colonne nécessite un composant provenant de /libs/cq/reporting/components/columnbase
.
Un composant de colonne définit une combinaison des éléments suivants :
- Le Requête spécifique à la colonne configuration.
- Le Résolveurs et prétraitement.
- Définitions spécifiques à la colonne (telles que des filtres et des agrégats ; nœud enfant
definitions
). - Valeurs par défaut de colonne.
- Le Filtre client pour extraire les informations à afficher à partir des données retournées par le serveur.
- En outre, un composant de colonne doit fournir une instance appropriée de
cq:editConfig
. pour définir les événements et actions requis. - Configuration de colonnes génériques.
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
Consultez aussi Définition de votre nouveau rapport.
Requête spécifique à la colonne column-specific-query
Cette requête définit l’extraction de données spécifiques (à partir du jeu de résultats de données du rapport) à utiliser dans la colonne individuelle.
N:definitions
N:queryBuilder
P:property [String|String[]]
P:subPath
P:secondaryProperty [String|String[]]
P:secondarySubPath
-
property
Définit la propriété à utiliser pour calculer la valeur réelle de la cellule.
Si la propriété est définie en tant que String[], plusieurs propriétés sont analysées (dans l’ordre) pour rechercher la valeur réelle.
Par exemple, dans le cas de :
property = [ "jcr:lastModified", "jcr:created" ]
L’extracteur de valeur correspondant (qui contrôle ici) :
- vérifie si une propriété jcr:lastModified est disponible et, si tel est le cas, l’utilise.
- Si aucune propriété jcr:lastModified n’est disponible, le contenu de jcr:created est utilisé à la place.
-
subPath
Si le résultat ne se trouve pas sur le nœud renvoyé par la requête,
subPath
définit l’emplacement réel de la propriété. -
secondaryProperty
définit une deuxième propriété qui doit également être utilisée pour calculer la valeur réelle de la cellule ; cette propriété ne sera utilisée que pour certains types de colonne (diff et sortable).
Par exemple, dans le cas du rapport Instances de workflow, la propriété spécifiée est utilisée pour stocker la valeur actuelle du décalage horaire (en millisecondes) entre les heures de début et de fin.
-
secondarySubPath
Semblable à subPath, lorsque
secondaryProperty
est utilisé.
Dans la plupart des cas, seul property
est utilisé.
Filtre client client-filter
Le filtre client extrait les informations à afficher, des données retournées par le serveur.
N:definitions
N:data
P:clientFilter [String]
Le clientFilter
est défini comme une fonction JavaScript qui :
- en tant qu’entrée, reçoit un seul paramètre ; les données renvoyées par le serveur (et donc entièrement prétraitées) ;
- en tant que sortie, renvoie la valeur filtrée (traitée) ; les données extraites ou déduites des informations saisies.
L’exemple suivant extrait le chemin de page correspondant d’un chemin de composant :
function(v) {
var sepPos = v.lastIndexOf('/jcr:content');
if (sepPos < 0) {
return v;
}
return v.substring(sepPos + '/jcr:content'.length, v.length);
}
Résolveurs et prétraitement resolvers-and-preprocessing
La file d’attente de traitement définit les différents programmes de résolution et configure le prétraitement :
N:definitions
N:data
P:resolver
N:resolverConfig
N:preprocessing
N:apply
N:applyAfter
-
resolver
définit le programme de résolution à utiliser. Les programmes de résolution suivants sont disponibles :
-
const
fait correspondre des valeurs avec d’autres ; il est utilisé, par exemple, pour résoudre une constante telle que
en
sur sa valeur équivalenteEnglish
. -
default
Il s’agit du programme de résolution par défaut. Il s’agit d’un programme de résolution factice qui, en fait, ne résout rien.
-
page
résout une valeur de chemin sur le chemin d’accès de la page appropriée ; plus précisément, sur le nœud
jcr:content
correspondant. Par exemple,/content/.../page/jcr:content/par/xyz
est résolu en/content/.../page/jcr:content
. -
path
résout une valeur de chemin en ajoutant éventuellement un sous-chemin et en extrayant la valeur réelle d’une propriété du nœud (tel que défini par
resolverConfig
) au niveau du chemin résolu. Par exemple, unpath
/content/.../page/jcr:content
peut être résolu sur le contenu de la propriétéjcr:title
; cela signifie que le chemin de page sera résolu sur le titre de la page. -
pathextension
résout une valeur en ajoutant un chemin d’accès en préfixe et en prenant la valeur réelle d’une propriété du nœud au niveau du chemin résolu. Par exemple, une valeur
de
peut être précédée d’un chemin, tel que/libs/wcm/core/resources/languages
, et prendre la valeur de la propriétélanguage
pour résoudre le code de paysde
sur la description de la langueGerman
.
-
-
resolverConfig
fournit des définitions pour le programme de résolution ; les options disponibles dépendent du
resolver
sélectionné :-
const
Utilisez des propriétés pour spécifier les constantes en vue de la résolution. Le nom de la propriété définit la constante à résoudre ; la valeur de la propriété définit la valeur résolue.
Par exemple, une propriété avec Nom=
1
et Valeur=One
va résoudre 1 sur One. -
default
Aucune configuration n’est disponible.
-
page
-
propertyName
(facultatif)Définit le nom de la propriété qui doit être utilisée pour résoudre la valeur. Si elle n’est pas spécifiée, la valeur par défaut de jcr:title (titre de la page) est utilisée ; pour le programme de résolution
page
, cela signifie que le chemin est d’abord résolu sur le chemin d’accès de la page, puis sur le titre de la page.
-
-
path
-
propertyName
(facultatif)Spécifie le nom de la propriété qui doit être utilisée pour résoudre la valeur. Si elle n’est pas spécifiée, la valeur par défaut de
jcr:title
est utilisée. -
subPath
(facultatif)Cette propriété peut être utilisée pour spécifier un suffixe à ajouter au chemin d’accès avant la résolution de la valeur.
-
-
pathextension
-
path
(obligatoire)Définit le chemin d’accès à ajouter comme préfixe.
-
propertyName
(obligatoire)Définit la propriété sur le chemin résolu où se situe la valeur réelle.
-
i18n
(facultatif ; type booléen)Détermine si la valeur résolue doit être internationalisée (c’est-à-dire à l’aide des services d’internationalisation de CQ5).
-
-
-
preprocessing
Le prétraitement est facultatif et peut être lié (séparément) aux phases de traitement apply ou applyAfter :
-
apply
Phase de prétraitement initiale (étape 3 dans l’organigramme de la file d’attente de traitement).
-
applyAfter
Application après le prétraitement (étape 9 dans l’organigramme de la file d’attente de traitement).
-
Résolveurs resolvers
Les programmes de résolution sont utilisés pour extraire les informations requises. Voici quelques exemples des différents programmes de résolution :
Const
L’exemple ci-dessous résout une valeur constante VersionCreated
sur la chaîne New version created
.
Consultez /libs/cq/reporting/components/auditreport/typecol/definitions/data
.
N:data
P:resolver=const
N:resolverConfig
P:VersionCreated="New version created"
Page
Résout une valeur de chemin d’accès sur la propriété jcr:description sur le nœud jcr:content (enfant) de la page correspondante.
Consultez /libs/cq/reporting/components/compreport/pagecol/definitions/data
.
N:data
P:resolver=page
N:resolverConfig
P:propertyName="jcr:description"
Chemin
L’exemple ci-dessous résout un chemin d’accès /content/.../page
sur le contenu de la propriété jcr:title
; cela signifie que le chemin de page est résolu sur le titre de la page.
Consultez /libs/cq/reporting/components/auditreport/pagecol/definitions/data
.
N:data
P:resolver=path
N:resolverConfig
P:propertyName="jcr:title"
P:subPath="/jcr:content"
Extension de chemin
L’exemple ci-dessous ajoute une valeur de
avec l’extension de chemin /libs/wcm/core/resources/languages
, puis extrait la valeur de la propriété language
pour résoudre le code de pays de
sur la description de la langue German
.
Consultez /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"
Prétraitement preprocessing
La définition de preprocessing
peut être appliquée à l’un des éléments suivants :
-
valeur d’origine :
La définition de prétraitement de la valeur d’origine est spécifiée directement sur
apply
et/ouapplyAfter
. -
valeur dans son état agrégé :
Si nécessaire, une définition distincte peut être fournie pour chaque agrégation.
Pour spécifier un prétraitement explicite des valeurs agrégées, les définitions de prétraitement doivent résider sur un nœud enfant
aggregated
correspondant (apply/aggregated
,applyAfter/aggregated
). Si un prétraitement explicite est requis pour des agrégats distincts, la définition de prétraitement se trouve sur un nœud enfant ayant le nom de l’agrégat correspondant (par exemple,apply/aggregated/min/max
ou d’autres agrégats).
Vous pouvez spécifier l’une des options suivantes à utiliser lors du prétraitement :
-
motifs de recherche et de remplacement
Lorsqu’il est trouvé, le motif spécifié (qui est défini sous la forme d’une expression régulière) est remplacé par un autre ; il peut, par exemple, être utilisé pour extraire une sous-chaîne de l’original. -
Convertissent une valeur numérique en chaîne relative ; par exemple, la valeur `` représentant un décalage horaire de 1 heure sera résolue dans une chaîne telle que
1:24PM (1 hour ago)
.
Par exemple :
N:definitions
N:data
N:preprocessing
N:apply|applyAfter
P:pattern // regex
P:replace // replacement for regex
// and/or
P:format // data type formatter
Prétraitement - Modèles de recherche et de remplacement preprocessing-find-and-replace-patterns
Pour le prétraitement, vous pouvez spécifier un pattern
(défini en tant qu’expression régulière ou regex) qui est localisé, puis remplacé par le motif replace
:
-
pattern
Expression régulière utilisée pour localiser une sous-chaîne
-
replace
Chaîne, ou représentation de la chaîne, qui sera utilisée en remplacement de la chaîne d’origine. Elle représente souvent une sous-chaîne de la chaîne localisée par l’expression régulière
pattern
.
Un exemple de remplacement peut être décomposé comme suit :
-
Pour le nœud
definitions/data/preprocessing/apply
avec les deux propriétés suivantes :pattern
:(.*)(/jcr:content)(/|$)(.*)
replace
:$1
-
Une chaîne qui arrive en tant que :
/content/geometrixx/en/services/jcr:content/par/text
-
sera divisée en quatre sections :
$1
-(.*)
-/content/geometrixx/en/services
$2
-(/jcr:content)
-/jcr:content
$3
-(/|$)
-/
$4
-(.*)
-par/text
-
et remplacée par la chaîne représentée par
$1
:/content/geometrixx/en/services
Prétraitement - Formats des types de données preprocessing-data-type-formatters
Ces formateurs convertissent une valeur numérique en chaîne relative.
Vous pouvez, par exemple, l’utiliser pour une colonne horaire qui accepte les agrégats avg
, min
et max
. À mesure que les agrégats max
/ min
/ avg
s’affichent sous la forme d’une différence temporelle (par exemple, 10 days ago
), ils nécessitent un formateur de données. Pour cela, un formateur datedelta
est appliqué aux valeurs agrégées max
/ min
/ avg
. Si un agrégat count
est également disponible, aucun formateur n’est nécessaire, pas plus que la valeur d’origine.
Actuellement, les formateurs de type de données disponibles sont les suivants :
-
format
Formateur de type de données :
-
duration
La durée correspond à l’intervalle entre deux dates définies. Par exemple, le début et la fin d’une action de workflow qui a duré 1 heure, lancée le 13/02/2011 à 11h23, pour se terminer une heure plus tard, le 13/02/2011 à 12h23.
Il convertit une valeur numérique (interprétée en millisecondes) en chaîne de durée ; par exemple,
30000
est formaté comme *30s
.* -
datedelta
Datadelta est une période entre une date passé et « maintenant » (le résultat sera donc différent si le rapport est visualisé ultérieurement).
Il convertit une valeur numérique (interprétée en tant que différence temporelle en jours) en une chaîne de date relative. Par exemple, 1 est formaté comme étant « il y a 1 jour ».
-
L’exemple suivant définit le formatage de datedelta
pour les agrégats min
et max
:
N:definitions
N:data
N:preprocessing
N:apply
N:aggregated
N:min
P:format = "datedelta"
N:max
P:format = "datedelta"
Définitions spécifiques à la colonne column-specific-definitions
Les définitions spécifiques à la colonne définissent les colonnes et agrégats disponibles pour cette colonne.
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
Les options suivantes sont disponibles en standard :
-
string
-
number
-
int
-
date
-
diff
-
timeslot
Utilisé pour extraire des parties d’une date nécessaires pour l’agrégation (par exemple, un regroupement par année pour obtenir des données agrégées pour chaque année).
-
sortable
Utilisé pour des valeurs qui utilisent différentes valeurs (provenant de différentes propriétés) à des fins de tri et d’affichage.
En outre, l’une des options ci-dessus peut être définie comme valeur multiple ; par exemple,string[]
définit un tableau de chaînes.
L’extracteur de valeurs est sélectionné par le type de colonne. Si un extracteur de valeurs est disponible pour un type de colonne, il est utilisé. Dans le cas contraire, l’extracteur de valeur par défaut est utilisé.
Un type peut (éventuellement) prendre un paramètre. Par exemple,
timeslot:year
extrait l’année d’un champ de date. Types avec leurs paramètres :-
timeslot
- Les valeurs sont comparables aux constantes correspondantes dejava.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
Détermine si le rapport peut être regroupé en fonction de cette colonne.
-
filters
Définitions de filtre.
-
filterType
Les filtres disponibles sont les suivants :
-
string
Filtre basé sur une chaîne.
-
-
id
Identifiant du filtre.
-
phase
Phases disponibles :
-
raw
Le filtre est appliqué sur les données brutes.
-
preprocessed
Le filtre est appliqué sur les données prétraitées.
-
resolved
Le filtre est appliqué sur les données résolues.
-
-
-
aggregates
Définitions d’agrégat.
-
text
Nom textuel de l’agrégat. Si
text
n’est pas spécifié, la description par défaut de l’agrégat est utilisée ; par exemple,minimum
est utilisé pour l’agrégatmin
. -
type
Type d’agrégat. Les agrégats disponibles sont les suivants :
-
count
Compte le nombre de lignes.
-
count-nonempty
Compte le nombre de lignes non vides.
-
min
Fournit la valeur minimale.
-
max
Fournit la valeur maximale.
-
average
Fournit la valeur moyenne.
-
sum
Fournit la somme de toutes les valeurs.
-
median
Fournit la valeur médiane.
-
percentile95
Prend le 95e percentile de toutes les valeurs.
-
-
Valeurs par défaut de colonne column-default-values
Celles-ci sont utilisées pour définir les valeurs par défaut de la colonne :
N:defaults
P:aggregate
-
aggregate
Les valeurs
aggregate
valides sont les mêmes que pourtype
sousaggregates
(voir Définitions spécifiques à la colonne (définitions - filtres / agrégats)).
Événements et actions events-and-actions
Modifier la configuration définit les événements nécessaires que les écouteurs doivent détecter et les actions à appliquer après ces événements. Pour obtenir des informations générales, consultez Présentation du développement de composants.
Les valeurs suivantes doivent être définies afin que toutes les actions requises soient traitées :
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"
Colonnes génériques generic-columns
Les colonnes génériques sont une extension où (la plupart) des définitions de colonne sont stockées sur l’instance du noeud de colonne (plutôt que sur le noeud de composant).
Ils utilisent une boîte de dialogue (standard) que vous personnalisez pour chaque composant générique. Cette boîte de dialogue permet à l’utilisateur du rapport de définir les propriétés de colonne d’une colonne générique sur la page du rapport (à l’aide de l’option de menu ). Propriétés des colonnes…).
Exemple : la colonne Générique du Rapport utilisateur ; voir /libs/cq/reporting/components/userreport/genericcol
.
Pour rendre une colonne générique, procédez comme suit :
-
Définissez la propriété
type
du nœuddefinition
de la colonne surgeneric
.Consultez
/libs/cq/reporting/components/userreport/genericcol/definitions
. -
Spécifiez une définition de boîte de dialogue (standard) sous le nœud
definition
de la colonne.Consultez
/libs/cq/reporting/components/userreport/genericcol/definitions/dialog
.-
Les champs de la boîte de dialogue doivent faire référence aux mêmes noms que la propriété de composant correspondante (y compris son chemin d’accès).
Par exemple, si vous souhaitez que le type de la colonne générique puisse être configuré par le biais de la boîte de dialogue, utilisez un champ avec le nom
./definitions/type
. -
Les propriétés définies à l’aide de l’interface utilisateur/la boîte de dialogue sont prioritaires sur celles définies sur le composant
columnbase
.
-
-
Définissez la configuration de modification.
Consultez
/libs/cq/reporting/components/userreport/genericcol/cq:editConfig
. -
Utilisez les méthodes AEM standard pour définir des propriétés de colonne (supplémentaires).
Notez que pour les propriétés qui sont définies à la fois sur les instances de composant et de colonne, la valeur définie sur la colonne est prioritaire.
Les propriétés disponibles pour une colonne générique sont les suivantes :
jcr:title
- Nom de la colonnedefinitions/aggregates
- Agrégatsdefinitions/filters
- Filtresdefinitions/type
- Type de la colonne (doit être défini dans la boîte de dialogue, soit à l’aide d’un sélecteur ou d’une zone de liste modifiable, soit d’un champ masqué)definitions/data/resolver
etdefinitions/data/resolverConfig
(mais pasdefinitions/data/preprocessing
ou.../clientFilter
) - Le programme de résolution et la configurationdefinitions/queryBuilder
- Configuration du générateur de requêtesdefaults/aggregate
- Agrégat par défaut
Dans le cas d’une nouvelle instance de la colonne générique dans le Rapport utilisateur, les propriétés définies avec la boîte de dialogue sont conservées sous :
/etc/reports/userreport/jcr:content/report/columns/genericcol/settings/generic
Conception de rapports report-design
La conception définit les types de colonnes disponibles pour la création d’un rapport. Il définit également le système de paragraphes auquel les colonnes sont ajoutées.
Il est vivement recommandé de créer une conception individuelle pour chaque rapport. Cela garantit une flexibilité totale. Consultez aussi Définition de votre nouveau rapport.
Les composants de création de rapports par défaut sont conservés sous /etc/designs/reports
.
L’emplacement de vos rapports peut varier selon l’endroit où vous avez placé les composants :
-
/etc/designs/reports/<yourReport>
convient si le rapport se trouve sous/apps/cq/reporting
. -
/etc/designs/<yourProject>/reports/<*yourReport*>
pour les rapports utilisant le motif/apps/<yourProject>/reports
.
Les propriétés de conception requises sont enregistrées sur jcr:content/reportpage/report/columns
(par exemple, /etc/designs/reports/<reportName>/jcr:content/reportpage/report/columns
) :
-
components
Tous les composants et/ou groupes de composants autorisés sur le rapport.
-
sling:resourceType
Propriété avec la valeur
cq/reporting/components/repparsys
.
Voici un exemple de fragment de code de conception (extrait de la conception du rapport de composant) :
<!-- ... -->
<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>
<!-- ... -->
Il n’est pas nécessaire de spécifier des conceptions pour des colonnes individuelles. Les colonnes disponibles peuvent être définies en mode de conception.
Modèle de rapport report-template
Chaque type de rapport doit fournir un modèle. Il s’agit de Modèles CQ standard qui peuvent être configurés comme tels.
Le modèle doit :
-
définir le
sling:resourceType
surcq/reporting/components/reportpage
; -
indiquer la conception à utiliser ;
-
créer un nœud enfant
report
qui référence le composant de conteneur (reportbase
) au moyen de la propriétésling:resourceType
.
Voici un exemple de fragment de code de modèle (extrait du modèle de rapport de composant) :
<!-- ... -->
<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>
<!-- .. -->
Voici un exemple de fragment de code de modèle, indiquant la définition du chemin racine (extrait du modèle de rapport utilisateur) :
<!-- ... -->
<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>
<!-- .. -->
Les modèles de création de rapports par défaut se situent sous /libs/cq/reporting/templates
.
Cependant, il est vivement conseillé de ne pas mettre à jour ces nœuds, mais de créer vos propres nœuds de composant sous /apps/cq/reporting/templates
ou, le cas échéant, sous /apps/<yourProject>/reports/templates
.
Où, par exemple (voir aussi Emplacement des composants de rapport) :
N:apps
N:cq [nt:folder]
N:reporting|reports [sling:Folder]
N:templates [sling:Folder]
En dessous, créez la racine de votre modèle :
N:apps
N:cq [nt:folder]
N:reporting|reports [sling:Folder]
N:templates [sling:Folder]
N:<reportname> [sling:Folder]
Création De Votre Propre Rapport - Exemple creating-your-own-report-an-example
Définition de votre nouveau rapport defining-your-new-report
Pour définir un nouveau rapport, vous devez créer et configurer les éléments suivants :
- La racine de vos composants de rapport.
- Composant de base de rapports.
- Un ou plusieurs composants de base de colonne.
- La conception du rapport.
- La racine de votre modèle de rapport.
- Le modèle de rapport.
Pour illustrer ces étapes, l’exemple suivant définit un rapport qui répertorie toutes les configurations OSGi dans le référentiel ; c’est-à-dire toutes les instances du nœud sling:OsgiConfig
.
-
Créez le nœud racine de votre nouveau rapport.
Par exemple, sous
/apps/cq/reporting/components/osgireport
.code language-xml N:cq [nt:folder] N:reporting [sling:Folder] N:components [sling:Folder] N:osgireport [sling:Folder]
-
Définissez votre base de rapport. Par exemple
osgireport[cq:Component]
sous/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"
Cet exemple définit un composant de rapport de base qui :
- recherche tous les nœuds de type
sling:OsgiConfig
; - affiche les graphiques
pie
etlineseries
; - fournit une boîte de dialogue permettant à l’utilisateur de configurer le rapport.
- recherche tous les nœuds de type
-
Définissez votre premier composant de colonne (columnbase). Par exemple
bundlecol[cq:Component]
sous/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"
Cet exemple définit un composant de base de colonne qui :
- recherche et renvoie la valeur qu’il reçoit du serveur ; dans ce cas, la propriété
jcr:path
de chaque nœudsling:OsgiConfig
; - fournit l’agrégat
count
; - ne peut pas être regroupé ;
- porte le titre
Bundle
(titre de colonne dans le tableau) ; - se trouve dans l’
OSGi Report
du groupe sidekick ; - est actualisé lors d’événements spécifiés.
note note NOTE Dans cet exemple, il n’existe aucune définition de N:data
ni deP:clientFilter
. Cela est dû au fait que la valeur reçue du serveur est renvoyée sur une base 1:1 ; ce qui est le comportement par défaut.Il s’agit de la même chose que les définitions : code language-none N:data [nt:unstructured] P:clientFilter [String] = "function(v) { return v; }"
Lorsque la fonction renvoie simplement la valeur qu’elle reçoit. - recherche et renvoie la valeur qu’il reçoit du serveur ; dans ce cas, la propriété
-
Définissez votre conception de rapport. Par exemple
osgireport[cq:Page]
sous/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"
-
Créez le nœud racine de votre nouveau modèle de rapport.
Par exemple, sous
/apps/cq/reporting/templates/osgireport
.code language-xml N:cq [nt:folder] N:reporting [sling:Folder] N:templates [sling:Folder] N:osgireport [cq:Template]
-
Définissez votre modèle de rapport. Par exemple
osgireport[cq:Template]
sous/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 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]
Cet exemple définit un modèle qui :
- définit les chemins autorisés (
allowedPaths
) pour les rapports obtenus (dans l’exemple ci-dessus, n’importe où sous/etc/reports
) ; - fournit des titres et des descriptions pour le modèle ;
- fournit une vignette pour l’utiliser dans la liste de modèles (la définition complète de ce nœud n’est pas indiquée ci-dessus ; il est plus facile de copier une instance de thumbnail.png à partir d’un rapport existant).
- définit les chemins autorisés (
Création d’une instance de votre nouveau rapport creating-an-instance-of-your-new-report
Vous pouvez maintenant créer une instance de votre nouveau rapport :
-
Ouvrez la console Outils.
-
Sélectionner Rapports dans le volet de gauche.
-
Alors Nouveau… dans la barre d’outils. Définition d’une Titre et Nom, sélectionnez votre nouveau type de rapport (le Modèle de rapport OSGi) dans la liste des modèles, puis cliquez sur Créer.
-
Votre nouvelle instance de rapport apparaît dans la liste. Double-cliquez dessus pour l’ouvrir.
-
Faites glisser un composant (pour cet exemple, Bundle dans le groupe Rapport OSGi) depuis le sidekick pour créer la première colonne et commencez la définition du rapport.
note note NOTE Puisque cet exemple ne contient pas de colonnes pouvant être groupées, les graphiques ne sont pas disponibles. Pour afficher les graphiques, définissez groupable
surtrue
:code language-none N:osgireport [sling:Folder] N:bundlecol [cq:Component] N:definitions [nt:unstructured] P:groupable [Boolean] = true
Configuration des services de structure de rapports configuring-the-report-framework-services
Cette section décrit les options de configuration avancées pour les services OSGi qui implémentent la structure de rapports.
Il est possible de les consulter à l’aide du menu Configuration de la console Web (disponible, par exemple, à l’adresse http://localhost:4502/system/console/configMgr
). Lorsque vous utilisez AEM, plusieurs méthodes permettent de gérer les paramètres de configuration pour ces services. Consultez la section Configuration d’OSGi pour plus de détails et connaître les pratiques recommandées.
Service de base (configuration des rapports Day CQ) basic-service-day-cq-reporting-configuration
-
Fuseau horaire définit le fuseau horaire pour lequel les données historiques sont créées. Cela permet de s’assurer que le graphique historique affiche les mêmes données pour chaque utilisateur dans le monde entier.
-
Paramètres régionaux définit les paramètres régionaux à utiliser conjointement avec la variable Fuseau horaire pour les données historiques. Les paramètres régionaux sont utilisés pour déterminer certains paramètres du calendrier spécifiques aux paramètres régionaux (par exemple, si le premier jour d’une semaine est dimanche ou lundi).
-
Chemin de l’instantané définit le chemin racine où sont stockés les instantanés des graphiques historiques.
-
Chemin d’accès aux rapports définit le chemin d’accès à l’emplacement des rapports. Il est utilisé par le service d’instantané pour déterminer les rapports pour lesquels prendre des instantanés.
-
Instantanés quotidiens définit l’heure de chaque jour où des instantanés quotidiens sont réalisés. L’heure spécifiée se trouve dans le fuseau horaire local du serveur.
-
Instantanés horaires définit la minute de chaque heure à laquelle des instantanés horaires sont réalisés.
-
Lignes (max) définit le nombre maximal de lignes stockées pour chaque instantané. Cette valeur doit être choisie raisonnablement; s’il est trop élevé, cela aura une incidence sur la taille du référentiel. s’il est trop faible, les données peuvent ne pas être exactes en raison de la façon dont les données historiques sont traitées.
-
Fausses données : si cette option est activée, de fausses données historiques peuvent être créées à l’aide du sélecteur
fakedata
. Si elle est désactivée, l’utilisation du sélecteurfakedata
générera une exception.Les données étant fausses, elles doivent uniquement être utilisées à des fins de test et de débogage.
L’utilisation du sélecteur
fakedata
met implicitement fin au rapport, de sorte que toutes les données existantes sont perdues ; elles peuvent être restaurées manuellement, mais il s’agit d’un processus particulièrement long. -
Utilisateur d’instantanés : définit un utilisateur facultatif qui peut être utilisé pour prendre des instantanés.
En fait, les instantanés sont réalisés pour l’utilisateur qui a terminé le rapport. Dans certains cas (par exemple, sur un système de publication, où cet utilisateur n’existe pas, car son compte n’a pas été répliqué), vous pouvez spécifier un utilisateur de secours qui est utilisé à la place.
Spécifier un utilisateur peut, en outre, poser un risque sur le plan de la sécurité.
-
Imposer l’utilisateur d’instantanés : si cette option est activée, tous les instantanés sont effectués avec l’utilisateur spécifié sous Utilisateur d’instantanés. Mal gérée, cette option peut présenter de sérieux risques sur la sécurité.
Paramètres du cache (cache de création de rapports Day CQ) cache-settings-day-cq-reporting-cache
- Activer vous permet d’activer ou de désactiver la mise en cache des données de rapport. L’activation du cache du rapport permet de conserver les données du rapport en mémoire pendant plusieurs requêtes. Cela peut améliorer les performances, mais peut entraîner une consommation de mémoire plus élevée et, dans des circonstances extrêmes, entraîner des problèmes de mémoire insuffisante.
- TTL définit la durée (en secondes) pendant laquelle les données du rapport sont mises en cache. Un nombre plus élevé améliore les performances, mais peut également renvoyer des données inexactes si les données changent au cours de la période.
- Entrées maximales définit le nombre maximal de rapports à mettre en cache à la fois.
2
met en cache des données pour :- un seul rapport pour deux utilisateurs avec des paramètres linguistiques différents ou
- un seul utilisateur et deux rapports.