レポートの開発 developing-reports
AEM には様々な標準レポートが用意されており、それらのほとんどはレポートフレームワークに基づいています。
フレームワークを使用して、これらの標準レポートを拡張するか、または独自の完全に新しいレポートを作成できます。 レポートフレームワークは、既存の CQ5 の概念や原則と緊密に統合されているので、開発者は CQ5 に関する既存の知識を、レポート開発の出発点として活用できます。
AEM に用意されている標準レポートの特徴:
-
以下のレポートは、レポートフレームワークに基づいています。
-
以下のレポートは、個別の原則に基づいているので、拡張できません。
-
各行では、次のようにノードまたはプロパティを定義しています。
-
N:<name> [<nodeType>]
という名前のノードを表します。
<*name*>
およびのノードタイプ<*nodeType*>
. -
P:<name> [<propertyType]
という名前のプロパティを記述します。
<*name*>
およびのプロパティタイプ<*propertyType*>
. -
P:<name> = <value>
プロパティを記述します
<name>
を<value>
.
-
-
インデントは、ノード間の階層的依存関係を示します。
-
次で区切られた項目 |は可能な項目のリストを示します。例えば、型や名前は次のようになります。
例:
String|String[]
は、プロパティが String または String のいずれかであることを示します。[]. -
[]
は配列を示します。例えば String[] や、クエリ定義で説明しているノードの配列などがあります。
- ノード -
nt:unstructured
- プロパティ -
String
レポートフレームワーク reporting-framework
レポートフレームワークは、次のような原則に従って動作します。
-
完全に、CQ5 QueryBuilder で実行されるクエリによって返される結果セットに基づいています。
-
結果セットは、レポートに表示するデータを定義します。結果セットの各行は、レポートの表形式表示の行に対応しています。
-
結果セットに対して実行できる操作は RDBMS の概念に似ており、主に グループ化 と 集約 です。
-
データの取得と処理のほとんどはサーバー側でおこなわれます。
-
クライアント側では、事前に処理されたデータの表示のみが行われます。小規模な処理タスク(セルコンテンツ内のリンクの作成など)のみクライアント側で実行されます。
レポートフレームワーク(標準レポートの構造で示される)は、処理キューによって提供される次の構築ブロックを使用します。
レポートページ report-page
レポートページの特徴は次のとおりです。
- 標準の CQ5 ページです。
- が 標準の CQ5 テンプレート。レポート用に設定されます。.
レポートベース report-base
reportbase
コンポーネントは、すべてのレポートの基礎となるもので、次のような特徴があります。
-
基になる結果セットのデータを提供するクエリの定義を保持しています。
-
レポートに追加されたすべての列(
columnbase
)を含む適応可能な段落システムです。 -
使用可能なグラフの種類と、現在アクティブなグラフの種類を定義します。
-
編集ダイアログを定義します。このダイアログでは、レポートの特定のデザインを設定できます。
列ベース column-base
各列は、 columnbase
コンポーネントのインスタンスであり、次のような特徴があります。
- 各レポートの parsys(
reportbase
)で使用される段落です。 - 基になる結果セットへのリンクを定義します。つまり、この結果セット内で参照される特定のデータと、その処理方法を定義します。
- 使用可能な集約やフィルターなどといった追加の定義のほか、デフォルト値も保持します。
クエリとデータの取得 the-query-and-data-retrieval
クエリ:
-
reportbase
コンポーネントの一部として定義されます。 -
は、 CQ QueryBuilder.
-
レポートの基本要素として使用するデータを取得します。結果セット(テーブル)の各行は、クエリが返すノードに結び付けられます。 それぞれの列の具体的な情報はこのデータセットから抽出されます。
-
通常、次で構成されます。
-
ルートパス。
これにより、検索対象とするリポジトリのサブツリーを指定します。
パフォーマンスへの影響を減らすため、クエリの対象をなるべくリポジトリの特定のサブツリーに制限することをお勧めします。このルートパスは、レポートテンプレートで事前定義するか、設定(編集)ダイアログでユーザーが設定することができます。
-
これらは、(最初の)結果セットの生成に適用されます。例えば、ノードタイプの制限や、プロパティの制限などがあります。
-
ここで重要な点は、クエリの結果セットで返される各単一のノードを使用して、レポート上に単一の行を生成する(1 対 1 の関係)ことです。
開発者は、レポートに対して定義したクエリが、そのレポートに適したノードセットを返すようにする必要があります。 ただし、ノード自体が必要な情報をすべて保持する必要はありません。親ノードや子ノードから導き出すこともできます。例えば、ユーザーレポートで使用するクエリでは、ノードタイプ(この場合は rep:user
)に基づいてノードを選択します。ただし、このレポートのほとんどの列は、これらのノードから直接データを取り出すのではなく、子ノードの profile
からデータを取り出します。
処理キュー processing-queue
この クエリ レポートに行として表示するデータの結果セットを返します。 結果セットの各行が(サーバー側で)処理され、 いくつかの段階を返します。
次のような操作が可能です。
-
基になる結果セットから値を抽出したり導き出したりします。
例えば、2 つのプロパティ値の差を計算することで、2 つの値を 1 つの値として処理できます。
-
抽出した値を解決します。これは様々な方法で行うことができます。
例えば、パスをタイトル(対応する jcr:title プロパティにある、人間が読み取れるコンテンツ)にマッピングできます。
-
様々なポイントでフィルターを適用します。
-
必要に応じて、複合値を作成します。
例えば、ユーザーに表示するテキスト、ソートに使用する値、リンクの作成(クライアントサイドで)に使用する追加の URL で構成されます。
処理キューのワークフロー workflow-of-the-processing-queue
処理キューのワークフローを次に示します。
処理キューのフェーズ phases-of-the-processing-queue
具体的な手順と要素は次の通りです。
-
値抽出を使用して、初期クエリ(reportbase)から返された結果を、基になる結果セットに変換します。
値抽出は、列のタイプに基づいて自動的に選択されます。値抽出を使用して、基になる JCR クエリから値を読み取り、その値から結果セットを作成し、その後の処理で適用できるようにします。例えば
diff
タイプの場合、値抽出では 2 つのプロパティを読み取り、単一の値を計算して結果セットに追加します。値抽出は設定できません。 -
生データを含む最初の結果セットに対して 初期フィルタリング (raw フェーズ ) が適用されます。
-
値は 前処理済み;定義された 適用 フェーズ。
-
フィルター ( 前処理済み フェーズ ) は、前処理された値に対して実行されます。
-
値が解決される。次によると 定義済みリゾルバー.
-
フィルター ( 解決済み フェーズ ) は、解決された値に対して実行されます。
-
データはグループ化および集計済です。
-
配列データは、リスト(文字列ベース)に変換することで解決されます。
これは、複数の値を持つ結果をリストに変換して表示できるようにする暗黙の手順です。複数の値を持つ JCR プロパティに基づいたセル値(未集計)が必要です。
-
afterApply フェーズの定義に従い、値が再度前処理されます。
-
データが並べ替えられます。
-
処理されたデータはクライアントに転送されます。
reportbase
コンポーネントで定義されます。columnbase
コンポーネントで定義されます。レポートの構築と設定 report-construction-and-configuration
レポートを作成して設定するには、次の手順を実行する必要があります。
- a レポートコンポーネントの定義場所
reportbase
コンポーネント- 1 つ以上の
columnbase
コンポーネント - a ページコンポーネント
- a レポートデザイン
- a レポートテンプレート
レポートコンポーネントの場所 location-of-report-components
デフォルトのレポートコンポーネントは、/libs/cq/reporting/components
の下に保持されます。
ただし、これらのノードをアップデートしないことを強くお勧めします。独自のコンポーネントノードの作成場所は /apps/cq/reporting/components
の下か、/apps/<yourProject>/reports/components
の下がより適切です。
場所(一例として):
N:apps
N:cq [nt:folder]
N:reporting|reports [sling:Folder]
N:components [sling:Folder]
この下にレポートのルートを作成し、このルート下にレポートベースコンポーネントおよび列ベースコンポーネントを作成します。
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
ページコンポーネント page-component
レポートページには、/libs/cq/reporting/components/reportpage
の sling:resourceType
を使用する必要があります。
カスタマイズしたページコンポーネントは必要ありません(ほとんどの場合)。
レポートの基本コンポーネント report-base-component
レポートタイプごとに、/libs/cq/reporting/components/reportbase
からコンテナコンポーネントを取得する必要があります。
このコンポーネントは、レポート全体のコンテナとして使用され、以下の情報が含まれます。
- この クエリ定義.
- An (オプション)dialog レポートを設定するために使用します。
- 任意 グラフ と統合されています。
N:<reportname> [cq:Component]
P:sling:resourceSuperType = "cq/reporting/components/reportbase"
N:charting
N:dialog [cq:Dialog]
N:queryBuilder
クエリ定義 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
特定のプロパティと特定の値を持つノードのみを結果セットに含める場合に使用できます。複数の制限が指定された場合、ノードはこれらすべてを満たす(AND 演算による)必要があります。
次に例を示します。
code language-none N:propertyConstraints [ N:0 P:sling:resourceType P:foundation/components/textimage N:1 P:jcr:modifiedBy P:admin ]
admin
ユーザーによって最終的な変更が加えられた、すべてのtextimage
コンポーネント を返します。 -
nodeTypes
指定したノードタイプのみを結果セットに含める場合に使用します。複数のノードタイプを指定できます。
-
mandatoryProperties
指定したプロパティを すべて 持つノードのみを、結果セットに含める場合に使用できます。プロパティの値は考慮されません。
すべてはオプションであり、必要に応じて組み合わせることができますが、少なくともそのうちの 1 つを定義する必要があります。
チャート定義 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
アクティブなチャートについての定義を保持します。
-
active
複数の設定を定義できるので、これを使用してどれが現在アクティブなものかを定義できます。これらはノードの配列によって定義されます(これらのノードには強制的な命名規則はありませんが、標準レポートでは通常、
0
、1
…x
が使用されます)。各ノードは次のプロパティを持ちます。-
id
アクティブなチャートの ID。チャート(
definitions
)のいずれかの ID に一致する必要があります。
-
-
-
definitions
レポートでの使用が可能なチャートタイプを定義します。使用する
definitions
が、active
の設定で指定されます。この定義はノードの配列(通常は
0
、1
…x
と命名)を使用して指定され、各ノードには次のプロパティが含まれています。-
id
チャートの ID。
-
type
使用できるグラフのタイプ。次から選択します。
-
pie
円グラフ。現在のデータのみから生成されます。 -
lineseries
折れ線グラフ(実際のスナップショットを表す点をつないだもの)履歴データからのみ生成されます。
-
-
グラフのタイプに応じて、追加のプロパティを使用できます。
-
グラフタイプが
pie
の場合:-
maxRadius
(Double/Long
)円グラフで許容される最大半径。グラフで許容される最大サイズ(凡例を使用しない場合)。
fixedRadius
が指定されている場合、この値は無視されます。 -
minRadius
(Double/Long
)円グラフで許容される最小半径。
fixedRadius
が指定されている場合、この値は無視されます。 -
fixedRadius
(Double/Long
)
円グラフの半径の固定値を指定します。
-
-
グラフタイプが
lineseries
の場合:-
totals
(Boolean
)合計 を示す線を追加表示する場合は、true を指定します。
デフォルト:false
-
series
(Long
)表示する線(系列)の数。
デフォルト:9
(この値も許容される最大値です) -
hoverLimit
(Long
)集計されたスナップショット(各水平線上に表示される個別の値を示す点)の最大数。ユーザーが個別の値、またはグラフの凡例の対応するラベルにマウスオーバーしたときに、ポップアップを表示する点の数です。
デフォルト:
35
(現在のチャート設定で適用される個別の値が 35 個を超える場合は、ポップアップが表示されません)。このほかに、同時表示できるポップアップ数(凡例のテキストにマウスオーバーしたときに表示できる複数のポップアップ)を 10 個までに制限できます。
-
-
-
設定ダイアログ configuration-dialog
各レポートには設定ダイアログを設定でき、ユーザーはレポートの様々なパラメーターを指定できます。このダイアログには、レポートページを開いているときに、「編集」ボタンでアクセスできます。
このダイアログは、標準の CQ ダイアログであり、そのように設定することができます(詳しくは CQ.Dialog を参照してください)。
ダイアログの例を次に示します。
<?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>
いくつかの事前設定されたコンポーネントを使用できます。xtype
プロパティに値 cqinclude
を指定して、これらのコンポーネントをダイアログで参照できます。
-
title
/libs/cq/reporting/components/commons/title
レポートタイトルを定義するテキストフィールド。
-
description
/libs/cq/reporting/components/commons/description
レポートの説明を定義するテキスト領域。
-
processing
/libs/cq/reporting/components/commons/processing
レポート処理モード(手動/自動でのデータの読み込み)のセレクター。
-
scheduling
/libs/cq/reporting/components/commons/scheduling
履歴グラフのスナップショットをスケジュールするためのセレクター。
.infinity.json
サフィックスを使用して、参照されるコンポーネントを含める必要があります(上記の例を参照)。ルートパス root-path
さらに、レポートのルートパスを定義できます。
-
rootPath
レポートの対象を、リポジトリの特定のセクション(ツリーまたはサブツリー)に限定できます。パフォーマンスの最適化のために、限定することをお勧めします。このルートパスは、各レポートページの
report
ノードのrootPath
プロパティで指定します(ページを作成するときにテンプレートから取得されます)。次の方法で指定できます。
- レポートテンプレート(固定値または設定ダイアログのデフォルト値として)。
- ユーザー(このパラメーターを使用)
列の基本コンポーネント column-base-component
各列タイプには、/libs/cq/reporting/components/columnbase
から派生したコンポーネントが必要です。
列コンポーネントは、次の組み合わせを定義します。
- この 列固有のクエリ 設定。
- この リゾルバーと前処理.
- 列固有の定義(フィルターや集計など。
definitions
の子ノード)。 - 列のデフォルト値.
- この クライアントフィルター を使用して、サーバから返されたデータから表示する情報を抽出する。
- 以上のほか、必要なイベントとアクションを定義するために、適切な
cq:editConfig
のインスタンスを列コンポーネントで提供する必要があります。 - 汎用列の設定。
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
新規レポートの定義も参照してください。
列固有のクエリ column-specific-query
個々の列で使用するための(レポートデータ結果セットからの)特定のデータ抽出を定義します。
N:definitions
N:queryBuilder
P:property [String|String[]]
P:subPath
P:secondaryProperty [String|String[]]
P:secondarySubPath
-
property
セルの実際の値を計算するために使用するプロパティを定義します。
プロパティを文字列[] として定義すると、複数のプロパティを(順に)スキャンして実際の値を探します。
例えば、次の場合です。
property = [ "jcr:lastModified", "jcr:created" ]
対応する値の抽出(ここで制御されます)は、次のようになります。
- jcr:lastModified プロパティが利用可能かどうかを確認し、利用できる場合はそのプロパティを使用します。
- 利用可能な jcr:lastModified プロパティがない場合は、代わりに jcr:created のコンテンツを使用します。
-
subPath
クエリが返すノードに結果がない場合、
subPath
はプロパティが実際にある場所を定義します。 -
secondaryProperty
セルの実際の値の計算に必要な、2 つ目のプロパティを定義します。このプロパティは、特定の列のタイプ(diff および sortable)でのみ使用されます。
例えば、ワークフローインスタンスレポートの場合、指定されたプロパティは、開始時刻と終了時刻の時間差(ミリ秒単位)の実測値を格納するために使用されます。
-
secondarySubPath
subPath と同様、
secondaryProperty
が使用された場合。
ほとんどの場合、property
のみを使用します。
クライアントフィルター client-filter
クライアントフィルターは、サーバーが返したデータから、表示する情報を抽出します。
N:definitions
N:data
P:clientFilter [String]
clientFilter
は、JavaScript 関数として、次のように定義されます。
- 入力として、パラメーターを 1 つ受け取ります。サーバーから返されたデータ(完全に前処理済み)です。
- 出力として、フィルターを適用した(処理後の)値を返します。入力データから抽出または派生したデータです。
次の例では、コンポーネントパスから対応するページパスを抽出します。
function(v) {
var sepPos = v.lastIndexOf('/jcr:content');
if (sepPos < 0) {
return v;
}
return v.substring(sepPos + '/jcr:content'.length, v.length);
}
リゾルバーと前処理 resolvers-and-preprocessing
処理キューで様々なリゾルバーを定義し、前処理を設定します。
N:definitions
N:data
P:resolver
N:resolverConfig
N:preprocessing
N:apply
N:applyAfter
-
resolver
使用するリゾルバーを定義します。次のリゾルバーを利用できます。
-
const
値を他の値にマッピングします。例えば、
en
などの定数を、等価な値English
に解決するために使用します。 -
default
デフォルトのリゾルバー。これは、実際には何も解決しないダミーのリゾルバーです。
-
page
パスの値を、適切なページのパス(正確には、対応する
jcr:content
ノード)に解決します。例えば、/content/.../page/jcr:content/par/xyz
は/content/.../page/jcr:content
に解決されます。 -
path
オプションでサブパスを追加し、解決されたパスにあるノードのプロパティ(
resolverConfig
で定義)から実際の値を取得することによって、パス値を解決します。例えば、/content/.../page/jcr:content
のpath
はjcr:title
プロパティのコンテンツに解決でき、これはページパスがページタイトルに解決されることを意味します。 -
pathextension
パスを先頭に追加し、解決されたパスのノードのプロパティから実際の値を取得することで、値を解決します。例えば、値
de
の先頭に、プロパティlanguage
から値を取得して/libs/wcm/core/resources/languages
のようなパスを追加すると、国コードde
を言語の説明German
に解決できます。
-
-
resolverConfig
リゾルバーの定義を提供します。利用できるオプションは、選択した
resolver
によって異なります。-
const
プロパティを使用して、解決する定数を指定します。プロパティの名前で、解決する定数を定義します。プロパティの値で、解決後の値を定義します。
例えば、Name=
1
、Value=One
というプロパティの場合、1 が One に解決されます。 -
default
使用できる設定がありません。
-
page
-
propertyName
(オプション)値の解決に使用するプロパティの名前を定義します。指定しない場合、デフォルト値の jcr:title(ページタイトル)が使用されます。
page
リゾルバーの場合、最初にパスがページパスに解決され、次にページタイトルに解決されることを意味します。
-
-
path
-
propertyName
(オプション)値の解決に使用するプロパティの名前を指定します。指定しない場合、
jcr:title
のデフォルト値が使用されます。 -
subPath
(任意)このプロパティは、値を解決する前にパスに付加する接尾辞を指定するときに使用します。
-
-
pathextension
-
path
(必須)先頭に付加するパスを定義します。
-
propertyName
(必須)実際の値が配置されている、解決されたパスのプロパティを定義します。
-
i18n
(任意、ブール演算タイプ)解決された値を 国際化する(すなわち CQ5 の国際化対応サービスを使用する)かどうかを決定します。
-
-
-
preprocessing
前処理は任意で、apply または applyAfter の処理フェーズに(別々に)バインドできます。
-
apply
初期の前処理フェーズ(処理キューの説明での手順 3)に適用。
-
applyAfter
前処理(処理キューの説明での手順 9)後に適用。
-
リゾルバー resolvers
リゾルバーを使用して、必要な情報を抽出します。様々なリゾルバーの例を以下に示します。
Const
以下のコードを実行すると、VersionCreated
の定数値を、文字列 New version created
に解決します。
/libs/cq/reporting/components/auditreport/typecol/definitions/data
を参照してください。
N:data
P:resolver=const
N:resolverConfig
P:VersionCreated="New version created"
ページ
対応するページの jcr:content(子)ノードの jcr:description プロパティに、パス値を解決します。
/libs/cq/reporting/components/compreport/pagecol/definitions/data
を参照してください。
N:data
P:resolver=page
N:resolverConfig
P:propertyName="jcr:description"
パス
以下は、jcr:title
プロパティのコンテンツへの /content/.../page
パスを解決します。これは、ページパスがページタイトルに解決されることを意味します。
/libs/cq/reporting/components/auditreport/pagecol/definitions/data
を参照してください。
N:data
P:resolver=path
N:resolverConfig
P:propertyName="jcr:title"
P:subPath="/jcr:content"
パスの拡張子
以下のコードでは、値 de
の前にパスの拡張子 /libs/wcm/core/resources/languages
を付けて、プロパティ language
から値を取得し、言語の説明 German
に対して国名コード de
を解決します。
/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"
前処理 preprocessing
preprocessing
の定義は、以下のどちらかに適用できます。
-
元の値:
元の値に対する前処理の定義は、
apply
やapplyAfter
に直接指定します。 -
値の集計状態:
必要に応じて、集計ごとに個別の定義を指定できます。
集計値の明示的な前処理を指定するには、前処理定義がそれぞれの
aggregated
子ノード(apply/aggregated
、applyAfter/aggregated
)に存在している必要があります。個別の集計に対する明示的な前処理が必要な場合、前処理定義は、例えばapply/aggregated/min/max
や他の集計などの、それぞれの集計の名前を持つ子ノードに配置します。
以下のいずれかを指定して、前処理中に使用できます。
-
パターンの検索と置換
検索後、(正規表現として定義される)指定したパターンを別のパターンに置き換えます。例えば、元の値からサブ文字列を抽出するときに使用できます。 -
数値を対応する文字列に変換します。例えば、1 時間の時間差を表す値は、
1:24PM (1 hour ago)
などの文字列に解決されます。
以下に例を示します。
N:definitions
N:data
N:preprocessing
N:apply|applyAfter
P:pattern // regex
P:replace // replacement for regex
// and/or
P:format // data type formatter
前処理 — パターンの検索と置換 preprocessing-find-and-replace-patterns
前処理の場合は、正規表現 または Regex と定義される pattern
を指定しますが、これは検索後に replace
パターンによって置換されます。
-
pattern
サブ文字列の検索に使用する正規表現です。
-
replace
元の文字列の置き換えに使用する文字列、または文字列の表示です。多くの場合、
pattern
の正規表現によって検索される文字列のサブ文字列を示します。
置換の例は、以下のように分類できます。
-
definitions/data/preprocessing/apply
ノードを以下の 2 つのプロパティと共に使用します。pattern
:(.*)(/jcr:content)(/|$)(.*)
replace
:$1
-
以下の文字列が検索されます。
/content/geometrixx/en/services/jcr:content/par/text
-
以下の 4 つのセクションに分類されます。
$1
-(.*)
-/content/geometrixx/en/services
$2
-(/jcr:content)
-/jcr:content
$3
-(/|$)
-/
$4
-(.*)
-par/text
-
$1
で表される文字列に置き換えます。/content/geometrixx/en/services
前処理 — データタイプフォーマッター preprocessing-data-type-formatters
これらのフォーマッターは、数値を対応する文字列に変換します。
例えば、min
、avg
、max
の集計を許可する時間列に使用できます。min
/avg
/max
の集計は 時間差(例:10 days ago
)として表示されるので、データフォーマッターが必要です。したがって、min
/avg
/max
の集計値に対して datedelta
フォーマッターが適用されます。count
集計も利用できる場合、フォーマッターは不要です。また、元の値は含まれません。
現在使用可能なデータタイプフォーマッターは、以下のとおりです。
-
format
データタイプフォーマッター:
-
duration
指定された 2 つの日時の間のタイムスパンです。例えば、ワークフローアクションの開始から終了までの時間を 1 時間とした場合、開始を 2011 年 2 月 13 日 11 時 23 分とすると、終了は 1 時間後の 2011 年 2 月 13 日 12 時 23 分となります。
数値(ミリ秒として解釈)が期間を表す文字列に変換されます。例えば、
30000
は30s
にフォーマットされます。 -
datedelta
過去の日付から「現在」までのタイムスパンです(したがって、レポートを後の時点で表示すると、結果が異なります)。
数値(日単位の時間差として解釈)が、対応する日付の文字列に変換されます。例えば、1 という値は 1 日前としてフォーマットされます。
-
以下の例では、min
および max
の集計に対して datedelta
フォーマットが指定されています。
N:definitions
N:data
N:preprocessing
N:apply
N:aggregated
N:min
P:format = "datedelta"
N:max
P:format = "datedelta"
列固有の定義 column-specific-definitions
列固有の定義は、その列で使用できるフィルターや集計を指定するものです。
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
標準オプションとして使用できるものは以下のとおりです。
-
string
-
number
-
int
-
date
-
diff
-
timeslot
日付から、集計に必要な部分を抽出する場合(例えば年でグループ化し、年ごとに集計したデータを取得する場合)に使用します。
-
sortable
異なる値(異なるプロパティの値)を使用してソートし、表示できる値に適用します。
さらに、上記のオプションはすべて、複数値として指定できます。例えば、string[]
は文字列の配列を定義します。
値抽出は、列のタイプによって選択されます。値抽出が列のタイプに対して使用可能な場合は、この抽出が使用されます。それ以外の場合は、デフォルトの値抽出が使用されます。
タイプには、(任意で)パラメーターを指定できます。例えば、
timeslot:year
は日付フィールドから年を抽出します。タイプとそのパラメーター:-
timeslot
- 値は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
レポートをこの列でグループ化できるかどうかを指定します。
-
filters
フィルターの定義。
-
filterType
使用可能なフィルターは以下のとおりです。
-
string
文字列ベースのフィルター。
-
-
id
フィルター識別子。
-
phase
利用可能なフェーズ:
-
raw
RAW データにフィルターを適用します。
-
preprocessed
前処理されたデータにフィルターを適用します。
-
resolved
解決されたデータにフィルターを適用します。
-
-
-
aggregates
集計の定義。
-
text
集計のテキスト名。
text
の指定がない場合、集計のデフォルトの説明が使用されます。例えばmin
集計の場合、minimum
が使用されます。 -
type
集計タイプ。使用可能な集計は次のとおりです。
-
count
行数を数えます。
-
count-nonempty
空でない行の数を数えます。
-
min
最小値を示します。
-
max
最大値を示します。
-
average
平均値を示します。
-
sum
すべての値の合計を示します。
-
median
中間値を示します。
-
percentile95
すべての値の 95 パーセンタイル値を取ります。
-
-
列のデフォルト値 column-default-values
列のデフォルト値を定義するために使用します。
N:defaults
P:aggregate
-
aggregate
有効な
aggregate
の値は、aggregates
のtype
と同じです(列固有の定義(定義 - フィルター/集計)を参照)。
イベントおよびアクション events-and-actions
「設定を編集」では、リスナーが検出する必要なイベントと、それらのイベントの発生後に適用されるアクションを定義します。 背景の情報について詳しくは、コンポーネント開発の概要を参照してください。
必要なアクションがすべて実行されるようにするには、次の値を定義します。
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"
汎用列 generic-columns
汎用列は、列定義(の大部分)を(コンポーネントノードではなく)列ノードのインスタンスに格納する拡張機能です。
個々の汎用コンポーネントに対して、カスタマイズした(標準)ダイアログを使用します。このダイアログでは、レポートユーザーは、レポートページ上の汎用列の列プロパティを(メニューオプションを使用して)定義できます 列のプロパティ…) をクリックします。
ユーザーレポート の「汎用」列は、その一例です。/libs/cq/reporting/components/userreport/genericcol
を参照してください。
列を汎用にするには:
-
generic
に列のdefinition
ノードのtype
プロパティを設定します。/libs/cq/reporting/components/userreport/genericcol/definitions
を参照してください。 -
列の
definition
ノードで、(標準)ダイアログの定義を指定します。/libs/cq/reporting/components/userreport/genericcol/definitions/dialog
を参照してください。-
ダイアログのフィールドが、対応するコンポーネントプロパティと同じ名前(パスを含む)を参照する必要があります。
例えば、汎用列のタイプをダイアログで設定できるようにする場合、名前が
./definitions/type
のフィールドを使用します。 -
UI やダイアログを使用して定義するプロパティは、
columnbase
コンポーネントで定義するプロパティより優先されます。
-
-
編集設定を定義します。
/libs/cq/reporting/components/userreport/genericcol/cq:editConfig
を参照してください。 -
標準の AEM の手法を使用して、(その他の)列のプロパティを定義します。
プロパティがコンポーネントインスタンスと列インスタンスの両方で指定されている場合、列インスタンスの値が優先されます。
汎用列で使用できるプロパティは次のとおりです。
jcr:title
- 列名definitions/aggregates
- 集計definitions/filters
- フィルターdefinitions/type
- 列のタイプ(セレクターかコンボボックス、または非表示のフィールドを使用して、ダイアログで定義する必要があります)definitions/data/resolver
およびdefinitions/data/resolverConfig
(ただしdefinitions/data/preprocessing
と.../clientFilter
は除く)- リゾルバーと設定definitions/queryBuilder
- クエリビルダーの設定defaults/aggregate
- デフォルトの集計
「ユーザーレポート」の汎用列の新しいインスタンスの場合、ダイアログで定義されるプロパティは次の場所に保持されます。
/etc/reports/userreport/jcr:content/report/columns/genericcol/settings/generic
レポートデザイン report-design
レポートの作成に使用できる列のタイプはデザインで定義します。列を追加する段落システムも定義します。
各レポートに個別のデザインを作成することを強くお勧めします。これにより、完全な柔軟性が確保されます。新規レポートの定義も参照してください。
デフォルトのレポートコンポーネントは、/etc/designs/reports
の下に保持されます。
レポートの格納場所は、独自のコンポーネントを配置した場所によって次のいずれかになります。
-
レポートの場所が
/apps/cq/reporting
の場合は、/etc/designs/reports/<yourReport>
が適しています。 -
/apps/<yourProject>/reports
パターンを使用したレポートの場合は/etc/designs/<yourProject>/reports/<*yourReport*>
必要なデザインプロパティは、jcr:content/reportpage/report/columns
に登録されます(例:/etc/designs/reports/<reportName>/jcr:content/reportpage/report/columns
)。
-
components
レポートで使用できるコンポーネントやコンポーネントグループ。
-
sling:resourceType
値が
cq/reporting/components/repparsys
のプロパティ。
(コンポーネントレポートのデザインから取得した)デザインスニペットの例を次に示します。
<!-- ... -->
<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>
<!-- ... -->
個々の列に対してデザインを指定する必要はありません。使用可能な列は、デザインモードで定義できます。
レポートテンプレート report-template
各レポートタイプは、テンプレートを提供する必要があります。これらは標準的な CQ テンプレートであり、そのように設定できます。
テンプレートは次の条件を満たす必要があります。
-
cq/reporting/components/reportpage
にsling:resourceType
を設定 -
使用するデザインを示す
-
sling:resourceType
プロパティでコンテナ(reportbase
)コンポーネントを参照するreport
子ノードを作成
(コンポーネントレポートテンプレートから取得される)テンプレートスニペットの例を次に示します。
<!-- ... -->
<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>
<!-- .. -->
(ユーザーレポートテンプレートから取得した)ルートパスの定義を示すテンプレートスニペットの例を次に示します。
<!-- ... -->
<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>
<!-- .. -->
デフォルトのレポートテンプレートは、/libs/cq/reporting/templates
の下に保持されます。
ただし、これらのノードは更新しないことを強くお勧めします。独自のコンポーネントノードは、/apps/cq/reporting/templates
の下か、より適切であれば /apps/<yourProject>/reports/templates
の下に作成してください。
定義例は次のとおりです(レポートコンポーネントの場所も参照)。
N:apps
N:cq [nt:folder]
N:reporting|reports [sling:Folder]
N:templates [sling:Folder]
この場所に、テンプレートのルートを作成します。
N:apps
N:cq [nt:folder]
N:reporting|reports [sling:Folder]
N:templates [sling:Folder]
N:<reportname> [sling:Folder]
独自レポートの作成 — 例 creating-your-own-report-an-example
新しいレポートの定義 defining-your-new-report
新しいレポートを定義するには、次を作成して設定する必要があります。
- レポートコンポーネントのルート。
- レポートのベースコンポーネント。
- 1 つ以上の列ベースコンポーネント。
- レポートデザイン。
- レポートテンプレートのルート。
- レポートテンプレート。
これらの手順を説明するために、次の例では、リポジトリ内のすべての OSGi 設定、すなわち sling:OsgiConfig
ノードのすべてのインスタンスを一覧表示するレポートを定義します。
-
新しいレポートのルートノードを作成します。
例えば、
/apps/cq/reporting/components/osgireport
の下です。code language-xml N:cq [nt:folder] N:reporting [sling:Folder] N:components [sling:Folder] N:osgireport [sling:Folder]
-
レポートベースを定義します。例えば、
/apps/cq/reporting/components/osgireport
の下のosgireport[cq:Component]
です。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"
これは、次のようなレポートベースコンポーネントを定義します。
- タイプが
sling:OsgiConfig
のすべてのノードを検索 pie
とlineseries
の両方のグラフを表示- ユーザーがレポートを設定するためのダイアログを提供します
- タイプが
-
最初の列 (columnbase) コンポーネントを定義します。 例えば、
/apps/cq/reporting/components/osgireport
下のbundlecol[cq:Component]
です。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"
これは、次のような列ベースコンポーネントを定義します。
- サーバーから受信する値(この場合、
sling:OsgiConfig
の各ノードのjcr:path
プロパティ)を検索し、その値を返す count
集計を提供- グループ化はできない
- タイトル(テーブル内の列タイトル)は
Bundle
- サイドキックグループ
OSGi Report
に含まれる - 指定されたイベントで更新
note note NOTE この例では、 N:data
およびP:clientFilter
の定義はありません。これは、サーバーから受け取った値が 1 対 1 で返されるためで、これがデフォルトの動作です。これは、定義と同じです。 code language-none N:data [nt:unstructured] P:clientFilter [String] = "function(v) { return v; }"
関数が受け取った値を返すだけの場合。 - サーバーから受信する値(この場合、
-
レポートデザインを定義します。例えば、
/etc/designs/reports
下のosgireport[cq:Page]
です。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"
-
新しいレポートテンプレートのルートノードを作成します。
例えば、
/apps/cq/reporting/templates/osgireport
の下です。code language-xml N:cq [nt:folder] N:reporting [sling:Folder] N:templates [sling:Folder] N:osgireport [cq:Template]
-
レポートテンプレートを定義します。例えば、
/apps/cq/reporting/templates
下のosgireport[cq:Template]
。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]
これは、次のようなテンプレートを定義します。
- 結果のレポートの
allowedPaths
を定義します。上記の場合、/etc/reports
下の任意の場所となります。 - テンプレートのタイトルと説明を提供します
- テンプレートリストで使用するサムネール画像を提供します(このノードの完全な定義は上記ではありません。既存のレポートから thumbnail.png のインスタンスをコピーするのが最も簡単です)。
- 結果のレポートの
新しいレポートのインスタンスの作成 creating-an-instance-of-your-new-report
これで、新しいレポートのインスタンスを作成できます。
-
ツール コンソールを開きます。
-
選択 レポート をクリックします。
-
次に、ツールバーから「新規…」を選択します。「タイトル」 および 「名前」を定義して、テンプレートのリストから新しいレポートタイプ(OSGi レポートテンプレート)を選択し、「作成」をクリックします。
-
新しいレポートインスタンスがリストに表示されます。ダブルクリックして開きます。
-
サイドキックからコンポーネント(この例では、「OSGi レポート」グループの「バンドル」)をドラッグして最初の列を作成し、レポートの定義を開始します。
note note NOTE この例では、グループ化可能な列がないので、グラフは使用できません。グラフを表示するには、 groupable
をtrue
に設定します。code language-none N:osgireport [sling:Folder] N:bundlecol [cq:Component] N:definitions [nt:unstructured] P:groupable [Boolean] = true
レポートフレームワークサービスの設定 configuring-the-report-framework-services
この節では、レポートフレームワークを実装する OSGi サービスの高度な設定オプションについて説明します。
これらの設定オプションは、web コンソール(http://localhost:4502/system/console/configMgr
などで入手可能)の設定メニューを使用して表示できます。AEM を操作しているときは、このようなサービスの設定を管理する方法がいくつかあります。詳細および推奨事項については、OSGi の設定を参照してください。
基本サービス(Day CQ レポート設定) basic-service-day-cq-reporting-configuration
-
タイムゾーン は、履歴データが作成されるタイムゾーンを定義します。これは、履歴グラフで世界中の各ユーザーに対して、確実に同じデータを表示するためです。
-
ロケール は、履歴データの タイムゾーン と組み合わせて使用するロケールを定義します。ロケールは、ロケール固有のカレンダー設定(週の最初の曜日が日曜日か月曜日かなど)を決定するために使用されます。
-
スナップショットパス は、履歴グラフのスナップショットを保存するルートパスを定義します。
-
レポートへのパス は、レポートのあるパスを定義します。これは、スナップショットサービスで、実際にスナップショットを作成するレポートを決定するために使用されます。
-
日別スナップショット は、日別のスナップショットを取得する時間を定義します。指定された時間は、サーバーのローカルタイムゾーンになります。
-
時間別スナップショット は、時間別のスナップショットを取得する各時刻の分を定義します。
-
行(最大) は、各スナップショットに対して保存される最大行数を定義します。この値は合理的に選択する必要があります。値が大きすぎる場合は、リポジトリのサイズに影響します。値が小さすぎる場合は、履歴データの処理方法が原因で、データが正確でない可能性があります。
-
フェイクデータ を有効にした場合、
fakedata
セレクターを使用することでフェイク履歴データを作成できます。無効にした場合、fakedata
セレクターを使用することで例外がスローされます。フェイクデータは、テストおよびデバッグの用途で のみ 使用してください。
fakedata
セレクターを使用すると、レポートが暗黙的に終了するので、既存のデータがすべて失われます。データは手動で復元できますが、この処理には時間がかかる場合があります。 -
スナップショットユーザー で、スナップショットの取得に使用できるオプションのユーザーを定義します。
基本的には、レポートを終了したユーザーに対してスナップショットが取得されます。例えばパブリッシュシステムで、ユーザーアカウントが複製されていないのでこのユーザーが存在しない場合など、このユーザーの代わりに使用するフォールバックユーザーの指定が必要な場合があります。
ただし、ユーザーを指定するとセキュリティリスクが高まる可能性もあります。
-
スナップショットユーザーを適用 を有効にすると、すべてのスナップショットが、スナップショットユーザー で指定したユーザーを使用して取得されます。この機能は適切に使用しないと、セキュリティに重大な影響を与える可能性があります。
キャッシュ設定 (Day CQ Reporting Cache) cache-settings-day-cq-reporting-cache
- 有効にする を使用すると、レポートデータのキャッシュを有効または無効にできます。レポートのキャッシュを有効にすると、複数のリクエストを実行する際にレポートデータがメモリに保持されます。 これによりパフォーマンスが向上する可能性がありますが、メモリ消費量が増加し、極端な状況ではメモリ不足に陥る場合があります。
- TTL は、レポートデータがキャッシュされる時間(秒単位)を定義します。数値を大きくするとパフォーマンスが向上しますが、期間内にデータが変更された場合は不正確なデータが返される場合もあります。
- 最大エントリ数 は、一度にキャッシュできるレポートの最大数を定義します。
2
の 最大エントリ数 の値が、実際には次のいずれかのデータをキャッシュすることを意味します。- 言語設定が異なる 2 人のユーザー向けの 1 つのレポート
- 1 人のユーザーと 2 つのレポート