AEM fornece uma seleção de relatórios padrão a maioria dos quais se baseia em uma estrutura de relatórios.
Usando a estrutura, você pode estender esses relatórios padrão ou desenvolver seus próprios relatórios completamente novos. A estrutura do relatórios integra-se perfeitamente aos conceitos e princípios do CQ5 existentes, para que os desenvolvedores possam usar seus conhecimentos atuais do CQ5 como trampolim para desenvolver relatórios.
Para os relatórios padrão entregues com AEM:
Esses relatórios são baseados na estrutura do relatórios:
Os seguintes relatórios baseiam-se em princípios individuais e, por conseguinte, não podem ser alargados:
O tutorial Criação de seu próprio relatório - Um exemplo também mostra quantos dos princípios abaixo podem ser usados.
Você também pode consultar os relatórios padrão para ver outros exemplos de implementação.
Nos exemplos e definições abaixo, é usada a seguinte notação:
Cada linha define um nó ou uma propriedade em que:
N:<name> [<nodeType>]
Descreve um nó com o nome <*name*>
e o tipo de nó <*nodeType*>
.
P:<name> [<propertyType]
Descreve uma propriedade com o nome de <*name*>
e um tipo de propriedade de <*propertyType*>
.
P:<name> = <value>
Descreve uma propriedade <name>
que deve ser definida com o valor de <value>
.
O recuo mostra as dependências hierárquicas entre os nós.
Itens separados por | indica uma lista de itens possíveis; por exemplo, tipos ou nomes:
por exemplo, String|String[]
significa que a propriedade pode ser String ou String[].
[]
representa um conjunto; como [] Stringor ou uma matriz de nós como na Definição do Query.
Salvo indicação em contrário, os tipos padrão são:
nt:unstructured
String
A estrutura do relatórios assenta nos seguintes princípios:
Ele se baseia inteiramente em conjuntos de resultados que são retornados por um query executado pelo CQ5 QueryBuilder.
O conjunto de resultados define os dados exibidos no relatório. Cada linha no conjunto de resultados corresponde a uma linha na visualização tabular do relatório.
As operações disponíveis para execução no conjunto de resultados assemelham-se aos conceitos do RDBMS; primariamente agrupamento e agregação.
A maioria da recuperação e do processamento de dados é feita no servidor.
O cliente é o único responsável pela exibição dos dados pré-processados. Somente tarefas de processamento secundárias (por exemplo, criação de links no conteúdo da célula) são executadas no cliente.
A estrutura do relatórios (ilustrada pela estrutura de um relatório padrão) usa os seguintes blocos componentes, alimentados pela fila de processamento:
A página do relatório:
O componente reportbase
forma a base de qualquer relatório como ele:
Mantém a definição do query que fornece o conjunto de dados de resultado subjacente.
É um sistema de parágrafo adaptado que conterá todas as colunas ( columnbase
) adicionadas ao relatório.
Define quais tipos de gráficos estão disponíveis e quais estão ativos no momento.
Define a caixa de diálogo Editar, que permite ao usuário configurar certos aspectos do relatório.
Cada coluna é uma instância do componente columnbase
que:
reportbase
) do respectivo relatório.O query:
É definido como parte do componente reportbase
.
É baseado no CQ QueryBuilder.
Recupera os dados usados como base do relatório. Cada linha do conjunto de resultados (tabela) é vinculada a um nó conforme retornado pelo query. As informações específicas para colunas individuais são então extraídas deste conjunto de dados.
Normalmente consiste em:
Um caminho raiz.
Isso especifica a subárvore do repositório a ser pesquisado.
Para ajudar a minimizar o impacto no desempenho, é aconselhável restringir o query a uma subárvore específica do repositório. O caminho raiz pode ser predefinido no modelo de relatório ou definido pelo usuário na caixa de diálogo Configuração (Editar).
São impostas para produzir o resultado (inicial) fixado; incluem, por exemplo, restrições no tipo de nó ou restrições de propriedade.
O ponto principal aqui é que cada nó retornado no conjunto de resultados do query é usado para gerar uma única linha no relatório (portanto, uma relação 1:1).
O desenvolvedor deve garantir que o query definido para um relatório retorne um conjunto de nós apropriado para esse relatório. No entanto, o nó em si não precisa conter todas as informações necessárias, isso também pode ser derivado de nós pai e/ou filho. Por exemplo, o query usado para o Relatório do usuário seleciona nós com base no tipo de nó (neste caso, rep:user
). No entanto, a maioria das colunas neste relatório não obtém seus dados diretamente desses nós, mas dos nós filhos profile
.
O query a1/> retorna um conjunto de dados de resultado a ser exibido como linhas no relatório. Cada linha no conjunto de resultados é processada (no lado do servidor), em várias fases, antes de ser transferida para o cliente para exibição no relatório.
Isso permite:
Extrair e derivar valores do conjunto de resultados subjacente.
Por exemplo, permite processar dois valores de propriedade como um único valor, calculando a diferença entre os dois.
Resolução dos valores extraídos; isso pode ser feito de várias maneiras.
Por exemplo, os caminhos podem ser mapeados para um título (como no conteúdo mais legível por humanos da respectiva propriedade jcr:title).
Aplicação de filtros em vários pontos.
Criação de valores compostos, se necessário.
Por exemplo, consistindo de um texto que é exibido ao usuário, um valor a ser usado para classificar e um URL adicional que é usado (no lado do cliente) para criar um link.
O fluxo de trabalho a seguir representa a fila de processamento:
Quando as etapas e os elementos detalhados forem:
Transforma os resultados retornados pelo query inicial (reportbase) no conjunto de resultados básicos usando extratores de valor.
Os extratores de valores são escolhidos automaticamente dependendo do tipo de coluna a1/>. São utilizados para ler valores a partir do Query JCR subjacente e para criar um conjunto de resultados a partir deles; após o que pode ser aplicada a transformação subsequente. Por exemplo, para o tipo diff
, o extrator de valor lê duas propriedades, calcula o valor único que é adicionado ao conjunto de resultados. Os extratores de valor não podem ser configurados.
Para esse conjunto de resultados inicial, contendo dados brutos, filtragem inicial (fase bruta) é aplicada.
Os valores são pré-processados; conforme definido para a fase apply.
A filtragem (atribuída à fase ** pré-processada) é executada nos valores pré-processados.
Os valores são resolvidos; de acordo com o resolvedor definido.
A filtragem (atribuída à fase ** resolvida) é executada nos valores resolvidos.
Os dados são agrupados e agregados.
Os dados da matriz são resolvidos convertendo-os em uma lista (baseada em sequência).
Esta é uma etapa implícita que converte um resultado de vários valores em uma lista que pode ser exibida; é necessário para valores de células (não agregadas) baseados em propriedades JCR de vários valores.
Os valores são novamente pré-processados; conforme definido para a fase afterApply.
Os dados são classificados.
Os dados processados são transferidos para o cliente.
O query inicial que retorna o conjunto de resultados de dados base é definido no componente reportbase
.
Outros elementos da fila de processamento são definidos nos componentes columnbase
.
Os seguintes itens são necessários para construir e configurar um relatório:
reportbase
componentecolumnbase
componente(s)Os componentes padrão do relatórios são mantidos em /libs/cq/reporting/components
.
No entanto, é altamente recomendável que você não atualize esses nós, mas crie seus próprios nós de componentes em /apps/cq/reporting/components
ou, se mais apropriado, /apps/<yourProject>/reports/components
.
Onde (como exemplo):
N:apps
N:cq [nt:folder]
N:reporting|reports [sling:Folder]
N:components [sling:Folder]
Sob isso, você cria a raiz do seu relatório e, sob isso, o componente base do relatório e os componentes base da coluna:
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
Uma página de relatório deve usar sling:resourceType
de /libs/cq/reporting/components/reportpage
.
Um componente de página personalizado não deve ser necessário (na maioria dos casos).
Cada tipo de relatório requer um componente de container derivado de /libs/cq/reporting/components/reportbase
.
Este componente atua como um container para o relatório como um todo e fornece informações para:
N:<reportname> [cq:Component]
P:sling:resourceSuperType = "cq/reporting/components/reportbase"
N:charting
N:dialog [cq:Dialog]
N:queryBuilder
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
Pode ser usado para limitar o conjunto de resultados a nós que têm propriedades específicas com valores específicos. Se várias restrições forem especificadas, o nó deverá atender a todas elas (operação AND).
Por exemplo:
N:propertyConstraints
[
N:0
P:sling:resourceType
P:foundation/components/textimage
N:1
P:jcr:modifiedBy
P:admin
]
Retornaria todos os textimage
componentes que foram modificados pela última vez pelo usuário admin
.
nodeTypes
Usado para limitar o conjunto de resultados aos tipos de nó especificados. Vários tipos de nó podem ser especificados.
mandatoryProperties
Pode ser usado para limitar o conjunto de resultados a nós que têm all das propriedades especificadas. O valor das propriedades não é considerado.
Todos são opcionais e podem ser combinados conforme necessário, mas você deve definir pelo menos um deles.
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
Mantém definições para os gráficos ativos.
active
Como várias configurações podem ser definidas, você pode usá-las para definir quais estão ativas no momento. Eles são definidos por uma matriz de nós (não há convenção de nomenclatura obrigatória para esses nós, mas os relatórios padrão muitas vezes usam 0
, 1
. x
), cada um com a seguinte propriedade:
id
Identificação dos gráficos ativos. Deve corresponder à ID de um dos gráficos definitions
.
definitions
Define os tipos de gráficos que estão potencialmente disponíveis para o relatório. O definitions
a ser usado será especificado pelas configurações active
.
As definições são especificadas usando uma matriz de nós (mais uma vez chamada de 0
, 1
). x
), cada um com as seguintes propriedades:
id
A identificação do gráfico.
type
O tipo de gráfico disponível. Selecionar de:
pie
Gráfico de pizza. Gerado somente a partir dos dados atuais.
lineseries
Série de linhas (pontos de conexão representando os instantâneos reais). Gerado somente a partir de dados históricos.
Propriedades adicionais estão disponíveis, dependendo do tipo de gráfico:
para o tipo de gráfico pie
:
maxRadius
( Double/Long
)
O raio máximo permitido para o gráfico setorial; portanto, o tamanho máximo permitido para o gráfico (sem legenda). Ignorado se fixedRadius
estiver definido.
minRadius
( Double/Long
)
O raio mínimo permitido para o gráfico de pizza. Ignorado se fixedRadius
estiver definido.
fixedRadius
( Double/Long
) Define um raio fixo para o gráfico de pizza.
para o tipo de gráfico lineseries
:
totals
( Boolean
)
True se uma linha adicional mostrando o Total deve ser exibida.
default: false
series
( Long
)
Número de linhas/séries a apresentar.
padrão: 9
(este também é o máximo permitido)
hoverLimit
( Long
)
Número máximo de instantâneos agregados (pontos mostrados em cada linha horizontal, representando valores distintos) para os quais os pop-ups devem ser exibidos, isto é, quando o usuário passa o mouse sobre um valor distinto ou rótulo correspondente na legenda do gráfico.
padrão: 35
(ou seja, nenhum pop-up será exibido se mais de 35 valores distintos forem aplicáveis às configurações atuais do gráfico).
Há um limite adicional de 10 pop-ups que podem ser exibidos em paralelo (vários pop-ups podem ser exibidos quando o mouse é passado sobre os textos de legenda).
Cada relatório pode ter uma caixa de diálogo de configuração, permitindo que o usuário especifique vários parâmetros para o relatório. Essa caixa de diálogo pode ser acessada pelo botão Editar quando a página do relatório estiver aberta.
Esta caixa de diálogo é um CQ padrão diálogo e pode ser configurada como tal (consulte CQ.Dialog para obter mais informações).
Um exemplo de caixa de diálogo pode ser exibido da seguinte maneira:
<?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>
Vários componentes pré-configurados são fornecidos; eles podem ser referenciados na caixa de diálogo, usando a propriedade xtype
com um valor de cqinclude
:
title
/libs/cq/reporting/components/commons/title
Campo de texto para definir o título do relatório.
description
/libs/cq/reporting/components/commons/description
Área de texto para definir a descrição do relatório.
processing
/libs/cq/reporting/components/commons/processing
Seletor para o modo de processamento do relatório (carregar dados manualmente/automaticamente).
scheduling
/libs/cq/reporting/components/commons/scheduling
Seletor para agendar instantâneos para o gráfico histórico.
Os componentes referenciados devem ser incluídos usando o sufixo .infinity.json
(consulte o exemplo acima).
Além disso, um caminho raiz pode ser definido para o relatório:
rootPath
Isso limita o relatório a uma determinada seção (árvore ou subárvore) do repositório, que é recomendada para otimização de desempenho. O caminho raiz é especificado pela propriedade rootPath
do nó report
de cada página de relatório (retirado do modelo na criação da página).
Pode ser especificado por:
Cada tipo de coluna requer um componente derivado de /libs/cq/reporting/components/columnbase
.
Um componente de coluna define uma combinação do seguinte:
definitions
nó filho).cq:editConfig
. para definir os Eventos e Ações necessários.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
Consulte também Definindo seu novo relatório.
Isso define a extração de dados específica (do conjunto de resultados de dados do relatório) para uso na coluna individual.
N:definitions
N:queryBuilder
P:property [String|String[]]
P:subPath
P:secondaryProperty [String|String[]]
P:secondarySubPath
property
Define a propriedade a ser usada para calcular o valor real da célula.
Se a propriedade for definida como String[], várias propriedades serão examinadas (em sequência) para localizar o valor real.
Por exemplo, no caso de:
property = [ "jcr:lastModified", "jcr:created" ]
O extrator de valor correspondente (que está sob controle aqui) irá:
subPath
Se o resultado não estiver localizado no nó que é retornado pelo query, subPath
define onde a propriedade está realmente localizada.
secondaryProperty
Define uma segunda propriedade que também deve ser usada para calcular o valor real da célula; isso só será usado para determinados tipos de coluna (diff e classificável).
Por exemplo, no caso do Relatório de instâncias de fluxo de trabalho, a propriedade especificada é usada para armazenar o valor real da diferença de tempo (em milissegundos) entre os tempos de start e término.
secondarySubPath
Semelhante ao subPath, quando secondaryProperty
é usado.
Na maioria dos casos, somente property
será usado.
O filtro de cliente extrai as informações a serem exibidas, dos dados retornados pelo servidor.
Esse filtro é executado no cliente, depois que todo o processamento no servidor é aplicado.
N:definitions
N:data
P:clientFilter [String]
clientFilter
é definida como uma função JavaScript que:
O exemplo a seguir extrai o caminho de página correspondente de um caminho de componente:
function(v) {
var sepPos = v.lastIndexOf('/jcr:content');
if (sepPos < 0) {
return v;
}
return v.substring(sepPos + '/jcr:content'.length, v.length);
}
A fila de processamento define os vários resolvedores e configura o pré-processamento:
N:definitions
N:data
P:resolver
N:resolverConfig
N:preprocessing
N:apply
N:applyAfter
resolver
Define o resolvedor a ser usado. Os seguintes resolvedores estão disponíveis:
const
Mapeia valores para outros valores; por exemplo, isso é usado para resolver constantes como en
para seu valor equivalente English
.
default
O resolvedor padrão. Este é um resolvedor simulado que na verdade não resolve nada.
page
Resolve um valor de caminho para o caminho da página apropriada; mais precisamente, no nó jcr:content
correspondente. Por exemplo, /content/.../page/jcr:content/par/xyz
é resolvido como /content/.../page/jcr:content
.
path
Resolve um valor de caminho anexando opcionalmente um subcaminho e obtendo o valor real de uma propriedade do nó (conforme definido por resolverConfig
) no caminho resolvido. Por exemplo, um path
de /content/.../page/jcr:content
pode ser resolvido para o conteúdo da propriedade jcr:title
, isso significa que um caminho de página é resolvido para o título da página.
pathextension
Resolve um valor ao antecipar um caminho e obter o valor real de uma propriedade do nó no caminho resolvido. Por exemplo, um valor de
pode ser anexado por um caminho como /libs/wcm/core/resources/languages
, usando o valor da propriedade language
, para resolver o código do país de
para a descrição do idioma German
.
resolverConfig
Fornece definições para o resolvedor; as opções disponíveis dependem do resolver
selecionado:
const
Use as propriedades para especificar as constantes para resolução. O nome da propriedade define a constante a ser resolvida; o valor da propriedade define o valor resolvido.
Por exemplo, uma propriedade com Name= 1
e Value =One
resolverá 1 como One.
default
Nenhuma configuração disponível.
page
propertyName
(opcional)
Define o nome da propriedade que deve ser usada para resolver o valor. Se não for especificado, o valor padrão de jcr:title (o título da página) será usado; para o resolvedor page
, isso significa que, primeiro, o caminho é resolvido para o caminho da página e depois para o título da página.
path
propertyName
(opcional)
Especifica o nome da propriedade que deve ser usada para resolver o valor. Se não for especificado, o valor padrão de jcr:title
será usado.
subPath
(opcional)
Essa propriedade pode ser usada para especificar um sufixo a ser anexado ao caminho antes que o valor seja resolvido.
pathextension
path
(mandatory)
Define o caminho a ser anexado.
propertyName
(obrigatório)
Define a propriedade no caminho resolvido no qual o valor real está localizado.
i18n
(facultativo; type Boolean)
Determina se o valor resolvido deve ser internacionalizado (isto é, usando serviços de internacionalização do CQ5).
preprocessing
O pré-processamento é opcional e pode ser vinculado (separadamente) às fases de processamento apply ou applyAfter:
apply
A fase de pré-processamento inicial (etapa 3 na representação da fila de processamento).
applyAfter
Aplique após o pré-processamento (etapa 9 na representação da fila de processamento).
Os resolvedores são usados para extrair as informações necessárias. Exemplos dos vários resolvedores são:
Const
O seguinte resolverá um valor de conteúdo de VersionCreated
para a string New version created
.
Consulte /libs/cq/reporting/components/auditreport/typecol/definitions/data
.
N:data
P:resolver=const
N:resolverConfig
P:VersionCreated="New version created"
Página
Resolve um valor de caminho para a propriedade jcr:description no nó jcr:content (filho) da página correspondente.
Consulte /libs/cq/reporting/components/compreport/pagecol/definitions/data
.
N:data
P:resolver=page
N:resolverConfig
P:propertyName="jcr:description"
Caminho
O seguinte resolve um caminho de /content/.../page
para o conteúdo da propriedade jcr:title
, isso significa que um caminho de página é resolvido para o título da página.
Consulte /libs/cq/reporting/components/auditreport/pagecol/definitions/data
.
N:data
P:resolver=path
N:resolverConfig
P:propertyName="jcr:title"
P:subPath="/jcr:content"
Extensão do caminho
O valor a seguir prepara de
com a extensão de caminho /libs/wcm/core/resources/languages
, em seguida, pega o valor da propriedade language
para resolver o código de país de
para a descrição de idioma German
.
Consulte /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"
A definição preprocessing
pode ser aplicada a:
valor original:
A definição de pré-processamento do valor original é especificada em apply
e/ou applyAfter
diretamente.
no seu estado agregado:
Se necessário, pode ser fornecida uma definição separada para cada agregação.
Para especificar o pré-processamento explícito para valores agregados, as definições de pré-processamento têm que residir em um aggregated
nó filho respectivo ( apply/aggregated
, applyAfter/aggregated
). Se for necessário pré-processamento explícito para agregações distintas, a definição de pré-processamento estará localizada em um nó filho com o nome da respectiva agregação (por exemplo, apply/aggregated/min/max
ou outras agregações).
Você pode especificar um dos seguintes itens a serem usados durante o pré-processamento:
localizar e substituir
padrõesQuando encontrado, o padrão especificado (que é definido como uma expressão regular) é substituído por outro padrão; por exemplo, isso pode ser usado para extrair uma substring do original.
Converte um valor numérico em uma string relativa; por exemplo, o valor "representando uma diferença de tempo de 1 hora seria resolvido como uma string como 1:24PM (1 hour ago)
.
Por exemplo:
N:definitions
N:data
N:preprocessing
N:apply|applyAfter
P:pattern // regex
P:replace // replacement for regex
// and/or
P:format // data type formatter
Para o pré-processamento, você pode especificar um pattern
(definido como expressão regular ou regex) localizado e substituído pelo padrão replace
:
pattern
A expressão regular usada para localizar uma subsequência de caracteres.
replace
A string, ou a representação da string, que será usada como uma substituição da string original. Geralmente, isso representa uma substring da string localizada pela expressão regular pattern
.
Um exemplo de substituição pode ser dividido como:
Para o nó definitions/data/preprocessing/apply
com as duas propriedades a seguir:
pattern
: (.*)(/jcr:content)(/|$)(.*)
replace
: $1
Uma string chegando como:
/content/geometrixx/en/services/jcr:content/par/text
Serão divididas em quatro seções:
$1
- (.*)
- /content/geometrixx/en/services
$2
- (/jcr:content)
- /jcr:content
$3
- (/|$)
- /
$4
- (.*)
- par/text
E substituída pela string representada por $1
:
/content/geometrixx/en/services
Esses formatadores convertem um valor numérico em uma string relativa.
Por exemplo, isso pode ser usado para uma coluna de hora que permite min
, avg
e max
agregações. As agregações min
/ avg
/ max
são exibidas como uma diferença de tempo (por exemplo, 10 days ago
), exigem um formatador de dados. Para isso, um formatador datedelta
é aplicado aos valores agregados min
/ avg
/ max
. Se uma agregação count
também estiver disponível, isso não precisará de um formatador, o valor original também não será necessário.
Atualmente, os formatos de tipo de dados disponíveis são:
format
Formatador de tipo de dados:
duration
Duração é o intervalo de tempo entre duas datas definidas. Por exemplo, o start e o fim de uma ação de fluxo de trabalho que levou 1 hora, começando em 13/02/11 11:23 e terminando uma hora depois em 13/02/11 12:23.
Ele converte um valor numérico (interpretado como milissegundos) em uma string de duração; por exemplo, 30000
está formatado como * 30s
.*
datedelta
Dados são o intervalo de tempo entre uma data no passado e "agora" (portanto, terá um resultado diferente se o relatório for visualizado posteriormente).
Ele converte o valor numérico (interpretado como uma diferença de tempo em dias) em uma string de data relativa. Por exemplo, 1 é formatado como 1 dia atrás.
O exemplo a seguir define a formatação datedelta
para min
e max
agregações:
N:definitions
N:data
N:preprocessing
N:apply
N:aggregated
N:min
P:format = "datedelta"
N:max
P:format = "datedelta"
As definições específicas da coluna definem os filtros e agregações disponíveis para essa coluna.
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
As opções a seguir estão disponíveis como opções padrão:
string
number
int
date
diff
timeslot
É usado para extrair partes de uma data necessária para agregação (por exemplo, grupo por ano para obter dados agregados para cada ano).
sortable
É usado para valores que usam valores diferentes (como obtidos de propriedades diferentes) para classificar e exibir.
Além disso. qualquer uma das situações anteriores pode ser definida como valor múltiplo; por exemplo, string[]
define uma matriz de strings.
O extrator de valor é escolhido pelo tipo de coluna. Se um extrator de valor estiver disponível para um tipo de coluna, esse extrator será usado. Caso contrário, o extrator de valor padrão será usado.
Um tipo pode (opcionalmente) usar um parâmetro. Por exemplo, timeslot:year
extrai o ano de um campo de data. Tipos com seus parâmetros:
timeslot
- Os valores são comparáveis às constantes correspondentes de java.utils.Calendar
.
timeslot:year
- Calendar.YEAR
timeslot:month-of-year
- Calendar.MONTH
timeslot:week-of-year
- Calendar.WEEK_OF_YEAR
timeslot:day-of-month
- Calendar.DAY_OF_MONTH
timeslot:day-of-week
- Calendar.DAY_OF_WEEK
timeslot:day-of-year
- Calendar.DAY_OF_YEAR
timeslot:hour-of-day
- Calendar.HOUR_OF_DAY
timeslot:minute-of-hour
- Calendar.MINUTE
groupable
Define se o relatório pode ser agrupado por essa coluna.
filters
Filtrar definições.
filterType
Os filtros disponíveis são:
string
Um filtro baseado em string.
id
Identificador do filtro.
phase
Fases disponíveis:
raw
O filtro é aplicado aos dados brutos.
preprocessed
O filtro é aplicado aos dados pré-processados.
resolved
O filtro é aplicado em dados resolvidos.
aggregates
Definições de agregação.
text
Nome textual da agregação. Se text
não for especificado, então ele usará a descrição padrão da agregação; por exemplo, minimum
será usado para a agregação min
.
type
Tipo de agregação. As agregações disponíveis são:
count
Conta o número de linhas.
count-nonempty
Conta o número de linhas não vazias.
min
Fornece o valor mínimo.
max
Fornece o valor máximo.
average
Fornece o valor médio.
sum
Fornece a soma de todos os valores.
median
Fornece o valor mediano.
percentile95
Obtém o 95º percentil de todos os valores.
Isso é usado para definir valores padrão para a coluna:
N:defaults
P:aggregate
aggregate
Os valores válidos de aggregate
são os mesmos que para type
em aggregates
(consulte Definições Específicas de Coluna (definições - filtros / agregações) ).
Editar configuração define os eventos necessários para que os ouvintes detectem e as ações a serem aplicadas após a ocorrência desses eventos. Consulte a introdução ao desenvolvimento de componentes para obter informações de plano de fundo.
Os valores a seguir devem ser definidos para garantir que todas as ações necessárias sejam atendidas:
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"
Colunas genéricas são uma extensão em que (a maioria das) as definições de coluna são armazenadas na instância do nó de coluna (em vez do nó de componente).
Eles usam uma caixa de diálogo (padrão), que você personaliza, para o componente genérico individual. Essa caixa de diálogo permite que o usuário do relatório defina as propriedades da coluna de uma coluna genérica na página do relatório (usando a opção de menu Propriedades da coluna…).
Um exemplo é a coluna Genérica do Relatório do Usuário; consulte /libs/cq/reporting/components/userreport/genericcol
.
Para tornar uma coluna genérica:
Defina a propriedade type
do nó definition
da coluna como generic
.
Consulte /libs/cq/reporting/components/userreport/genericcol/definitions
Especifique uma definição de diálogo (padrão) no nó definition
da coluna.
Consulte /libs/cq/reporting/components/userreport/genericcol/definitions/dialog
Os campos da caixa de diálogo devem se referir aos mesmos nomes que a propriedade do componente correspondente (incluindo seu caminho).
Por exemplo, se você deseja tornar o tipo da coluna genérica configurável por meio da caixa de diálogo, use um campo com o nome de ./definitions/type
.
As propriedades definidas usando a interface de usuário/caixa de diálogo têm prioridade sobre as definidas no componente columnbase
.
Defina Editar configuração.
Consulte /libs/cq/reporting/components/userreport/genericcol/cq:editConfig
Use metodologias de AEM padrão para definir propriedades de colunas (adicionais).
Observe que para propriedades que são definidas nas instâncias de componente e coluna, o valor na instância da coluna tem prioridade.
As propriedades disponíveis para uma coluna genérica são:
jcr:title
- nome da colunadefinitions/aggregates
- agregaçõesdefinitions/filters
- filtrosdefinitions/type
- o tipo da coluna (isso deve ser definido na caixa de diálogo, usando um seletor/caixa de combinação ou um campo oculto)definitions/data/resolver
e definitions/data/resolverConfig
(mas não definitions/data/preprocessing
ou .../clientFilter
) - o resolvedor e a configuraçãodefinitions/queryBuilder
- a configuração do construtor de querydefaults/aggregate
- a agregação padrãoNo caso de uma nova instância da coluna genérica no Relatório do Usuário as propriedades definidas com a caixa de diálogo são mantidas em:
/etc/reports/userreport/jcr:content/report/columns/genericcol/settings/generic
O design define quais tipos de coluna estão disponíveis para criar um relatório. Também define o sistema de parágrafo ao qual as colunas são adicionadas.
É altamente recomendável criar um design individual para cada relatório. Isso garante total flexibilidade. Consulte também Definindo seu novo relatório.
Os componentes padrão do relatórios são mantidos em /etc/designs/reports
.
O local para seus relatórios pode depender de onde você localizou seus componentes:
/etc/designs/reports/<yourReport>
é adequado se o relatório estiver localizado em /apps/cq/reporting
/etc/designs/<yourProject>/reports/<*yourReport*>
para relatórios que usam o /apps/<yourProject>/reports
padrão
As propriedades de design necessárias estão registradas em jcr:content/reportpage/report/columns
(por exemplo, /etc/designs/reports/<reportName>/jcr:content/reportpage/report/columns
):
components
Todos os componentes e/ou grupos de componentes permitidos no relatório.
sling:resourceType
Propriedade com valor cq/reporting/components/repparsys
.
Um trecho de design de exemplo (retirado do design do relatório do 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>
<!-- ... -->
Não é necessário especificar designs para colunas individuais. As colunas disponíveis podem ser definidas no modo de design.
É recomendável que você não faça alterações nos designs de relatório padrão. Isso garante que você não perca nenhuma alteração ao atualizar ou instalar hotfixes.
Copie o relatório e seu design se quiser personalizar um relatório padrão.
Colunas padrão podem ser criadas automaticamente quando um relatório é criado. Eles são especificados no modelo.
Cada tipo de relatório deve fornecer um modelo. Estes são modelos padrão CQ e podem ser configurados como tal.
O modelo deve:
defina sling:resourceType
como cq/reporting/components/reportpage
indicar o projeto a utilizar
crie um nó filho report
que faça referência ao componente container ( reportbase
) por meio da propriedade sling:resourceType
Um trecho de modelo de exemplo (retirado do modelo de relatório do 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>
<!-- .. -->
Um trecho de modelo de exemplo, mostrando a definição do caminho raiz (retirado do modelo de relatório do usuário), é:
<!-- ... -->
<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>
<!-- .. -->
Os modelos de relatórios padrão são mantidos em /libs/cq/reporting/templates
.
No entanto, é altamente recomendável que você não atualize esses nós, mas crie seus próprios nós de componentes em /apps/cq/reporting/templates
ou, se mais apropriado, /apps/<yourProject>/reports/templates
.
Onde, como exemplo (consulte também Localização dos componentes do relatório):
N:apps
N:cq [nt:folder]
N:reporting|reports [sling:Folder]
N:templates [sling:Folder]
Nesta seção, você cria a raiz do seu modelo:
N:apps
N:cq [nt:folder]
N:reporting|reports [sling:Folder]
N:templates [sling:Folder]
N:<reportname> [sling:Folder]
Para definir um novo relatório, é necessário criar e configurar:
Para ilustrar essas etapas, o exemplo a seguir define um relatório que lista todas as configurações OSGi no repositório. Ou seja, todas as instâncias do nó sling:OsgiConfig
.
Copiar um relatório existente e, em seguida, personalizar a nova versão é um método alternativo.
Crie o nó raiz para seu novo relatório.
Por exemplo, em /apps/cq/reporting/components/osgireport
.
N:cq [nt:folder]
N:reporting [sling:Folder]
N:components [sling:Folder]
N:osgireport [sling:Folder]
Defina sua base de relatórios. Por exemplo osgireport[cq:Component]
em /apps/cq/reporting/components/osgireport
.
N:osgireport [sling:Folder]
N:osgireport [cq:Component]
P:sling:resourceSuperType [String] = "cq/reporting/components/reportbase"
N:charting [nt:unstructured]
N:settings [nt:unstructured]
N:active [cq:WidgetCollection]
N:0 [nt:unstructured]
P:id [String] = "pie"
N:1 [nt:unstructured]
P:id [String] = "lineseries"
N:definitions [cq:WidgetCollections]
N:0 [nt:unstructured]
P:id [String] = "pie"
P:maxRadius [Long] = 180
P:type [String] = "pie"
N:1 [nt:unstructured]
P:id [String] = "lineseries"
P:type [String] = "lineseries"
N:dialog [cq:Dialog]
P:height [Long] = 424
N:items [cq:WidgetCollection]
N:props [cq:Panel]
N:items [cq:WidgetCollection]
N:title [cq:Widget]
P:path [String] = "/libs/cq/reporting/components/commons/title.infinity.json"
P:xtype [String] = "cqinclude"
N:description [cq:Widget]
P:path [String] = "/libs/cq/reporting/components/commons/description.infinity.json"
P:xtype [String] = "cqinclude"
N:rootPath [cq:Widget]
P:fieldLabel [String] = "Root path"
P:name [String] = "./report/rootPath"
P:xtype [String] = "pathfield"
N:processing [cq:Widget]
P:path [String] = "/libs/cq/reporting/components/commons/processing.infinity.json"
P:xtype [String] = "cqinclude"
N:scheduling [cq:Widget]
P:path [String] = "/libs/cq/reporting/components/commons/scheduling.infinity.json"
P:xtype [String] = "cqinclude"
N:queryBuilder [nt:unstructured]
P:nodeTypes [String[]] = "sling:OsgiConfig"
Isso define um componente de base de relatórios que:
sling:OsgiConfig
pie
e lineseries
Defina o componente da primeira coluna (columnbase). Por exemplo bundlecol[cq:Component]
em /apps/cq/reporting/components/osgireport
.
N:osgireport [sling:Folder]
N:bundlecol [cq:Component]
P:componentGroup [String] = "OSGi Report"
P:jcr:title = "Bundle"
P:sling:resourceSuperType [String] = "cq/reporting/components/columnbase"
N:cq:editConfig [cq:EditConfig]
P:cq:actions [String[]] = "insert", "delete"
P:cq:dialogMode [String] = "floating"
P:cq:layout [String] = "auto"
N:cq:listeners [cq:EditListenersConfig]
P:aftercreate [String] "REFRESH_INSERTED"
P:afterdelete [String] "REFRESH_SELF"
P:afteredit [String] "REFRESH_SELF"
P:afterinsert [String] "REFRESH_INSERTED"
P:aftermove [String] "REFRESH_SELF"
P:afterremove [String] "REFRESH_SELF"
N:defaults [nt:unstructured]
P:aggregate [String] = "count"
N:definitions [nt:unstructured]
P:groupable [Boolean] = false
P:type [String] = "string"
N:queryBuilder [nt:unstructured]
P:property [String] = "jcr:path"
Isso define um componente base de coluna que:
jcr:path
para cada nó sling:OsgiConfig
count
Bundle
(título da coluna na tabela)OSGi Report
Neste exemplo, não há definições de N:data
e P:clientFilter
. Isso ocorre porque o valor recebido do servidor é retornado com base em 1:1 - que é o comportamento padrão.
É o mesmo que as definições:
N:data [nt:unstructured]
P:clientFilter [String] = "function(v) { return v; }"
Quando a função simplesmente retorna o valor recebido.
Defina seu design de relatório. Por exemplo osgireport[cq:Page]
em /etc/designs/reports
.
N:osgireport [cq:Page]
N:jcr:content [nt:unstructured]
P:jcr:title [String] = "OSGi report"
P:sling:resourceType [String] = "wcm/core/components/designer"
N:reportpage [nt:unstructured]
N:report [nt:unstructured]
N:columns [nt:unstructured]
P:components [String] = "group:OSGi Report"
P:sling:resourceType [String] = "cq/reporting/components/repparsys"
Crie o nó raiz para seu novo modelo de relatório.
Por exemplo, em /apps/cq/reporting/templates/osgireport
.
N:cq [nt:folder]
N:reporting [sling:Folder]
N:templates [sling:Folder]
N:osgireport [cq:Template]
Defina seu modelo de relatório. Por exemplo osgireport[cq:Template]
em /apps/cq/reporting/templates
.
N:osgireport [cq:Template]
P:allowedPaths [String[]] = "/etc/reports(/.*)?"
P:jcr:description [String] = "Use this report generator to create a new OSGi report."
P:jcr:title [String] = "OSGi Report Template"
P:ranking [Long] = 100
P:shortTitle [String] = "OSGi Report"
N:jcr:content [cq:PageContent]
P:cq:designPath [String] = "/etc/designs/reports/osgireport"
P:sling:resourceType [String] = "cq/reporting/components/reportpage"
N:report [nt:unstructured]
P:rootPath [String] = "/"
P:sling:resourceType [String] = "cq/reporting/components/osgireport/osgireport"
N:thumbnail.png [nt:file]
Isso define um modelo que:
allowedPaths
para os relatórios resultantes - no caso acima, em qualquer lugar em /etc/reports
Uma instância do seu novo relatório agora pode ser criada:
Abra o console Ferramentas.
Selecione Relatórios no painel esquerdo.
Em seguida, Novo… da barra de ferramentas. Defina um Título e Nome, selecione o novo tipo de relatório (o Modelo de Relatório OSGi) na lista de modelos e clique em Criar.
Sua nova instância do relatório será exibida na lista. Clique neste duplo para abrir.
Arraste um componente (por exemplo, Bundle no grupo Relatório OSGi) do sidekick para criar a primeira coluna e start a definição do relatório.
Como este exemplo não tem nenhuma coluna agrupável, os gráficos não estarão disponíveis. Para ver gráficos, defina groupable
como true
:
N:osgireport [sling:Folder]
N:bundlecol [cq:Component]
N:definitions [nt:unstructured]
P:groupable [Boolean] = true
Esta seção descreve as opções de configuração avançadas para os serviços OSGi que implementam a estrutura de relatório.
Eles podem ser exibidos usando o menu Configuração do console da Web (disponível, por exemplo, em http://localhost:4502/system/console/configMgr
). Ao trabalhar com AEM existem vários métodos de gestão das definições de configuração para esses serviços; consulte Configuração do OSGi para obter mais detalhes e as práticas recomendadas.
O Timezonedefine os dados históricos de fuso horário para os quais são criados. Isso garante que o gráfico histórico exiba os mesmos dados para cada usuário ao redor do globo.
Localedefine a localidade a ser usada em conjunto com o Timezonepara dados históricos. A localidade é usada para determinar algumas configurações de calendário específicas da localidade (por exemplo, se o primeiro dia de uma semana é domingo ou segunda-feira).
Os caminhos de instantâneo definem o caminho raiz onde os instantâneos para gráficos históricos são armazenados.
Caminho para relatórios define o caminho onde os relatórios estão localizados. Isso é usado pelo serviço de snapshot para determinar os relatórios para os quais realmente são obtidos instantâneos.
Os instantâneos diários definem a hora de cada dia em que os instantâneos diários são tirados. A hora especificada está no fuso horário local do servidor.
Os instantâneos por hora definem o minuto de cada hora quando os instantâneos por hora são tirados.
As linhas (máx.) definem o número máximo de linhas armazenadas para cada instantâneo. Este valor deve ser razoavelmente escolhido; se for muito alto, isso afetará o tamanho do repositório, se for muito baixo, os dados podem não ser precisos devido à forma como os dados históricos são tratados.
Dados falsos, se ativados, podem ser criados dados históricos falsos usando o fakedata
seletor; se desativado, o uso do fakedata
seletor acionará uma exceção.
Como os dados são falsos, eles devem somente ser usados para fins de teste e depuração.
O uso do seletor fakedata
finalizará o relatório implicitamente, de modo que todos os dados existentes serão perdidos; os dados podem ser restaurados manualmente, mas isso pode ser um processo demorado.
O usuário do snapshot define um usuário opcional que pode ser usado para tirar instantâneos.
Basicamente, os instantâneos são tirados para o usuário que terminou o relatório. Pode haver situações (por exemplo, em um sistema de publicação, em que esse usuário não existe, pois sua conta não foi replicada) em que você deseja especificar um usuário de fallback que é usado.
Além disso, especificar um usuário pode impor um risco à segurança.
Impor usuário de snapshot, se ativado, todos os snapshots serão coletados com o usuário especificado em Usuário de Snapshot. Isso pode ter sérios impactos na segurança se não for tratado corretamente.
Os dados do relatório podem ser diferentes para cada usuário e idioma. Portanto, os dados do relatório são armazenados em cache por relatório, usuário e idioma. Isso significa que um valor Máximo de entradas de 2
realmente armazena dados em cache para: