ワークフローモデルは、各種タイプの一連のステップで構成されます。これらのステップを、それぞれのタイプに応じてパラメーターやスクリプトで設定および拡張し、必要な機能とコントロールを実現することができます。
- タイトル
ステップのタイトル。 - 説明
ステップの説明。 - タイムアウト
ステップが「タイムアウト」するまでの期間です。
「オフ」、「即」、「1 時間」、「6 時間」、「12 時間」、「24 時間」から選択できます。 - タイムアウトハンドラー
ステップがタイムアウトしたときにワークフローを制御するハンドラーです。例:
com.day.cq.workflow.timeout.autoadvance.AutoAdvancer - ハンドラー処理の設定
実行後にワークフローを次のステップに自動的に進めるには、このオプションを選択します。選択しない場合、実装スクリプトでワークフローの進行を処理する必要があります。
多くのワークフローステップコンポーネントでは、プロパティダイアログの「ユーザー/グループ」タブで、次のプロパティを使用できます。
- ユーザー / グループ
- ドロップダウン選択ボックスを使用して、ユーザーやグループ間を移動し、選択することができます
- 特定のユーザーにステップを割り当てた場合は、そのユーザーだけがステップのアクションを実行できます。
- グループ全体にステップを割り当てた場合、ワークフローがこのステップに到達すると、グループのユーザーすべての「ワークフローの受信ボックス」にアクションが保持されます。
- 詳しくは、ワークフローへの参加を参照してください。
- ドロップダウン選択ボックスを使用して、ユーザーやグループ間を移動し、選択することができます
- 電子メール
- ワークフローがステップに到達したときに、参加者に電子メールを送信して通知できます。
- 「オン」に設定すると、「ユーザー / グループ」プロパティによって定義されたユーザー、またはグループが定義されている場合はグループの各メンバーに、電子メールが送信されます。
AND 分割は、ワークフロー内に分割を作成し、両方のブランチをアクティブにします。必要に応じて、各ブランチにワークフローステップを追加できます。このステップを使用して、ワークフローに複数の処理パスを導入できます。例えば、複数のレビューステップを並列で発生させ、時間を節約することができます。

コンテナステップは、子ワークフローとして実行される別のワークフローモデルを開始します。
このコンテナを使用すると、ワークフローモデルを再利用して、共通のステップシーケンスを実装できます。例えば、1 つの翻訳ワークフローモデルを複数の編集ワークフローで使用することができます。

このステップを設定するには、次のタブを編集および使用します。
- 共通
- コンテナ
- サブワークフロー:開始するワークフローを選択します。
移動ステップを使用すると、ワークフローモデル内で実行する次のステップを ECMAScript の結果に応じて指定できます。
- true:移動ステップが完了すると、ワークフローエンジンが指定のステップを実行します。
- false:移動ステップが完了すると、通常のルーティングロジックが次に実行するステップを決定します。
移動ステップを使用すると、ワークフローモデル内に詳細なルーティング構造を実装できます。例えば、ループを実装するには、ループ条件を評価するスクリプトを使用して、ワークフロー内の前のステップを実行するように移動ステップを定義します。
このステップを設定するには、次のタブを編集および使用します。
- 共通
- プロセス
- 移動先のステップ。:実行するステップを選択します。
- スクリプトのパス:移動ステップを実行するかどうかを判断する ECMAScript へのパス。
- スクリプト:移動ステップを実行するかどうかを判断する ECMAScript。
警告:
「スクリプトのパス」または「スクリプト」のどちらかを指定してください。両方のオプションを同時に使用することはできません。両方のプロパティに値を指定した場合、このステップは「スクリプトのパス」を使用します。
ループをシミュレートするには、発生したループの繰り返し回数を記録する必要があります。
- この回数は、一般的に、アクションの対象となるワークフロー内の項目のインデックスを表します。
- この回数がループの終了基準として評価されます。
例えば、複数の JCR ノードに対してアクションを実行するワークフローを実装するには、ループカウンターをノードのインデックスとして使用できます。回数を保持するには、ワークフローインスタンスのデータマップに integer 値を保存します。回数を増分したり、回数を終了基準と比較するには、移動ステップのスクリプトを使用します。
function check(){ var count=0; var keyname="loopcount" try{ if (workflowData.getMetaDataMap().containsKey(keyname)){ log.info("goto script: found loopcount key"); count= parseInt(workflowData.getMetaDataMap().get(keyname))+1; } workflowData.getMetaDataMap().put(keyname,count); }catch(err) { log.info(err.message); return false; } if (parseInt(count) <7){ return true; } else { return false; } }
OR 分割は、ワークフロー内に分割を作成し、どちらか 1 つのブランチだけをアクティブにします。これを使用すると、ワークフローに条件付き処理パスを導入できます。必要に応じて、各ブランチにワークフローステップを追加できます。

-
次のタブを編集および使用します。
- 共通
- ブランチ:必要なブランチの数(2、3、4 または 5)を選択します。
- ブランチ <x>
- スクリプトのパス:スクリプトが格納されたファイルへのパス。
- スクリプト:スクリプトをボックス内に追加します。
- デフォルトのルート:分割内のどのブランチにもスクリプトが定義されていない場合、またはどのスクリプトも満たされない場合は、デフォルトのブランチに進みます。デフォルトとして指定できるブランチは 1 つだけです。
注意:
ブランチごとに別個のタブがあります。
- 各ブランチのスクリプトは一度に 1 つずつ評価されます。
- ブランチの番号によって、評価される順序が決定されます。
- true に評価された最初のスクリプトが実行されます。
- true に評価されたスクリプトがない場合、デフォルトのブランチに進みます。
警告:
「スクリプトのパス」または「スクリプト」のどちらかを指定してください。両方のオプションを同時に使用することはできません。両方のプロパティに値を指定した場合、このステップは「スクリプトのパス」を使用します。
注意:
OR 分割用のルールの定義を参照してください。
- 共通
参加者ステップでは、特定のアクションの所有者を割り当てることができます。ワークフローは、ユーザーが手動でステップを承認した場合にのみ続行します。こうした動作は、任意のユーザーに対してワークフロー上のアクション(ステップのレビューなど)を実行させる必要がある場合に利用されます。
余談になりますが、アクションを割り当てる際には、ユーザー認証を考慮する必要があります。ユーザーは、ワークフローのペイロードであるページにアクセスする必要があるからです。
注意:
次の場合、ワークフロー開始者には常に通知が送信されます。
- ワークフローが完了(終了)した場合。
- ワークフローが中止(中断)された場合。
注意:
一部のプロパティでは、電子メール通知を有効にするように設定する必要があります。電子メールテンプレートをカスタマイズしたり、新しい言語用の電子メールテンプレートを追加することもできます。AEM で電子メール通知を設定するには、電子メール通知の設定を参照してください。
ダイアログ参加者ステップは、作業項目を割り当てられたユーザーから情報を収集するために使用します。このステップは、ワークフロー内で後で使用する少量のデータを収集するのに役立ちます。
ステップの完了時、作業項目を完了ダイアログには、ダイアログで定義したフィールドが表示されます。各フィールドで収集されたデータは、ワークフローペイロードのノードに保存されます。後続のワークフローステップは、この値をリポジトリから読み取ることができます。
このステップを設定するには、作業項目を割り当てるユーザーまたはグループ、およびダイアログへのパスを指定します。
このステップを設定するには、次のタブを編集および使用します。
- 共通
- ユーザー / グループ
- ダイアログ
- ダイアログのパス:作成するダイアログの dialog ノードへのパス。
ダイアログを作成するには、以下を実行する必要があります。
- 収集されたデータをペイロード内に保存する場所を決定します。
- ダイアログを定義します。これには、データの収集(および保存)に使用するフィールドの定義が含まれます。ダイアログ構造は、使用する UI に依存します。
ウィジェットデータは、ワークフローペイロードまたは作業項目のメタデータに保存できます。widget ノードの name プロパティの形式によって、データの保存場所が決定されます。
- データをペイロードと共に保存
- ウィジェットデータをワークフローペイロードのプロパティとして保存するには、widget ノードの name プロパティの値に次の形式を使用します。
./jcr:content/nodename - データは、ペイロードのノードの nodename プロパティに保存されます。ノードにこのプロパティが含まれていない場合は、プロパティが作成されます。
- ペイロードと共に保存した場合は、後で同じペイロードを持つダイアログを使用したときに、プロパティの値が上書きされます。
- ウィジェットデータをワークフローペイロードのプロパティとして保存するには、widget ノードの name プロパティの値に次の形式を使用します。
- データを作業項目と共に保存
- ウィジェットデータを作業項目のメタデータのプロパティとして保存するには、name プロパティの値に次の形式を使用します。
nodename - データは、作業項目のメタデータの nodename プロパティに保存されます。この場合は、同じペイロードを持つダイアログを使用しても、データは保存されます。
- ウィジェットデータを作業項目のメタデータのプロパティとして保存するには、name プロパティの値に次の形式を使用します。
-
ダイアログ参加者ステップのダイアログは、コンポーネントのオーサリング用に作成するダイアログと似ています。ダイアログは、次の場所に保存されます。
/etc/workflow/dialogs
タッチ操作向け UI 用ダイアログは、次のノード構造を持ちます。
newComponent (cq:Component) |- cq:dialog (nt:unstructured) |- content |- layout |- items |- column |- items |- component0 |- component1 |- ...
注意:
詳しくは、タッチ操作向け UI 用ダイアログの作成と設定を参照してください。
-
ダイアログ参加者ステップには、ダイアログパスのプロパティ(および参加者ステップのプロパティ)があります。ダイアログパスのプロパティの値は、ダイアログの dialog ノードへのパスです。
例えば、ダイアログが /etc/workflows/dialogs ノードに保存されている EmailWatch というコンポーネントに含まれるとします。タッチ操作向け UI の場合、ダイアログパスのプロパティには次の値を使用します。
/etc/workflow/dialogs/EmailWatch/cq:dialog
-
次の XML コードスニペットは、ペイロードコンテンツの watchEmail ノードに String 値を保存するダイアログを表しています。title ノードは、TextField コンポーネントを表します。
jcr:primaryType="nt:unstructured" jcr:title="Watcher Email Address Dialog" sling:resourceType="cq/gui/components/authoring/dialog"> <content jcr:primaryType="nt:unstructured" sling:resourceType="granite/ui/components/foundation/container"> <layout jcr:primaryType="nt:unstructured" margin="false" sling:resourceType="granite/ui/components/foundation/layouts/fixedcolumns" /> <items jcr:primaryType="nt:unstructured"> <column jcr:primaryType="nt:unstructured" sling:resourceType="granite/ui/components/foundation/container"> <items jcr:primaryType="nt:unstructured"> <title jcr:primaryType="nt:unstructured" fieldLabel="Notification Email Address" name="./jcr:content/watchEmails" sling:resourceType="granite/ui/components/foundation/form/textfield" /> </items> </column> </items> </content> </cq:dialog>
-
ダイアログ参加者ステップのダイアログは、コンポーネントのオーサリング用に作成するダイアログと似ています。ダイアログは、次の場所に保存されます。
/etc/workflows/dialogs
クラシック UI 用ダイアログは、次のノード構造を持ちます。
newComponent |- dialog |- items |- widget0 |- widget1 |- ...
ノード名 jcr:PrimaryType 説明 dialog cq:Dialog ダイアログのルートノード。
このノードには、値が dialog で xtype という名前の String プロパティが必要です。
items cq:WidgetCollection dialog ノードの子ノード。 field_name cq:Widget ダイアログに表示される 1 つ以上の UI ウィジェット。これらのノードには任意の有効な JCR 名を使用できます。各ノードには、次のプロパティが必要です。
- xtype:ウィジェットのタイプを決定する String 値。詳しくは、Widget API のリファレンスを参照してください。
- name:ウィジェットデータを格納するノードのパスを表す String 値。
注意:
詳しくは、クラシック UI 用ダイアログの作成と設定を参照してください。
-
ダイアログ参加者ステップには、ダイアログパスのプロパティ(および参加者ステップのプロパティ)があります。ダイアログパスのプロパティの値は、ダイアログの dialog ノードへのパスです。
例えば、ダイアログが /etc/workflows/dialogs ノードに保存されている EmailWatch というコンポーネントに含まれるとします。クラシック UI の場合、ダイアログパスのプロパティには次の値を使用します。
/etc/workflow/dialogs/EmailWatch/dialog
-
次の XML コードスニペットは、ペイロードコンテンツの watchEmail ノードに String 値を保存するダイアログを表しています。title ノードは、textfield ウィジェットを表します。
jcr:primaryType="cq:Dialog" title="Watcher Email Address Dialog" xtype="dialog"> <items jcr:primaryType="cq:WidgetCollection"> <title jcr:primaryType="cq:Widget" fieldLabel="Notification Email Address" name="./jcr:content/watchEmails" xtype="textfield" /> </items> </dialog>
動的参加者ステップコンポーネントは参加者ステップに似ていますが、参加者が実行時に自動的に選択される点が異なります。
このステップを設定するには、ダイアログと、作業項目を割り当てる参加者を識別する参加者選択を選択します。
参加者選択を作成します。そのために、あらゆる選択ロジックまたは選択条件を使用できます。例えば、参加者選択を使用して、(グループ内で)最も作業項目が少ないユーザーを選択できます。任意の数の参加者選択を作成して、ワークフローモデル内の動的参加者ステップコンポーネントの異なるインスタンスで使用できます。
-
ECMAScript
スクリプトには、ユーザー ID を String 値として返す、getParticipant という関数を含める必要があります。スクリプトを /etc/workflow/scripts フォルダーまたはサブフォルダーに保存します。
標準 AEM インスタンスには、次のサンプルスクリプトが付属しています。
/etc/workflow/scripts/initiator-participant-chooser.ecma
このスクリプトは、ワークフロー開始者を参加者として選択します。
function getParticipant() { return workItem.getWorkflow().getInitiator(); }
注意:
ワークフローイニシエーター参加者選択コンポーネントは、動的参加者ステップを拡張し、このスクリプトをステップ実装として使用します。
-
OSGi サービス
サービスは、com.day.cq.workflow.exec.ParticipantStepChooser インターフェイスを実装する必要があります。このインターフェイスは、次の構成要素を定義します。
- SERVICE_PROPERTY_LABEL フィールド:このフィールドを使用して、参加者選択の名前を指定します。この名前が、動的参加者ステップのプロパティで使用可能な参加者選択のリストに表示されます。
- getParticipant メソッド:動的に解決されるプリンシパル ID を String 値として返します。
警告:
getParticipant メソッドは、動的に解決されるプリンシパル ID を返します。この ID は、グループ ID またはユーザー ID のいずれかになります。
ただし、グループ ID を使用できるのは、参加者ステップに対してのみです(参加者のリストが返された場合)。動的参加者ステップの場合は、空のリストが返されるので、委任のために使用することはできません。
注意:
ランダム参加者選択は、ランダムにユーザーを選択するサンプルサービスです(com.day.cq.workflow.impl.process.RandomParticipantChooser)。サンプルのランダム参加者選択ステップコンポーネントは、動的参加者ステップを拡張し、このサービスをステップ実装として使用します。
次の Java クラスは、ParticipantStepChooser インターフェイスを実装します。このクラスは、ワークフローを開始した参加者の名前を返します。このコードでは、サンプルスクリプト(initator-participant-chooser.ecma)と同じロジックを使用しています。
@Property アノテーションは、SERVICE_PROPERTY_LABEL フィールドの値を「ワークフローイニシエーター参加者選択」に設定します。
package com.adobe.example; import org.apache.felix.scr.annotations.Component; import org.apache.felix.scr.annotations.Properties; import org.apache.felix.scr.annotations.Property; import org.apache.felix.scr.annotations.Service; import org.osgi.framework.Constants; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import com.adobe.granite.workflow.WorkflowException; import com.adobe.granite.workflow.WorkflowSession; import com.adobe.granite.workflow.exec.ParticipantStepChooser; import com.adobe.granite.workflow.exec.WorkItem; import com.adobe.granite.workflow.metadata.MetaDataMap; @Component @Service @Properties({ @Property(name = Constants.SERVICE_DESCRIPTION, value = "An example implementation of a dynamic participant chooser."), @Property(name = ParticipantStepChooser.SERVICE_PROPERTY_LABEL, value = "Workflow Initiator Participant Chooser") }) public class InitiatorParticipantChooser implements ParticipantStepChooser { private Logger logger = LoggerFactory.getLogger(this.getClass()); public String getParticipant(WorkItem arg0, WorkflowSession arg1, MetaDataMap arg2) throws WorkflowException { String initiator = arg0.getWorkflow().getInitiator(); logger.info("Assigning Dynamic Participant Step work item to {}",initiator); return initiator; } }
ワークフローモデルが開始されると、ワークフローを開始し、作業項目が割り当てられたユーザーの ID がログに記録されます。この例では、admin ユーザーがワークフローを開始しています。
13.09.2015 15:48:53.037 *INFO* [10.176.129.223 [1347565733037] POST /etc/workflow/instances HTTP/1.1] com.adobe.example.InitiatorParticipantChooser Assigning Dynamic Participant Step work item to admin
フォーム参加者ステップは、作業項目が開かれるとフォームを表示します。ユーザーがフォームに入力して送信すると、フィールドデータがワークフローペイロードのノードに保存されます。
このステップを設定するには、作業項目を割り当てるユーザーまたはグループ、およびフォームへのパスを指定します。
このステップを設定するには、次のタブを編集および使用します。
- 共通
- ユーザー / グループ
- フォーム
- フォームパス:作成するフォームへのパス。
注意:
「フォームとワークフローを使用したデータの収集」チュートリアルでは、フォーム参加者ステップと関連フォームを使用するワークフローの作成について、順を追って説明します。
通常どおり、フォーム参加者ステップで使用するフォームを作成します。ただし、フォーム参加者ステップ用のフォームには、次の設定が必要です。
- フォームの最初コンポーネントでは、アクションタイププロパティを「ワークフロー制御リソースを編集」に設定する必要があります。
- フォームの最初コンポーネントでは、フォーム識別子プロパティに値が必要です。
- フォームコンポーネントでは、エレメント名プロパティを、フィールドデータを保存するノードのパスに設定する必要があります。パスは、ワークフローペイロードコンテンツ内のノードを指す必要があります。値には次の形式を使用します。
./jcr:content/path_to_node
- フォームには、ワークフロー送信ボタンコンポーネントを含める必要があります。このコンポーネントのプロパティは一切設定しないでください。
ワークフローの要件によって、フィールドデータを保存する場所が決定されます。例えば、フィールドデータを使用して、ページコンテンツのプロパティを設定できます。次の値を持つエレメント名プロパティは、フィールドデータを jcr:content ノードの redirectTarget プロパティの値として保存します。
./jcr:content/redirectTarget
次の例では、フィールドデータはペイロードページのテキストコンポーネントのコンテンツとして使用されます。
./jcr:content/par/text_3/text に設定します。
最初の例は、cq:Page コンポーネントがレンダリングする、あらゆるページに使用できます。2 番目の例は、ペイロードページに「text_3」という ID を持つテキストコンポーネントが含まれる場合にのみ使用できます。
フォームは、リポジトリ内のどこにでも配置できますが、ワークフローユーザーにはフォームを読み取るための権限が必要です。
注意:
フォームの作成については、フォームの作成を参照してください。使用可能なフォームコンポーネントについては、ページオーサリング用コンポーネント - フォームセクションを参照してください。

このステップを設定するには、次のタブを編集および使用します。
- 共通
- 引数
- 参加者:選択に使用できるユーザーのリストを指定します。ユーザーをリストに追加するには、「項目を追加」をクリックし、ユーザーノードのホームパスまたはユーザー ID を入力します。ユーザーの順序は、作業項目が割り当てられる可能性に影響を与えません。
このステップを設定するには、次のタブを編集および使用します。
- 共通
- 引数
- 使用可能な引数がありません。

このステップを設定するには、次のタブを編集および使用します。
- 共通
- プロセス
- プロセス:実行するプロセス実装。ドロップダウンメニューを使用して、ECMAScript または OSGi サービスを選択します。参考情報:
- 標準の ECMAScript および OSGi サービスについては、プロセスステップ用のビルトインプロセスを参照してください。
- プロセスステップ用の ECMAScript の作成については、ECMAScript を使用したプロセスステップの実装を参照してください。
- プロセスステップ用の OSGi サービスの作成については、Java クラスを使用したプロセスステップの実装を参照してください。
- ハンドラー処理の設定:実行後にワークフローを次のステップに自動的に進めるには、このオプションを選択します。選択しない場合、実装スクリプトでワークフローの進行を処理する必要があります。
- 引数:プロセスに渡される引数。
- プロセス:実行するプロセス実装。ドロップダウンメニューを使用して、ECMAScript または OSGi サービスを選択します。参考情報:
Forms のワークフローステップは、デフォルトのワークフローステップに追加されたステップです。これらのステップを使用すると、OSGi でアダプティブフォームをベースとした Forms 中心型ワークフローを迅速に構築できます。このようなワークフローは、基本的なレビューおよび承認、ファイアウォールの内部およびファイアウォールを経由した簡単なビジネスプロセス、ドキュメントサービスの開始、Adobe Sign 署名ワークフローとの統合などの操作に使用できます。これらのステップをワークフローで使用するには、AEM Forms アドオンが必要です。
AEM Forms のステップは、デフォルトでサイドキックに表示されません。サイドキックのデザインモードツールから Forms のワークフローオプションを選択すると、これらのステップを有効にすることができます。詳しくは、OSGi の Forms 中心型ワークフローを参照してください。
タスクを割り当てコンポーネントは、タスクを作成してユーザーまたはグループに割り当てます。このコンポーネントを使用すると、タスクの割り当てに加えて、タスクのアダプティブフォームまたは非インタラクティブ PDF を指定できます。アダプティブフォームは、ユーザーからの入力を受け取るために必要です。また、非インタラクティブ PDF または読み取り専用のアダプティブフォームは、レビュー専用のワークフローに使用されます。
このコンポーネントを使用すると、タスクの動作を制御することもできます。例えば、レコードの自動ドキュメントの作成、特定のユーザーまたはグループへのタスクの割り当て、送信されたデータのパス、事前に入力されるデータのパス、デフォルトのアクションを制御できます。タスクを割り当てステップには、次のプロパティがあります。
- タイトル:タスクのタイトル。タイトルは AEM インボックスに表示されます。
- 説明:タスクで実行される操作の説明。この情報は、共有開発環境で作業している場合に他のプロセス開発者にとって有用です。この説明も AEM インボックスに表示されます。
- サムネールのパス:タスクサムネールのパス。パスを指定しない場合、アダプティブフォームではデフォルトのサムネールが表示され、レコードのドキュメントではデフォルトのアイコンが表示されます。
- ワークフローステージ:1 つのワークフローに複数のステージを含めることができます。これらのステージは、AEM インボックスに表示されます。これらのステージは、モデルのプロパティ(サイドキック/ページ/ページのプロパティ/ステージ)で定義できます。
- 優先度:選択した優先度が AEM インボックスに表示されます。使用可能なオプションは、「高」、「中」および「低」です。デフォルト値は「中」です。
- 期限:タスクが期限切れとマークされるまでの日数または時間数を指定します。「オフ」を選択した場合、タスクが期限切れとマークされることはありません。タイムアウトハンドラーを指定して、タスクが期限切れになった後に特定のタスクを実行することもできます。
- 日:タスクを完了するまでの日数。この日数は、タスクがユーザーに割り当てられた後にカウントされます。タスクが完了せず、「日」フィールドに指定された日数を過ぎると、期限後にタイムアウトハンドラー(選択した場合)が呼び出されます。
- 時間:タスクを完了するまでの時間数。この時間数は、タスクがユーザーに割り当てられた後にカウントされます。タスクが完了せず、「時間」フィールドに指定された時間数を過ぎると、期限後にタイムアウトハンドラー(選択した場合)が呼び出されます。
- 期限後にタイムアウト:このオプションを選択して、タイムアウトハンドラー選択フィールドを有効にします。
- タイムアウトハンドラー:タスクを割り当てステップが期限切れになったときに実行するスクリプトを選択します。CRX リポジトリ([apps]/fd/dashboard/scripts/timeoutHandler)にあるスクリプトを選択できます。指定されたパスは crx リポジトリに存在しません。このパスは、使用する前に管理者が作成します。
- タスクの詳細で最後のタスクのアクションとコメントを強調表示する:タスクの詳細セクションで最後に実行されたアクションと受け取ったコメントを表示するには、このオプションを選択します。
- タイプ:ワークフローの開始時に入力するドキュメントのタイプを選択します。アダプティブフォーム、読み取り専用のアダプティブフォームまたは非インタラクティブ PDF ドキュメントを選択できます。
- アダプティブフォームのパス:アダプティブフォームのパスを指定します。このフィールドは、「タイプ」フィールドでアダプティブフォームまたは読み取り専用のアダプティブフォームを選択した場合に使用できます。
- PDF のパス:非インタラクティブ PDF ドキュメントのパスを指定します。このフィールドは、「タイプ」フィールドで非インタラクティブ PDF ドキュメントを選択した場合に使用できます。必ずペイロードに対する相対パスを指定します。例えば、[Payload_Directory]/Workflow/PDF/credit-card.pdf となります。このパスは crx リポジトリに存在しません。このパスは、使用する前に管理者が作成します。「PDF のパス」オプションを使用する場合は、有効な「レコードのドキュメント」オプションか、フォームテンプレートベースのアダプティブフォームが必要です。
- 完了したタスクのアダプティブフォームを次の形式でレンダリングする:タスクが完了とマークされると、アダプティブフォームを読み取り専用のアダプティブフォームまたは PDF ドキュメントとしてレンダリングできます。アダプティブフォームをレコードのドキュメントとしてレンダリングするには、有効な「レコードのドキュメント」オプションか、フォームテンプレートベースのアダプティブフォームが必要です。
- あらかじめ入力する情報:以下のフィールドは、タスクへの入力として使用できます。
- データファイルのパス:入力データファイル(.json または .xml)のパス。必ずペイロードに対する相対パスを指定します。例えば、ファイルには、AEM インボックスアプリケーションを介してフォームに送信されるデータが含まれています。一例として、[Payload_Directory]/workflow/data というパスを指定します。
- 添付ファイルのパス:指定した場所にある添付ファイルは、タスクに関連付けられたフォームに添付されます。必ずペイロードに対する相対パスを指定します。一例として、[Payload_Directory]/attachments/ というパスを指定します。
- 送信される情報:以下のフィールドは、タスクの出力先として使用できます。
- データファイルのパス:データファイル(.json または .xml)のパス。このデータファイルには、関連付けられたフォームを介して送信された情報が含まれます。必ずペイロードに対する相対パスを指定します。例えば、[Payload_Directory]/Workflow/data のように指定します。ここで、data はファイルです。
- 添付ファイルのパス:タスクで提供されたフォームの添付ファイルの保存先のパス。
- レコードのドキュメントのパス:レコードのドキュメントファイルの保存先のパス。例えば、[Payload_Directory]/DocumentofRecord/credit-card.pdf のように指定します。パスフィールドを空白にした場合、レコードのドキュメントは生成されません。必ずペイロードに対する相対パスを指定します。
- 割り当てオプション:タスクをユーザーに割り当てる方法を指定します。参加者選択スクリプトを使用してタスクを動的にユーザーまたはグループに割り当てることも、タスクを特定の AEM ユーザーまたはグループに割り当てることもできます。
- 参加者選択:このオプションは、「割り当てオプション」フィールドで「ユーザーまたはグループに動的に割り当て」オプションを選択した場合に使用できます。ユーザーまたはグループを動的に選択するには、ECMAScript またはサービスを使用できます。詳しくは、ワークフローを動的にユーザーに割り当てる方法および Adobe Experience Manager のカスタム動的参加者ステップの作成を参照してください。
- ユーザーまたはグループ:選択したユーザーまたはグループにタスクが割り当てられます。このオプションは、「割り当てオプション」フィールドで「特定のユーザーまたはグループに割り当て」オプションを選択した場合に使用できます。基になる AEM インスタンスで使用可能なユーザーとグループすべてが表示されます。
- 担当者に電子メールで通知する:電子メール通知を担当者に送信するには、このオプションを選択します。この通知は、タスクがユーザーに割り当てられたときに送信されます。このオプションを使用する前に、AEM Web コンソールからの通知を有効にしてください。詳しい手順については、タスクを割り当てステップの電子メール通知の設定を参照してください。
- HTML 電子メールテンプレート:通知電子メールの電子メールテンプレートを選択します。テンプレートを編集するには、crx リポジトリの /libs/fd/dashboard/templates/email/htmlEmailTemplate.txt にあるファイルを変更します。
- 委任を許可:AEM インボックスには、ログインユーザーが、割り当てられたワークフローを別のユーザーに委任するオプションが用意されています。同じグループ内または別のグループのワークフローユーザーに委任することができます。タスクが 1 人のユーザーに割り当てられていて、「担当者グループのメンバーへの委任を許可する」オプションが選択されている場合、そのタスクを別のユーザーまたはグループに委任することはできません。
- デフォルトのアクション:標準提供されている送信、保存およびリセットアクションを使用できます。デフォルトのアクションはすべて、デフォルトで有効になっています。オプションの選択を解除すると、ワークフローのアクションを無効にすることができます。
- ルート変数:ルート変数の名前。ルート変数は、ユーザーが AEM インボックスで選択したカスタムアクションを取得します。
- ルート:タスクは様々なルートに分岐することができます。AEM インボックスで選択すると、ルートから値が返され、選択したルートに基づいてワークフローが分岐します。
- タイトル:ルートのタイトルを指定します。タイトルは AEM インボックスに表示されます。
- Coral アイコン:Coral アイコンの HTML 属性を指定します。Adobe CorelUI ライブラリでは、多数のタッチファーストなアイコンを提供します。ルートのアイコンを選択して使用することができます。アイコンは、タイトルと共に AEM インボックスに表示されます。
- 担当者によるコメントの追加を許可:タスクのコメントを有効にするには、このオプションを選択します。担当者は、タスクの送信時に AEM インボックス内からコメントを追加できます。
- 担当者によるタスクへの添付ファイルの追加を許可:タスクの添付ファイルを有効にするには、このオプションを選択します。担当者は、タスクの送信時に AEM インボックス内から添付ファイルを追加できます。
- タスクの添付ファイルの出力パス:添付ファイルフォルダーの場所を指定します。ペイロードに対する相対位置を指定します。
- カスタムメタデータを使用:カスタムメタデータフィールドを有効にするには、このオプションを選択します。カスタムメタデータは電子メールテンプレートで使用されます。
- カスタムメタデータ:電子メールテンプレートのカスタムメタデータを選択します。カスタムメタデータは、crx リポジトリの apps/fd/dashboard/scripts/metadataScripts にあります。指定されたパスは crx リポジトリに存在しません。このパスは、使用する前に管理者が作成します。また、カスタムメタデータ用のサービスを使用することもできます。さらに、WorkitemUserMetadataService インターフェイスを拡張してカスタムメタデータを提供することもできます。
- 前のステップのデータを表示:以前の担当者、タスクに対して既に実行されたアクション、タスクに追加されたコメントおよび完了したタスクのレコードのドキュメント(使用可能な場合)を担当者が表示できるようにするには、このオプションを選択します。
- 後続のステップのデータを表示:現在の担当者の後にさらに多くのユーザーにタスクを割り当てることができます。後続の担当者が実行したアクションおよびタスクに追加したコメントを現在の担当者が表示できるようにするには、このオプションを選択します。また、このオプションを選択すると、完了したタスクのレコードのドキュメント(使用可能な場合)を現在の担当者が表示できるようになります。
- データタイプの表示:デフォルトで、担当者は、レコードのドキュメント、担当者、実行されたアクションに加え、前の担当者および後続の担当者が追加したコメントを表示することができます。「データタイプの表示」オプションを使用すると、担当者に表示されるデータタイプが制限されます。
フォームの入力時または送信時には、そのフォームを印刷物またはドキュメント形式で記録しておくことができます。これは、レコードのドキュメント(DoR)と呼ばれます。レコードのドキュメントを生成ステップを使用して、アダプティブフォームの(読み取り専用/インタラクティブ)PDF バージョンを作成することができます。PDF バージョンには、アダプティブフォームのレイアウトと共にフォームに入力された情報が含まれます。
レコードのドキュメントステップには、次のプロパティがあります。
アダプティブパス:レコードのドキュメントが生成されるアダプティブフォームのパスを指定します。
入力データパス:アダプティブフォームの入力データのパス。データを保持する場所として、ペイロードを基準とした相対的な場所、ペイロードの場所またはデータの絶対パスを指定することができます。入力データは、レコードのドキュメントを作成するためにアダプティブフォームとマージされます。
生成されたレコードのドキュメントのパス:レコードのドキュメントファイルを保持する場所を指定します。ペイロードフォルダーを上書きするか、ペイロードディレクトリ内の場所にレコードのドキュメントを配置するかを選択できます。
ロケール:レコードのドキュメントの言語を指定します。
ドキュメントに署名ステップでは、Adobe Sign を使用してドキュメントに署名できます。ドキュメントに署名ステップには、次のプロパティがあります。
- 契約名:契約のタイトルを指定します。契約名は、署名者に送信される電子メールの件名と本文の一部になります。
- ロケール:電子メールと検証オプションの言語を指定します。
- Adobe Sign クラウド設定:Adobe Sign クラウド設定を選択します。Adobe Sign を AEM Forms 用に設定していない場合は、Adobe Sign と AEM Forms の統合を参照してください。
- 署名するドキュメント:ペイロードを基準とした相対的な場所からドキュメントを選択するか、ペイロードをドキュメントとして使用するか、ドキュメントの絶対パスを指定することができます。
- 期限までの日数:「期限までの日数」フィールドに指定された日数の間にタスクのアクティビティがない場合、ドキュメントは期限切れとマークされます。 日数は、ドキュメントが署名のためにユーザーに割り当てられた後にカウントされます。
- リマインダー電子メールの頻度:リマインダー電子メールを日単位または週単位で送信できます。週のカウントは、ドキュメントが署名のためにユーザーに割り当てられた日から始まります。
- 署名プロセス:ドキュメントへの署名を順次おこなうか並列でおこなうかを選択できます。順次おこなう場合、ドキュメントは署名のために一度に 1 人の署名者に送信されます。最初の署名者がドキュメントの署名を完了すると、ドキュメントは 2 人目の署名者に送信され、それ以降も同様です。並列でおこなう場合、複数の署名者が同時に 1 つのドキュメントに署名することができます。
- リダイレクト URL:リダイレクト URL を指定します。ドキュメントへの署名が完了したら、担当者を URL にリダイレクトすることができます。通常、この URL には、感謝のメッセージやその後の手順が含まれています。
- ワークフローステージ:1 つのワークフローに複数のステージを含めることができます。これらのステージは、AEM インボックスに表示されます。これらのステージは、モデルのプロパティ(サイドキック/ページ/ページのプロパティ/ステージ)で定義できます。
- 署名者を選択:ドキュメントの署名者を選択する方法を指定します。ワークフローを動的にユーザーまたはグループに割り当てることも、手動で署名者の詳細を追加することもできます。
- 署名者を選択するためのスクリプトまたはサービス:このオプションを使用できるのは、「署名者を選択」フィールドで「動的」オプションが選択されている場合のみです。ECMAScript またはサービスを指定して、ドキュメントの署名者と検証オプションを選択することができます。
- 署名者の詳細:このオプションを使用できるのは、「署名者を選択」フィールドで「手動」オプションが選択されている場合のみです。電子メールアドレスを指定し、オプションの検証メカニズムを選択します。2 段階検証メカニズムを選択する前に、設定済みの Adobe Sign アカウントに対して対応する検証オプションが有効になっていることを確認してください。
- ステータス変数:Adobe Sign 対応ドキュメントでは、ドキュメントの署名ステータスが変数に格納されます。ステータス変数の名前(adobeSignStatus)を指定します。インスタンスのステータス変数は、変数のステータスが格納されている CRXDE の /etc/workflow/instances/<server>/<date-time>/<instance of workflow model>/workItems/<node>/metaData から利用できます。
- 署名済みドキュメントのパス:署名済みドキュメントを保持する場所を指定します。ペイロードファイルを上書きするか、ペイロードディレクトリ内の場所に署名済みドキュメントを配置するかを選択できます。
AEM ドキュメントサービスは、PDF ドキュメントを作成、アセンブルおよび保護するための一連のサービスです。AEM Forms は、それぞれのドキュメントサービスに対して個別の AEM ワークフローステップを提供します。
ドキュメントにタイムスタンプを追加します。入力ドキュメントのパス、入力ドキュメントの名前、書き出されたデータの保存場所など、ドキュメントの詳細を指定します。既存のペイロードファイルを上書きすることも、別のファイル名を選択してペイロードフォルダー内の別のファイルにデータを保存することも可能です。
PDF ドキュメントを画像ファイルに変換します。サポートされている画像形式は、JPEG、JPEG2000、PNG および TIFF です。TIFF 画像への変換には、次の情報が当てはまります。
- 複数ページの TIFF ファイルが生成されます。
- 一部の注釈は TIFF 画像に含まれません。外観の生成に Acrobat を必要とする注釈は含まれません。
指定したオプションを使用して PDF ドキュメントを PDF/A 形式に変換します。PDF/A バージョンの Portable Document Format(PDF)は、ドキュメントのアーカイブおよび長期保存に特化しています。
PDF ドキュメントを PostScript に変換します。PostScript に変換する際に、この変換操作を使用して、変換元のドキュメントと、PostScript レベル 2 と 3 のどちらに変換するかを指定できます。PostScript ファイルに変換する PDF ドキュメントは、非インタラクティブである必要があります。
PDF フォームまたは XDP ファイルからデータを書き出します。入力ドキュメントのファイルパスとデータの書き出し形式を入力する必要があります。データの書き出し形式のオプションは、「自動」、「XDP」および「XmlData」です。
PDF ファイルは、サイズを小さくして最適化します。この変換の結果、PDF ファイルは元のバージョンよりも小さくなる可能性があります。また、この操作では、PDF ドキュメントが最適化パラメーターで指定された PDF バージョンに変換されます。
最適化の設定では、ファイルの最適化方法を指定します。設定の例を次に示します。
ターゲットの PDF バージョン
JavaScript アクションや埋め込みページサムネールなどのオブジェクトの破棄
コメントや添付ファイルなどのユーザーデータの破棄
無効な設定や未使用の設定の破棄
非圧縮データの圧縮、またはより効率的な圧縮アルゴリズムの使用
埋め込まれたフォントの削除
透過値の設定
ドキュメントの暗号化、署名および証明をおこないます。AEM Forms は、パスワードベースと証明書ベース両方の暗号化をサポートしています。ドキュメントに署名するための様々なアルゴリズムの中から選択することもできます。例えば、SHA-256 や SH-512 があります。また、このワークフローステップを使用して PDF ドキュメントを拡張することもできます。このワークフローステップには、バーコードのデコード、デジタル署名、PDF データの読み込みと書き出しなどのオプションを有効にするためのオプションが用意されています。
ドキュメントをプリンターに直接送信します。次の印刷アクセスメカニズムがサポートされています。
- 直接アクセス型プリンター:同じコンピューターにインストールされているプリンターは、直接アクセス型プリンターと呼ばれます。また、そのコンピューターはプリンターホストと呼ばれます。このタイプのプリンターには、コンピューターに直接接続されているローカルプリンターが該当します。
- 間接アクセス型プリンター:プリントサーバーにインストールされているプリンターには、他のコンピューターからアクセスできます。ネットワークプリンターへの接続には、Common UNIX® Printing System(CUPS)や Line Printer Daemon(LPD)プロトコルなどのテクノロジーを使用できます。間接アクセス型プリンターにアクセスするには、プリントサーバーの IP またはホスト名を指定します。このメカニズムを使用すると、ネットワークで LPD が実行されている場合はドキュメントを LPD URI に送信できます。このメカニズムにより、LPD が実行されているネットワークに接続されているどのプリンターにもドキュメントをルーティングすることができます。