Oracle® Fusion Middleware Content Serverアプリケーション管理者ガイド 11g リリース1 (11.1.1) B65036-01 |
|
前 |
次 |
ホーム > アプリケーション管理者ガイド > ワークフローの管理
この章では、コンテンツ・サーバーで使用可能なワークフロー機能を使用するためのタスク情報および概念とリファレンス情報を示します。
この章には次の項があります。
この項では、ワークフローの概要、使用方法およびワークフローがビジネス活動に与える利点を示します。ここで説明する内容は次のとおりです。
ワークフローは、コンテンツをレビューして承認し、システムにリリースするためのルーティング方法を指定するために使用します。
たとえば、ワークフローを使用すると、新しいポリシーを組織のイントラネットにリリースする前に、法務部、人事部および上層部の適切な担当者によるレビューと承認を確実に実行できます。また、ワークフローを設定して、社内で作成されたマーケティング・キャンペーンの承認とサインオフをタイムリに取得することもできます。ワークフロー内のコンテンツのレビュー準備が完了すると、ユーザーに電子メールで通知されます。
効果的なワークフローの設計は、反復プロセスです。ワークフローは、プロセスの実装に沿って、計画、調整および再定義されます。最初の計画が適切であれば、ワークフローが使用可能になる前に、多くの問題を回避できます。計画プロセスの詳細は、「ワークフローの計画」を参照してください。
ビジネス・プロセスにワークフローを設定すると、様々な利点が得られます。
ワークフローは、優れたレポート・メトリックを提供します。ワークフローを使用すると、コンテンツのライフ・サイクルの様々な時点でコンテンツをサインオフしたユーザーの監査証跡を作成できます。
ワークフローにより、適切な関係者に適切な情報を提供できます。
ワークフローの設計では、ビジネス・プロセスの調査と理解が必要となるため、改善可能な領域の検出に役立ちます。
長所となる要素は、同時に短所にもなります。つまり、ビジネス・プロセスを調査し、ワークフローの使用方法を計画することが必要になります。これは時間のかかるプロセスですが、それに値する価値があります。
ステップは、ワークフローのプロセスと機能を定義します。各ワークフローは、複数のレビューと通知のステップで構成され、各ステップには、コンテンツを承認または却下する複数のレビューアを割り当てることができます。ワークフローの各ステップには、一連のユーザーとステップ・タイプを定義する必要があります。
あるステップに対して定義したユーザーは、そのステップ・タイプで許可されているタスクのみを実行できます。
ワークフローが有効になると、そのワークフローは複数の特定なステージに移動します。
コンテンツ・アイテムが特定のステップの最小限のレビューアによって承認されると、そのコンテンツ・アイテムはワークフローの次のステップに進みます。
ステップに定義されている必要な承認の数が0の場合、レビューアには通知されますが、コンテンツは自動的に次のステップに進みます。これにより、ワークフロー・プロセスでアイテムが処理されていることを適切な関係者に確実に知らせることができます。
いずれかのレビューアがコンテンツを却下した場合、そのコンテンツは最新のレビュー/リビジョンの編集ステップまたはレビュー/新規リビジョンの作成ステップに戻ります。該当するステップがない場合、コンテンツは最初の作成者に戻ります。
最新のレビュー/リビジョンの編集ステップまたはレビュー/新規リビジョンの作成ステップでは、編集基準の定義方法に応じて、リビジョンが新規作成または更新されます。
リビジョンはシステムにリリースできます。
ワークフローの終了後: ワークフローの最後のステップでコンテンツが承認されると、そのコンテンツ・アイテムはシステムにリリースされます。
ワークフローの終了前: サイド・エフェクトを設定してドキュメントを編集状態からリリースすると、そのドキュメントの索引付け、検索およびアーカイブが可能になります。これは主に、経費精算書など、Webへの公開が不要なビジネス・ルーティングで役立ちます。
通常、基本ワークフローに複数のコンテンツ・アイテムが含まれている場合は、すべてのアイテムがワークフローを完了するまで、どのアイテムもシステムにリリースされません。ただし、コンテンツ・アイテムをサイド・エフェクトとして編集状態からリリースする場合、そのコンテンツ・アイテムは基本ワークフロー内のすべてのアイテムを待たずにリリースできます。
ジャンプ、トークンおよびエイリアスを使用して標準ワークフロー・プロセスをカスタマイズすると、高い柔軟性が得られます。詳細は、「ワークフローのカスタマイズ」を参照してください。
トークンおよびエイリアスを使用すると、ワークフローでユーザーを柔軟に指定できます。トークンは、不明ユーザーの指定に使用できる変数であり、エイリアスは、ユーザーのグループをワークフロー・ステップに含める際に使用できます。
ジャンプを使用すると、条件文を作成して、コンテンツが同じワークフロー内の別の経路を通過するように分岐させたり、コンテンツ・アイテムを基準ワークフローまたはサブワークフローから別の基準ワークフローまたはサブワークフローに転送することができます。
終了条件を使用すると、条件文を作成して、特定の条件に合致しないかぎり、コンテンツが次のステップに移動しないようにできます。これはワークフロー・ステップ中に、外部プロセスによってメタデータが変更される可能性がある場合に役立ちます。
カスタム・メタデータ・フィールドを作成し、それを使用して異なるワークフローをトリガーすることもできます。
次の図に、通常のワークフロー・プロセスを示します。
ワークフローの各ステップには、開始、更新および終了の3つのイベントがあります。
開始時イベント・スクリプトは、ステップに入るときに評価されます。開始時イベント・スクリプトによって、ジャンプまたは終了が発生しなかった場合は、ユーザー、エイリアスおよびトークンが評価され、電子メールで通知されます。
更新時イベント・スクリプトは、様々な時点で評価されます(たとえば、1時間ごとの更新サイクルやリビジョンのチェックインの際)。更新時イベント・スクリプトが評価されるたびに、追加の終了条件が評価されます。
終了時イベント・スクリプトは、リビジョンがステップの承認要件を完了し、ステップの追加の終了条件が満たされたときに評価されます。
ジャンプの詳細は、「ジャンプおよびイベント」を参照してください。
重要: リビジョンが却下された場合、更新時および終了時のイベント・スクリプトは実行されません。却下の際に評価するコードは、却下されたコンテンツの送信先ステップの開始時イベント・スクリプトに存在している必要があります。 |
この項では、ワークフローを開始して使用する際に作成されるファイルについて説明します。
コンパニオン・ファイルは、ワークフローのリビジョンの状態に関する情報を保持するテキスト・ファイルです。ワークフローの存続期間中にのみアクティブになります。
コンパニオン・ファイルは、リビジョンが通過したステップを追跡し、ワークフロー変数の現行の値を保持します。
ワークフローの各リビジョンには、1つのコンパニオン・ファイルがあり、リビジョンがワークフロー内にある間は存在し続けます。リビジョンがワークフローからリリースされると、対応するコンパニオン・ファイルは削除されます。
コンパニオン・ファイルは、DomainHome/ucm/cs/data/workflow/states/ディレクトリにあります。これらのファイルのフォーマットはHDAファイル・フォーマットで、コンテンツIDの名前が付けられています(例: HR_004.hda)。
各コンパニオン・ファイルには、2つのセットのデータが含まれています。
LocalDataプロパティ・セクションには、親リストおよび他のワークフロー変数が定義されています。
WorkflowActionHistory ResultSetセクションには、リビジョンのワークフロー履歴に関連のあるステップ、ワークフロー・アクションおよびユーザーのレコードが記述されています。
ワークフローからコンテンツ・アイテムがリリースされると、コンパニオン・ファイルは削除されます。コンパニオン・ファイルを保存するには、/config/config.cfgファイルにIsSaveWfCompanionFiles
構成変数を追加し、パラメータをTRUEに設定します。詳細は、Oracle Fusion Middleware Idocスクリプト・リファレンス・ガイドを参照してください。
コンパニオン・ファイルでは、キーを使用してワークフロー変数を追跡します。たとえば、次のキーは、Marketing Brochures
というワークフローにあるEditorステップのEntryCount
変数およびLast Entry
変数の値を定義します。
Editor@Marketing Brochures.entryCount=1 Editor@Marketing Brochures.lastEntryTs={ts '2001-05-02 16:57:00'}
コンパニオン・ファイルは、リビジョンが通過したステップの順序を(現行のステップから過去に遡って)リストした親リストを保持しています。親リストは、ファイルの却下、ワークフローの最後のステップの終了、またはエラーが発生した場合に戻り先のステップを決定するために使用されます。たとえば、次の親リストは、Marketing BrochuresワークフローのMarketing Teamステップ、EditorステップおよびGraphic Artistステップを示しています。
WfParentList=Marketing Team@Marketing Brochures#Editor@Marketing Brochures#Graphic Artist@Marketing Brochures#contribution@Marketing Brochures
親リストのステップ名の前にあるアスタリスク(*)は、ジャンプ・ステップを示します。
リビジョンがワークフロー・ステップに入ると、そのリビジョンは次のプロセスに移動します。
エントリ件数および最終エントリを追跡するデフォルトの開始スクリプトが更新されます。
アクション(追加のユーザー通知など)が実行されます。
ジャンプ条件が満たされ、ジャンプ先のステップが定義されている場合、リビジョンは別のステップにジャンプします。
ジャンプ条件が満たされない場合は、リビジョンを承認する準備が完了していることが現行ステップのレビューアに通知されます。
無限ループを回避するために、前にアクセスしたステップの開始スクリプトは無視されます。これに対する唯一の例外は、wfCurrentStep(0)
シンボリック・ステップを使用してステップが再開された場合です。
必要なレビューア数によってリビジョンが承認されると、終了スクリプトが評価されます。
終了スクリプトがない場合、リビジョンはワークフローの次のステップに進みます。
終了スクリプトのジャンプ条件が満たされ、ジャンプ先のステップが定義されている場合、リビジョンは別のステップにジャンプします。
終了スクリプトが評価された後は、現行アクションの状態(wfAction
ワークフロー変数)が設定されます。設定可能なアクションは次のとおりです。
APPROVE
REJECT
CHECKIN
CONVERSION
META_UPDATE
TIMED_UPDATE
RESUBMIT
リビジョンがワークフローのステップ間を移動すると、各ステップが親リストに追加されます。リビジョンがいずれかのステップに戻った場合、親リストは巻き戻され、リビジョンがそのステップを最初に利用したときの状態に戻ります。次に例を示します。
リビジョンの移動先 | 親リスト |
---|---|
Step1 | Step1 |
Step2 | Step1#Step2 |
Step3 | Step1#Step2#Step3 |
Step2 | Step1#Step2 |
リビジョンが却下された場合、親リストは最新のレビューア/コントリビュータ・ステップについて確認され、そのリビジョンはワークフローのステップに移動します。
リビジョンがワークフローの最後のステップを完了すると、親リストは、定義されているリターン・ステップを使用した最新のジャンプ・ステップについて確認されます。リターン・ステップが見つかった場合、リビジョンはそのステップに移動します。親リストにジャンプ・ステップがない場合、またはジャンプ・ステップにリターン・ステップが定義されていない場合、リビジョンはワークフローを終了します。
ワークフロー内のコンテンツ・アイテムのステータスは、次のいずれかです。
基本ワークフローに参加すると、指定されたコンテンツをチェックインする必要があるコントリビュータに電子メールが送信されます。電子メールは、ワークフローの異なるステップに関与しているレビューアにも送信されます。
ワークフローで実行するアクションは、ワークフロー・コンテンツ・アイテム・ページに表示されます。これには、「コンテンツ管理」トレイの「アクティブなワークフロー」を介してアクセスできます。レビューアは、コンテンツをレビュー、却下または承認して、コンテンツとワークフローに関する情報を表示できます。
コンテンツが却下されると、コンテンツ・アイテムの却下ページが表示されます。レビューアは、却下の理由を説明するメッセージを入力できます。このメッセージは、コントリビューションが可能な最後のステップに割り当てられているレビューアに送信されます。メッセージを受け取ったレビューアは、コンテンツをチェックアウトして編集した後、再びコンテンツをチェックインできます。コンテンツ・チェックイン・フォームの「リビジョン編集の終了」ボックスを選択する必要があります。コンテンツは、ワークフロー内の次のステップに進みます。ボックスが選択されていない場合、コンテンツは「レビュー」ステータスのままになるため、ワークフロー内を移動する前に、承認する必要があります。
優れた実践方法として、関連するユーザーにワークフローについて説明し、各ユーザーがプロセスで担当する作業を知らせておきます。ワークフローへの参加の詳細は、『Oracle Fusion Middleware Content Serverユーザーズ・ガイド』を参照してください。
この章では、ワークフロー・タイプを選択してワークフローを計画する際に実行する手順について説明します。次の内容について説明します。
ワークフローの設計を開始する前に、すでに運用しているプロセスを評価します。ワークフローに現行プロセスを適合させることもできます。たとえば、プロジェクトで、ユーザー間の情報の管理のために電子メール・ループをすでに使用している場合は、そのようなシナリオをワークフロー設計に取り込むことは可能でしょうか。
ワークフローを情報の検証のために使用しますか。コラボレーションのために使用しますか。対処する特定の問題は何ですか。現行のプロセスとその短所を理解することで、問題を解決するワークフローの設計が可能になります。
ワークフローの設計を開始するときは、次の質問を自分自身に尋ねてみてください。
ワークフローに関係するユーザーは誰ですか。アイテムのレビュー準備が完了していることを、どのユーザーに通知しますか。どのユーザーにアイテムの編集権限を付与しますか。アイテムを最終的にサインオフするのはどのユーザーですか。
同様に重要となるのは、どのユーザーをワークフローから除外するかという質問です。
ワークフローの関係者に、どのようなトレーニングを提供しますか。
ワークフロー内のアイテムをどのように処理しますか。アイテムが承認、却下または更新された場合、どのようなアクションを実行しますか。ワークフロー内にアイテムが長くとどまりすぎた場合、どのように処理しますか。
ワークフローの次のステージにアイテムをエスカレートするのはいつですか。ワークフローが完了したかどうかを決定する基準は何ですか。
ワークフローに参加する場合、ユーザーはどこにアクセスしますか。Webインタフェースを使用しますか、または独自に設計した別のインタフェースを使用しますか。
承認および却下をどのように処理しますか。監査情報を格納しますか。承認の認証(デジタル署名)のための準備は必要ですか。
使用するワークフローのタイプを決定する際は、次の事項を検討します。
特定の基準に基づいて有効になるワークフローではなく、非定型のワークフローを指定する場合。
同じ一連のステップで、複数のコンテンツ・アイテムをルーティングする場合。各アイテムは個別にステップを移動しますが、サイクルの終わりには、ワークフロー内のすべてのアイテムが終了するまでリリースされません。
ワークフローにコンテンツ・アイテムをコントリビュートするようにユーザーに通知または催促する場合。
ワークフローにアイテムを手動で送信する場合。
頻繁に使用しないワークフローを指定する場合。
基本ワークフローを使用して、一意のレビュー・プロセスを設定する場合、または関連するコンテンツ・アイテムのグループに対してレビュー・プロセスを設定する場合。
ワークフローを開始するユーザーを指定する場合。コンテンツが基本ワークフローに入ることができるのは、ワークフロー権限があるユーザーがそのワークフローを開始した場合のみです。
自動的にコンテンツをワークフローに入れる場合。
特定の基準に一致する単一のコンテンツ・アイテムをルーティングする場合。基準に一致する複数のアイテムをルーティングできますが、これらのアイテムは1つのユニットとしてワークフロー内を移動しません。
個別のドキュメントに対して標準レビュー・プロセスを設定する場合。
頻繁に使用するワークフローを指定する場合。
多数のユーザーに対してワークフローをオープンする場合。基準ワークフローには、ワークフロー権限のないユーザーのコンテンツを入れることができます。
使用するワークフローのタイプを決定する際は、次の重要事項を考慮してください。
コンテンツが間違ったセキュリティ・グループまたはメタデータ値を使用してチェックインされた場合、そのコンテンツは誤って基準ワークフローに入る可能性があります。
ユーザーが同一の基本ワークフローを使用してコンテンツを頻繁に処理する場合は、基準ワークフローを設定してプロセスの自動化を検討します。
複数のワークフローに対して、同一の基準または重複した基準を使用することはできません。コンテンツ・アイテムが複数のワークフローの基準に一致している場合、そのコンテンツ・アイテムは、リストの最初のワークフローに入ります。
ワークフローを管理するときは、セキュリティに関する次の問題を考慮してください。
各ワークフローは、セキュリティ・グループに関連付けられています。
基準ワークフローの場合は、同じセキュリティ・グループ内のコンテンツ・アイテムのみがワークフローに入ります。
基本ワークフローの場合、新しいコンテンツ・アイテムはワークフローのセキュリティ・グループに割り当てられ、既存のコンテンツ・アイテムはワークフローのセキュリティ・グループに属している必要があります。
ワークフローは、同じセキュリティ・グループに所属している別のワークフローにのみジャンプできます。
ワークフローがアクティブである間は、ワークフローのセキュリティ・グループを変更できません。ただし、現在ワークフロー・プロセス内に存在するコンテンツ・アイテムのセキュリティ・グループは変更できます。
ワークフローを設定し、ワークフロー・プロセスを開始または有効にするには、ワークフロー権限およびコンテンツ・アイテムのセキュリティ・グループに対する管理権限が必要です。
ワークフローを設定するには、ワークフロー・テンプレートを使用してコントリビューション・ステップを開始できます。
コントリビュータとしてワークフローに参加するには、そのワークフローのセキュリティ・グループに対する書込み権限が必要です。
ワークフローを設計する手順は、次のとおりです。
ワークフローのフローチャートを作成します。(たとえば、「基準ワークフロー・プロセス」や「基本ワークフロー・プロセス」のフローチャートを参照してください。)
ワークフローに必要なすべてのメタデータがあることを確認します。ない場合は、ワークフローを設定する前に、必要なメタデータを作成する必要があります。
ワークフローで必要となるエイリアスを設定します。エイリアスの作成は、『Oracle Fusion Middleware Content Serverシステム管理者ガイド』を参照してください。
ワークフローで必要となるトークンを設定します。詳細は、「トークンの作成」を参照してください。
基本ワークフローまたは基準ワークフローを設定します。使用可能なワークフロー・テンプレートがある場合は、テンプレートを手掛かりとして使用できます。詳細は、「ワークフローおよびスクリプトのテンプレート」を参照してください。
必要に応じて、サブワークフローを設定します。
必要に応じて、ジャンプを設定します。詳細は、「ジャンプの設定」を参照してください。
使用可能なスクリプト・テンプレートがある場合は、それを使用してステップ・イベント・スクリプトを作成します。
ジャンプを使用する場合は、各ジャンプのサブワークフローを備えた「マスター」ワークフローの設定を検討してください。
ワークフローをテストします。
基準ワークフローの場合は、定義したセキュリティ・グループおよびメタデータ・フィールド値に一致するテスト用のドキュメントをチェックインします。
基本ワークフローの場合は、テスト用のコンテンツを定義し、ワークフローを開始します。
できるだけ多数の承認/却下シナリオをシミュレーションします。
ワークフローにジャンプが含まれている場合は、できるだけ多数のイベント・シナリオをシミュレーションします。
ワークフローのテストにレビューアを含めて、ユーザーが各自の役割を理解していることを確認します。
ワークフローを作成した後は、ワークフローの一部の側面を変更できますが、その他の変更はできません。ステップを追加または削除するために、基準ワークフローを無効にしたり、基本ワークフローを取り消した場合、ワークフロー内のコンテンツはリリース(基準)または削除(基本)されます。
ワークフローを設計する際は、次の点に留意してください。
次の操作を実行できます。
基準ワークフローの基準の変更。
基本ワークフローのコンテンツ・アイテムの追加または削除。
ステップの定義の変更(レビューア、終了条件、イベントなど)。
次の操作は実行できません。
ステップの順序の変更。ただし、ステップを削除して、別の場所に再作成することは可能です。
ワークフローの中心部へのステップの追加(新しいステップは常にワークフローの最後に追加されます)。
次に、既存ワークフローの変更に役立つヒントを示します。これらの処理の複雑さは、ワークフローを実装する前には、設計での十分な注意が必要であることを示しています。使用中のワークフローの変更は、時間のかかる困難な作業になる可能性があります。
既存ワークフローで、ステップの順序を変更する必要がある場合は、次のオプションを検討してください。
サブワークフローを作成し、既存ステップからそのサブワークフローへのジャンプを追加します。(詳細は、「ジャンプについて」を参照してください。)この変更を既存ステップに加えるために、ワークフローを無効化または取り消す必要はありません。このオプションは、ワークフローの無効化または取消しが可能になり、必要に応じて再構築できるまでの一時的な処置として考慮してください。
既存ステップにステップ・イベント・スクリプトを追加して、通常は別のステップで実行されるアクションを定義します。(詳細は、「ジャンプおよびイベント」を参照してください。)この変更を既存ステップに加えるために、ワークフローを無効化または取り消す必要はありません。このオプションは、ワークフローの無効化または取消しが可能になり、必要に応じて再構築できるまでの一時的な処置として考慮してください。
変更(たとえば、ステップの追加)するために、ワークフローの無効化が必要になった場合は、すべてのコンテンツがワークフローから即時にリリースされます。
コンテンツをリリースせずにワークフローを無効化するには、最初に、そのワークフローを、ステップの順序は元のワークフローと同じだが、ステップ・ロジックがない静的なワークフローにクローニングします。コンテンツはいずれかのステップに入り、移動されるまでそこにとどまります。
次に、元のワークフローに更新時イベントを作成します。このイベントは時間でトリガーされ、適切なステップでコンテンツを静的なクローン・ワークフローにプッシュします。
元のワークフローにコンテンツがない場合、そのワークフローは無効にして必要な変更を加え、再び有効にできます。次に、同じ時限イベント・ロジックを使用して、クローン・ワークフローのコンテンツを元のワークフローに戻します。
基準ワークフローでは、個別のドキュメントの標準レビュー・プロセスを設定します。事前定義済の基準に一致すると、自動的にワークフローに入るコンテンツのレビュー・プロセスを定義します。たとえば、新しい注文書が生成されたときは、その注文書を特定のレビューアに自動的にルーティングして承認を得ることができます。
基準ワークフローには、次のものが含まれます。
セキュリティ・グループと1つのメタデータ・フィールドによって定義された基準。
事前定義済ユーザーのない自動コントリビューション・ステップ。
1つ以上のレビューア・ステップ(1ステップ当たりのレビューア数は1人以上)。
サブワークフローは、初期コントリビューション・ステップのないワークフローです。サブワークフローは、大規模で複雑なワークフローを管理可能なピースに分割する場合に役立ちます。
基準ワークフローからのジャンプによってのみ、コンテンツはサブワークフローに入ることができます。
この項では、次の項について説明します。
概念
タスク
いくつかの例外はありますが、サブワークフローの設定手順は、基準ワークフローと同じです。これらの例外は、基準ワークフローの設定手順で説明します。
次の手順に従って、基準ワークフロー・プロセスを簡潔に説明します。
ワークフロー権限があるユーザーが、次の要素を定義して基準ワークフローを設定します。
セキュリティ・グループ。
メタデータ・フィールドおよび値(たとえば、「ContentType」「次に一致する」「PurchaseOrder」)。
レビュー・ステップおよび各ステップのレビューア。
各ステップに必要な承認の数。たとえば、次のステップに進む前に、すべてのレビューアの承認が必要かどうか。
ユーザー・グループをエイリアスに含める必要がある場合またはトークンを設定する必要がある場合は、それらのタスクを事前に実行しておきます。
ワークフロー権限があるユーザーが、基準ワークフローを有効化して、開始します。
定義されたセキュリティ・グループとメタデータ・フィールド値を持つコンテンツがチェックインされると、そのコンテンツがワークフローに入ります。
リビジョンのレビュー準備が完了していることが、最初のステップのレビューアに電子メールで通知されます。
レビューアがリビジョンを承認または却下します。
レビューア/コントリビュータ・ステップの場合、レビューアはリビジョンをチェックアウトして編集し、チェックインして戻してから、リビジョンを承認できます。たとえば、編集者によるワークフロー内のコンテンツ・アイテムの変更が必要になる場合もあります。
ユーザーがリビジョンを却下した場合、ワークフローは前のコントリビューション・ステップに戻り、そのステップのユーザーには電子メールで通知されます。
リビジョンが最小限のユーザー数によって承認された場合、そのリビジョンは次のステップに進みます。(最低承認数が0の場合、リビジョンは自動的に次のステップに進みます。)
すべてのステップが完了すると、リビジョンはシステムにリリースされます。
各基準ワークフローには、一意の基準が必要です。コンテンツ・アイテムが2つの異なるワークフローの基準に一致している場合、そのコンテンツ・アイテムはワークフロー定義リストの最初のワークフローに入ります。
基準ワークフローに割り当てられたすべてのユーザーには、選択されたセキュリティ・グループに対する読取り権限が必要です。コントリビュータがリビジョンをチェックインおよびチェックアウトするには、選択されたセキュリティ・グループに対する書込み権限が必要です。
基準ワークフローが有効である間は、ステップの追加や削除はできません。
基準ワークフローが無効なときにチェックインされたコンテンツ・アイテムは、ワークフロー・プロセスをバイパスしてシステムにリリースされます。
基準ワークフローを無効にすると、ワークフロー・プロセス内にあるリビジョンはシステムにリリースされます。
基準ワークフローでは、サブワークフローおよび同じセキュリティ・グループ内の他の基準ワークフローへのジャンプを使用することも、同じワークフローの他のステップにジャンプすることもできます。
ワークフローに少なくとも1つのレビューア/コントリビュータ・ステップが作成されていると、却下されたリビジョンは、最初の作成者ではなく、そのステップに戻されます。
基準ワークフローを設定する際は、次の点に留意してください。
ワークフローに割り当てるすべてのユーザーには、選択されたセキュリティ・グループに対する読取り権限が必要で、コントリビュータには、書込み権限が必要です。チェックインしたアイテムのセキュリティ・グループが、ワークフローのセキュリティ・グループと一致しない場合、そのアイテムはワークフローに入りません。
ワークフローを設定する前に、エイリアスおよびトークンを定義しておきます。
テンプレートを使用する場合は、選択したテンプレートのレビューアを使用できます。
使用する基準が、他の基準ワークフローと同じでないことを確認します。コンテンツ・アイテムが2つの異なるワークフローの基準に一致している場合、そのコンテンツ・アイテムは、ワークフロー・リストの最初のワークフローに入ります。
「フィールド」で「コンテンツID」を選択し、かつ、コンテンツ・サーバーでOracleデータベースを使用する場合、値はすべて大文字で入力する必要があります。他のすてべのフィールドでは、大文字と小文字の両方を使用できます。
また、「フィールド」で「コンテンツID」を選択した場合は、「値」フィールドの下の「選択」をクリックして、既存のコンテンツ・アイテムを選択できます。
「レビューアの最低必要人数」フィールドにゼロ(0)を入力すると、リビジョンがステップに到達したときに、レビューアに通知されますが、そのステップではリビジョンの承認、却下、編集はできません。ワークフローは自動的に次のステップに進みます。
基準ワークフローまたはサブワークフローを作成するには、次の手順に従います。
「ワークフロー管理」アプレットから「ワークフロー管理」: 「条件」タブを表示します。
「追加」をクリックします。
「新しい基準ワークフロー」/「基準ワークフローの編集」画面が表示されます。
「ワークフロー名」フィールドに名前を入力します。ワークフロー名の最大フィールド長は30文字で、特殊文字(; @ &など)を含めることはできません。ワークフローを作成した後でワークフロー名を変更することはできません。
「説明」フィールドに、ワークフローの詳細を入力します。
リストからセキュリティ・グループを選択します。これは、ワークフローのコンテンツ・アイテムが属しているセキュリティ・グループです。
「元の作成者の編集ルール」から、オプションを選択します。コンテンツ・アイテムが却下された場合は、最初の作成者に既存リビジョンの編集を許可するか、新規リビジョンの作成を許可するかを指定します。
ワークフロー・テンプレートを使用する場合は、「テンプレートの使用」チェック・ボックスを選択し、テンプレート名を選択します。このチェック・ボックスは、現在テンプレートが存在する場合にのみ表示されます。詳細は、「ワークフローおよびスクリプトのテンプレート」を参照してください。
ワークフローのタイプを決定します。
基準ワークフローを作成するには、「条件定義を設定する」チェック・ボックスを選択します。
サブワークフローを作成するには、「条件定義を設定する」チェック・ボックスの選択を解除します。
ワークフローのタイプは、後で「条件定義を設定する」チェック・ボックスを選択または選択を解除して変更できます。
基準ワークフローの場合は、「フィールド」、「演算子」および「値」で適切な値を選択して基準を定義します。たとえば、「Review Process」「次に一致する」「HRBenefits」のような基準になります。
「OK」をクリックします。
ステップの作成にテンプレートを使用しなかった場合、または別のステップを追加する場合は、「ワークフロー管理」画面の右側のペインで、「追加」をクリックします。「新しいステップの追加」/「ステップの編集」画面が表示されます。
「名前」および「説明」に、ステップの適切な名前および説明を入力します。ステップを作成した後で名前を変更することはできません。ステップには、通常、わかりやすい名前を付けます(たとえば、EditorialReviewやTechnicalReviewなど)。
このステップのユーザーの認可レベルを指定します。
ユーザーは現在のリビジョンをレビューできます: ユーザーはリビジョンを承認または却下できますが、リビジョンの編集はできません。
ユーザーは現在のリビジョンをレビューおよび編集(置換)できます: ユーザーはリビジョンを編集、承認または却下できます。編集によってコンテンツ・アイテムのリビジョンは更新されません。
ユーザーは現在のリビジョンをレビューするか、新規リビジョンを作成できます: ユーザーはリビジョンを編集、承認または却下できます。編集すると、コンテンツ・アイテムのリビジョンが更新されます。元のコンテンツは保持され、変更の監査証跡が提供されます。
ステップに追加するユーザーのタイプを選択します。1つのステップに複数のユーザー・タイプを定義できます。
エイリアスで定義されたユーザー・グループを追加するには、「エイリアスの追加」をクリックします。「ステップへのエイリアスの追加」画面が表示されます。表示されたリストから、エイリアスを選択します。
個々のユーザー・ログインを追加するには、「ユーザーの追加」をクリックします。「ステップへのユーザーの追加」が表示されます。
ユーザー・リストを絞り込むには、「フィルタの使用」チェック・ボックスを選択し、「フィルタの定義」をクリックし、フィルタ基準を選択して「OK」をクリックします。
複数のユーザーを範囲選択するには、一人のユーザーをクリックし、[Shift]キーを押しながら他のユーザー名をクリックします。
ユーザーを個別に選択するには、[Ctrl]キーを押しながら各ユーザー名をクリックします。
トークンで定義した可変ユーザーを追加するには、「トークンの追加」をクリックします。「ステップへのトークンの追加」画面が表示されます。トークンの作成の詳細は、「トークンの作成」を参照してください。
「OK」をクリックします。
「終了条件」タブをクリックします。
リビジョンが次のステップに進むには、何人のレビューアの承認が必要であるかを指定します。
すべてのレビューアの承認が必要な場合は、「すべてのレビューア」を選択します。
リビジョンを承認する必要がある最小限のレビューア数を指定するには、「レビューアの最低必要人数」を選択し、数値を入力します。
通常、終了条件は、ワークフロー・ステップ中にコンテンツが外部プロセスによって変更される可能性がある場合に役立ちます。次のステップに進むために、ステップに終了条件を追加する必要がある場合は、次の手順を使用してください。
「追加終了条件を使用」チェック・ボックスを選択します。
「編集」をクリックします。
「追加終了条件の編集」画面が表示されます。この画面では、オプション・リストから、追加の基準を選択できます。
「フィールド」オプション・リストから、ワークフロー条件またはメタデータ・フィールドを選択します。
「演算子」オプション・リストから、演算子を選択します。これは、「フィールド」に関連する演算子を示す依存選択リストです。
「値」オプション・リストから値を選択します。このリストは、「フィールド」で選択したオプションに基づいた依存リストです。
「追加」をクリックして「条件句」に条件文を追加します。「条件句」ボックスに、句が表示されます。AND
文を使用して複数の句を追加できます。
必要な条件の数に応じて繰り返します。式を変更するには、「条件句」ボックスで式を選択して、「フィールド」、「演算子」または「値」を変更し、「更新」をクリックします。
条件式を変更するには、「カスタム条件の式」チェック・ボックスを選択し、スクリプトを編集します(たとえば、条件にAND
ではなくOR
を使用するなど)。追加終了条件は、trueまたはfalseに評価されるIdocスクリプト文である必要があります。コードをIdocスクリプトのタグ<$ $>
で囲まないでください。
注意: 「カスタム条件の式」チェック・ボックスの選択を解除すると、式は元の定義に戻り、すべての変更が失われます。 |
「OK」をクリックします。
ワークフローに条件付ステップまたは特別な処理が必要な場合は、「イベント」タブをクリックし、適切なスクリプトを追加してください。詳細は、「ジャンプの設定」を参照してください。
「OK」をクリックします。
必要に応じてステップを追加、編集および削除して、ワークフローを完成します。
左側のペインで、正しいワークフローが選択されていることを確認し、「有効化」をクリックします。
確認画面が表示されます。
「はい」をクリックして選択されたワークフローをアクティブにします。
既存の基準ワークフローまたはサブワークフローを変更する手順は、次のとおりです。
「ワークフロー管理」: 「条件」タブを表示します。
左側のペインで、変更するワークフローを選択します。
ステップを追加または削除する場合は、ワークフローを無効にします。
左右のペインの「追加」、「編集」および「削除」ボタンを使用して、次の情報を変更します。
ワークフローの説明
セキュリティ・グループ
ワークフローのタイプ(基準ワークフローまたはサブワークフロー)
基準
ステップの説明
ステップのタイプ(レビューア、コントリビュータの同じリビジョン、コントリビュータの新規リビジョン)
ユーザー
イベント
必要な承認数
終了条件
基準ワークフローが有効なときはユーザーをステップに追加できますが、ワークフローのそのステップにリビジョンが現存している場合は、新しいユーザーに通知が即座に送信されません。通知は、スケジュールされたワークフロー・システム・イベントが発生した時点で送信されます。これにより、ワークフロー内のすべてのアイテムに対してTIMED_UPDATE
が行われます。
ワークフローが無効な場合は、左側のペインで、正しいワークフローが選択されていることを確認し、「有効化」をクリックします。
確認画面が表示されます。
「はい」をクリックして選択されたワークフローをアクティブにします。
基準ワークフローまたはサブワークフローを無効にする手順は、次のとおりです。
「ワークフロー管理」: 「条件」タブを表示します。
ワークフローを選択します。
「無効化」をクリックします。
現在ワークフロー・プロセスにコンテンツ・アイテムが存在している場合は、コンテンツのすべてのリビジョンがリリースされることが通知されます。コンテンツをリリースしない場合は、「いいえ」をクリックします。
「はい」をクリックしてワークフローを無効化します。
ワークフローのステータスが「無効」に変更されます。
基本ワークフローは、特定のコンテンツ・アイテムのレビュー・プロセスを定義します。ワークフローに入るコンテンツの基準を定義する必要がないという点で、基準ワークフローと異なります。基本ワークフローは、手動で設定および開始します。
基本ワークフローには、次のものが含まれます。
1つ以上のコンテンツ・アイテム。
1人以上のコントリビュータを伴う初期コントリビューション・ステップ。
0以上のレビュー・ステップ(1ステップ当たりのレビューア数は0人以上)。
この項では、次の項について説明します。
ワークフロー権限があるユーザーが、次の項目を定義して基本ワークフローを設定します。
コンテンツ: 新しいコンテンツの作成または既存コンテンツの選択(あるいはその両方)が可能です。ワークフローでの処理が終わると、新しいコンテンツはリビジョン1でシステムにリリースされ、既存のコンテンツはそのコンテンツ・アイテムの次のリビジョン番号でシステムにリリースされます。
最初のコントリビュータ。
レビュー・ステップ、各ステップのレビューアおよび各ステップに必要な承認数。
ワークフロー権限があるユーザーが、基本ワークフローを有効化し、開始します。
コントリビュータに電子メールが送信されます。
コントリビュータは、ワークフローの各コンテンツ・アイテムのファイルをチェックアウトし、再びチェックインできます。
リビジョンのレビュー準備が完了していることが、最初のステップのレビューアに電子メールで通知されます。
レビューアがリビジョンを承認または却下します。
このステップで編集が許可されている場合、レビューアはリビジョンをチェックアウトして編集し、チェックインして戻してから、リビジョンを承認できます。
ユーザーがリビジョンを却下した場合、そのリビジョンは前のコントリビューション・ステップに戻り、そのステップのユーザーに電子メールで通知されます。
リビジョンが最小限のユーザー数によって承認された場合、そのリビジョンは次のステップに進みます。(最低承認数が0の場合、リビジョンは自動的に次のステップに進みます。)
通常、基本ワークフローに複数のファイルが含まれている場合は、すべてのファイルがワークフローを完了するまで、どのファイルもシステムにリリースされません。最後のリビジョンが承認されるまで、完了したコンテンツ・アイテムは「保留」ステータスになります。ただし、コンテンツ・アイテムをサイド・エフェクトとして編集状態からリリースする場合、そのコンテンツ・アイテムは基本ワークフロー内のすべてのアイテムを待たずにリリースできます。
すべてのステップが完了し、すべてのリビジョンが承認されると、それらのリビジョンはシステムにリリースされます。
新しいコンテンツの場合、ワークフローで定義されたコンテンツIDは、リビジョンがシステムにリリースされるときに適用されるコンテンツIDです。作成後にコンテンツIDを変更することはできません。
コンテンツ・アイテムを複数の基本ワークフローに追加することはできません。エラー・メッセージが表示され、ワークフローは有効になりません。
新しいコンテンツは、基本ワークフローのセキュリティ・グループに割り当てられます。
既存リビジョンのセキュリティ・グループは、基本ワークフローのセキュリティ・グループと一致している必要があります。
基本ワークフローに割り当てられたすべてのユーザーには、選択されたセキュリティ・グループに対する読取り権限が必要です。コントリビュータがリビジョンを編集するには、選択されたセキュリティ・グループに対する書込み権限が必要です。
基本ワークフローがアクティブである間は、レビュー・ステップを追加、編集または削除できません。
アクティブなワークフローの取消しは可能ですが、そのワークフロー内のリビジョンはシステムから削除されます。ファイルに対する編集内容は、ローカル・ハード・ドライブにも保存されていないかぎり、失われます。
非アクティブな基本ワークフローは再利用できますが、常に手動で開始する必要があります。
基本ワークフローではジャンプを使用できますが、ジャンプ先は、同じワークフロー内の別のステップのみです。基本ワークフローでは、サブワークフローにジャンプできません。
基本ワークフローを作成する前に、次の点に留意してください。
ワークフローに割り当てるすべてのユーザーには、選択されたセキュリティ・グループに対する読取り権限が必要で、コントリビュータには、書込み権限が必要です。
テンプレートを使用する場合、レビューアが、選択したテンプレートに定義されているレビューアと異なる場合は、レビューアを変更する必要があります。
コンテンツ・アイテムを複数の基本ワークフローに追加しないでください。エラーが発生し、ワークフローは有効になりません。
「レビューアの最低必要人数」フィールドにゼロ(0)を入力すると、リビジョンがステップに到達したときに、レビューアに通知されますが、そのステップではリビジョンの承認、却下、編集はできません。ワークフローは自動的に次のステップに進みます。
「ワークフロー管理」: 「ワークフロー」タブを表示します。このタブには、基本ワークフローがデフォルトで表示されます。
「追加」をクリックします。
「新しいワークフローの追加」/「ワークフローの編集」画面が表示されます。
「ワークフロー名」フィールドに名前を入力します。ワークフロー名の最大フィールド長は30文字で、特殊文字(; @ &など)を含めることはできません。ワークフローを作成した後で「ワークフロー名」を変更することはできません。
「説明」フィールドに、ワークフローの詳細を入力します。
リストからセキュリティ・グループを選択します。これは、ワークフローのコンテンツ・アイテムが属しているセキュリティ・グループです。
「元の作成者の編集ルール」から、オプションを選択します。コンテンツ・アイテムが却下された場合は、最初の作成者に既存リビジョンの編集を許可するか、新規リビジョンの作成を許可するかを指定します。
テンプレートを使用する場合は、「テンプレートの使用」チェック・ボックスを選択し、テンプレート名を選択します。このボックスは、テンプレートが存在する場合にのみ表示されます。詳細は、「ワークフローおよびスクリプトのテンプレート」を参照してください。
「OK」をクリックします。
ワークフローに新しいコンテンツ・アイテムを追加するには、「新規」をクリックします。
「ワークフローへのコンテンツの追加」(新しいコンテンツ)画面が表示されます。
新しいコンテンツ・アイテムのコンテンツIDを入力します。コンテンツを作成した後でコンテンツIDを変更することはできません。コンテンツIDを変更するには、リストからコンテンツ・アイテムを削除して、新しいコンテンツ・アイテムを追加します。Oracleデータベースを使用している場合、コンテンツIDはすべて自動的に大文字に変換されます。
「OK」をクリックします。
ワークフローに既存のコンテンツ・アイテムを追加するには、「選択」をクリックします。
「ワークフローへのコンテンツの追加」(既存のコンテンツ)画面が表示されます。
コンテンツ・アイテムのリストを絞り込むには、フィルタまたはリリース日付(あるいはその両方)の基準を指定します。
複数のコンテンツ・アイテムを範囲選択するには、1つのアイテムをクリックし、[Shift]キーを押しながら他のアイテムをクリックします。
コンテンツ・アイテムを個別に選択するには、[Ctrl]キーを押しながら各アイテムをクリックします。
既存のコンテンツ・アイテムのセキュリティ・グループは、ワークフローのセキュリティ・グループと同じである必要があります。
初期コントリビューション・ステップのコントリビュータを1人以上定義します。1つのコントリビューション・ステップに複数のユーザー・タイプを定義できます。
エイリアスで定義されたユーザー・グループを追加するには、「エイリアスの追加」をクリックします。「ワークフローへのエイリアスの追加」画面が表示されます。
個々のユーザー・ログインを追加するには、「ユーザーの追加」をクリックします。「ユーザーの追加」: 基本ワークフロー画面が表示されます。
ユーザー・リストを絞り込むには、「フィルタの使用」チェック・ボックスを選択し、「フィルタの定義」をクリックし、フィルタ基準を選択して「OK」をクリックします。
複数のユーザーを範囲選択するには、一人のユーザーをクリックし、[Shift]キーを押しながら他のユーザーをクリックします。
ユーザーを個別に選択するには、[Ctrl]キーを押しながら各ユーザーをクリックします。
レビュー・ステップの作成にテンプレートを使用しなかった場合、または別のステップを追加する場合は、右側のペインで、「ステップ」ボックス付近にある「追加」をクリックします。
「新しいステップの追加」/「ステップの編集」画面が表示されます。
「名前」および「説明」に、ステップの適切な名前および説明を入力します。ステップを作成した後で名前を変更することはできません。ステップには、わかりやすい名前を使用します(たとえば、CopyEditReviewやFinalApprovalなど)。
このステップのユーザーの認可レベルを指定します。
ユーザーは現在のリビジョンをレビューできます: ユーザーはリビジョンを承認または却下できます。
ユーザーは現在のリビジョンをレビューおよび編集(置換)できます: ユーザーはリビジョンを編集、承認または却下できます。編集によってコンテンツ・アイテムのリビジョンは更新されません。
ユーザーは現在のリビジョンをレビューするか、新規リビジョンを作成できます: ユーザーはリビジョンを編集、承認または却下できます。編集すると、コンテンツ・アイテムのリビジョンが更新されます。元のコンテンツは保持され、変更の監査証跡が提供されます。
ステップに追加するユーザーのタイプを選択します。1つのステップに複数のユーザー・タイプを定義できます。
エイリアスで定義されたユーザー・グループを追加するには、「エイリアスの追加」をクリックします。「ステップへのエイリアスの追加」画面が表示されます。
個々のユーザー・ログインを追加するには、「ユーザーの追加」をクリックします。「ユーザーの追加」: 基本ワークフロー画面が表示されます。リストを絞り込むには、「フィルタの使用」チェック・ボックスを使用します。複数のユーザーを範囲選択するには、一人のユーザーをクリックし、[Shift]キーを押しながら他のユーザー名をクリックします。ユーザーを個別に選択するには、[Ctrl]キーを押しながら各ユーザー名をクリックします。
トークンで定義した可変ユーザーを追加するには、「トークンの追加」をクリックします。「トークンの追加」: 基本ワークフロー画面が表示されます。詳細は、「トークンの作成」を参照してください。
「終了条件」タブをクリックします。
リビジョンが次のステップに進むには、何人のレビューアの承認が必要であるかを指定します。
すべてのレビューアの承認が必要な場合は、「すべてのレビューア」を選択します。
リビジョンを承認する必要がある最小限のレビューア数を指定するには、「レビューアの最低必要人数」を選択し、数値を入力します。
通常、終了条件は、ワークフロー・ステップ中にコンテンツが外部プロセスによって変更される可能性がある場合に役立ちます。次のステップに進むために、ステップに終了条件を追加する必要がある場合は、次の手順を使用してください。
「追加終了条件を使用」チェック・ボックスを選択します。
「編集」をクリックします。
「追加終了条件の編集」画面が表示されます。この画面では、オプション・リストから、追加の基準を選択できます。
「フィールド」オプション・リストから、ワークフロー条件またはメタデータ・フィールドを選択します。
「演算子」オプション・リストから、演算子を選択します。これは、「フィールド」に関連する演算子を示す依存オプション・リストです。
「値」オプション・リストから値を選択します。このリストは、「フィールド」で選択したオプションに基づいた依存リストです。
「追加」をクリックして「条件句」に条件文を追加します。「条件句」ボックスに、句が表示されます。AND
文を使用して複数の句を追加できます。
必要な条件の数に応じて繰り返します。式を変更するには、「条件句」ボックスで式を選択して、「フィールド」、「演算子」または「値」を変更し、「更新」をクリックします。
条件式を変更するには、「カスタム条件の式」チェック・ボックスを選択し、スクリプトを編集します(たとえば、条件にAND
ではなくOR
を使用するなど)。追加終了条件は、trueまたはfalseに評価されるIdocスクリプト文である必要があります。コードをIdocスクリプトのタグ<$ $>
で囲まないでください。
注意: 「カスタム条件の式」チェック・ボックスの選択を解除すると、式は元の定義に戻り、すべての変更が失われます。 |
「OK」をクリックします。
ワークフローに条件付ステップまたは特別な処理が必要な場合は、「イベント」タブをクリックし、適切なスクリプトを追加してください。詳細は、「ワークフローのカスタマイズ」を参照してください。
「OK」をクリックします。
必要に応じてステップを追加、編集および削除して、ワークフローを完成します。
左側のペインで、正しいワークフローが選択されていることを確認し、「開始」をクリックします。
「ワークフローの開始」画面が表示されます。
コントリビュータに送信するメッセージを入力します。
「OK」をクリックします。
既存の基本ワークフローを変更する手順は、次のとおりです。
「ワークフロー管理」: 「ワークフロー」タブを表示します。
左側のペインで、変更するワークフローを選択します。
アクティブなワークフローのワークフロー・セキュリティ・グループまたはレビュー・ステップ数を変更するには、最初に「取消」をクリックしてワークフローを取り消す必要があります。
ワークフローの説明またはセキュリティ・グループを変更するには、左側のペインで「編集」をクリックします。
ワークフローのコンテンツを追加または削除するには、「コンテンツ」ペインの「新規」、「選択」および「削除」ボタンを使用します。
初期コントリビューション・ステップのコントリビュータを追加または削除するには、「コントリビュータ」ペインの「エイリアスの追加」、「ユーザーの追加」および「削除」ボタンを使用します。
注意: コンテンツ・アイテムは、基本ワークフローの開始後に変更できますが、コントリビュータには自動的に通知されません。コントリビュータも基本ワークフローの開始後に変更できますが、通知は、新しいコントリビュータに即座に送信されません。 |
「ステップ」ペインの「追加」、「編集」および「削除」ボタンを使用して、次の情報を変更します。
ステップの説明
ステップのタイプ(レビューアまたはレビューア/コントリビュータ)
ユーザー
イベント
必要な承認数
終了条件
ワークフローは、トークンおよびジャンプを使用して、様々なビジネス・シナリオに応じてカスタマイズできます。トークンはワークフロー可変ユーザーを定義し、ジャンプは、別のサイド・エフェクトへのワークフローの分岐に使用できます。
この項では、トークンおよびジャンプの設定方法と使用方法について説明します。ここで説明する内容は次のとおりです。
ジャンプおよびトークンは、Idocスクリプトを使用して作成されます。トークンおよびジャンプを作成すると、適切な構文および使用方法がインタフェースにより作成されます。ただし、スクリプトは、次のIdocスクリプト関数を使用してカスタマイズできます。使用方法の詳細は、Oracle Fusion Middleware Idocスクリプト・リファレンス・ガイドを参照してください。
Idocスクリプトの関数:
wfAddUser
: ワークフローのレビューア・リストにユーザー、エイリアスまたはワークフロー・トークンを追加します。これはトークン内でのみ使用できます。
wfLoadDesign
: ワークフローの既存ステップまたはワークフローの終了条件に関する情報を取得するために使用します。
wfReleaseDocument
: 現在ワークフローによってロックされているドキュメントについて、ワークフローにすべての未処理のドキュメント・リビジョンをリリースさせます。
Idocスクリプトの変数:
トークンは、次の操作に使用できます。
ワークフローの実行時に、特定のユーザーまたはユーザーのクラスとして解釈される変数をワークフローに追加します。
ワークフローのジャンプにユーザーおよびエイリアスを指定します。
条件文を使用してユーザーを定義します。
トークンの割当ては、ワークフローの各ドキュメントに対して一意であり、ローカルに行われます。1つのドキュメントのトークンの割当てに使用するロジックが、ワークフローの別のドキュメントに影響を与えることはありません。
ワークフロー管理アプリケーションには、いくつかのサンプル・ワークフロー・トークンが付属しています。これらのサンプルは、そのまま使用することも、独自のワークフロー・トークンを作成するために変更することもできます。これらのトークンは、コンテンツ・サーバーで使用できます。
重要: トークンが有効なユーザー名に解決されない場合、そのトークンは無視されます。ステップに有効なユーザーが定義されていない場合、リビジョンはワークフローの次のステップに移動します。このため、各ステップには少なくとも1つのユーザーを定義することをお薦めします。 |
トークンのIdocスクリプト関数wfAddUser
は、2つのパラメータを取ります。
User: 最初のパラメータは、メタデータ・フィールド、エイリアス、またはユーザー名かエイリアスに解決される変数です。
Type: 2番目のパラメータは、トークンのタイプ(ユーザーまたはエイリアス)です。
Idocスクリプトのすべてのコマンドは、デリミタ<$
で始まり、$>
で終わります。次に例を示します。
<$wfAddUser(dDocAuthor, "user")$> <$wfAddUser("MktTeam", "alias")$> <$wfAddUser("myUserList", "alias")$>
Idocスクリプトの構文および使用方法の詳細は、Oracle Fusion Middleware Idocスクリプト・リファレンス・ガイドを参照してください。
トークンを作成するには、次の手順に従います。
ワークフロー管理アプリケーションで、「オプション」メニューから「トークン」を選択します。
「ワークフロー・トークン」画面が表示されます。
「追加」をクリックします。
「トークンの追加」/「トークンの編集」画面が表示されます。
「トークン名」フィールドにトークン名を入力します。トークンを作成した後で「トークン名」を変更することはできません。トークンには、わかりやすい名前を使用します(たとえば、GetOriginalAuthorやAuthorManagerなど)。
「説明」フィールドに、詳細を入力します。
「追加」をクリックします。
「トークン・ユーザーの追加」画面が表示されます。
「ユーザー」または「エイリアス」を選択します。
メタデータ・フィールドを入力します。
コンテンツ・アイテムの最初の作成者を指定するには、dDocAuthorと入力します。
エイリアスを指定するには、エイリアスを正確に入力します。定義済のエイリアスのリストは、「ユーザー管理」画面の画面エイリアスタブを参照してください。
「OK」をクリックします。「ユーザー」ウィンドウに、指定した値を含むIdocスクリプトが表示されます。
条件付きトークンを作成するには、「ユーザー」フィールドを編集します。
「OK」をクリックします。
既存のワークフロー・トークンを変更する手順は、次のとおりです。
ワークフロー管理アプリケーションで、「オプション」メニューから「トークン」を選択します。
「ワークフロー・トークン」画面が表示されます。
変更するトークンを選択します。
「編集」をクリックします。
「トークンの追加」/「トークンの編集」画面が表示されます。
必要に応じて、トークン・スクリプトを編集します。詳細は、「ジャンプについて」を参照してください。
「OK」をクリックします。
ワークフロー・トークンを変更する手順は、次のとおりです。
ワークフロー管理アプリケーションで、「オプション」メニューから「トークン」を選択します。
「ワークフロー・トークン」画面が表示されます。
削除するトークンを選択します。
「削除」をクリックします。
確認画面が表示されます。
「はい」をクリックします。
次の例は、ワークフローでのトークンの使用方法を示しています。
例4-1 最初の作成者が唯一のコントリビュータ
この例は、最初の作成者が、ファイルの唯一のコントリビュータであることを前提にしています。例4-2は、ワークフロー・プロセス中に、異なる作成者がファイルをチェックアウトし、チェックインする状況に対処しています。
コンテンツがワークフローからシステムにリリースされたときは、各ファイルの最初の作成者に通知する必要があるとします。最初に、IdocスクリプトでdDocAuthor
と呼ばれる、「作成者」メタデータ・フィールドに対応するトークンを作成します。ワークフローを設定するときは、通知ステップ(必要な承認数は0)を作成し、そのステップのユーザーとしてトークンを選択できます。このトークン・スクリプトは、次の例のようになります。
<$wfAddUser(dDocAuthor, "user")$>
例4-2 レビューア/コントリビュータ・ステップを備えたワークフロー
ワークフローにレビューア/ コントリビュータ・ステップが含まれている場合は、最初のコントリビュータ以外のユーザーが、変更したファイルをチェックインした可能性があるため、dDocAuthor
は最初の作成者であるとはかぎりません。この場合は、カスタム・スクリプトを最初のワークフロー・ステップで使用してコンパニオン・ファイルにOriginalAuthorというワークフロー変数を設定し、dDocAuthor
を使用せずに、このカスタム変数をトークンで指定できます。
最初のステップのイベント・スクリプトは、次のようになります。
<$wfSet("originalContributor", dDocAuthor)$> <$wfSet("type", user)$>
通知ステップのトークン・スクリプトは、次のようになります。
<$wfAddUser(wfGet("originalContributor"), wfGet("type"))$>
例4-3 ジャンプ条件に基づいて選択されるレビューア
トークンの一般的な使用方法の1つは、ジャンプの条件に基づいてレビューアをその場で選択することです。たとえば、マーケティング部門では、すべてのマーケティング資材の標準ルーティングのワークフローが設定されています。ただし、会社のカタログへの変更に関しては、流通部門によるレビューも必要になります。
この場合は、タイプがcatalog
のときは常にレビューアのリストにトークンが追加されるようにジャンプを作成します。トークン・スクリプトは、次のようになります。
<$wfAddUser("Dist_Dept", "alias")$>
ジャンプを使用すると、システム、コンテンツおよびユーザーのワークフローをカスタマイズできます。通常、ジャンプは、Idocスクリプトで記述された条件文です。
一般に、ジャンプは次の場合に使用します。
ワークフローに入るための基準として、複数のメタデータ・フィールドを指定する場合。
一定時間が経過した後、コンテンツに対して自動的にアクションを実行する場合。
メタデータおよびユーザーの基準に応じて、同じワークフロー内でファイルが移動する様々な経路を定義する場合。
サイド・エフェクト(編集状態からのドキュメントのリリース)を使用して、承認の前にワークフロー・ドキュメントをリリースする場合。
作成者がシステム管理者であった場合にワークフローを終了するジャンプの例を次に示します。
<$if dDocAuthor like "sysadmin"$> <$wfSet("wfJumpName", "Entry step")$> <$wfSet("wfJumpTargetStep", wfExit(0, 0))$> <$wfSet("wfJumpEntryNotifyOff", "0")$> <$endif$>
ほとんどの場合、ジャンプには条件文が含まれます。ただし、次のように、条件コードを含まないジャンプも作成できます。
<$wfSet("custom_wf_variable", new_value)$> <$wfSet("wfJumpTargetStep", step_1)$>
このタイプのジャンプは、コードの実行や別のステップへのリビジョンの移動を自動的に行う場合に使用できます。
「イベント」で説明したように、ワークフローの各ステップには、入力イベント、更新時イベントおよび終了時イベントがあります。
ステップのすべてまたは任意のイベントには、1つ以上のジャンプを伴うスクリプトを定義できます。イベントに対して定義されたIdocスクリプトは、イベントのタイプに応じて、特定の時点で評価されます。
開始時イベント・スクリプトは、ステップに入るときに評価されます。ステップに入るたびに、ユーザー定義のカスタム・スクリプトに加えて、デフォルトのスクリプトが評価されます。デフォルトのスクリプトは、ステップの開始回数(entryCount
)および最後に開始した時間(lastEntryTs
)を追跡します。
開始時イベント・スクリプトによって、ジャンプまたは終了が発生しなかった場合は、ユーザー、エイリアスおよびトークンが評価され、電子メールで通知されます。
更新時イベント・スクリプトは、ワークフローの更新サイクル、リビジョンのメタデータの更新、リビジョンの承認またはチェックインなど、コンテンツの状態の変化によって評価およびトリガーされます。
更新時イベント・スクリプトが評価されるたびに、追加の終了条件が評価されます。
終了時イベント・スクリプトは、リビジョンがステップの承認要件を完了し、ステップの追加の終了条件が満たされたときに評価されます。
デフォルトでは、ワークフローの更新サイクルは1時間ごとに発生します。このサイクル時間は、(WorkflowIntervalHours
構成の設定を使用して)1時間ずつ増加できますが、1時間未満には短縮できません。更新スクリプトを頻繁に評価したり、他のイベントに応じて評価するには、メタデータを変更せずにメタデータの更新サイクルを開始できます。
単一のワークフロー内で、レビューアがリビジョンを却下すると、コンテンツ・アイテムは最新のコントリビューション・ステップに戻されます。
ただし、サブワークフローまたは別のワークフローにジャンプした後、そのジャンプ先でコンテンツが却下された場合、その動作は異なります。プロセスは前のコントリビューション・ステップではなく、親ワークフローに戻ります。
重要: リビジョンが却下された場合、更新時および終了時のイベント・スクリプトは実行されません。却下の際に評価するコードは、却下されたファイルの送信先ステップの開始時イベント・スクリプトに存在している必要があります。 |
サイド・エフェクトは、ワークフロー・ステップのリビジョンがジャンプ条件を満たした場合に実行されるアクションです。サイド・エフェクトには、次のものがあります。
同じワークフロー内の別のステップへのジャンプ
サブワークフローまたは別の基準ワークフローのステップへのジャンプ(基準ワークフローの場合のみ)
ユーザーへの通知
ワークフローの終了
コンパニオン・ファイルの状態情報の設定
承認される前のワークフロー・ドキュメントのリリース
サイド・エフェクトは、「スクリプトのプロパティ」画面および「ジャンプの追加」/「ジャンプの編集」画面で選択することで自動的に生成され、カスタム・サイド・エフェクトは、「ジャンプの追加」/「ジャンプの編集」画面の「カスタム効果」フィールドで指定できます。
ジャンプには、コンテンツがジャンプ条件を満たしている場合に、ワークフローにそのコンテンツの移動先を知らせるターゲット・ステップを含めることができます。次の例は、コンテンツをワークフローの次のステップに移動させるターゲット・ステップを示しています。
<$wfSet("wfJumpTargetStep", wfCurrentStep(1))$>
ジャンプには、コンテンツが別のワークフローから戻る場合に、ワークフローにそのコンテンツの戻り先を知らせるリターン・ステップを含めることもできます。次の例は、コンテンツをワークフローの次のステップに移動させるリターン・ステップを示しています。
<$wfSet("wfJumpReturnStep", wfCurrentStep(1))$>
ステップ名変数step_name>@<workflow_name
は、ワークフローの各ステップに割り当てられます。ジャンプでは、2つの方法でステップを参照します。
明示的な参照は、Editor@Marketing Brochures
などの特定のステップ名を参照します。
シンボリック参照は、wfCurrentStep(-1) (
前のステップ)やwfStart (
ワークフローの最初のステップ)など、現在のステップおよびワークフローに対して相対的に参照します。
ヒント: スクリプト・テンプレートを作成するときは、明示的なステップ名ではなく、シンボリック参照を使用します。 |
エントリ件数の変数entryCount
は、ステップの開始回数を追跡します。これは、ステップに入るたびに更新されるデフォルトの開始スクリプトの一部です。次の例は、条件文でのエントリ件数の変数の使用方法を示しています。
<$if entryCount = 1$>
最終エントリの変数lastEntryTs
は、最後にステップを開始した時間を追跡します。これは、ステップに入るたびに更新されるデフォルトの開始スクリプトの一部です。次の例は、最終エントリ変数を使用して、ステップが7日以内に実行されなかった場合に必要なアクションを指定する方法を示しています。
<$if parseDate(wfCurrentGet("lastEntryTs")) < dateCurrent(-7)$>
ワークフローのジャンプを作成するには、その前に、フローチャートを作成して、可能なすべてのジャンプ・シナリオを解決しておく必要があります。ジャンプの構築方法としては、サブワークフローにジャンプするステップを備えたメイン・ワークフローを作成することをお薦めします。次のフローチャートの例を参照してください。
ワークフロー内で発生させる必要があるジャンプを決定した後は、そのジャンプを設定してテストします。既存のワークフローにジャンプを直接作成することも、ジャンプのスクリプト・テンプレートを作成して異なるワークフローで再利用することもできます。
ジャンプを作成する手順は、次のとおりです。
ジャンプを使用するワークフローを作成します。「基準ワークフローの設定」または「基本ワークフローの設定」を参照してください。
ワークフローのタイプに応じて、「ワークフロー管理」: 「条件」タブまたは「ワークフロー管理」: 「ワークフロー」タブでワークフローを選択します。
「ステップ」ペインで、「追加」をクリックするか、ジャンプを含めるステップを選択して「編集」をクリックします。
ワークフロー・タイプ(基準または基本)の「新しいステップの追加」/「ステップの編集」画面が表示されます。
「イベント」タブをクリックします。
ジャンプを含めるイベント(入力、更新または終了)の横にある「編集」をクリックします。
スクリプト・テンプレートが存在しない場合は、「スクリプトのプロパティ」画面が表示されます。手順0に進みます。
スクリプト・テンプレートが存在する場合は、ステップ名のスクリプトの編集画面が表示されます。
編集オプションを選択します。
空白の画面からスクリプトを作成するには、「新規作成」を選択します。
スクリプト・テンプレートからスクリプトを作成するには、「スクリプト・テンプレートを使用」を選択し、オプション・リストからテンプレートを選択します。
「OK」をクリックします。
「スクリプトのプロパティ」画面が表示されます。
サイド・エフェクトをテストするには、次の手順に従います。
「ジャンプ」タブで、「追加」をクリックするか、既存のジャンプを選択して「編集」をクリックします。
「ジャンプの追加」/「ジャンプの編集」画面が表示されます。
新しいジャンプの場合は、ジャンプ名を入力します。ジャンプを作成した後でジャンプ名を変更することはできません。意味のあるわかりやすい名前を付けます。
ジャンプにリターン・ポイントを指定する必要がある場合は、「リターン・ポイントを設定する」チェック・ボックスを選択し、オプション・リストからリターン・ポイントを選択します。「現在のステップ」、「次のステップ」、「前のステップ」から選択できます。
ジャンプに入ったときに、このステップのレビューアに通知しない場合は、「実行時にユーザーに通知しない」チェック・ボックスを選択します。
承認される前にコンテンツ・アイテムをリリースする場合は、「ドキュメントの編集状態の解除」チェック・ボックスを選択します。
カスタム・サイド・エフェクトを「カスタム効果」フィールドに入力します。例については、「ジャンプの例」を参照してください。
ジャンプに入ったときにレビューアに通知する場合は、「メッセージ」タブをクリックし、通知メッセージを入力します。
「OK」をクリックします。「スクリプトの編集」画面が再び表示されます。
条件文を設定するには、次の手順に従います。
「フィールド」オプション・リストからメタデータ・フィールドを選択します。これは、評価されるワークフロー条件またはメタデータ・フィールドです。
「演算子」オプション・リストから、演算子を選択します。これは、「フィールド」に関連する演算子のみを示す依存オプション・リストです。
「値」オプション・リストから値を選択します。これは、指定したメタデータ・フィールドに関連付ける値です。
「追加」をクリックしてスクリプトに条件文を追加します。
ジャンプを完成するには、次の手順に従います。
ジャンプにターゲット・ステップを指定する必要がある場合は、次のようにします。
特定のステップを指定するには、「選択」をクリックし、「ターゲット・ステップの選択」画面でワークフローおよびステップ名を選択します。ターゲット・ステップ領域に、ターゲット・ステップ名が表示されます。
シンボリック・ステップ(現在のステップまたはワークフローの終了など)を選択するには、「ターゲット・ステップ」オプション・リストからステップを選択します。
作成したスクリプトを変更するには、「カスタム」タブをクリックし、「カスタム・スクリプトの式」チェック・ボックスを選択して、コードを編集します。
注意: 「カスタム・スクリプトの式」チェック・ボックスの選択を解除すると、式は元の定義に戻り、すべての変更が失われます。 |
スクリプトをテストするには、次の手順に従います。
「テスト」タブをクリックします。
「選択」をクリックします。
「コンテンツ・アイテムの表示」画面が表示されます。
コンテンツ・リストを絞り込むには、「フィルタの使用」チェック・ボックスを選択して「フィルタの定義」をクリックし、フィルタ基準を選択して「OK」をクリックします。
テストするコンテンツ・アイテムを選択し、「OK」をクリックします。テスト用のドキュメントをチェックインして処理し、ワークフロー内のジャンプを追加するステップに置き、次に、そのコンテンツ・アイテムを選択してテストします。選択したコンテンツ・アイテムが現在ワークフローにない場合でも、そのコンテンツ・アイテムはスクリプトのテストに使用できますが、ワークフロー内では新しいコンテンツ・アイテムと同様に処理されます。
「アイテムのワークフロー状態のロード」をクリックします。
選択したコンテンツ・アイテムがワークフローにある場合は、コンパニオン・ファイルが「データの入力」フィールドにロードされます。
「テスト・スクリプト」をクリックします。
テストの結果が「結果」フィールドに表示されます。
スクリプトの各パラメータの値が表示されます。
Idocスクリプトのエラーが発生した場合は、エラーおよびエラーが含まれているスクリプトが表示されます。
スクリプトを保存するには、「OK」をクリックします。
引き続き、異なるステップへのジャンプを追加します(必要な場合)。
既存のジャンプを変更する手順は、次のとおりです。
ワークフロー管理アプリケーションまたは「ワークフロー管理」: 「ワークフロー」タブで、ワークフローを選択します。
「ステップ」ペインで、変更するジャンプが含まれているステップを選択します。
「ステップ」ペインで、「編集」をクリックします。
ワークフロー・タイプ(基準または基本)の「新しいステップの追加」/「ステップの編集」画面が表示されます。
「イベント」タブをクリックします。
ジャンプを削除するには、対応するイベント・ペインで「クリア」をクリックします。
ジャンプを変更するには、対応するイベント・ペインで「編集」をクリックします。
ステップ名のスクリプトの編集画面が表示されます。
編集オプションを選択します。
既存のスクリプトを編集するには、「現在のスクリプトを編集」を選択します。
新規スクリプトを作成するには、「新規作成」を選択します。
スクリプト・テンプレートを使用するには、「スクリプト・テンプレートを使用」を選択し、オプション・リストからテンプレートを選択します。
「スクリプトのプロパティ」画面が表示されます。
「ジャンプ」ペインの「追加」、「編集」および「削除」ボタンを使用して、ジャンプのサイド・エフェクトを変更します。
「スクリプトの句」ペインの「フィールド」、「演算子」、「値」フィールドおよび「追加」ボタンと「更新」ボタンを使用して、ジャンプの条件文を変更します。
「ターゲット・ステップ」オプション・リストを使用して、ジャンプのターゲット・ステップを変更します。
自動的に生成されたスクリプトを変更するには、「カスタム」タブをクリックし、「カスタム・スクリプトの式」チェック・ボックスを選択して、コードを編集します。
注意: 「カスタム・スクリプトの式」チェック・ボックスの選択を解除すると、式は元の定義に戻り、すべての変更が失われます。 |
変更を保存する場合は、「OK」をクリックします。
次の例は、様々なタイプのジャンプの設定方法を示しています。
「マーケティング・パンフレット」という基準ワークフローがあり、このワークフローは、Marketingセキュリティ・グループおよびMktBrochureコンテンツ・タイプで定義されています。ただし、グラフィック担当者が送信したパンフレットは、最初のステップのグラフィック部門の承認を必要としません。「スクリプトの編集」画面を使用して、次のように、最初のステップの開始時イベント・スクリプトを作成します。
<$if dDocAuthor like "bjones" or dDocAuthor like "sjames"$> <$wfSet("wfJumpName", "BypassGraphics")$> <$wfSet("wfJumpTargetStep", wfCurrentStep(1))$> <$wfSet("wfJumpEntryNotifyOff", "0")$> <$endif$>
自動的に生成された条件文のand
をor
に変更するには、「スクリプトの編集」画面の「カスタム」タブで、スクリプトを編集する必要があります。
レビュー期間が1週間に制限されていると仮定します。リビジョンが承認も却下もされていない場合は、レビューアに通知し、ApprovalPeriodExpiredというサブワークフローでそのリビジョンを処理します。「スクリプトの編集」画面で、次のような更新時イベント・スクリプトを作成します。
<$if parseDate(wfCurrentGet("lastEntryTs")) < dateCurrent(-7)$> <$wfSet("wfJumpName", "LateApproval")$> <$wfSet("wfJumpTargetStep", "NotifyAuthor@ApprovalPeriodExpired")$> <$wfSet("wfJumpMessage", "The review period for content item <$eval(<$dDocTitle$>)$> has expired.")$> <$wfSet("wfJumpReturnStep", wfCurrentStep(0))$> <$wfSet("wfJumpEntryNotifyOff", "0")$> <$endif$>
ワークフロー・テンプレートを使用すると、作成済のワークフローを簡単に再利用できます。各ワークフロー・テンプレートは、ワークフロー管理ツールに格納されている基本、基準またはサブワークフローのアウトラインです。ワークフロー・テンプレートは、セキュリティ・グループに結び付けられていないため、ステップ・イベント・スクリプトを含めることはできません。
この章には次の項があります。
重要: ワークフロー・テンプレートを使用するときに、レビューアが、選択したテンプレートに定義されているレビューアと異なる場合は、レビューアを変更する必要があります。 |
スクリプト・テンプレートは、ステップ・イベント・スクリプトを格納するために使用できますが、ワークフロー・テンプレートとは機能が異なります。詳細は、「スクリプト・テンプレートの作成」を参照してください。
テンプレートの作成で使用する手順の多くは、ワークフローの設定で使用する手順と同じです。この項では、プロセスの概要について説明します。詳細は、「基準ワークフローの設定」または「基本ワークフローの設定」を参照してください。
ワークフロー・テンプレートを作成する手順は、次のとおりです。
「ワークフロー管理」: 「テンプレート」タブを表示します。
「追加」をクリックします。
「テンプレートの追加」/「テンプレートの編集」画面が表示されます。
「テンプレート名」フィールドにテンプレート名を入力します。テンプレートを作成した後でテンプレート名を変更することはできません。
「説明」フィールドに、詳細を入力します。
適切なチェック・ボックスを選択して、コンテンツ・アイテムが却下された場合に、最初の作成者に既存リビジョンの編集を許可するか、新規リビジョンの作成を許可するかを指定します。
「追加」をクリックしてステップを追加します。
「名前」および「説明」に、ステップの適切な名前および説明を入力します。
ステップのユーザーの認可レベルとして、「ユーザーは現在のリビジョンをレビューできます」、「ユーザーは現在のリビジョンをレビューおよび編集(置換)できます」または「ユーザーは現在のリビジョンをレビューするか、新規リビジョンを作成できます」を指定します。
「OK」をクリックします。
ステップに追加するユーザーのタイプを選択します。1つのステップに複数のユーザー・タイプを定義できます。
「OK」をクリックします。
「終了条件」タブをクリックします。
リビジョンが次のステップに進むには、何人のレビューアの承認が必要であるかを指定します。
必要に応じて、追加の終了条件を指定します。
ワークフローに条件付ステップまたは特別な処理が必要な場合は、「イベント」タブをクリックし、適切なスクリプトを追加してください。
「OK」をクリックします。
既存のワークフロー・テンプレートを変更する手順は、次のとおりです。
「ワークフロー管理」: 「テンプレート」タブを表示します。
変更するワークフロー・テンプレートを選択します。
「編集」をクリックします。
「テンプレートの追加」/「テンプレートの編集」画面が表示されます。
「ステップ」ペインの「追加」、「編集」および「削除」ボタンを使用して、ステップを変更します。
選択したステップのレビューアを追加または削除するには、「ユーザー」タブの「エイリアスの追加」、「ユーザーの追加」、「トークンの追加」および「削除」ボタンを使用します。
「終了条件」タブで、必要に応じて、必要なレビューア数または追加の終了条件を変更します。
「イベント」タブで、必要に応じて、ジャンプを追加、変更または削除します。詳細は、「ジャンプの設定」を参照してください。
「OK」をクリックします。
ワークフロー・テンプレートを削除する手順は、次のとおりです。
「ワークフロー管理」: 「テンプレート」タブを表示します。
削除するワークフロー・テンプレートを選択します。
「削除」をクリックします。
確認画面が表示されます。
「はい」をクリックします。
スクリプト・テンプレートを使用すると、作成済のステップ・イベント・スクリプトを簡単に再利用できます。スクリプト・テンプレートは、イベント・スクリプトを作成する手掛かりとして使用されます。各スクリプト・テンプレートは、ワークフロー管理ツールに格納されているIdocスクリプトの一部です。
スクリプト・テンプレートを作成するには、次の手順に従います。
ワークフロー管理アプリケーションで、「オプション」メニューから「スクリプト・テンプレート」を選択します。
「追加」をクリックします。
「スクリプトの追加」/「スクリプトの編集」画面が表示されます。
「スクリプト名」フィールドにスクリプト名を入力します。スクリプト・テンプレートを作成した後で「スクリプト名」を変更することはできません。
「説明」フィールドに、詳細を入力します。
「ジャンプ」タブで、「追加」をクリックします。
ジャンプ名を入力します。ジャンプを作成した後で名前を変更することはできません。
ジャンプにリターン・ポイントを指定する必要がある場合は、「リターン・ポイントを設定する」チェック・ボックスを選択し、オプション・リストからリターン・ポイントを選択します。
ジャンプに入ったときにユーザーに通知しない場合は、「実行時にユーザーに通知しない」チェック・ボックスを選択します。
承認される前にコンテンツ・アイテムをリリースする場合は、「ドキュメントの編集状態の解除」チェック・ボックスを選択します。
カスタム・サイド・エフェクトを「カスタム効果」フィールドに入力します。
ジャンプに入ったときにユーザーに通知する場合は、「メッセージ」タブをクリックし、通知メッセージを入力します。
「OK」をクリックします。
「フィールド」オプション・リストからメタデータ・フィールドを選択します。
「演算子」オプション・リストから、演算子を選択します。
「値」オプション・リストから値を選択します。
「追加」をクリックしてスクリプトに条件文を追加します。
「テスト」タブをクリックします。
「選択」をクリックします。
「コンテンツ・アイテムの表示」画面が表示されます。
コンテンツ・リストを絞り込むには、「フィルタの使用」チェック・ボックスを選択して「フィルタの定義」をクリックし、フィルタ基準を選択して「OK」をクリックします。
テストするコンテンツ・アイテムを選択し、「OK」をクリックします。選択したコンテンツ・アイテムが現在ワークフローにない場合、そのコンテンツ・アイテムはスクリプトのテストには使用できますが、ワークフロー内では新しいコンテンツ・アイテムと同様に処理されます。
「ワークフローの選択」をクリックします。
「ワークフロー・ステップの選択」画面が表示されます。
「ワークフロー」ペインでワークフローを選択し、「ステップ」ペインでステップを選択し、「OK」をクリックします。スクリプト・テンプレートで使用されるステップに類似したワークフロー・ステップを選択します。
「アイテムのワークフロー状態のロード」をクリックします。
選択したコンテンツ・アイテムがワークフローにある場合は、コンパニオン・ファイルが「データの入力」フィールドにロードされます。
「テスト・スクリプト」をクリックします。
テストの結果が「結果」フィールドに表示されます。
スクリプトの各パラメータの値が表示されます。
Idocスクリプトのエラーが発生した場合は、エラーおよびエラーが含まれているスクリプトが表示されます。
スクリプト・テンプレートを保存するには、「OK」をクリックします。
既存のスクリプト・テンプレートを変更する手順は、次のとおりです。
ワークフロー管理アプリケーションで、「オプション」メニューから「スクリプト・テンプレート」を選択します。
「ワークフロー・スクリプト」画面が表示されます。
変更するスクリプト・テンプレートを選択します。
「編集」をクリックします。
「スクリプトの追加」/「スクリプトの編集」画面が表示されます。
「ジャンプ」ペインの「追加」、「編集」および「削除」ボタンを使用して、ジャンプを変更します。
「スクリプトの句」ペインの「フィールド」、「演算子」、「値」フィールドおよび「追加」ボタンと「更新」ボタンを使用して、ジャンプの条件文を変更します。
「ターゲット・ステップ」オプション・リストを使用して、ジャンプのターゲット・ステップを変更します。
自動的に生成されたスクリプトを変更するには、「カスタム」タブをクリックし、「カスタム・スクリプトの式」チェック・ボックスを選択して、テキストを編集します。
注意: 「カスタム・スクリプトの式」チェック・ボックスの選択を解除すると、式は元の定義に戻り、すべての変更が失われます。 |
変更を保存する場合は、「OK」をクリックします。
既存のスクリプト・テンプレートを変更する手順は、次のとおりです。
ワークフロー管理アプリケーションで、「オプション」メニューから「スクリプト・テンプレート」を選択します。
「ワークフロー・スクリプト」画面が表示されます。
削除するスクリプト・テンプレートを選択します。
「削除」をクリックします。
確認画面が表示されます。
「はい」をクリックします。
次のワークフローのシナリオでは、特定のワークフロー・タスクの実行に必要な計画プロセスおよびアクション・タイプについて説明します。次のワークフロー例が記載されています。
シナリオ1: 基準ワークフロー。基準ワークフローの設定に使用するステップの詳細は、「基準ワークフローの設定」を参照してください。
シナリオ2: トークン。トークンの作成の詳細は、「トークンの作成」を参照してください。
シナリオ3: メタデータに基づいたジャンプ。ジャンプの設定の詳細は、「ジャンプの作成」を参照してください。
シナリオ4: 時間依存のジャンプ。変数を使用してジャンプを設定する方法の詳細は、「ジャンプの変数およびステップ」を参照してください。
マーケティング部門のすべてのマーケティング・パンフレットは、3人のグラフィック担当者の少なくとも1人と編集者、およびマーケティング管理者全員による承認が必要です。グラフィック担当者および編集者はコンテンツを編集できますが、管理者には編集権限がありません。
この例のワークフローを設定するには、次のようにします。
Marketingというセキュリティ・グループを定義し、グラフィック担当者および編集者にはセキュリティ・グループに対する書込み権限があり、マーケティング管理者には読取り権限があることを確認します。
MktBrochureというコンテンツ・タイプを定義します。
ワークフロー名がMarketing Brochures、セキュリティ・グループがMarketing、基準が「タイプ」= MktBrochureというワークフローを定義します。
ステップ名がGraphic Artistという最初のステップを、少なくとも1人のレビューアによる承認が必要なレビューア/コントリビュータ・ステップとして定義します。グラフィック部門は安定しているため、3人のグラフィック担当者のユーザー・ログインをステップに割り当てることができます。
ステップ名がEditorという2番目のステップを、レビューア/コントリビュータ・ステップとして定義します。編集者のユーザー・ログインをステップに割り当てます。
ステップ名がMarketing Teamという3番目のステップを、すべてのレビューアによる承認が必要なレビューア・ステップとして定義します。管理構造は頻繁に変更されるため、MktTeamというエイリアスを設定し、このステップに割り当てます。
すべてのマーケティング・パンフレットは、MktBrochureタイプを使用してMarketingセキュリティ・グループにチェックインする必要があるため、マーケティング・パンフレットのコントリビュータになる可能性があるすべてのユーザーに、チェックイン方法を説明しておくと役立ちます。
承認プロセスが正しく機能するには、MktTeamエイリアスを最新の状態にしておく必要があります。
シナリオ1のMarketing Brochuresワークフローを作成した後、マーケティング部門の要請により、マーケティング・パンフレットをリリースする前に、すべてのマーケティング・パンフレットを最初の作成者に戻して最終レビューを行うことになりました。最初の作成者には、編集権限がありません。
この例のワークフローを設定するには、次のようにします。
Authorという名前のトークンを作成し、ユーザーをdDocAuthor
として定義します。
ステップ名がOriginal Authorというワークフローの4番目のステップを、レビューア・ステップとして定義します。トークンAuthorをステップに割り当てます。
シナリオ1と3で作成したMarketing Brochuresワークフローは適切に機能していますが、マーケティング部門の新たな要請により、取扱品目の新しいパンフレットがリリースされる場合は、様々な営業担当者に自動的に通知することになりました。
この例のワークフローを設定するには、次のようにします。
必要なカスタム・メタデータ・フィールドをProductという名前で定義し、製品のオプション・リストを作成します。
各製品のエイリアスを設定し、適切な営業担当者を各エイリアスに割り当てます。各ユーザーを複数のエイリアスに割り当てることができます。
ステップ名がNotify Salesというワークフローの5番目のステップを、承認に必要なレビューア数が0のレビューア・ステップとして定義します。
承認に必要なレビューア数が0のレビューア・ステップが1つ含まれている、各製品のサブワークフローを定義します。対応する製品のエイリアスをステップに割り当てます。
Notify Salesステップに、製品と一致するサブワークフローにジャンプする開始スクリプトを定義します。
通知プロセスが正しく機能するには、製品のオプション・リストおよびエイリアスを最新の状態にしておく必要があります。
マーケティング部門では、マーケティング・パンフレットの承認をタイムリに得ることが困難になっています。Marketing Brochuresワークフローを変更して、コンテンツが7日以内にグラフィック部門、管理者または最初の作成者によって承認または却下されなかった場合は、そのコンテンツを次のステップに自動的に移動することにしました。編集者には多少の余裕を与え、10日間が経過した後、次のステップにコンテンツを移動します。
この例のワークフローを設定するには、次のようにします。
AutoApproveというスクリプト・テンプレートを定義し、ターゲット・ステップを使用して、最終エントリが7日前の場合はワークフローの次のステップに移動するようにします。
Graphic Artistステップ、Marketing TeamステップおよびOriginal Authorステップに、更新ジャンプを追加します。AutoApproveスクリプト・テンプレートを使用してジャンプを作成します。
AutoApproveスクリプト・テンプレートを使用して、Editorステップに更新ジャンプを追加します。ジャンプが7日ではなく、10日で発生するように、スクリプトを編集します。
この項では、ワークフローのヒントおよび要領について説明します。次の項目について説明します。
この機能に加えて、コンサルティング・サービスを介してその他のカスタマイズを入手できます。詳細は、「その他のカスタマイズ」を参照してください。
ワークフローの中では、ユーザーの再認証が必要になる場合があります。これは、ワークフローの該当する特定のステップの中では、ユーザーのデジタル署名として機能します。この機能を使用するには、最初に、承認前の認証が必要なワークフロー・ステップを判断します。次に、次の操作を実行します。
IntradocDir/config/config.cfgファイルに、次の行を追加します。
<
workflow step name>:isRepromptLogin=true
複数のワークフロー・ステップで検証が必要な場合は、別々の行にそのステップを追加します。
コンテンツ・サーバーを再起動します。
ワークフローを設定して有効にし、検証が必要なステップに対しては、構成エントリで指定したステップ名を必ず使用します。
ワークフローを開始すると、構成変数isRepromptLogin
で指定されたワークフロー・ステップのユーザーは、そのワークフロー・ステップでコンテンツを承認する前に、ログインするよう求められます。
次の例では、VIPApprovalおよびCEOsignoffという名前のステップで検証が必要です。次のエントリをconfig.cfgファイルに追加します。
VIPApproval:isRepromptLogin=true
CEOsignoff:isRepromptLogin=true
コンテンツ・サーバーを再起動し、VIPApprovalおよびCEOsignoffという名前のステップ名でワークフローを設定して有効にします。VIPApprovalステップには複数のユーザーが割り当てられ、CEOsignoffステップには1人のユーザー(会社のCEO)のみが割り当てられます。
これらのステップでユーザーがワークフロー・アイテムを承認するには、その前に、コンテンツ・サーバーに再度ログインする必要があります。
この機能は、Content Server 7.5以上のバージョンでのみ使用可能です。
2つの別個のユーザー・グループがワークフローのコンテンツ・アイテムを同時にレビューできるようにし、コンテンツがワークフロー内を進む前に、各グループから指定された数のユーザーがコンテンツを承認できると便利な場合があります。
コンテンツ・サーバーを使用している場合、先に進むためには、すべてのユーザーまたは指定した数のユーザーがコンテンツを承認する必要があります。通常、ワークフローでは承認元は区別されません。そのため、1つのグループのすべてのメンバーがコンテンツを承認し、他のグループのメンバーが誰も承認しない場合でも、コンテンツはワークフロー内を進み続けます。次のコードは、承認プロセスに区別を追加する例を示しています。
このコードによって、ステップのユーザーをグループに分けて設定できます。スクリプトでは、各承認で、ユーザーが所属するグループが確認されます。ユーザーは、複数のグループに所属している場合があり、あるグループのユーザーが承認すると、そのグループのカウンタが1増えます。
ステップ内にコンテンツは、追加の終了条件により、追加条件が満たされるまで保持されます。
ステップのエントリ部分に、次のコードを追加します。
<$wfSet("set1", "0")$> <$wfSet("set2", "0")$> <$group1 = "user1, user2, user3,"$> <$wfSet("group1", group1)$> <$group2 = "user8, user9, user10,"$> <$wfSet("group2", group2)$>
ステップの更新部分に、次のコードを追加します。
<$if wfAction like "APPROVE"$> <$if strIndexOf(wfGet("group1"), dUser) >=0$> <$set1 = toInteger(wfGet("set1"))+1$> <$wfSet("set1", set1)$> <$endif$> <$if strIndexOf(wfGet("group2"), dUser)>=0$> <$set2 = toInteger(wfGet("set2"))+1$> <$wfSet("set2", set2)$> <$endif$> <$endif$>
ステップの追加の終了条件部分に次のコードを追加します(nはグループ1から必要な承認者の数、rはグループ2から必要な承認者の数)。
toInteger(wfGet("set1")) >= n toInteger(wfGet("set2")) >= r
このワークフロー・コードは、各承認アクションの中で承認ユーザーを確認し、そのユーザーが所属するグループのカウンタを増加します。ステップ内にコンテンツ・アイテムは、追加の終了条件により、各グループの最低ユーザー数がコンテンツを承認するまで保持されます。各グループに必要な最低承認数を超過して承認が行われた場合、承認アクションはログに記録されますが、コンテンツ・アイテムは進みません。
却下アクションは絶対的です。指定されたユーザーからの却下により、通常どおりのワークフローの却下動作が実行されます。
トークンが通常アクセスするメタデータ・フィールドを使用せずに、ユーザーをワークフロー・ステップに追加できます。たとえば、コンテンツ・アイテムはワークフロー内を移動しており(編集されている)、編集ごとに、コンテンツを編集したユーザーがdDocAuthorとしてリストされます。ワークフロー・サイクルの終わりに、アイテムを最初の作成者に送信するには、特別なトークンを作成する必要があります。
<$wfAddUser(wfGet("originalContributor"), wfGet("type”))$>
ワークフローの最初のステップの入力イベントに次のコードを追加して、最初の作成者をリストアします。
<$originalContributor=dDocAuthor$> <$wfSet("originalContributor",originalContributor)$> <$type="user"$> <$wfSet("type",type)$>
イベント・スクリプトは、トークン・コールより前のいずれかの時点で、wfSet()
を使用してカスタム変数および値をコンパニオン・ファイル内に設定します。次に、トークンがwfGet()
を使用してそれらの値を取得し、ステップ・ユーザーを設定します。
このテクニックを使用すると、有効なユーザー名またはエイリアスを保持する標準またはカスタムIdoc変数を取得して保存できます。Idoc変数には、ユーザー名またはエイリアスのカンマ区切りのリストを含めることができます。ユーザー名を保存する場合は、<$type$>
変数をuserに設定する必要があります(例: <$type="user"$>
)。エイリアスを保存する場合は、<$type$>
変数をaliasに設定する必要があります(例: <$type="alias"$>
)。
トークンをステップ・ユーザーとして設定して、ワークフロー・ステップの入力イベントに置くと、入力イベント・コードによって情報が処理されます。保存されたユーザー名(またはエイリアス)がトークンによってコールされ、ステップ・ユーザーとして設定されます(リストを指定した場合は複数のユーザーが設定されます)。ステップの入力イベントおよびステップ・ユーザー定義に、複数または条件付のコード・ブロックおよびトークン(前述のとおり)を追加すると、真の非定型ワークフロー・ルーティングが可能になります。
電子メールは、プロセスの3つのポイントで、基準ワークフローによりトリガーされます。
ステップに入るとき。
却下理由フォームを受信したとき。
wfNotify
Idocスクリプト関数を実行したとき。
基準ワークフローで送信される電子メールは、電子メールのメッセージ、件名およびテンプレートをカスタマイズできます。この項では、基準ワークフローの電子メール機能をカスタマイズするプロセスについて説明します。
ワークフローに関連する受信者に送信される電子メール・メッセージを生成する際に最もよく使用される2つのテンプレートは、reviewer_mail.htmおよびreject_mail.htmです。これらは、IdcHomeDir/resources/core/templatesに格納されています。
これらのテンプレートは、他のテンプレートと同様に変更できます。電子メール・テンプレートの変更は、柔軟性を高め、ワークフロー電子メールをカスタマイズする機会を提供します。この種の変更は比較的簡単ですが、コンポーネントの開発には十分な注意が必要です。電子メールの件名およびメッセージの変更は、多くの場合、メッセージの最も重要な部分であるため、最も頻繁に変更されます。
標準テンプレートに基づいたカスタム・ワークフロー電子メール・テンプレートを作成することもできます。カスタム・テンプレートは、次の例に示すように、wfNotify
関数のオプションの3番目のパラメータとして追加することで、必要に応じて呼び出すことができます。
<$wfNotify(userName, "user", templateName)$> <$wfNotify(aliasName, "alias", templateName)$>
代替テンプレートが指定されていない場合は、システムのデフォルト・テンプレートが使用されます。
詳細は、Oracle Fusion Middleware Idocスクリプト・リファレンス・ガイドのwfNotify
の説明を参照してください。
基準ワークフローの電子メールの件名行およびメッセージ行は、アプリケーション用にカスタマイズできます。電子メールの件名行は、電子メールに表示され、メッセージ行は、ワークフロー電子メールに関する他の情報(ワークフロー名、ステップおよびコンテンツ・アイテム)とともに、電子メールの本文に表示されます。
メッセージ行は、そのステップが通知のみ(つまり、必要なレビューア数が0)かどうかに応じて、2つのメッセージのいずれかにデフォルト設定されます。
件名行およびメッセージ行は、2つの方法でカスタマイズできます。
標準コンポーネント・アーキテクチャに従って、コア・ストリング・リソース・ファイルを変更できます。
簡単なカスタマイズの場合は、Idocスクリプト変数wfMailSubject
(電子メールの件名の場合)またはwfMessage
(メッセージ行の場合)を基準ワークフローのステップ・イベント・スクリプトで宣言するか、コンパニオン・ファイルに保存できます。
文字列の定義は、次のとおりです(変数1
はコンテンツ・アイテムのタイトル、変数2
はワークフロー・ステップの名前)。
<@wwWfIsNotifyOnly=Workflow notification for content item '{1}' is in step '{2}'.@>
<@wwWfReadyForStep=Content item '{1}' is ready for workflow step '{2}'.@>
<@wwWfRejected=Content item '{1}' has been rejected.@>
通常、これらの文字列の定義は、Idocスクリプト<$lc()$>
ローカライゼーション関数を使用してコールされ、これらをコンポーネント・リソース・ファイルでエイリアス化できます。電子メール件名行のストリングのインクルードの例は、std_page.htmファイルの<@dynamichtml wf_approve_mail_subject@>
インクルード定義を参照してください。
電子メールまたは件名行の簡単な変更には、コンポーネントではなく、Idocスクリプトを使用できます。ステップ・イベント・スクリプトで、構成変数wfMailSubject
またはwfMessage
を使用できます。次の例のように、これらの変数の値にもIdocスクリプトを使用できます。
<$wfMailSubject=”My custom subject text for content with <$dDocTitle$> title”$>
Idocスクリプト変数を評価するためにeval()
関数は不要です。
ワークフロー・ステップの入力イベントでwfMailSubject
またはwfMessage
を使用すると、ステップに入ったコンテンツによってトリガーされる電子メール・メッセージは、カスタマイズされた件名またはメッセージ行を受け取ります。これらの変数はwfNotify()
関数の前に宣言することもでき、その場合、この関数によって生成される電子メールはカスタマイズを受けます。
この例では、トークンおよびコーディングに関する知識が必要です。
ワークフローのエスカレーション(リストされたユーザーとは異なるユーザーへのワークフロー・コンテンツの動的なルーティング)は、一般的なワークフロー要件です。これはジャンプおよびいくつかの基準(たとえば、日付、アクション、メタデータ)の解析により簡単に実行できますが、最初は、コンテンツの移動先について、混乱や迷いが発生する場合があります。
この問題がさらに複雑化するのは、多数のステップ・ユーザーを追加し、コンテンツが次へ進むために、これらのユーザーのサブセットのみの承認が必要な場合です。このワークフローは、電子メールを生成および送信し、承認を行わないユーザー、外出中のユーザー、および本来のレビューアがいない場合に備えて待機しているユーザーのワークフロー・キューに表示されます。
このソリューションでは、2つのカスタム・ユーザー・メタデータ・フィールド、トークン、ワークフロー・ステップの入力イベントおよび更新時イベント・コードを利用します。
次の要素を使用して、ユーザー・メタデータ・フィールドを作成します。
名前: OutOfOffice
タイプ: テキスト
オプション・リスト: はい
オプション・リスト・タイプ: Vタイプの選択リスト
オプション・リストの値: <blank>、falseおよびtrue
次の要素を使用して、もう1つのユーザー・メタデータ・フィールドを作成します。
名前: OutOfOfficeBackup
タイプ: ロング・テキスト
OutOfOffice
フィールドは、ユーザーが外出するときにTRUEに設定するフラグです。ユーザーは、選択リストから「True」オプションを選択し、「更新」ボタンをクリックして自分のユーザー・プロファイルを更新し、このフラグを設定します。
OutOfOfficeBackup
フィールドには、外出中のユーザーの代理として補充できるユーザーの名前が保存されます。最適には、このフィールドに、ユーザー管理アプレットに表示されるとおりに書式設定された単一のユーザー名が保存されます。
次のワークフロー・ステップ・イベント・コードで、リストされたユーザーの1人が外出中であることが検知されると、そのユーザーの名前をリストされた代理人(OutOfOfficeBackup
フィールドの値で指定されたユーザー)に置き換えます。ワークフロー・ステップは、コンテンツをまだ承認していないユーザーと指定された代理人のみで再開されます。
トークンによって、コンパニオン・ファイルからユーザーのリストが取り出され、ステップ・ユーザーとして設定されます。コンテンツが更新ステップ・イベントで待機している間に、指定された代理人に特別なワークフロー・メッセージが送信されます。
ワークフロー・トークンを作成します。
名前: DynamicStepUsers
トークン・コード:
<$if wfGet("dsu")$> <$wfAddUser(wfGet("dsu"), "user")$> <$else$> <$wfAddUser("sysadmin", "user")$> <$endif$> <$if wfGet("dsa")$> <$wfAddUser(wfGet("dsa"), "alias")$> <$endif$>
トークンによって、コンパニオン・ファイルからカスタム変数dsu
およびdsa
の値が取り出されます。dsu
の値が見つからない場合は、予防措置としてシステム管理者ユーザーを追加します。dsu
およびdsa
の初期値は、ステップの入力イベントにリストされています。ユーザーのみ: ステップにユーザーを割り当てる必要がある場合は、最初のコントリビュータを最初のステップに追加し、次のステップには、最初のユーザーとその次のユーザー(ユーザー2)を含める必要があります。
次のコードをワークフロー・ステップの入力イベントに貼り付けます。このコードには、コメントが含まれている点に注意し、このコメントを削除してから、ステップに挿入します。
<$restartFlag=wfGet("restartStep")$>
新しいバックアップ・ユーザーで再開するために、ここに到達したかどうかを確認します。その場合、古いユーザーへの通知は省略し、新しいユーザーにのみ通知します。
<$if restartFlag$>
<$if toInteger(wfGet("restartStep"))>=1$>
<$wfSet("wfJumpEntryNotifyOff", "1")$>
<$oooUsers=wfGet("outOfOfficeUsers")$>
<$if strIndexOf(oooUsers,",")>=1$>
外出している複数のユーザーをチェックします。
<$wfMessage=eval("The Following Users are out of the office: <$oooUsers$>
\nYou are the designated backup for one of them.\n
The content item <$dDocName$> is in the workflow step <$dwfStepName$> awaiting your review")$>
<$else$>
<$wfMessage=eval("The Following User is out of the office: <$oooUsers$>
\nYou are the designated backup for this user.\n
The content item <$dDocName$> is in the workflow step <$dwfStepName$> awaiting your review")$>
<$endif$>
<$rsMakeFromString("ooou",oooUsers)$>
<$loop ooou$>
<$userBackupName=row&"_Bkup"$>
<$wfNotify(wfGet(userBackupName),"user")$>
<$endloop$>
<$wfSet("restartStep","0")$>
<$endif$>
<$else$>
<$wfSet("restartStep","0")$>
<$endif$>
ここでステップ・ユーザーを設定します。複数のユーザーはカンマで区切り、ユーザー名は引用符で囲む必要がありますが、メタデータ・フィールド参照には引用符を付けないでください。この例では、エイリアスではなくユーザー名を使用して進行します。エイリアスを使用する場合は、コードを多少書き直す必要があります。
<$dynamicStepUsers= <LIST USER NAMES IN QUOTES HERE>$>
<$if strIndexOf(dynamicStepUsers,",")>=1$>
複数のユーザーが指定されている場合は、各ユーザーが外出しているかどうかを確認します。
<$rsMakeFromString("multiDynamicUsers",dynamicStepUsers)$>
<$loop multiDynamicUsers$>
<$if strEquals(getValueForSpecifiedUser(row,"uOutOfOffice"),"true")$>
ユーザーが外出中の場合は、バックアップ・ユーザーを取得します。
<$backup=getValueForSpecifiedUser(row,"uOutOfOfficeBackup")$>
ユーザー・リストの外出中のユーザーをバックアップ・ユーザーで置換します。
<$dynamicStepUsers=strReplace(dynamicStepUsers,row,backup)$>
<$endif$>
<$endloop$>
<$else$>
単一のユーザーが外出しているどうかを確認します。
<$if strEquals(getValueForSpecifiedUser(dynamicStepUsers,"uOutOfOffice"),"true")$>
ユーザーが外出中の場合は、バックアップ・ユーザーを取得します。
<$dynamicStepUsers=getValueForSpecifiedUser(dynamicStepUsers,"uOutOfOfficeBackup")$>
<$endif$>
<$endif$>
<$wfSet("dsu",dynamicStepUsers)$>
リストされているユーザーおよびバックアップ・ユーザーを使用して、コンパニオン・ファイルにdsu変数を設定します。
次のコードをワークフロー・ステップの更新イベントに貼り付けます。コメント行を削除してから貼り付けてください。
<$remainingUsers=wfGet("wfUserQueue")$>
承認していないユーザーを取得します。
<$rsMakeFromString("ru", remainingUsers)$>
<$loop ru$>
<$if strEquals(getValueForSpecifiedUser(row,"uOutOfOffice"),"true")$>
残りのユーザーが外出中かどうかを確認します。
<$if getBackup$>
代理となるバックアップ・ユーザーが必要なユーザーのリストを作成します。
<$getBackup=row &","&getBackup$>
<$else$>
<$getBackup=row$>
<$endif$>
<$endif$>
<$endloop$>
<$if getBackup or strLength(getBackup)>0 $>
ユーザーの1人が外出中としてリストされている場合は、ユーザー・リストを書き直してステップを再開します。
<$wfSet("outOfOfficeUsers",getBackup)$>
<$rsMakeFromString("needBkup", getBackup)$>
<$loop needBkup$>
<$bkupUser=getValueForSpecifiedUser(row,"uOutOfOfficeBackup")$>
<$newRemainingUsersList=strReplace(remainingUsers,row,bkupUser)$>
<$wfSet(row&"_Bkup",bkupUser)$>
<$endloop$>
<$wfSet("dsu",newRemainingUsersList)$>
<$getBackup=""$>
<$wfSet("wfJumpTargetStep", wfCurrentStep(0))$>
<$wfSet("restartStep","1")$>
<$endif$>
ワークフローのカスタマイズの多くは、コンサルティング・サービスを介して入手できます。この項では、そのような2つのカスタマイズについて簡単に説明します。ワークフローの例の複製に関連する影響を評価する際は、オラクル社コンサルティング・サービスをご利用ください。
この項では、次のカスタマイズについて説明します。
実際のワークフローに参加していなくても、ワークフロー・ステップのコンテンツを承認するユーザーが必要になる場合があります。たとえば、ワークフローの特定のステージで、ドキュメントに対する一度かぎりの部外者の意見を聞いたり、レビューアの外出中に一度かぎりのレビューアを指定できると便利な場合があります。これにより、ユーザーはコンテンツを承認できますが、通常のワークフロー通知は送信されず、ワークフロー・キューにコンテンツ・アイテムが表示されることもありません。
指定されたロールのユーザーまたは指定されたエイリアスのメンバーは、これに基づいてコンテンツを承認できます。これらの指定されたユーザーには、ワークフローのアイテムごとに、ワークフロー・アクション・ボックスにバイパス承認リンクが表示され、このワークフローに対する標準のセキュリティ・アクセス権が設定されます。バイパス承認を実行すると、現在コンテンツが置かれているステップで、コンテンツ・アイテムが承認されます。定義済のステップの終了条件も評価および適用されます。承認はワークフロー履歴データベース表およびコンパニオン・ファイルのWorkflowActionHistory ResultSetに記録されます。
指定された承認担当者は、通常のワークフロー・ステップの承認担当者ではないため、自動ワークフロー通知を受信しません。このため、承認担当者は意図的にワークフローのコンテンツ・アイテムにアクセスして、バイパス承認アクションを実行する必要があります。指定された承認担当者は、「アクティブなワークフロー」メニューにアクセスし、ワークフロー名およびアクションを選択する必要があります。
指定された承認担当者のコンポーネントは、コア・リソースをエイリアス化します。したがって、他のコンポーネントが実行中であるか、実行を予定している場合は、これを考慮する必要があります。すべての必要な機能を含めるためにコンポーネント・リソースを結合したり、すべてのコンポーネントが適切に(別個に)動作するように名前変更や再参照を行う場合もあります。
次のシナリオでは、ユーザーAのロールまたはエイリアスには、指定された承認担当者のステータスが付与されており、MyWF
というサンプル・ワークフローには2つのステップがあることが前提となっています。
シナリオ1: ユーザーAは、MyWF
のステップ1では承認担当者としてリストされていますが、ステップ2ではリストされていません。しがたって、ステップ1ではバイパス承認リンクは表示されません。ユーザーAは、デフォルトのワークフロー・アクションの機能および通知を受け取っています。コンテンツ・アイテムがステップ2にある場合は、ユーザーAがワークフローのコンテンツ'MyWF'ページにアクセスすると、「ワークフロー・アクション」メニューの下にステップ2のバイパス承認リンクが表示されます。
シナリオ2: ユーザーAは、MyWF
の承認担当者としてリストされていません。バイパス承認リンクは、ユーザーAがセキュリティ・グループで少なくとも読取り権限があるすべてのステップおよびコンテンツで、ワークフローのコンテンツ'MyWF'ページのアクション・メニューに表示されます。
シナリオ3: ユーザーAは、MyWF
のステップ1の承認担当者としてリストされていません。ステップ2に移動するには、ステップ1でレビューアから2つの承認が必要です。ユーザーAのバイパス承認リンクが表示されます。バイパス承認をクリックすると、承認が登録され、ワークフローでの続行に必要なステップの2つの承認のうちの1つが満たされます。
多くの場合、コンテンツ・アイテムは、リリースされる前に(様々な形式で)処理されます。リリースされたコンテンツ・アイテムは、索引付けされた後、検索結果、アーカイブおよび他のプロセスやアプリケーションに含めることが可能になります。
ワークフローのコンテンツ・アイテムを完了前にリリースできると、便利な場合があります。たとえば、コンテンツ・アイテムをレプリケートするには(後で障害時リカバリなどで使用するために)、そのコンテンツ・アイテムをリリース状態にする必要があります。レプリケータでは、リリースされていないアイテム(ワークフロー内のアイテムなど)を使用できません。
ワークフロー・アイテムがワークフロー内にある間に、そのアイテムをリリース済として指定できます。更新、チェックアウト、チェックインなどの通常のワークフロー・アクションは、引き続き使用できます。また、これらのアイテムは、索引付けされて検索結果に表示され、レプリケーション、アーカイブ、他のプロセスまたはアプリケーションで使用できます。
重要: ワークフロー・アイテムをレプリケートするには、その前に、いくつかの検討事項があります。この項では、プロセスを説明しますが、詳細には触れません。ワークフロー・アイテムのレプリケーションを設定する前に、コンサルティング・サービスに問い合せてください。 |
自動レプリケーションを設定するには、その前に、いくつかの点に留意する必要があります。
データの整合性の消失: 意図的かどうかに関係なく、コンテンツを途中でリリースすると、ビジネス・プロセス管理、コンテンツのアクセス可能性および情報整合性に予期しない影響を与える可能性があります。ワークフロー内にあるアイテムのリリースを検討する前に、起こり得る悪影響について十分に考慮する必要があります。
ワークフロー情報を取得できない: ワークフローは、プロセスとコンテンツの組合せです。コンテンツをリリースし、レプリケーションおよび他のプロセスで使用することは可能ですが、ワークフローの状態情報の取得およびレプリケートは、(カスタマイズおよびコンサルティング・サービスの支援がないと)実行できません。
ソース・インスタンスでワークフローのコンテンツをレプリケートし、そのインスタンスのワークフロー内を通過せずにターゲット・インスタンスでリリースした場合は、コンテンツのワークフロー状態を手動で再設定する作業がリカバリ・プロセスに必要となります。
以前のワークフロー状態へのリカバリは、実際の障害時リカバリでのみ必要となるため、ほとんどの場合、ワークフロー情報のクローニングは不要です。他のすべての場合は、ワークフローの終了後にコンテンツ・アイテムが通常どおりレプリケートされ、ワークフローの途中でレプリケートされたバージョンまたはリビジョンよりもそのコンテンツ・アイテムが優先されます。
インポートしたコンテンツ・アイテムがワークフローに入らない: ソース・インスタンス上のワークフロー内にある間にレプリケートされたコンテンツ・アイテムは、追加のカスタマイズおよびコンサルティング・サービスからの支援がないと、ターゲット・インスタンス上のワークフローに入りません。レプリケートされたコンテンツ・アイテムは、ターゲット・インスタンスにチェックインされ、リリースされます。
レプリケートされたワークフロー・アイテムのリストアには手動操作が必要: 一部のワークフロー情報はメタデータとして取得してワークフローの手動リストアに使用できます。ワークフローへのコンテンツ・アイテムの入力は、チェックイン・アクションによってのみトリガーされます。したがって、元のワークフローにアイテムをリストアするには、新しいリビジョンを作成する必要があります。
これにより、ソース・インスタンスとターゲット・インスタンスのリビジョン数に不一致が生じます。ターゲット上のコンテンツ・アイテムを、ソースでの以前の状態にできるだけ近い状態にリカバリするため、2つのインスタンス間の不一致は意図的に導入され、回避できません。
ワークフロー内にある間にリリースされていないコンテンツ・アイテム1には、次のことが当てはまります。
このコンテンツ・アイテムは、未リリース状態でワークフロー内を移動します。
このコンテンツ・アイテムは、ワークフロー内にある間はレプリケーションの候補になりません。
このコンテンツ・アイテムは、指定されたワークフロー・ステップ・レビューアおよび管理者のみが使用できます。
このコンテンツ・アイテムは、ワークフローを完了すると、コンテンツ・サーバーにリリースされ、索引付けされ、レプリケーションの候補になります。
ワークフロー内にある間にリリースされるコンテンツ・アイテム2には、次のことが当てはまります。
このコンテンツ・アイテムはワークフロー内を移動し、指定されたとおりにリリースされます。リリースした後のアイテムを未リリースにすることはできません。指定しないかぎり、ワークフロー中に作成されたコンテンツ・アイテムの新規リビジョンはリリースされません。
ワークフロー内にある間にリリースされたコンテンツ・アイテムは、検索結果に表示され、適切なセキュリティ・アクセス権があるユーザーに表示されます。
ユーザーがワークフロー内のリリース・アイテムを編集、チェックアウト、チェックインまたは更新するには、そのアイテムが存在するステップの指定されたユーザーであり、試みるアクションがそのステップで許可されている必要があります。
ワークフロー内にある間にリリースされるコンテンツ・アイテムは、自動レプリケーションの候補です。レプリケータでは、そのアイテムがワークフロー内にない場合と同様に処理されます。
ワークフローを完了したコンテンツ・アイテムは、通常の方法でレプリケートされ、ワークフローの途中でレプリケートされた既存のコンテンツ・アイテム・バージョンより優先されます。
レプリケーションやその他の目的でワークフロー内のコンテンツ・アイテムをリリースする場合の詳細および影響は、コンサルティング・サービスに問い合せてください。
特定のフォルダに保存されたドキュメントを基準ワークフローで処理することが必要になる場合があります。ただし、フォルダに基づいて基準ワークフローを作成した場合、フィールド・リストには、folder
という基準オプションはリストされません。基準ワークフローのフィールド・リストには、タイプがtext
またはlong text
のフィールドのみがリストされます。フォルダ(xCollectionID)は整数フィールドであるため、オプションではありません。
「条件の編集」フォームではフォルダ・フィールドを選択できませんが、そのフォルダ・フィールドはイベントの条件として定義できます。最初のステップの入力イベントで、基準を設定して、該当するフォルダ番号(xCollectionID)があるかどうかを確認します。基準を満たさない場合、アイテムはワークフローから終了します。
このようなワークフローを設定する一般的な手順は、次のとおりです。
新しい基準ワークフローを開始し、ワークフローで使用するセキュリティ・グループを選択します。
条件定義セクションで、システムに入力されるすべてのドキュメントを監視するグローバル基準を定義します。これは、次のような簡単な基準で構いません。
Field: ContentID Operator: Matches Value: *
これによって、システムに入力されるセキュリティ・グループに一致するすべてのコンテンツ・アイテムがチェックされます。フォルダからのアイテムのみを監視することもできます。その場合は、基準のベースとなるすべてのフォルダに対するデフォルトとなる追加のメタデータ・フィールドを設定します。
複数のワークフローがある場合は、このワークフローですべてのコンテンツをフィルタリングし、このワークフローの最初のステップで複数の基準の設定を介してサブワークフローにジャンプするのが最善の方法です。
ワークフローに最初のステップを追加します。
「イベント」タブで、入力イベントの「編集」をクリックします。
「ジャンプ」タブで、「追加」をクリックします。
わかりやすいジャンプ名(たとえば、Folder Criteria)を指定し、「OK」をクリックします。
ジャンプの基準として、次のように入力します。
Field: Folder Operator: Not Equals Value: Folder ID on which the workflow should be based
終了したら、「追加」をクリックします。
ターゲット・ステップとして「終了して親ステップへ移動」を選択し、両方の0パラメータを10に変更します(例: @wfExit(10,10)
)。これにより、フォルダにないドキュメントはワークフローの外へ出されます。
入力イベントで「OK」をクリックし、「新しいステップの追加」ダイアログで「OK」をクリックします。
ワークフローのその他の部分に必要なジャンプ、ステップおよびイベントを追加し、ワークフローを有効にします。
ワークフロー・ステップ内でGET_SEARCH_RESULTSサービスを実行したときに、予想した結果が得られない場合があります。ワークフロー・イベントでサービスを実行すると、ワークフローのデータ・バインダがサービスによって使用されるため、データの破損が発生する可能性があります。
この問題を解決するには、セキュリティ・グループの値を一時変数として一時的に設定します。次に、現行のセキュリティ・グループ値を消去し、検索結果をコールした後で、セキュリティ・グループを元の設定に戻します。これにより、求めていた結果が戻ります。
複数の承認者が必要なワークフロー・ステップでは、時間指定されたワークフロー更新サイクル中に、ドキュメントをすでに承認したユーザーに通知が再度送信される場合があります。追加の通知を抑止するには、wfSetIsNotifyingUsers
ワークフロー関数を使用します。ワークフローのスクリプト・セクションにあるワークフロー・ステップで使用すると、現行のドキュメント・アクション(チェックイン、承認、更新など)を実行する際にワークフロー通知を送信するかどうかを判定する内部フラグが設定されます。この抑止は、電子メールおよびキュー内のワークフローの更新に適用されます。
この関数をwfIsFinishedDocConversion
と組み合せて使用すると、変換が終了するまで通知を抑止できます。これは、自動コントリビューション・ステップからのドキュメントの進行は阻止せず、キュー内のワークフローの更新および電子メール通知を停止します。
これらの通知は、失われていません。今後のワークフロー・イベントで、wfSetIsNotifyingUsers
関数を使用して通知(キュー内のワークフローの更新およびワークフロー・メール)を抑止しない場合、現行のステップに参加しているすべてのユーザーに通知されます。
次に、スクリプト・セクションで使用できるその他の関数を示します。
wfIsFinishedDocConversion
: 現行のドキュメント・アクションの終了後に、ドキュメントが「WWW生成」ステータスになるかどうかを示す結果を返します。
wfIsNotifyingUsers
: ワークフローで、この特定のワークフロー・イベントに関するすべてのワークフロー通知が現在抑止されているかどうかを示す結果を返します。
これらのすべての関数の使用方法の詳細は、Oracle Fusion Middleware Idocスクリプト・リファレンス・ガイドを参照してください。
この項では、いくつかの一般的なワークフローの問題に対する解決策を提供します。
現象
ワークフローのコンテンツ・アイテムが「編集」ステータスまたは「WWW生成」ステータスで、アクションが必要なことを示す電子メールがレビューアに通知されていません。
問題
Inbound Refineryでファイルが正しく変換されていません。
推奨事項
リポジトリ・マネージャまたはワークフローのコンテンツ・アイテム・ページで、コンテンツ・アイテムのステータスを表示します(「コンテンツ・マネージャ」→「アクティブなワークフロー」→「<Workflow_Name>」の順に選択してアクセスします)。変換の失敗に関する詳細を確認するには、コンテンツ情報ページを表示します。
変換に失敗した理由を判断します。
Inbound Refineryまたは変換アドオン製品が問題の原因となっている場合:
ファイルが正しく変換されるように問題を修正します。
リポジトリ・マネージャ・ページまたはコンテンツ情報ページから変換対象ファイルを再送信します。コンテンツ・アイテムがワークフロー内を進行するようになります。
基準ワークフローのファイルが問題の原因で、ワークフロー内にコンテンツ・アイテムが1つのみある場合:
ネイティブ・ファイルのコピーを保存します。
ワークフローを無効にしてコンテンツ・アイテムをリリースします。
リポジトリ・マネージャまたはコンテンツ情報ページを使用して、リリースされたリビジョンを削除します。
ファイルが正しく変換されるように問題を修正します。
コンテンツ・アイテムを再度チェックインし、ワークフロー・プロセス内を完全に移動できるようにします。
基準ワークフローのファイルが問題の原因で、ワークフロー内に複数のコンテンツ・アイテムがある場合:
ネイティブ・ファイルのコピーを保存します。
リポジトリ・マネージャを使用して、スタックしているリビジョンを削除します。(ワークフローを無効にすることもできますが、ワークフロー内のすべてのコンテンツ・アイテムがリリースされることになります。)
ファイルが正しく変換されるように問題を修正します。
コンテンツ・アイテムを再度チェックインし、ワークフロー・プロセス内を完全に移動できるようにします。
基本ワークフローのファイルが問題の原因で、ワークフロー内にコンテンツ・アイテムが1つのみある場合:
ネイティブ・ファイルのコピーを保存します。
ワークフローを取り消し、システムからリビジョンを削除します。
ファイルが正しく変換されるように問題を修正します。
コンテンツ・アイテムを基本ワークフローに再度コントリビュートし、ワークフロー・プロセス内を完全に移動できるようにします。
基本ワークフローのファイルが問題の原因で、ワークフロー内に複数のコンテンツ・アイテムがある場合:
ネイティブ・ファイルのコピーを保存します。
リポジトリ・マネージャを使用して、スタックしているリビジョンを削除します。(ワークフローを取り消すこともできますが、ワークフロー内のすべてのコンテンツ・アイテムがシステムから削除されることになります。)
ファイルが正しく変換されるように問題を修正します。
コンテンツ・アイテムを基本ワークフローに再度コントリビュートし、ワークフロー・プロセス内を完全に移動できるようにします。
現象
ワークフロー内のコンテンツ・アイテムが「レビュー」ステータスにあり、最小限のレビューアによって承認されているのに、リビジョンが次のステップに移動しません。
問題
コンテンツ・アイテムがワークフローの終了条件を満たしていません。
推奨事項
ワークフロー・ステップの終了条件定義をチェックし、ドキュメントが終了条件を満たしていない理由を確認します。
外部プロセスと相互作用してファイルが終了するかどうかを判断します。外部プロセスとの問題を解決し、終了条件が満たされるかどうかを確認します。
終了条件または終了処理(あるいはその両方)にエラーがある場合は、ドキュメントをチェックアウトし、終了条件を満たすように修正したメタデータでドキュメントをチェックインします。