4.3 ワークフロー作成のガイドライン

適格なワークフローを作成するには、アクティビティとフローパス追加のルールを理解する必要があります。ワークフローデータを操作する方法を理解する必要もあります。次のトピックを参照してください。

メモ:プロビジョニング要求定義は、展開前に検証することができます。詳細については、セクション 2.6, プロビジョニングオブジェクトの検証を参照してください。

4.3.1 アクティビティのルール

ワークフローにアクティビティを追加するときに、次のルールに従います:

  • 1つのワークフローには開始アクティビティと完了アクティビティをそれぞれ1つだけ設定できます。

  • 1つのワークフローは次のアクティビティタイプを0個、またはそれ以上持つことができます。

    • 承認アクティビティ
    • ログアクティビティ
    • ブランチアクティビティ
    • マージアクティビティ
    • 条件アクティビティ
    • マッピングアクティビティ
    • ワークフローステータス
    • 電子メールアクティビティ
    • 統合
    • エンタイトルメント
    • エンティティ
  • 各ブランチアクティビティには対応するマージアクティビティが必要です。

  • プロビジョニングのステップが実行されていることを確かめるために、ワークフローに少なくとも1つのエンタイトルメントアクティビティまたはエンティティアクティビティが必要です。

4.3.2 フローパスのルール

ワークフローにフローパスを追加するときには、次のルールに従います:

  • 開始アクティビティ以外のすべてのアクティビティには、1つ以上の着信フローパスを設定できます。開始アクティビティには着信フローパスを設定できません。

  • 完了アクティビティには発信フローパスを設定できません。

  • 開始アクティビティに設定できる発信フローパスは1つだけです。フローパスのタイプは転送でなければなりません。

  • 承認アクティビティには1つから5つまでの発信フローパスを設定できます。有効なフローパスのタイプは、承認、却下済み、拒否済み、タイムアウト、エラーです。ランタイム時には、1つのフローパスだけが実行されます。

  • エンタイトルメント、エンティティ、ログ、マージの各アクティビティに設定できる発信フローパスは1つだけです。フローパスのタイプは転送でなければなりません。

  • 条件アクティビティには2つまたは3つの発信フローパスを設定できます。有効なフローパスのタイプは、True、False、エラーです。TrueとFalseのフローパスは必須で、エラーのフローパスはオプションです。

  • ブランチアクティビティには1つ以上の発信フローパスを設定できます。それぞれのフローパスのタイプは転送でなければなりません。ランタイム時には、すべてのフローパスが実行されます。

着信および発信フローパスをアクティビティに追加するときのルールを、次の表にまとめて示します。

表 4-3 各アクティビティに設定できるフローパスの数

アクティビティ

着信パス

発信パス

開始

0

1 (常に転送)

承認

1以上

1~5 (承認、却下済み、拒否済み、タイムアウト、エラー)

ログ

1以上

1 (常に転送)

ブランチ

1以上

1以上

マージ

1以上

1 (常に転送)

条件

1以上

2~3 (TrueとFalseは必須、エラーはオプション)

マッピング

1以上

1

ワークフローステータス

1以上

1 (常に転送)

電子メール

1以上

1 (常に転送)

終了

1以上

0

統合

1以上

1~4 (成功、タイムアウト、エラー、フォルト)

エンタイトルメント

1以上

1 (常に転送)

Entity (エンティティ)

1以上

1 (常に転送)

ソースまたはターゲットとして設定できるアクティビティのタイプを、使用可能なフローパスタイプごとに、次の表にまとめて示します。

表 4-4 アクティビティで使用可能なフローパスタイプ

アクティビティ

転送

Approved

Denied

Refused

タイムアウト

True

False

エラー

成功

フォルト

開始

ソース

 

 

 

 

 

 

 

 

 

承認

ターゲット

ソース/ターゲット

ソース/ターゲット

ソース/ターゲット

ソース/ターゲット

ターゲット

ターゲット

ソース/ターゲット

 

 

ログ

ソース/ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

 

 

ブランチ

ソース/ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

 

 

マージ

ソース/ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

 

 

条件

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ソース/ターゲット

ソース/ターゲット

ソース/ターゲット

 

 

マッピング

ソース

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

 

 

ワークフローステータス

ソース/ターゲット

 

 

 

 

 

 

 

 

 

電子メール

ソース/ターゲット

 

 

 

 

 

 

 

 

 

完了

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

 

 

統合

ソース/ターゲット

 

 

 

ソース/ターゲット

 

 

ソース/ターゲット

ソース

ソース

エンタイトルメント

ソース/ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

 

 

エンティティ

ソース/ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

ターゲット

 

 

4.3.3 ワークフローデータについての理解

ワークフローの作成時には、プロビジョニングアプリケーションのニーズに合わせて、ワークフローデータを操作できます。

ワークフローでは、プロセスに関する情報を管理するために、1つのプロセスオブジェクトを使用します。ワークフロー内のアクティビティごとに別個のアクティビティオブジェクトが作成されて、ユーザとのやりとりを担う各アクティビティのフォームデータが保持されます。

フォーム上の各ユーザインタフェースコントロール(テキストフィールド、ドロップダウンリストなど)に関連付けられているデータオブジェクトは、対応するアクティビティ(開始アクティビティまたは承認アクティビティ)を実行する直前に変更することができます。アクティビティを実行した直後に、このデータを取得することもできます。制御が次のアクティビティに渡されると、フォームコントロールデータは使用できなくなります。そのため、ワークフローにはフローデータと呼ばれる特別なオブジェクトが用意されており、このオブジェクトを使用して独自のデータ項目を定義できるようになっています。このオブジェクトに独自の変数を追加して、フォームデータを含む、ワークフローにとって重要な情報が失われないように追跡することができます。

ワークフローデータのカテゴリを、次の表にまとめて示します。

表 4-5 ワークフローデータのカテゴリ

データオブジェクト

使用期間

編集可能

作成者

プロセス

ワークフロー

いいえ

システム

アクティビティ

ワークフロー

いいえ

システム

アクティビティフォーム

アクティビティ

はい

システムおよびワークフロー設計者

フローデータ

ワークフロー

はい

ワークフロー設計者

メモ:ワークフロー設計者とは、Designerでワークフローを作成するユーザのことです。

各オブジェクトタイプの変数を、次の表に示します。

表 4-6 ワークフロー内のデータ変数

オブジェクト

変数

説明

プロセス

approvalStatus

このプロセスの現在の状態。

 

category

要求を開始したユーザによって選択されたプロビジョニングカテゴリ(エンタイトルメントなど)。

 

container dn

インストール時にユーザアプリケーションに対して定義されたコンテナの識別名。

 

description

プロビジョニング要求定義の説明。

 

group container dn

インストール時にユーザアプリケーションに対して定義されたグループコンテナの識別名。

 

id

プロビジョニング要求定義の固有IDVault ID (CN)。

 

initiator

要求を開始したユーザの識別名。

 

locale

現在のロケール。

 

name

ワークフロープロセスの名前。

 

provisioning driver dn

インストール時にユーザアプリケーションに対して定義されたプロビジョニングドライバの識別名。

 

recipient

プロビジョニング対象リソースのターゲットの識別名。

 

user container dn

インストール時にユーザアプリケーションに対して定義されたユーザコンテナの識別名。

 

requestID

プロビジョニング要求のID。

 

timestamp

プロセスが開始された時刻。

approval-activity-name

action

ユーザが実行したアクション。

addressee

承認アクティビティの現在の宛先。

 

name

アクティビティの名前。

 

timestamp

アクティビティがワークリストのキューに入った時刻。

 

user

現在のアクティビティに関連付けられているユーザ。

 

workId

現在のワークフローアクティビティのシステム生成固有ID。

form-name

custom-form-controls

ユーザによりフォームに追加されたユーザインタフェースコントロール。

フローデータ

custom-variables

ワークフローに必要なデータを保持するために作成されたカスタム変数。

インストール済みのテンプレートの1つを使用してワークフローを作成する場合は、フローデータオブジェクトに初期要求フォームのreasonフィールドからコピーされたテキストを含むreasonという変数が設定できます。

これらのオブジェクトはECMAScript式で参照できます。ワークフローのスクリプト式は、フロー内でアップストリームにバインドされているデータ項目を常に参照できます。しかし、ワークフロー式はダウンストリームで作成されるデータ項目を参照できず(その時点で該当するデータ項目は存在しないため)、並行処理をサポートするフローで他のブランチにバインドされているデータも参照できません(このブランチが現在のアクティビティと同時に実行されている可能性があるため)。

新しいデータ項目の作成

開始または承認アクティビティの[データ項目マッピング]タブに後動作ターゲット式を指定することにより、フローデータオブジェクトに新しいデータ項目を作成できます。[ターゲット式]列に新しいデータ項目の名前を指定すると、変数が自動的に作成されます。その結果、このアクティビティの後に実行したアクティビティが新しいデータ項目にアクセスできるようになります。

たとえば、[reason]というフォームフィールドをターゲット式flowdata.myReasonにマップするとします。このとき変数myReasonは、ワークフロー内で後に実行されるすべてのアクティビティが使用できる新しいデータ項目になります。

データ項目の変更

開始または承認アクティビティの[データ項目マッピング]タブに前動作の式を指定することにより、データ項目を変更できます。たとえば、ドル記号を価格にプリペンドするために、次のソース式を[Price]というターゲットフォームフィールドにマップします。

"$" + flowdata.get(’cost’)

フォームが表示されると、Priceデータが次のように示されます:

$xx.xx

別の例として、基本コストに税金を加えて総コストを計算します。そのためには、次のソース式を[TotalCost]というターゲットフォームフィールドにマップします:

Number(flowdata.get('cost')) + Number(flowdata.get('tax')) 

複雑なデータ項目マッピングの処理

フローデータオブジェクト内のすべてのデータはXML形式で保持されるため、データ項目を階層的に作成することもできます。たとえば、ユーザが買掛金勘定と売掛金勘定の2つの内部システムへのアクセスを要求できるワークフローフォームがあるとします。このフォームには、他のフィールドとともに[Acct_Pay][Acct_Rec]という名前の2つのYes/Noフィールドがあります。後動作のデータ項目マッピングで、次のように2つのマッピングを作成できます。

表 4-7 複雑なデータ項目マッピングの例

ソースフォームフィールド

ターゲット式

Acct_Pay

flowdata.SystemAccess/AcctPay

Acct_Rec

flowdata.SystemAccess/AcctRec

その結果、SystemAccessという名前のXML要素と、AcctPayおよびAcctRecという名前の2つの子要素が作成されます。このようにしてデータを構造化する1つの理由は、多くのフォームとデータ項目が含まれている複雑なワークフローで、データの編成と管理をよりわかりやすくすることにあります。この階層データからデータを取得するには、次の構文を使用します:

flowdata.get(’SystemAccess/AcctPay’).

ECMAScript式の作成の詳細については、「セクション 10.0, ECMA式の使用」を参照してください。

フォームコントロールデータのフローデータへの移動

作成したフォームコントロール(DNの表示以外)はすべて自動的に、フォームを使用するアクティビティの[データ項目マッピング]」タブの前動作、後動作の式で使用可能になります。たとえば、AACTIVITYのフォームAFORM上にあるコントロールACONTROLのユーザ入力データを後続のアクティビティで利用できるようにするとします。そのためには、ワークフローでAACTIVITYを選択し、[データ項目マッピング]タブを選択し、[後動作マッピング]ラジオボタンをクリックします。それから、ソースフォームフィールドACONTROLの横に、次の形式でターゲット式を入力します:

flowdata.my_ACONTROL

ワークフロー内の後続のすべてのアクティビティは、次のような前動作ソース式を使用して、このデータにアクセスできるようになります:

flowdata.get(’my_ACONTROL’)
flowdata.getObject(’my_ACONTROL’)

フローデータのフォームコントロールへの移動

フローデータ値をフォームコントロールに移動することもできます。最もシンプルなケースは、単一のテキスト値をフォームコントロールに移動する場合です。前に示した例で、ACONTROLが1つのテキスト入力フィールドであるとします。この場合、このフィールドをZACTIVITYというアクティビティの別のテキスト入力フィールドに移動するには、ワークフローでZACTIVITYを選択し、[データ項目マッピング]タブを選択し、[前動作マッピング]ラジオボタンをクリックします。それから、ターゲットフォームフィールドの横に、次のソース式を入力します:

flowdata.my_ACONTROL

より複雑なフォームコントロールデータ(複数値DNコントロールなど)を別のフォームコントロールに移動するには、getObject()式構文を使用できます。たとえば、ACONTROLがMultiValue DNコントロールであれば、次のソース式を使用することができます:

flowdata.getObject(’my_ACONTROL’)

データをフォームコントロールに移動する場合には、タイプの制約に注意する必要があります。たとえば、テキストベースのデータを数値コントロールに移動しようとしたり、ブール値をDNコントロールに移動しようとしたりすべきではありません。