AEM でのプロジェクトの開発

まず、/apps/<your-app-folder> の直下に新しいフォルダーを作成して、名前を projects とします。 その直下に別のフォルダーを作成して、名前を templates とします。

/apps/aem-guides/projects-tasks/
                    + projects (nt:folder)
                             + templates (nt:folder)

作業を容易にするために、既存のシンプルなプロジェクトテンプレートからカスタムテンプレートの作成を開始します。

1. ノード /libs/cq/core/content/projects/templates/default をコピーして、手順 1 で作成した templates フォルダーの下にペーストします。

/apps/aem-guides/projects-tasks/
             + templates (nt:folder)
                  + default (cq:Template)

これで、パスは /apps/aem-guides/projects-tasks/projects/templates/authoring-project のようになります。

1. author-project ノードの jcr:title および jcr:description プロパティを編集して、カスタムタイトルと説明の値に変更します。

   1. wizard プロパティは、デフォルトのプロジェクトプロパティを指したままにしておきます。

/apps/aem-guides/projects-tasks/projects/
         + templates (nt:folder)
              + authoring-project (cq:Template)
                   - jcr:title = "Authoring Project"
                   - jcr:description = "A project to manage approval and publish process for AEM Sites or Assets"
                   - wizard = "/libs/cq/core/content/projects/wizard/steps/defaultproject.html"

このプロジェクトテンプレートでは、タスクを利用します。

1. 新しい nt:unstructured ノードを authoring-project/gadgets の直下に追加して、名前を tasks にします。
2. String プロパティを tasks ノードに追加して、cardWeight="100"、jcr:title="Tasks"、sling:resourceType="cq/gui/components/projects/admin/pod/taskpod" とします。

これで、新しいプロジェクトが作成される際に Tasks タイルがデフォルトで表示されます。

../projects/templates/authoring-project
    + gadgets (nt:unstructured)
         + team (nt:unstructured)
         + asset (nt:unstructured)
         + work (nt:unstructured)
         + experiences (nt:unstructured)
         + projectinfo (nt:unstructured)
         ..
         + tasks (nt:unstructured)
              - cardWeight = "100"
              - jcr:title = "Tasks"
              - sling:resourceType = "cq/gui/components/projects/admin/pod/taskpod"

プロジェクトテンプレートにカスタムの「承認者」役割を追加します。

1. プロジェクトテンプレート（authoring-project）ノードの直下に新しい nt:unstructured ノードを追加して、roles というラベルを付けます。

2. 別の nt:unstructured ノードを、approvers というラベルを付けて、roles ノードの子として追加します。

3. String プロパティ jcr:title="Approvers"、roleclass="owner"、roleid="approvers" を追加します。

   1. approvers ノードの名前、および jcr:title と roleid には、（roleid が一意である限り）任意の文字列値を指定できます。
   2. roleclass は、owner、editor、observer の 3 つの OOTB の役割に基づいて、その役割に適用される権限を管理します。
   3. 一般に、カスタムの役割が管理の役割の色彩が強い場合、roleclass は owner にできます。フォトグラファーやデザイナーなど、オーサリング上のより具体的な役割の場合は、editor の roleclass で十分です。 owner と editor の大きな違いは、プロジェクトの所有者はプロジェクトのプロパティを更新したり、新しいユーザーをプロジェクトに追加したりできる点です。

../projects/templates/authoring-project
    + gadgets (nt:unstructured)
    + roles (nt:unstructured)
        + approvers (nt:unstructured)
             - jcr:title = "Approvers"
             - roleclass = "owner"
             - roleid = "approver"

「シンプルなプロジェクト」テンプレートをコピーすると、4 つの OOTB ワークフローが設定されます。 workflows/models の直下の各ノードは、特定のワークフローと、そのワークフローの開始ダイアログウィザードを指しています。 このチュートリアルの後半では、このプロジェクトのカスタムワークフローを作成します。 ここでは、workflow/models の下のノードを削除します。

../projects/templates/authoring-project
    + gadgets (nt:unstructured)
    + roles (nt:unstructured)
    + workflows (nt:unstructured)
         + models (nt:unstructured)
            - (remove ootb models)

コンテンツ作成者がプロジェクトテンプレートを容易に識別できるように、カスタムサムネールを追加できます。 推奨サイズは 319 x 319 ピクセルです。

1. CRXDE Lite で、ガジェット、役割、ワークフローのノードの兄弟として、thumbnail.png という名前の新しいファイルを作成します。
2. 保存して、jcr:content ノードに移動し、jcr:data プロパティをダブルクリックします（「表示」をクリックしないでください）。
   1. これにより、jcr:data ファイルを編集するダイアログが表示され、カスタムサムネールをアップロードできます。

../projects/templates/authoring-project
    + gadgets (nt:unstructured)
    + roles (nt:unstructured)
    + workflows (nt:unstructured)
    + thumbnail.png (nt:file)

カスタムテンプレートが、プロジェクト作成用のオプションの 1 つとして表示されます。

カスタムテンプレートを選択したら、「次へ」をクリックし、プロジェクトメンバーに入力する際に、承認者の役割として追加できることに注意してください。

「作成」をクリックして、カスタムテンプレートに基づくプロジェクトの作成を終了します。 プロジェクトダッシュボードに、タスクタイルと、ガジェットの下に設定された他のタイルが自動的に表示されます。

AEM スタートメニューでツール／ワークフロー／モデルに移動します。 右上隅の「作成」をクリックして、ワークフローモデルを作成します。

新しいモデルに「コンテンツ承認ワークフロー」というタイトルを付け、URL 名に「content-approval-workflow」と入力します。

ワークフローの作成に関する詳細については、こちらをお読みください。

ベストプラクティスとして、カスタムワークフローは、/etc/workflow/models の下の専用フォルダーにグループ化する必要があります。 CRXDE Lite で、/etc/workflow/models の下に、「aem-guides」 ​という名前で、「nt:folder」 ​を作成します。 サブフォルダーを追加すると、アップグレードまたはサービスパックのインストール中に、カスタムワークフローが誤って上書きされることがなくなります。

*サブフォルダー全体がアップグレードやサービスパックによって上書きされる可能性もあるため、/etc/workflow/models/dam や /etc/workflow/models/projects などの ootb サブフォルダーの下にフォルダーやカスタムワークフローを配置しないことが重要です。

6.3 でのワークフローモデルの場所

AEM 6.4 以降を使用している場合、ワークフローモデルは /conf/global/settings/workflow/models の下に作成されます。 /conf ディレクトリで上記の手順を繰り返し、aem-guides という名前のサブフォルダーを追加し、その下に content-approval-workflow を移動します。

6.4 以降のワークフローモデルの場所

AEM 6.3 で導入されたのは、特定のワークフローにワークフローステージを追加する機能です。 ステージは、「ワークフロー情報」タブのインボックスからユーザーに表示されます。 ワークフローの現在のステージと、その前後のステージがユーザーに表示されます。

ステージを設定するには、サイドキックからページのプロパティダイアログを開きます。 4 番目のタブには、「ステージ」というラベルが付いています。 このワークフローの 3 つのステージを設定するには、以下の値を追加します。

1. コンテンツの編集
2. 承認
3. パブリッシュ

ページのプロパティダイアログで、ワークフローステージを設定します。

AEM インボックスから見たワークフローの進行状況バー。

オプションで、画像 ​をページのプロパティにアップロードできます。これは、ユーザーが選択した際にワークフローサムネールとして使用されます。 画像のサイズは、319 x 319 ピクセルにする必要があります。 ページのプロパティに​ 説明 ​を追加すると、ユーザーがワークフローを選択する際にも表示されます。

プロジェクトタスクを作成ワークフロープロセスは、ワークフローのステップとしてタスクを作成するように設計されています。 タスクを完了した後にのみ、ワークフローが前に進みます。 プロジェクトタスクを作成ステップの強力な側面は、ワークフローのメタデータ値を読み取り、それらを使用して動的にタスクを作成できる点です。

最初に、デフォルトで作成される参加者ステップを削除します。 コンポーネントメニューのサイドキックから​ 「プロジェクト」 ​サブ見出しを展開し、「プロジェクトタスクを作成」 ​をモデルにドラッグ＆ドロップします。

「プロジェクトタスクを作成」ステップをダブルクリックして、ワークフローダイアログを開きます。 以下のプロパティを設定します。

このタブは、すべてのワークフロープロセスステップで共通で、「タイトル」と「説明」を設定します（これらはエンドユーザーには表示されません）。 設定する重要なプロパティは、ワークフローステージをドロップダウンメニューから​ 「コンテンツを編集」 ​に設定することです。

Common Tab
-----------------
    Title = "Start Task Creation"
    Description = "This the first task in the Workflow"
    Workflow Stage = "Edit Content"

プロジェクトタスクを作成ワークフロープロセスは、ワークフローのステップとしてタスクを作成するように設計されています。 「タスク」タブでは、タスクのすべての値を設定できます。 担当者を動的にする場合は、空白のままにします。 残りのプロパティ値は次のとおりです。

Task Tab
-----------------
    Name* = "Edit Content"
    Task Priority = "Medium"
    Description = "Edit the content and finalize for approval. Once finished submit for approval."
    Due In - Days = "2"

「ルーティング」タブは、ユーザーがタスクを完了するために使用できるアクションを指定できるオプションのダイアログです。 これらのアクションは単なる文字列値であり、ワークフローのメタデータに保存されます。 これらの値は、ワークフローの後半でスクリプトやプロセスステップで読み取り、ワークフローを動的に「ルーティング」することができます。 ワークフローの目標に基づいて、このタブに 3 つのアクションを追加します。

Routing Tab
-----------------
    Actions =
        "Normal Approval"
        "Rush Approval"
        "Bypass Approval"

このタブでは、タスクの作成前にタスクの様々な値をプログラムで決定できるタスクを事前作成スクリプトを設定できます。 スクリプトを外部ファイルに指定するか、短いスクリプトをダイアログに直接埋め込むオプションがあります。 この例では、タスクを事前作成スクリプトを外部ファイルに指定します。 手順 5 で、そのスクリプトを作成します。

Advanced Settings Tab
-----------------
   Pre-Create Task Script = "/apps/aem-guides/projects/scripts/start-task-config.ecma"

前の手順では、タスクを事前作成スクリプトを参照しました。 ここで、ワークフローメタデータ値「assignee」の値に基づいてタスクの担当者を設定するスクリプトを作成します。 「assignee」 ​の値は、ワークフローがキックオフされたときに設定します。 また、ワークフローのメタデータの​ 「taskPriority」 値と "taskDueDate" ​ を読み取って、最初のタスクの有効期限が切れたときに動的に設定することで、タスクの優先度を動的に選択するワークフローメタデータを読み取ります。

組織のために、アプリフォルダーの下にフォルダーを作成して、すべてのプロジェクト関連スクリプト /apps/aem-guides/projects-tasks/projects/scripts を保持します。 このフォルダーの下に、「start-task-config.ecma」 ​という名前の新しいファイルを作成します。 *start-task-config.ecma ファイルへのパスが、手順 4 の「詳細設定」タブで設定したパスと一致するようにします。

ファイルのコンテンツとして以下を追加します。

// start-task-config.ecma
// Populate the task using values stored as workflow metadata originally posted by the start workflow wizard

// set the assignee based on start workflow wizard
var assignee = workflowData.getMetaDataMap().get("assignee", Packages.java.lang.String);
task.setCurrentAssignee(assignee);

//Set the due date for the initial task based on start workflow wizard
var dueDate = workflowData.getMetaDataMap().get("taskDueDate", Packages.java.util.Date);
if (dueDate != null) {
    task.setProperty("taskDueDate", dueDate);
}

//Set the priority based on start workflow wizard
var taskPriority = workflowData.getMetaDataMap().get("taskPriority", "Medium");
task.setProperty("taskPriority", taskPriority);

コンテンツ承認ワークフローに戻ります。 OR 分岐 ​コンポーネント （「ワークフロー」カテゴリの下のサイドキックにあります）を​ タスクを開始 ​ステップの下にドラッグ＆ドロップします。 共通ダイアログで、3 つのブランチのラジオボタンを選択します。 OR 分岐は、ワークフローメタデータ値​ 「lastTaskAction」 ​を読み取り、ワークフローのルートを決定します。 「lastTaskAction」 プロパティは、手順 4 で設定した「ルーティング」タブの値の 1 つに設定されます。 「分岐」タブのそれぞれで、「スクリプト」テキスト領域に次の値を記入します。

function check() {
var lastAction = workflowData.getMetaDataMap().get("lastTaskAction","");

if(lastAction == "Normal Approval") {
    return true;
}

return false;
}

function check() {
var lastAction = workflowData.getMetaDataMap().get("lastTaskAction","");

if(lastAction == "Rush Approval") {
    return true;
}

return false;
}

function check() {
var lastAction = workflowData.getMetaDataMap().get("lastTaskAction","");

if(lastAction == "Bypass Approval") {
    return true;
}

return false;
}

*ルートを決定するために文字列の直接照合を行っているので、分岐のスクリプトに設定された値が、手順 4 で設定されたルートの値と一致することが重要であることに注意してください。

別の「プロジェクトタスクを作成」ステップをドラッグして、OR 分岐の下の左端のモデル（分岐 1）にドロップします。 ダイアログに次のプロパティを入力します。

Common Tab
-----------------
    Title = "Approval Task Creation"
    Description = "Create a an approval task for Project Approvers. Priority is Medium."
    Workflow Stage = "Approval"

Task Tab
------------
    Name* = "Approve Content for Publish"
    Task Priority = "Medium"
    Description = "Approve this content for publication."
    Days = "5"

Routing Tab - Actions
----------------------------
    "Approve and Publish"
    "Send Back for Revision"

これは「通常の承認」ルートなので、タスクの優先度は「中」に設定しています。 さらに、承認者グループにタスクを完了するための期間を 5 日間とします。 「詳細設定」タブで動的に割り当てるので、「タスク」タブの担当者は空白のままにします。 このタスクを完了する際に、承認者グループに 2 つのルートを提供します。「承認して公開」は、コンテンツを承認し、公開できる場合で、「修正用に送り返す」は、元の編集者による修正が必要な問題がある場合です。 承認者は、元の編集者に対して、ワークフローが元の編集者に返されたかどうかを確認するコメントを残すことができます。

別の「プロジェクトタスクを作成」ステップをドラッグして、OR 分岐の下の中央のモデル（分岐 2）にドロップします。 ダイアログに次のプロパティを入力します。

Common Tab
-----------------
    Title = "Rush Approval Task Creation"
    Description = "Create a an approval task for Project Approvers. Priority is High."
    Workflow Stage = "Approval"

Task Tab
------------
    Name* = "Rush Approve Content for Publish"
    Task Priority = "High"
    Description = "Rush approve this content for publication."
    Days = "1"

Routing Tab - Actions
----------------------------
    "Approve and Publish"
    "Send Back for Revision"

これは「ラッシュ承認」ルートなので、タスクの優先度は「高」に設定しています。 さらに、承認者グループにタスクを完了するための期間として 1 日のみを与えます。 「詳細設定」タブで動的に割り当てるので、「タスク」タブの担当者は空白のままにします。

手順 7 と同じスクリプトスニペットを再利用し、「詳細設定」タブの「スクリプト」テキスト領域 に入力します。 次のコードをコピーしてペーストします。

var projectApproverGrp = workflowData.getMetaDataMap().get("project.group.approvers","administrators");

task.setCurrentAssignee(projectApproverGrp);

「操作なし」コンポーネントをドラッグして、右端の分岐（分岐 3）にドロップします。 「操作なし」コンポーネントは何のアクションも実行せず、直ちに次に進みます。承認ステップを省略したいという元の編集者の要求を表しています。 技術的には、この分岐をワークフローステップなしにしておくことが可能ですが、ベストプラクティスとして、「操作なし」のステップを追加します。 これにより、他の開発者に対して、分岐 3 の目的が明確になります。

ワークフローステップをダブルクリックし、「タイトル」と「説明」を設定します。

Common Tab
-----------------
    Title = "Bypass Approval"
    Description = "Placeholder step to indicate that the original editor decided to bypass the approver group."

OR 分岐の 3 つの分岐すべてが設定されたら、ワークフローモデルは次のようになります。

承認者グループには、ワークフローを元の編集者に送り返して追加の修正を求めるオプションがあるので、最後に実行されたアクションを読み取り、ワークフローを最初にルーティングするのか、それとも続行させるのかは、「移動」ステップに依存します。

「移動ステップ」コンポーネント（「ワークフロー」の下の「サイドキック」内）をドラッグし、OR 分岐の下の再結合する場所にドロップします。 ダブルクリックして、ダイアログで次のプロパティを設定します。

Common Tab
----------------
    Title = "Goto Step"
    Description = "Based on the Approver groups action route the workflow to the beginning or continue and publish the payload."

Process Tab
---------------
    The step to go to. = "Start Task Creation"

最後に設定するのは、「移動」プロセスステップの一部となるスクリプトです。 スクリプトの値は、ダイアログを使用して埋め込むことも、外部ファイルを指すように設定することもできます。 移動スクリプトには​ 関数 check() を含め、ワークフローが指定された手順に進む必要がある場合に true を返すようにする必要があります。 false が返されると、ワークフローが次に進みます。

承認者グループが「修正用に送り返す」アクション（手順 7 と 8 で設定）を選択した場合、ワークフローを「タスク作成を開始 」ステップに戻します。

「プロセス」タブで、次のスニペットを「スクリプト」テキスト領域に追加します。

function check() {
var lastAction = workflowData.getMetaDataMap().get("lastTaskAction","");

if(lastAction == "Send Back for Revision") {
    return true;
}

return false;
}

ペイロードを公開するには、OOTB の「ページ/アセットをアクティベート」プロセスステップを使用します。 このプロセスステップではほとんど設定が必要なく、アクティベーション用にワークフローのペイロードをレプリケーションキューに追加します。 「移動」ステップの下にステップを追加します。この方法では、承認者グループが公開用にコンテンツを承認した場合、または元の編集者が承認の省略ルートを選択した場合にのみ、このステップに到達できます。

「ページ/アセットをアクティベート」プロセスステップ（「WCM ワークフロー」の下の「サイドキック」内）をドラッグし、モデル内の「移動」ステップの下にドロップします。

「移動」ステップおよび「ページ/アセットをアクティベート」ステップを追加した後のワークフローモデルの表示内容。

承認者グループが修正用にコンテンツを送り返した場合、元の編集者に通知します。 これを実現するには、タスク作成プロパティを動的に変更します。 「修正用に送り返す」の lastActionTaken プロパティ値のキーを設定します。 その値が存在する場合は、タイトルと説明を変更して、このタスクはコンテンツが修正用に送り返された結果であることを示します。 また、優先度を「高」に更新して、編集者が最初に作業する項目になるようにします。 最後に、タスクの期限を、ワークフローが修正用に送り返された日から 1 日に設定します。

開始 start-task-config.ecma スクリプト（手順 5 で作成）を次のように置き換えます。

// start-task-config.ecma
// Populate the task using values stored as workflow metadata originally posted by the start workflow wizard

// set the assignee based on start workflow wizard
var assignee = workflowData.getMetaDataMap().get("assignee", Packages.java.lang.String);
task.setCurrentAssignee(assignee);

//Set the due date for the initial task based on start workflow wizard
var dueDate = workflowData.getMetaDataMap().get("taskDueDate", Packages.java.util.Date);
if (dueDate != null) {
    task.setProperty("taskDueDate", dueDate);
}

//Set the priority based on start workflow wizard
var taskPriority = workflowData.getMetaDataMap().get("taskPriority", "Medium");
task.setProperty("taskPriority", taskPriority);

var lastAction = workflowData.getMetaDataMap().get("lastTaskAction","");

//change the title and priority if the approver group sent back the content
if(lastAction == "Send Back for Revision") {
  var taskName = "Review and Revise Content";

  //since the content was rejected we will set the priority to High for the revison task
  task.setProperty("taskPriority", "High");

  //set the Task name (displayed as the task title in the Inbox)
  task.setProperty("name", taskName);
  task.setProperty("nameHierarchy", taskName);

  //set the due date of this task 1 day from current date
  var calDueDate = Packages.java.util.Calendar.getInstance();
  calDueDate.add(Packages.java.util.Calendar.DATE, 1);
  task.setProperty("taskDueDate", calDueDate.getTime());

}

CRXDE-Lite では、/apps/aem-guides/projects-tasks/projects フォルダーの下に「wizards」というサブフォルダーを作成します。 新しく作成されたウィザードフォルダーの下の /libs/cq/core/content/projects/workflowwizards/default_workflow からデフォルトのウィザードをコピーし、名前を「content-approval-start」に変更します。 フルパスは、/apps/aem-guides/projects-tasks/projects/wizards/content-approval-start になります。

デフォルトのウィザードは 2 列のウィザードで、最初の列には選択したワークフローモデルのタイトル、説明およびサムネールが表示されます。 2 番目の列には、ワークフロータイトル、コメントを開始およびペイロードパスのフィールドが含まれます。 ウィザードは、標準のタッチ UI フォームであり、標準の Granite UI フォームコンポーネントを使用してフィールドに値を入力します。

ワークフローの最初のタスクの担当者を設定するために使用するウィザードにフィールドを追加します（ワークフローモデルの作成：ステップ 5 を参照）。

../content-approval-start/jcr:content/items/column2/items の下に、「assign」 ​という名前の nt:unstructured タイプの新しいノードを作成します。 プロジェクトのユーザーピッカーコンポーネント（Granite ユーザーピッカーコンポーネントに基づいています）を使用します。 このフォームフィールドを使用すると、ユーザーとグループの選択を現在のプロジェクトに属するものだけに簡単に制限できます。

assign ノードの XML 表現を以下に示します。

<assign
    granite:class="js-cq-project-user-picker"
    jcr:primaryType="nt:unstructured"
    sling:resourceType="cq/gui/components/projects/admin/userpicker"
    fieldLabel="Assign To"
    hideServiceUsers="{Boolean}true"
    impersonatesOnly="{Boolean}true"
    showOnlyProjectMembers="{Boolean}true"
    name="assignee"
    projectPath="${param.project}"
    required="{Boolean}true"/>

ワークフローの最初のタスクの優先度を決定する優先度選択フィールドも追加します（ワークフローモデルの作成：ステップ 5 を参照）。

/content-approval-start/jcr:content/items/column2/items の下に、priority という名前の nt:unstructured タイプの新しいノードを作成します。 Granite UI 選択コンポーネントを使用して、フォームフィールドに値を入力します。

priority ノードの下に、nt:unstructured の items ノードを追加します。 items ノードの下にさらに 3 つのノードを追加して、高、中、低の選択オプションを入力します。 各ノードのタイプは nt:unstructured で、text と value のプロパティが必要です。 text と value の両方が同じ値である必要があります。

1. 高
2. 中
3. 低

「中」ノードの場合、「選択済み」 ​という名前のブーリアンプロパティを追加し、値を true に設定します。 これにより、「中」が選択フィールドのデフォルト値になります。

ノード構造とプロパティの XML 表現を以下に示します。

<priority
    jcr:primaryType="nt:unstructured"
    sling:resourceType="granite/ui/components/coral/foundation/form/select"
    fieldLabel="Task Priority"
    name="taskPriority">
        <items jcr:primaryType="nt:unstructured">
            <high
                jcr:primaryType="nt:unstructured"
                text="High"
                value="High"/>
            <medium
                jcr:primaryType="nt:unstructured"
                selected="{Boolean}true"
                text="Medium"
                value="Medium"/>
            <low
                jcr:primaryType="nt:unstructured"
                text="Low"
                value="Low"/>
            </items>
</priority>

ワークフローの開始者が最初のタスクの期日を設定できるようにします。 Granite UI DatePicker フォームフィールドを使用して、この入力をキャプチャします。 また、TypeHint を含む非表示フィールドを追加して、入力が Date タイプのプロパティとして JCR に格納されるようにします。

以下の XML で表される次のプロパティを持つ 2 つの nt:unstructured ノードを追加します。

<duedate
    granite:rel="project-duedate"
    jcr:primaryType="nt:unstructured"
    sling:resourceType="granite/ui/components/coral/foundation/form/datepicker"
    displayedFormat="YYYY-MM-DD HH:mm"
    fieldLabel="Due Date"
    minDate="today"
    name="taskDueDate"
    type="datetime"/>
<duedatetypehint
    jcr:primaryType="nt:unstructured"
    sling:resourceType="granite/ui/components/coral/foundation/form/hidden"
    name="taskDueDate@TypeHint"
    type="datetime"
    value="Calendar"/>

ウィザードを開始ダイアログの完全なコードは、こちらで確認できます。

CRXDE-Lite で、以前に /apps/aem-guides/projects-tasks/projects/templates/authoring-project/workflows/models で作成したプロジェクトの作成テンプレートに移動します。

models ノードの下に、ノード タイプが nt:unstructured の contentapproval という名前の新しいノードを追加します。 ノードに次のプロパティを追加します。

<contentapproval
    jcr:primaryType="nt:unstructured"
    modelId="/etc/workflow/models/aem-guides/content-approval-workflow/jcr:content/model"
    wizard="/apps/aem-guides/projects-tasks/projects/wizards/content-approval-start.html"
/>

<contentapproval
    jcr:primaryType="nt:unstructured"
    modelId="/var/workflow/models/aem-guides/content-approval-workflow"
    wizard="/apps/aem-guides/projects-tasks/projects/wizards/content-approval-start.html"
/>

コンテンツ承認ワークフローをプロジェクトテンプレートに追加したら、プロジェクトのワークフロータイルから開始できるようになります。 先に進んで、作成した様々なルーティングを起動して試してください。