| Oracle® WebCenter Content Content Serverアプリケーション管理者ガイド 11g リリース1 (11.1.1) B65036-02 |
|
 前 |
 次 |
この章では、Oracle WebCenter Content Serverで使用可能なワークフロー機能を使用するための概念、タスクおよびリファレンス情報を示します。
この章には次の項があります。
ワークフローは、コンテンツをレビューして承認し、システムにリリースするためのルーティング方法を指定するために使用します。
たとえば、ワークフローを使用すると、新しいポリシーを組織のイントラネットにリリースする前に、法務部、人事部および幹部の適切な担当者によるレビューと承認を確実に実行できます。また、ワークフローを設定して、マーケティング資料の承認とサインオフをタイムリに取得することもできます。ワークフロー内のコンテンツのレビュー準備が完了すると、ユーザーに電子メールで通知されます。
効果的なワークフローの設計は、反復プロセスです。最初の計画の後、ワークフローはプロセスの実装に沿って調整されます。最初の段階で優れた計画を立てておくと、やり直しの量を減らすことができます。詳細は、第4.2項「ワークフローの計画」を参照してください。
ワークフローには3つのタイプがあります。
基本ワークフローでは、特定のコンテンツ・アイテムのレビュー・プロセスを定義し、手動で開始する必要があります。
基準ワークフローは、事前定義済の基準に一致するメタデータに基づいて、自動的にワークフローに入るコンテンツに使用されます。
サブワークフローは、別のワークフロー内のステップから開始され、基準ワークフローと同じ方法で作成されます。サブワークフローは、大規模で複雑なワークフローを管理可能なピースに分割する場合に役立ちます。
ビジネス・プロセスにワークフローを設定すると、様々な利点が得られます。
ワークフローは、優れたレポート・メトリックを提供します。ワークフローでは、コンテンツのライフ・サイクルの様々な時点でコンテンツをサインオフしたユーザーの監査証跡を作成できます。
ワークフローは、適切な情報を適切なユーザーに渡すのに役立ちます。
ワークフローの設計では、ビジネス・プロセスの調査と理解が必要となるため、改善可能な領域の検出に役立ちます。
この項では、ワークフローの概要、使用方法およびワークフローがビジネス活動に与える利点を示します。ここで説明する内容は次のとおりです。
ステップは、ワークフローのプロセスと機能を定義します。各ワークフローは、複数のレビューと通知のステップで構成され、各ステップには、コンテンツを承認または却下する複数のレビューアを割り当てることができます。ワークフローの各ステップには、一連のユーザーとステップ・タイプを定義する必要があります。
あるステップに対して定義したユーザーは、そのステップ・タイプで許可されているタスクのみを実行できます。
| ステップ・タイプ | 説明 |
|---|---|
|
基本ワークフローの最初のステップ。管理者は、ワークフローの作成時にコントリビュータを定義します。 |
|
|
基準ワークフローの最初のステップ。このステップには関連する事前定義済のユーザーはありません。自動的にワークフロー・プロセスに入るコンテンツ・アイテムをチェックインしたコントリビュータがワークフローの参加者になります。 |
|
|
ユーザーはコンテンツを承認または却下できますが、コンテンツの編集はできません。また、ユーザーがコンテンツを承認して電子シグネチャで署名する必要があることを指定できます。 |
|
|
ユーザーは必要に応じてコンテンツを編集し、承認または却下して、リビジョンを維持できます。 |
|
|
ユーザーは必要に応じてコンテンツを編集し、承認または却下して、新しいリビジョンを作成できます。 |
ワークフローが有効になると、そのワークフローは複数の特定なステージに移動します。
コンテンツ・アイテムが特定のステップの最小限のレビューアによって承認されると、そのコンテンツ・アイテムはワークフローの次のステップに進みます。
ステップに定義されている必要な承認の数が0の場合、レビューアには通知されますが、コンテンツは自動的に次のステップに進みます。
いずれかのレビューアがコンテンツを却下した場合、そのコンテンツは最新のレビュー/リビジョンの編集ステップまたはレビュー/新規リビジョンの作成ステップに戻ります。該当するステップがない場合、コンテンツは最初の作成者に戻ります。
編集基準の定義方法に応じて、最新のレビュー/リビジョンの編集ステップまたはレビュー/新規リビジョンの作成ステップで、リビジョンが新規作成または更新される可能性があります。
リビジョンはシステムにリリースできます。
ワークフローの終了後: ワークフローの最後のステップでコンテンツが承認されると、そのコンテンツ・アイテムはシステムにリリースされます。
ワークフローの終了前: サイド・エフェクトを設定してドキュメントを編集状態からリリースすると、そのドキュメントの索引付け、検索およびアーカイブが可能になります。これは主に、経費精算書など、Webへの公開が不要なビジネス・ルーティングに使用します。
通常、基本ワークフローに複数のコンテンツ・アイテムが含まれている場合は、すべてのアイテムがワークフローを完了するまで、どのアイテムもシステムにリリースされません。ただし、コンテンツ・アイテムをサイド・エフェクトとして編集状態からリリースする場合、そのコンテンツ・アイテムは基本ワークフロー内のすべてのアイテムを待たずにリリースできます。
ジャンプ、トークンおよびエイリアスを使用して標準ワークフロー・プロセスをカスタマイズし、柔軟性を高めることができます。詳細は、第4.5項「ワークフローのカスタマイズ」を参照してください。
トークンおよびエイリアスを使用すると、ワークフローでユーザーを柔軟に指定できます。トークンは、不明なユーザーを指定するために使用できる変数です。エイリアスを使用すると、ワークフロー・ステップ内にユーザー・グループを含めることができます。
ジャンプを使用すると、条件文を作成して、コンテンツが同じワークフロー内の別の経路を通過するように分岐させたり、コンテンツ・アイテムを基準ワークフローまたはサブワークフローから別の基準ワークフローまたはサブワークフローに転送することができます。
終了条件を使用すると、条件文を作成して、たとえば、ワークフロー・ステップ中に外部プロセスによってメタデータが変更された後などに、特定の条件に合致しないかぎり、コンテンツが次のステップに移動しないようにできます。
カスタム・メタデータ・フィールドを作成し、それを使用して異なるワークフローをトリガーすることもできます。
次の図に、通常のワークフロー・プロセスを示します。
ワークフローの各ステップには、開始時、更新時および終了時の3つのイベントがあります。
開始時イベント・スクリプトは、ステップに入るときに評価されます。開始時イベント・スクリプトによって、ジャンプまたは終了が発生しなかった場合は、ユーザー、エイリアスおよびトークンが評価され、電子メールで通知されます。
更新時イベント・スクリプトは、様々な時点で評価されます(たとえば、1時間ごとの更新サイクルやリビジョンのチェックインの際)。更新時イベント・スクリプトが評価されるたびに、追加の終了条件が評価されます。
終了時イベント・スクリプトは、リビジョンがステップの承認要件を完了し、ステップの追加の終了条件が満たされたときに評価されます。
ジャンプの詳細は、第4.5.3.1項「ジャンプおよびイベント」を参照してください。
|
重要: リビジョンが却下された場合、更新時および終了時のイベント・スクリプトは実行されません。却下の際に評価するコードは、却下されたコンテンツの送信先ステップの開始時イベント・スクリプトに存在している必要があります。 |
コンパニオン・ファイルは、ワークフローのリビジョンの状態に関する情報を保持するテキスト・ファイルです。ワークフローの存続期間中にのみアクティブになります。
コンパニオン・ファイルは、リビジョンが通過したステップを追跡し、ワークフロー変数の現行の値を保持します。
ワークフローの各リビジョンには、1つのコンパニオン・ファイルがあり、リビジョンがワークフロー内にある間は存在します。リビジョンがワークフローからリリースされると、そのコンパニオン・ファイルは削除されます。
コンパニオン・ファイルのフォーマットはHDAファイル・フォーマットで、コンテンツIDの名前が付けられています(例: HR_004.hda)。
各コンパニオン・ファイルには、2つのセットのデータが含まれています。
LocalDataプロパティ・セクションには、親リストおよび他のワークフロー変数が定義されています。
WorkflowActionHistory ResultSetセクションには、リビジョンのワークフロー履歴に関連のあるステップ、ワークフロー・アクションおよびユーザーのレコードが記述されています。
コンパニオン・ファイルを保存するには、/config/config.cfgファイルにIsSaveWfCompanionFiles構成変数を追加し、パラメータをTRUEに設定します。詳細は、Oracle WebCenter Content 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 WebCenter Contentユーザーズ・ガイド』を参照してください。
この章では、ワークフロー・タイプを選択してワークフローを計画する際に実行する手順について説明します。次の内容について説明します。
ワークフローの設計を開始する前に、現在運用しているプロセスを評価します。ワークフローに現行プロセスを適合させることもできます。たとえば、プロジェクトで、ユーザー間の情報の管理のために電子メール・ループを使用している場合は、そのようなシナリオをワークフロー設計に取り込むことは可能でしょうか。
ワークフローを情報の検証のために使用しますか。コラボレーションのために使用しますか。対処する特定の問題は何ですか。現行のプロセスとその短所を理解すると、問題を解決するワークフローの設計が可能になります。
ワークフローに関係するユーザーは誰ですか。アイテムのレビュー準備が完了していることを、どのユーザーに通知しますか。どのユーザーにアイテムの編集権限を付与しますか。アイテムを最終的にサインオフするのはどのユーザーですか。
同様に重要となるのは、どのユーザーをワークフローから除外するかということです。
ワークフローの関係者に、どのようなトレーニングを提供しますか。
ワークフロー内のアイテムをどのように処理しますか。アイテムが承認、却下または更新された場合、どのようなアクションを実行しますか。ワークフロー内にアイテムが長くとどまりすぎた場合、どのように処理しますか。
ワークフローの次のステージにアイテムを移動する必要があるのはいつですか。ワークフローが完了したかどうかを決定する基準は何ですか。
ワークフローに参加する場合、ユーザーはどこにアクセスしますか。Webインタフェースまたは独自に設計した別のインタフェースはありますか。
承認および却下をどのように処理しますか。監査情報を格納しますか。承認またはコンテンツ・アイテム・リビジョンの認証(電子シグネチャ)は必要ですか。
使用するワークフローのタイプを決定する際は、次の事項を検討します。
特定の基準に基づいて有効になるワークフローではなく、非定型のワークフローを指定する場合。
同じ一連のステップで、複数のコンテンツ・アイテムをルーティングする場合。各アイテムは個別にステップを移動しますが、ワークフロー内のすべてのアイテムが終了するまでリリースされません。
ワークフローにコンテンツ・アイテムをコントリビュートするようにユーザーに通知または催促する場合。
頻繁に使用しないワークフローを指定する場合。
関連するコンテンツ・アイテムのグループ用にレビュー・プロセスを定義する場合。
ワークフローを開始するユーザーを指定する場合。コンテンツが基本ワークフローに入ることができるのは、ワークフロー権限があるユーザーがそのワークフローを開始した場合のみです。
特定のメタデータ値に基づいて自動的にコンテンツをワークフローに入れる場合。
特定の基準に一致する単一のコンテンツ・アイテムをルーティングする場合。基準に一致する複数のアイテムをルーティングできますが、これらのアイテムは1つのユニットとしてワークフロー内を移動しません。
個別のドキュメントに対して標準レビュー・プロセスを設定する場合。
頻繁に使用するワークフローを指定する場合。
多数のユーザーに対してワークフローをオープンする場合。基準ワークフローには、ワークフロー権限のないユーザーのコンテンツを入れることができます。
使用するワークフローのタイプを決定する際は、次の重要事項を考慮してください。
コンテンツが間違ったセキュリティ・グループまたはメタデータ値を使用してチェックインされた場合、そのコンテンツは誤って基準ワークフローに入る可能性があります。
ユーザーが同一の基本ワークフローを使用してコンテンツを頻繁に処理する場合は、基準ワークフローを設定してプロセスの自動化を検討します。
複数のワークフローに対して、同一の基準または重複した基準を使用することはできません。コンテンツ・アイテムが複数のワークフローの基準に一致している場合、そのコンテンツ・アイテムは、リスト内の最初のワークフローに入ります。
ワークフローを管理するときは、セキュリティに関する次の問題を考慮してください。
各ワークフローは、セキュリティ・グループに関連付けられています。
基準ワークフローの場合は、同じセキュリティ・グループ内のコンテンツ・アイテムのみがワークフローに入ります。
基本ワークフローの場合、新しいコンテンツ・アイテムはワークフローのセキュリティ・グループに割り当てられ、既存のコンテンツ・アイテムはワークフローのセキュリティ・グループに属している必要があります。
ワークフローは、同じセキュリティ・グループの別のワークフローにのみジャンプできます。
ワークフローがアクティブである間は、ワークフローのセキュリティ・グループを変更できませんが、ワークフロー・プロセス内のアイテムのセキュリティ・グループは変更できます。
ワークフローを設定して開始するには、ワークフロー権限およびコンテンツのセキュリティ・グループに対する管理権限が必要です。
ワークフロー・テンプレートを使用してコントリビューション・ステップを開始できます。
ワークフローのコントリビュータになるには、ワークフローのセキュリティ・グループに対する書込み権限が必要です。
ワークフローを設計する手順は、次のとおりです。
ワークフローのフローチャートを作成します。第4.3.1項「基準ワークフロー・プロセス」や第4.4.1項「基本ワークフロー・プロセス」などを参照してください。
ワークフローに必要なすべてのメタデータがあることを確認します。ない場合は、ワークフローを設定する前に、必要なメタデータを作成します。
ワークフローに必要なエイリアスを設定します。エイリアスの作成は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』を参照してください。
ワークフローのトークンを設定します。詳細は、第4.5.2.2項「トークンの作成、編集または削除」を参照してください。
基本ワークフローまたは基準ワークフローを設定します。使用可能なワークフロー・テンプレートがある場合は、テンプレートを手掛かりとして使用できます。詳細は、第4.6項「ワークフローおよびスクリプトのテンプレート」を参照してください。
必要に応じて、サブワークフローを設定します。
必要に応じて、ジャンプを設定します。詳細は、第4.5.3.2項「ジャンプの作成」を参照してください。
使用可能なスクリプト・テンプレートがある場合は、それを使用してステップ・イベント・スクリプトを作成します。
ジャンプを使用する場合は、各ジャンプのサブワークフローを備えた、マスター・ワークフローの設定を検討してください。
ワークフローをテストします。
基準ワークフローの場合は、定義したセキュリティ・グループおよびメタデータ・フィールド値に一致するテスト用のドキュメントをチェックインします。
基本ワークフローの場合は、テスト用のコンテンツを定義し、ワークフローを開始します。
できるだけ多数の承認/却下シナリオをシミュレーションします。
ワークフローにジャンプが含まれている場合は、できるだけ多数のイベント・シナリオをシミュレーションします。
ワークフローのテストにレビューアを含めて、ユーザーが各自の役割を理解していることを確認します。
ワークフローを設計する際は、次の点に留意してください。
次の操作を実行できます。
基準ワークフローの基準の変更。
基本ワークフローのコンテンツ・アイテムの追加または削除。
ステップの定義の変更(レビューア、終了条件、イベントなど)。
次の操作は実行できません。
ステップの順序の変更。ステップを削除して新しい場所に再作成することは可能です。
ワークフローの途中へのステップの追加。新規ステップは常にワークフローの最後に追加されます。
次に、既存ワークフローの変更に役立つヒントを示します。使用中のワークフローの変更は、時間のかかる困難な作業です。実装前に慎重に設計することが、やり直しの回避に役立ちます。ワークフローの再構築が可能になるまで、これらのオプションは一時的な修正とみなされます。
|
注意: ステップを追加または削除するために、基準ワークフローを無効にしたり、基本ワークフローを取り消した場合、ワークフロー内のリビジョンはすべてリリース(基準ワークフロー)または削除(基本ワークフロー)されます。 |
既存ワークフローのステップを並べ替えるには、次のオプションを検討します。
サブワークフローを作成し、既存ステップからそのサブワークフローへのジャンプを追加します。この変更を既存ステップに加えるために、ワークフローを無効化または取り消す必要はありません。
既存ステップにステップ・イベント・スクリプトを追加して、通常は別のステップで実行されるアクションを定義します。この変更を既存ステップに加えるために、ワークフローを無効化または取り消す必要はありません。
変更(たとえば、ステップの追加)するために、ワークフローの無効化が必要になった場合は、すべてのリビジョンがワークフローから即時にリリース(基準ワークフロー)または削除(基本ワークフロー)されます。コンテンツをリリースしないでワークフローを無効にするには、次の手順に従います。
最初に、そのワークフローを、ステップの順序は元のワークフローと同じだが、ステップ・ロジックがない静的なワークフローにクローニングします。コンテンツはいずれかのステップに入り、移動されるまでそこにとどまります。
次に、元のワークフローに更新時イベントを作成します。このイベントは時間でトリガーされ、適切なステップでコンテンツを静的なクローン・ワークフローにプッシュします。
元のワークフローからコンテンツがなくなったら、そのワークフローを無効にして必要な変更を加え、再び有効にします。次に、同じ時限イベント・ロジックを使用して、クローン・ワークフローのコンテンツを元のワークフローに戻します。
基準ワークフローは、個々のドキュメントが事前定義済の基準に一致した場合に自動的にワークフローに入れるレビュー・プロセスを設定するために使用します。たとえば、新しい注文書が生成されたときは、その注文書を特定のレビューアに自動的にルーティングして承認を得ることができます。
基準ワークフローには、次のものが含まれます。
セキュリティ・グループと1つのメタデータ・フィールドによって定義された基準。
事前定義済ユーザーのない自動コントリビューション・ステップ。
1つ以上のレビューア・ステップ(1ステップ当たりのレビューア数は1人以上)。
いくつかの例外はありますが、サブワークフローの設定手順は基準ワークフローと同じあり、例外については基準ワークフローの設定手順で説明します。
この項では、次の項について説明します。
次の手順に従って、基準ワークフロー・プロセスを簡潔に説明します。
ワークフロー権限があるユーザーが、次の要素を定義して基準ワークフローを設定します。
セキュリティ・グループ。
メタデータ・フィールドおよび値(たとえば、「ContentType」「次に一致する」「PurchaseOrder」)。テキスト・タイプまたはロング・テキスト・タイプのフィールドを使用できます。
レビュー・ステップおよび各ステップのレビューア。
各ステップに必要な承認の数。たとえば、次のステップに進む前に、すべてのレビューアの承認が必要かどうか。
エイリアスおよびエイリアス・グループ内のユーザー。
必要なトークン。
ワークフロー権限があるユーザーが、基準ワークフローを有効にします。
定義されたセキュリティ・グループおよびメタデータ・フィールド値と一致するコンテンツがチェックインされると、そのコンテンツはワークフローに入ります。
リビジョンのレビュー準備が完了していることが、最初のステップのレビューアに電子メールで通知されます。
レビューアがリビジョンを承認または却下します。
ステップがレビューア・ステップの場合、レビューアは必要に応じて変更なしでコンテンツ・アイテム・リビジョンに署名して承認できます(ドキュメントを変更すると、別の識別子が作成され、既存の電子シグネチャが無効化されます)。
レビューア/コントリビュータ・ステップの場合、レビューアはリビジョンをチェックアウトして編集し、チェックインして戻してから、リビジョンを承認できます。たとえば、編集者は、ワークフロー内のアイテムのコンテンツを変更できます。
ユーザーがリビジョンを却下した場合、ワークフローは前のコントリビューション・ステップに戻り、そのステップのユーザーには電子メールで通知されます。
リビジョンが最小限のユーザー数によって承認された場合、そのリビジョンは次のステップに進みます。最低承認数が0の場合、リビジョンは自動的に次のステップに進みます。
すべてのステップが完了すると、リビジョンはシステムにリリースされます。
各基準ワークフローには、一意の基準が必要です。コンテンツ・アイテムが2つのワークフローの基準に一致している場合、そのコンテンツ・アイテムはワークフロー定義リストの最初のワークフローに入ります。
基準ワークフローに割り当てられたすべてのユーザーには、選択されたセキュリティ・グループに対する読取り権限が必要です。コントリビュータがリビジョンをチェックインおよびチェックアウトするには、選択されたセキュリティ・グループに対する書込み権限が必要です。
基準ワークフローが有効である間は、ステップの追加や削除はできません。
基準ワークフローが無効なときにチェックインされたコンテンツ・アイテムは、ワークフロー・プロセスをバイパスしてシステムにリリースされます。
基準ワークフローを無効にすると、ワークフロー内のリビジョンがシステムにリリースされます。
基準ワークフローでは、サブワークフローおよび同じセキュリティ・グループ内の他の基準ワークフローへのジャンプを使用することも、同じワークフローの他のステップにジャンプすることもできます。
ワークフローに少なくとも1つのレビューア/コントリビュータ・ステップが作成されていると、却下されたリビジョンは、最初の作成者ではなく、そのステップに戻されます。
アイテムのセキュリティ・グループが、ワークフローのセキュリティ・グループと一致しない場合、そのアイテムはワークフローに入りません。
基準が他の基準ワークフローとは異なるようにします。
「フィールド」で「コンテンツID」を使用し、かつ、Oracleデータベースを使用している場合は、値をすべて大文字で入力します。他のすてべのフィールドでは、大文字と小文字の両方を使用できます。
「フィールド」で「コンテンツID」を使用している場合は、「値」フィールドの下の「選択」をクリックして、既存のコンテンツ・アイテムを選択します。
「レビューアの最低必要人数」フィールドにゼロ(0)を入力すると、リビジョンがステップに到達したことがレビューアに通知され、そのリビジョンは自動的に次のステップに渡されます。レビューアは、そのステップではリビジョンを承認、却下または編集できません。
基準ワークフローまたはサブワークフローを作成するには、次の手順に従います。
「メイン」メニューから「管理」→「管理アプレット」を選択します。「ワークフロー管理」をクリックします。「検索条件」タブをクリックします。
「追加」をクリックします。
「ワークフロー名」フィールドに名前を入力します。最大長は30文字です。特殊文字(; @ &など)は使用できません。ワークフロー作成後にワークフロー名を変更することはできません。
「説明」フィールドに、ワークフローの詳細を入力します。
このワークフローのコンテンツ・アイテムが属するセキュリティ・グループをリストから選択します。
「元の作成者の編集ルール」からオプションを選択して、アイテムが却下された場合に、最初の作成者がリビジョンを編集できるかどうか、または、新規リビジョンを作成できるかどうかを指定します。
ワークフロー・テンプレートを使用するには、「テンプレートの使用」チェック・ボックスを選択し、テンプレート名を選択します。このチェック・ボックスは、現在テンプレートが存在する場合にのみ表示されます。詳細は、第4.6項「ワークフローおよびスクリプトのテンプレート」を参照してください。
基準ワークフローを作成するには、「条件定義を設定する」チェック・ボックスを選択します。サブワークフローを作成するには、このチェック・ボックスの選択を解除します。この選択は後で変更することもできます。
基準ワークフローの場合は、「フィールド」、「演算子」および「値」で適切な値を選択して基準を定義します。たとえば、「Review Process」「次に一致する」「HRBenefits」のような基準になります。「フィールド」の値としては、「コンテンツID」、「作成者」、「タイプ」、「アカウント」およびテキスト・タイプまたはロング・テキスト・タイプのカスタム・メタデータがあります。
「OK」をクリックします。
ステップの作成または別のステップの追加にテンプレートを使用しなかった場合は、「ワークフロー管理」画面の右側のペインで、「追加」をクリックします。
「新しいステップの追加」/「ステップの編集」画面が開きます。
適切なステップの名前を入力します。ステップ作成後に名前を変更することはできません。ステップには、通常、わかりやすい名前を付けます(たとえば、EditorialReviewやTechnicalReviewなど)。
レビューアに電子シグネチャの資格証明の提供を要求するには、「承認にシグネチャが必要」を選択します。このオプションは、電子シグネチャ・コンポーネントが有効になっている場合にのみ使用できます。
電子シグネチャは、ファイルのコンテンツを特定のリビジョンで一意に識別し、シグネチャと特定のレビューアを関連付けます。このオプションを選択すると、レビューアに表示されるステップのオプションのリストでは、標準の「承認」アクションが「署名と承認」アクションに置換されます。
ステップの説明を入力します。
このステップのユーザーの認可レベルを指定します。
ユーザーは現在のリビジョンをレビューできます: ユーザーはリビジョンを承認または却下できますが、リビジョンの編集はできません。
ユーザーは現在のリビジョンをレビューおよび編集(置換)できます: ユーザーはリビジョンを編集、承認または却下できます。編集しても、リビジョンは更新されません。
ユーザーは現在のリビジョンをレビューするか、新規リビジョンを作成できます: ユーザーはリビジョンを編集、承認または却下できます。編集すると、リビジョンが更新されます。元のコンテンツは保持され、変更の監査証跡が提供されます。
ステップに追加するユーザーのタイプを選択します。1つのステップに対して、複数のタイプのユーザーを定義できます。
エイリアスで定義されたユーザー・グループを追加するには、「エイリアスの追加」をクリックします。「ステップへのエイリアスの追加」画面が開きます。表示されたリストから、エイリアスを選択します。
個々のユーザー・ログインを追加するには、「ユーザーの追加」をクリックします。「ステップへのユーザーの追加」が開きます。
ユーザー・リストを絞り込むには、「フィルタの使用」チェック・ボックスを選択し、「フィルタの定義」をクリックし、フィルタ基準を選択して「OK」をクリックします。
ユーザーの範囲を選択するには、最初のユーザーをクリックし、[Shift]を押しながら範囲の最後のユーザーをクリックします。
ユーザーを個別に選択するには、[Ctrl]を押しながら各ユーザー名をクリックします。
トークンで定義した可変ユーザーを追加するには、「トークンの追加」をクリックします。「ステップへのトークンの追加」画面が開きます。トークンの作成の詳細は、第4.5.2.2項「トークンの作成、編集または削除」を参照してください。
「OK」をクリックします。
「終了条件」タブをクリックします。
リビジョンが次のステップに進むには、何人のレビューアの承認が必要であるかを指定します。
すべてのレビューアの承認が必要な場合は、「すべてのレビューア」を選択します。
リビジョンを承認する必要がある最小限のレビューア数を指定するには、「レビューアの最低必要人数」を選択し、数値を入力します。
通常、終了条件は、ワークフロー・ステップ中にコンテンツが外部プロセスによって変更される可能性がある場合に役立ちます。次のステップに進むために、ステップに終了条件を追加する必要がある場合は、次の手順を使用してください。
「追加終了条件を使用」チェック・ボックスを選択します。
「編集」をクリックします。
「追加終了条件の編集」画面が開きます。この画面では、リストから追加の基準を選択できます。
「フィールド」リストから、ワークフロー条件またはメタデータ・フィールドを選択します。
「演算子」リストから演算子を選択します。「演算子」は、「フィールド」に関連する演算子を示す依存選択リストです。
「値」リストから値を選択します。「値」は、「フィールド」で選択したオプションに基づいた依存リストです。
「追加」をクリックして「条件句」に条件文を追加します。「条件句」ボックスに、句が表示されます。AND文で複数の句を追加できます。
必要な条件の数に応じて繰り返します。式を変更するには、「条件句」ボックスで式を選択して、「フィールド」、「演算子」または「値」を変更し、「更新」をクリックします。
条件式を変更するには、「カスタム条件の式」チェック・ボックスを選択し、スクリプトを編集します(たとえば、条件にANDではなくORを使用するなど)。追加終了条件は、trueまたはfalseに評価されるIdocスクリプト文である必要があります。コードをIdocスクリプトのタグ<$ $>で囲まないでください。
|
注意: 「カスタム条件の式」チェック・ボックスの選択を解除すると、式は元の定義に戻り、すべての変更が失われます。 |
「OK」をクリックします。
ワークフローに条件付ステップまたは特別な処理が必要な場合は、「イベント」タブをクリックし、適切なスクリプトを追加してください。詳細は、第4.5.3.2項「ジャンプの作成」を参照してください。
「OK」をクリックします。
必要に応じてステップを追加、編集および削除して、ワークフローを完成します。
左側のペインで、正しいワークフローが選択されていることを確認し、「有効化」をクリックします。
確認画面が開きます。
「はい」をクリックして選択されたワークフローをアクティブにします。
既存の基準ワークフローまたはサブワークフローを変更する手順は、次のとおりです。
|
注意: ステップを追加または削除するために、基準ワークフローを無効にすると、ワークフロー内のすべてのリビジョンがリリースされます。 |
「メイン」メニューから「管理」→「管理アプレット」を選択します。「ワークフロー管理」をクリックします。「条件」タブをクリックします。
左側のペインで、変更するワークフローを選択します。
ステップを追加または削除するには、「無効化」をクリックしてワークフローを無効にします。
左右のペインの「追加」、「編集」および「削除」をクリックして、次の情報を変更します。
ワークフローの説明
セキュリティ・グループ
ワークフローのタイプ(基準ワークフローまたはサブワークフロー)
基準
ステップの説明
ステップのタイプ(レビューア、コントリビュータの同じリビジョン、コントリビュータの新規リビジョン)
ユーザー
イベント
必要な承認数
終了条件
基準ワークフローが有効なときにユーザーをステップに追加できますが、ワークフローのそのステップにリビジョンが現存している場合は、新しいユーザーに通知が即座に送信されません。通知は、スケジュールされたワークフロー・システム・イベントが発生し、ワークフロー内のすべてのアイテムのTIMED_UPDATEが実行された後で送信されます。
ワークフローが無効な場合は、左側のペインで、正しいワークフローが選択されていることを確認し、「有効化」をクリックします。
確認画面が開きます。
「はい」をクリックして選択されたワークフローをアクティブにします。
基準ワークフローまたはサブワークフローを無効にする手順は、次のとおりです。
「メイン」メニューから「管理」→「管理アプレット」を選択します。「ワークフロー管理」をクリックします。「条件」タブを選択します。
ワークフローを選択します。
「無効化」をクリックします。
ワークフロー・プロセスにまだコンテンツ・アイテムが存在している場合は、コンテンツのすべてのリビジョンがリリースされることが通知されます。コンテンツをリリースしない場合は、「いいえ」をクリックして操作を取り消します。「はい」をクリックしてコンテンツをリリースし、ワークフローを無効にします。
ワークフローのステータスが「無効」に変更されます。
基本ワークフローは、特定のコンテンツ・アイテムのレビュー・プロセスを定義します。基本ワークフローは手動で設定および開始し、コンテンツがワークフローに入るための基準を定義する必要はありません。
基本ワークフローには、次のものが含まれます。
1つ以上のコンテンツ・アイテム。
1人以上のコントリビュータを伴う初期コントリビューション・ステップ。
0以上のレビュー・ステップ(1ステップ当たりのレビューア数は0人以上)。
この項では、次の項について説明します。
ワークフロー権限があるユーザーが、次の項目を定義して基本ワークフローを設定します。
コンテンツ: 新しいコンテンツを作成することも、既存のコンテンツを選択することもできます。ワークフローでの処理が終わると、新しいコンテンツはリビジョン1でシステムにリリースされ、既存のコンテンツはそのコンテンツ・アイテムの次のリビジョン番号でシステムにリリースされます。
最初のコントリビュータ: コンテンツをコントリビュートできるユーザーのリストを指定します。
レビュー・ステップ: 各ステップのレビューアおよび各ステップに必要な承認数を指定します。
ワークフロー権限があるユーザーが、基本ワークフローを有効化し、開始します。
コントリビュータに電子メールが送信されます。
コントリビュータは、ワークフローの各コンテンツ・アイテムのファイルをチェックアウトし、再びチェックインできます。
リビジョンのレビュー準備が完了していることが、最初のステップのレビューアに電子メールで通知されます。
レビューアがリビジョンを承認または却下します。
このステップで編集が許可されている場合、レビューアはリビジョンをチェックアウトして編集し、チェックインして戻してから、リビジョンを承認できます。
ユーザーがリビジョンを却下した場合、そのリビジョンは前のコントリビューション・ステップに戻り、そのステップのユーザーに電子メールで通知されます。
リビジョンが最小限のユーザー数によって承認された場合、そのリビジョンは次のステップに進みます。(最低承認数が0の場合、リビジョンは自動的に次のステップに進みます。)
通常、基本ワークフローに複数のファイルが含まれている場合は、すべてのファイルがワークフローを完了するまで、どのファイルもシステムにリリースされません。最後のリビジョンが承認されるまで、完了したコンテンツ・アイテムは「保留」ステータスになります。ただし、コンテンツ・アイテムをサイド・エフェクトとして編集状態からリリースする場合、そのコンテンツ・アイテムは基本ワークフロー内のすべてのアイテムを待たずにリリースできます。
すべてのステップが完了し、すべてのリビジョンが承認されると、それらのリビジョンはシステムにリリースされます。
新しいコンテンツの場合、ワークフローで定義されたコンテンツIDが、リビジョンがシステムにリリースされるときに適用されるコンテンツIDになります。コンテンツIDの作成後に、コンテンツIDを変更することはできません。
1つのコンテンツ・アイテムを複数の基本ワークフローに追加することはできず、これを行うとエラーが発生し、ワークフローが無効になります。
新しいコンテンツは、基本ワークフローのセキュリティ・グループに割り当てられます。
既存リビジョンのセキュリティ・グループは、基本ワークフローのセキュリティ・グループと一致している必要があります。
基本ワークフローに割り当てられたすべてのユーザーには、選択されたセキュリティ・グループに対する読取り権限が必要です。コントリビュータがリビジョンを編集するには、選択されたセキュリティ・グループに対する書込み権限が必要です。
基本ワークフローがアクティブである間は、レビュー・ステップを追加、編集または削除できません。
アクティブなワークフローの取消しは可能ですが、そのワークフロー内のリビジョンはシステムから削除されます。ファイルに対する編集内容は、ローカル・ハード・ドライブにも保存されていないかぎり、失われます。
非アクティブな基本ワークフローは再利用できますが、常に手動で開始する必要があります。
基本ワークフローではジャンプを使用できますが、ジャンプ先は、同じワークフロー内の別のステップのみです。基本ワークフローでは、サブワークフローにジャンプできません。
基本ワークフローを作成する前に、次の点に留意してください。
ワークフローに割り当てるすべてのユーザーには、選択されたセキュリティ・グループに対する読取り権限が必要で、コントリビュータには、書込み権限が必要です。
テンプレートを使用する場合、レビューアが、選択したテンプレートに定義されているレビューアと異なる場合は、レビューアを変更します。
1つのコンテンツ・アイテムを複数の基本ワークフローに追加しないでください。これを行うとエラーが発生し、ワークフローが無効になります。
「レビューアの最低必要人数」フィールドにゼロ(0)を入力すると、リビジョンがステップに到達したときに、レビューアに通知されますが、そのステップではリビジョンの承認、却下、編集はできません。ワークフローは自動的に次のステップに進みます。
「ワークフロー管理」: 「ワークフロー」タブを表示します。このタブには、基本ワークフローがデフォルトで表示されます。
「追加」をクリックします。
「ワークフロー名」フィールドに名前を入力します。ワークフロー名の最大フィールド長は30文字で、特殊文字(; @ &など)を含めることはできません。ワークフローの作成後に、ワークフロー名を変更することはできません。
「説明」フィールドに、ワークフローの詳細を入力します。
このワークフローのコンテンツ・アイテムが属するセキュリティ・グループをリストから選択します。
「元の作成者の編集ルール」からオプションを選択して、アイテムが却下された場合に、最初の作成者が既存リビジョンを編集できるかどうか、または、新規リビジョンを作成できるかどうかを指定します。
テンプレートを使用するには、「テンプレートの使用」チェック・ボックスを選択し、テンプレート名を選択します。このボックスは、テンプレートが存在する場合にのみ表示されます。詳細は、第4.6項「ワークフローおよびスクリプトのテンプレート」を参照してください。
「OK」をクリックします。
ワークフローに新しいコンテンツ・アイテムを追加するには、「新規」をクリックします。
「ワークフローへのコンテンツの追加」(新しいコンテンツ)画面が開きます。
新しいコンテンツ・アイテムのコンテンツIDを入力します。コンテンツ・アイテムの作成後に、コンテンツIDを変更することはできません。最大で30文字まで使用できます。特殊文字($、#など)は使用できません。コンテンツIDを変更するには、リストからコンテンツ・アイテムを削除して、新しいコンテンツ・アイテムを追加します。Oracleデータベースを使用している場合、コンテンツIDはすべて自動的に大文字に変換されます。
「OK」をクリックします。
ワークフローに既存のコンテンツ・アイテムを追加するには、「選択」をクリックします。
「ワークフローへのコンテンツの追加」(既存のコンテンツ)画面が開きます。
コンテンツ・アイテムのリストを絞り込むには、フィルタ、リリース日付またはその両方の基準を指定します。
コンテンツ・アイテムの範囲を選択するには、最初のコンテンツ・アイテムをクリックし、[Shift]を押しながら範囲の最後のコンテンツ・アイテムをクリックします。
コンテンツ・アイテムを個別に選択するには、[Ctrl]を押しながら各コンテンツ・アイテムをクリックします。
既存のコンテンツ・アイテムのセキュリティ・グループは、ワークフローのセキュリティ・グループと同じである必要があります。
初期コントリビューション・ステップのコントリビュータを1人以上定義します。コントリビューション・ステップに複数のタイプのユーザーを定義できます。
エイリアスで定義されたユーザー・グループを追加するには、「エイリアスの追加」をクリックします。「ワークフローへのエイリアスの追加」画面が開きます。
個々のユーザー・ログインを追加するには、「ユーザーの追加」をクリックします。「ユーザーの追加」: 基本ワークフロー画面が表示されます。
ユーザー・リストを絞り込むには、「フィルタの使用」チェック・ボックスを選択し、「フィルタの定義」をクリックし、フィルタ基準を選択して「OK」をクリックします。
ユーザーの範囲を選択するには、最初のユーザーをクリックし、[Shift]を押しながら範囲の最後のユーザーをクリックします。
ユーザーを個別に選択するには、[Ctrl]を押しながら各ユーザー名をクリックします。
レビュー・ステップの作成または別のステップの追加にテンプレートを使用しなかった場合は、右側のペインの「ステップ」ボックス付近にある「追加」をクリックします。
「新しいステップの追加」/「ステップの編集」画面が開きます。
適切なステップの名前を入力します。ステップ作成後に名前を変更することはできません。ステップには、通常、わかりやすい名前を付けます(たとえば、EditorialReviewやTechnicalReviewなど)。
レビューアに電子シグネチャの資格証明の提供を要求するには、「承認にシグネチャが必要」を選択します。このオプションは、電子シグネチャ・コンポーネントが有効になっている場合にのみ使用できます。
電子シグネチャは、ファイルのコンテンツを特定のリビジョンで一意に識別し、シグネチャと特定のレビューアを関連付けます。このオプションを選択すると、レビューアに表示されるステップのオプションのリストでは、標準の「承認」アクションが「署名と承認」アクションに置換されます。
ステップの説明を入力します。
このステップのユーザーの認可レベルを指定します。
ユーザーは現在のリビジョンをレビューできます: ユーザーはリビジョンを承認または却下できます。
ユーザーは現在のリビジョンをレビューおよび編集(置換)できます: ユーザーはリビジョンを編集、承認または却下できます。編集しても、コンテンツ・アイテムのリビジョンは更新されません。
ユーザーは現在のリビジョンをレビューするか、新規リビジョンを作成できます: ユーザーはリビジョンを編集、承認または却下できます。編集では、コンテンツ・アイテムのリビジョンが更新され、元のコンテンツは保持されて、変更の監査証跡が提供されます。
ステップに追加するユーザーのタイプを選択します。1つのステップに対して、複数のタイプのユーザーを定義できます。
エイリアスで定義されたユーザー・グループを追加するには、「エイリアスの追加」をクリックします。「ステップへのエイリアスの追加」画面が開きます。
個々のユーザー・ログインを追加するには、「ユーザーの追加」をクリックします。「ユーザーの追加」: 基本ワークフロー画面が表示されます。リストを絞り込むには、「フィルタの使用」チェック・ボックスを使用します。ユーザーの範囲を選択するには、最初のユーザーをクリックし、[Shift]を押しながら範囲の最後のユーザー名をクリックします。ユーザーを個別に選択するには、[Ctrl]キーを押しながら各ユーザー名をクリックします。
トークンで定義した可変ユーザーを追加するには、「トークンの追加」をクリックします。「トークンの追加」: 基本ワークフロー画面が開きます。詳細は、第4.5.2.2項「トークンの作成、編集または削除」を参照してください。
「終了条件」タブをクリックします。
リビジョンが次のステップに進むには、何人のレビューアの承認が必要であるかを指定します。
すべてのレビューアの承認が必要な場合は、「すべてのレビューア」を選択します。
リビジョンを承認する必要がある最小限のレビューア数を指定するには、「レビューアの最低必要人数」を選択し、数値を入力します。
通常、終了条件は、ワークフロー・ステップ中にコンテンツが外部プロセスによって変更される可能性がある場合に役立ちます。次のステップに進むために、ステップに終了条件を追加する必要がある場合は、次の手順を使用してください。
「追加終了条件を使用」チェック・ボックスを選択します。
「編集」をクリックします。
「追加終了条件の編集」画面が開きます。この画面では、リストから追加の基準を選択できます。
「フィールド」リストから、ワークフロー条件またはメタデータ・フィールドを選択します。
「演算子」リストから演算子を選択します。「演算子」は、「フィールド」に関連する演算子を示す依存リストです。
「値」リストから値を選択します。「値」は、「フィールド」で選択したオプションに基づいた依存リストです。
「追加」をクリックして「条件句」に条件文を追加します。「条件句」ボックスに、句が表示されます。AND文で複数の句を追加できます。
必要な条件の数に応じて繰り返します。式を変更するには、「条件句」ボックスで式を選択して、「フィールド」、「演算子」または「値」を変更し、「更新」をクリックします。
条件式を変更するには、「カスタム条件の式」チェック・ボックスを選択し、スクリプトを編集します(たとえば、条件にANDではなくORを使用するなど)。追加終了条件は、trueまたはfalseに評価されるIdocスクリプト文である必要があります。コードをIdocスクリプトのタグ<$ $>で囲まないでください。
|
注意: 「カスタム条件の式」チェック・ボックスの選択を解除すると、式は元の定義に戻り、すべての変更が失われます。 |
「OK」をクリックします。
ワークフローに条件付ステップまたは特別な処理が必要な場合は、「イベント」タブをクリックし、適切なスクリプトを追加してください。詳細は、第4.5.3.2項「ジャンプの作成」を参照してください。
「OK」をクリックします。
必要に応じてステップを追加、編集および削除して、ワークフローを完成します。
左側のペインで、正しいワークフローが選択されていることを確認し、「開始」をクリックします。
「ワークフローの開始」画面が開きます。
コントリビュータに送信するメッセージを入力します。
「OK」をクリックします。
既存の基本ワークフローを変更するには、次の手順に従います。
「ワークフロー管理」: 「ワークフロー」タブを表示します。
左側のペインで、変更するワークフローを選択します。
アクティブなワークフローのワークフロー・セキュリティ・グループまたはレビュー・ステップ数を変更するには、最初に「取消」をクリックしてワークフローを取り消します。
ワークフローの説明またはセキュリティ・グループを変更するには、左側のペインで「編集」をクリックします。
ワークフローのコンテンツを追加または削除するには、「コンテンツ」ペインの「新規」、「選択」および「削除」をクリックします。
初期コントリビューション・ステップのコントリビュータを追加または削除するには、「コントリビュータ」ペインの「エイリアスの追加」、「ユーザーの追加」および「削除」をクリックします。
|
注意: コンテンツ・アイテムは、基本ワークフローの開始後に変更できますが、コントリビュータに自動的には通知されません。コントリビュータも基本ワークフローの開始後に変更できますが、通知は、新しいコントリビュータに即座には送信されません。 |
「ステップ」ペインの「追加」、「編集」および「削除」をクリックして、次の情報を変更します。
承認時にシグネチャが必要かどうか(任意の電子シグネチャ・オプション)
ステップの説明
ステップのタイプ(レビューアまたはレビューア/コントリビュータ)
ユーザー
イベント
必要な承認数
終了条件
ワークフローは、トークンおよびジャンプを使用して、様々なビジネス・シナリオに応じてカスタマイズできます。トークンはワークフローの可変ユーザーを定義し、ジャンプは別のサイド・エフェクトにワークフローを分岐します。
この項では、トークンおよびジャンプの設定方法と使用方法について説明します。ここで説明する内容は次のとおりです。
ジャンプおよびトークンは、Idocスクリプトを使用して作成されます。トークンおよびジャンプを作成すると、適切な構文および使用方法がインタフェースにより作成されます。ただし、スクリプトは、次のIdocスクリプト関数を使用してカスタマイズできます。使用方法の詳細は、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。
Idocスクリプトの関数
| 関数 | 説明 |
|---|---|
|
現在のステップに定義されている終了条件を取得します。 |
|
|
ワークフローのレビューア・リストにユーザー、エイリアスまたはワークフロー・トークンを追加します。この関数はトークン内でのみ使用します。 |
|
|
コンパニオン・ファイルからローカル状態値を取得します。 |
|
|
コンパニオン・ファイルのキーのローカル状態値を設定します。 |
|
|
現在のステップに関連するステップ名を取得します。 |
|
|
ワークフロー・ステップの終了条件を取得します。 |
|
|
ワークフロー・ステップを終了します。ワークフローを終了する際に使用できます。 |
|
|
コンパニオン・ファイルから状態値を取得します。 |
|
|
内部ワークフロー・ステップ値を取得し、判読可能なラベルに変換します。 |
|
|
ドキュメントがリリースされるかどうかを示します(ワークフローに関するかぎり)。 |
|
|
ジャンプに入ったときに発行される電子メール通知に含まれるメッセージを定義します。 |
|
|
wfLoadDesign |
ワークフローの既存ステップまたはワークフローの終了条件に関する情報を取得するために使用します。 |
|
指定されたユーザー、エイリアスまたはワークフロー・トークンに電子メールを送信します。 |
|
|
現在ワークフローによってロックされているドキュメントについて、ワークフローにすべての未処理のドキュメント・リビジョンをリリースさせます。 |
|
|
コンパニオン・ファイルに特定の値のキーを設定します。 |
|
|
ワークフローの現在のコンテンツ・アイテム・リビジョンのメタデータ値を定義します。 |
Idocスクリプトの変数
| 変数 | 説明 |
|---|---|
|
現在リビジョンで実行されているアクション。 |
|
|
ジャンプ通知のオンとオフを切り替えます。 |
|
|
現在のジャンプの名前。 |
|
|
現在のジャンプの後にワークフローが終了したときに、リビジョンの戻り先となる親ワークフロー内のステップの名前。 |
|
|
条件が満たされた場合に、リビジョンがジャンプするステップの名前。 |
|
|
ワークフローの電子メール通知の件名行を定義します。 |
|
|
ワークフローの電子メール通知に記載されるメッセージを定義します。 |
|
|
これまでにリビジョンがアクセスしたワークフロー・ステップのリスト。 |
|
|
リビジョンを現在のワークフローの最初のステップに送信します。 |
トークンは、次の用途に使用できます。
ワークフローの実行時に、特定のユーザーまたはユーザーのクラスとして解釈される変数をワークフローに追加します。
ワークフローのジャンプにユーザーおよびエイリアスを指定します。
条件文を使用してユーザーを定義します。
トークンの割当ては、ワークフローの各ドキュメントに対して一意であり、ローカルに行われます。1つのドキュメントのトークンの割当てに使用するロジックが、ワークフローの別のドキュメントに影響を与えることはありません。
ワークフロー管理アプリケーションには、いくつかのサンプル・ワークフロー・トークンが付属しています。これらをそのまま使用することも、独自のワークフロー・トークンを作成するために変更することもできます。
|
重要: トークンが有効なユーザー名に解決されない場合、そのトークンは無視されます。ステップに有効なユーザーが定義されていない場合、リビジョンはワークフローの次のステップに移動します。このため、各ステップには少なくとも1つのユーザーを定義することをお薦めします。 |
この項では、トークンに関する次の項目について説明します。
トークンのIdocスクリプト関数wfAddUserは、2つのパラメータを取ります。
User: メタデータ・フィールド、エイリアス、またはユーザー名かエイリアスに解決される変数
Type: トークンのタイプで、userまたはaliasのいずれか
Idocスクリプトのすべてのコマンドは、デリミタ<$で始まり、$>で終わります。次に例を示します。
<$wfAddUser(dDocAuthor, "user")$>
<$wfAddUser("MktTeam", "alias")$>
<$wfAddUser("myUserList", "alias")$>
Idocスクリプトの構文および使用方法の詳細は、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。
トークンを作成して、ドキュメント作成者などの1人以上の未指定のユーザーを表すには、次の手順に従います。
「メイン」メニューから「管理」→「管理アプレット」を選択します。「ワークフロー管理」を選択します。「オプション」メニューから、「トークン」を選択します。
「ワークフロー・トークン」画面が開きます。
「追加」をクリックします。
「トークンの追加」/「トークンの編集」画面が開きます。
「トークン名」フィールドにトークン名を入力します。トークンの作成後に、トークン名を変更することはできません。トークンには、わかりやすい名前を使用します(たとえば、GetOriginalAuthorやAuthorManagerなど)。
「説明」フィールドに、詳細を入力します。
「追加」をクリックします。
「トークン・ユーザーの追加」画面が開きます。
「ユーザー」または「エイリアス」を選択します。
ユーザーまたはエイリアスに解決されるメタデータ・フィールドを入力します。
コンテンツ・アイテムの最初の作成者を指定するには、dDocAuthorと入力します。
エイリアスを指定するには、エイリアス名を入力します。定義済のエイリアスのリストは、「ユーザー管理」画面の画面エイリアスタブを参照してください。
「OK」をクリックします。「ユーザー」ウィンドウに、指定した値を含むIdocスクリプトが表示されます。
条件付きトークンを作成するには、「ユーザー」フィールドを編集します。例は、第4.5.2.3項「トークンの例」を参照してください。
「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)$>
ワークフローのジャンプを作成するには、その前に、フローチャートを作成して、可能なすべてのジャンプ・シナリオを解決しておきます。ジャンプの構築方法としては、サブワークフローにジャンプするステップを備えたメイン・ワークフローを作成することをお薦めします。次のフローチャートの例を参照してください。
ワークフロー内で発生させる必要があるジャンプを決定した後は、そのジャンプを設定してテストします。既存のワークフローにジャンプを直接作成することも、ジャンプのスクリプト・テンプレートを作成して異なるワークフローで再利用することもできます。
ジャンプを作成するには、次の手順に従います。
ジャンプを使用するワークフローを作成します。詳細は、第4.3.2項「基準ワークフローの設定」または第4.4.3項「基本ワークフローの設定」を参照してください。
ワークフローのタイプに応じて、「ワークフロー管理」: 「条件」タブまたは「ワークフロー管理」: 「ワークフロー」タブでワークフローを選択します。
「ステップ」ペインで、「追加」をクリックするか、ジャンプを含めるステップを選択して「編集」をクリックします。
ワークフロー・タイプ(基準または基本)の「新しいステップの追加」/「ステップの編集」画面が開きます。
「イベント」タブをクリックします。
ジャンプを含めるイベント(開始時、更新時または終了時)の横にある「編集」をクリックします。
スクリプト・テンプレートが存在しない場合は、「スクリプトのプロパティ」画面が開き、この画面でプロパティを追加できます。
スクリプト・テンプレートが存在する場合は、<ステップ名>のスクリプトの編集画面が開きます。
編集オプションを選択します。
空白の画面からスクリプトを作成するには、「新規作成」を選択します。
スクリプト・テンプレートからスクリプトを作成するには、「スクリプト・テンプレートを使用」を選択し、リストからテンプレートを選択します。
「OK」をクリックします。
「スクリプトのプロパティ」画面が開きます。
ジャンプのサイド・エフェクトをテストするには、次の手順に従います。
「ジャンプ」タブで、「追加」をクリックするか、既存のジャンプを選択して「編集」をクリックします。
「ジャンプの追加」/「ジャンプの編集」画面が開きます。
新しいジャンプの場合は、ジャンプ名を入力します。ジャンプの作成後に、ジャンプ名を変更することはできません。意味のあるわかりやすい名前を付けます。
ジャンプにリターン・ポイントを指定する必要がある場合は、「リターン・ポイントを設定する」チェック・ボックスを選択し、リストからリターン・ポイントを選択します。「現在のステップ」、「次のステップ」、「前のステップ」から選択できます。
ジャンプに入ったときに、このステップのレビューアに通知しない場合は、「実行時にユーザーに通知しない」チェック・ボックスを選択します。
承認される前にコンテンツ・アイテムをリリースする場合は、「ドキュメントの編集状態の解除」チェック・ボックスを選択します。
カスタム・サイド・エフェクトを「カスタム効果」フィールドに入力します。例は、第4.5.3.4項「ジャンプの例」を参照してください。
ジャンプに入ったときにレビューアに通知する場合は、「メッセージ」タブをクリックし、通知メッセージを入力します。
「OK」をクリックします。「スクリプトの編集」画面が再び表示されます。
条件文を設定するには、次の手順に従います。
「フィールド」リストからメタデータ・フィールドを選択します。この値は、評価されるワークフロー条件またはメタデータ・フィールドです。
「演算子」リストから演算子を選択します。「演算子」は、「フィールド」に関連する演算子のみを示す依存リストです。
「値」リストから値を選択します。「値」は、指定したメタデータ・フィールドに関連付ける値です。
「追加」をクリックしてスクリプトに条件文を追加します。
ジャンプを完成するには、次の手順に従います。
ジャンプでターゲット・ステップを指定する必要がある場合は、次のように行います。
特定のステップを指定するには、「選択」をクリックし、「ターゲット・ステップの選択」画面でワークフローおよびステップ名を選択します。ターゲット・ステップ領域に、ターゲット・ステップ名が表示されます。
シンボリック・ステップ(現在のステップまたはワークフローの終了など)を選択するには、「ターゲット・ステップ」リストからステップを選択します。
作成したスクリプトを変更するには、「カスタム」タブをクリックし、「カスタム・スクリプトの式」チェック・ボックスを選択して、コードを編集します。
|
注意: 「カスタム・スクリプトの式」チェック・ボックスの選択を解除すると、式は元の定義に戻ります。変更内容はすべて失われます。 |
スクリプトをテストするには、次の手順に従います。
「テスト」タブをクリックします。
「選択」をクリックします。
「コンテンツ・アイテムの表示」画面が開きます。
コンテンツ・リストを絞り込むには、「フィルタの使用」チェック・ボックスを選択して「フィルタの定義」をクリックし、フィルタ基準を選択して「OK」をクリックします。
テストするコンテンツ・アイテムを選択し、「OK」をクリックします。テスト用のドキュメントをチェックインして処理し、ワークフロー内のジャンプを追加するステップに置き、次に、そのコンテンツ・アイテムを選択してテストします。選択したコンテンツ・アイテムが現在ワークフローにない場合でも、そのコンテンツ・アイテムはスクリプトのテストに使用できますが、ワークフロー内では新しいコンテンツ・アイテムと同様に処理されます。
「アイテムのワークフロー状態のロード」をクリックします。
選択したコンテンツ・アイテムがワークフローにある場合は、コンパニオン・ファイルが「データの入力」フィールドにロードされます。
「テスト・スクリプト」をクリックします。
テストの結果が「結果」フィールドに表示されます。
スクリプトの各パラメータの値が表示されます。
Idocスクリプトのエラーが発生した場合は、エラーおよびエラーが含まれているスクリプトが表示されます。
スクリプトを保存するには、「OK」をクリックします。
引き続き、異なるステップへのジャンプを追加します(必要な場合)。
既存のジャンプを変更する手順は、次のとおりです。
「ワークフロー管理」画面または「ワークフロー管理」: 「ワークフロー」タブで、ワークフローを選択します。
「ステップ」ペインで、変更するジャンプが含まれているステップを選択します。
「ステップ」ペインで、「編集」をクリックします。
ワークフロー・タイプ(基準または基本)の「新しいステップの追加」/「ステップの編集」画面が表示されます。
「イベント」タブをクリックします。
ジャンプを削除するには、対応するイベント・ペインで「クリア」をクリックします。
ジャンプを変更するには、対応するイベント・ペインで「編集」をクリックします。
<ステップ名>のスクリプトの編集画面が開きます。
編集オプションを選択します。
既存のスクリプトを編集するには、「現在のスクリプトを編集」を選択します。
スクリプトを作成するには、「新規作成」を選択します。
スクリプト・テンプレートを使用するには、「スクリプト・テンプレートを使用」を選択し、リストからテンプレートを選択します。
「スクリプトのプロパティ」画面が開きます。
「ジャンプ」ペインの「追加」、「編集」または「削除」をクリックして、ジャンプのサイド・エフェクトを変更します。
「スクリプトの句」ペインの「フィールド」、「演算子」、「値」フィールドおよび「追加」ボタンと「更新」ボタンを使用して、ジャンプの条件文を変更します。
「ターゲット・ステップ」リストを使用して、ジャンプのターゲット・ステップを変更します。
自動的に生成されたスクリプトを変更するには、「カスタム」タブをクリックし、「カスタム・スクリプトの式」チェック・ボックスを選択して、コードを編集します。
|
注意: 「カスタム・スクリプトの式」チェック・ボックスの選択を解除した場合、その式は元の定義に戻り、変更は失われます。 |
スクリプトをテストし、保存します。第4.5.3.2.4項「スクリプトのテスト」を参照してください。
変更を保存する場合は、「OK」をクリックします。
次の例は、様々なタイプのジャンプの設定方法を示しています。
例4-6 メタデータ基準ジャンプ
Marketing Brochuresという基準ワークフローがあり、このワークフローが、Marketingセキュリティ・グループおよびMktBrochureコンテンツ・タイプで定義されているとします。ただし、グラフィック担当者が送信したパンフレットは、最初のステップのグラフィック部門の承認を必要としません。「スクリプトの編集」画面を使用して、次のように、最初のステップの開始時イベント・スクリプトを作成します。
<$if dDocAuthor like "bjones" or dDocAuthor like "sjames"$>
<$wfSet("wfJumpName", "BypassGraphics")$>
<$wfSet("wfJumpTargetStep", wfCurrentStep(1))$>
<$wfSet("wfJumpEntryNotifyOff", "0")$>
<$endif$>
自動的に生成された条件文のandをorに変更するには、「スクリプトの編集」画面の「カスタム」タブで、スクリプトを編集する必要があります。
例4-7 時間依存のジャンプ
レビュー期間が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$>
ワークフロー・テンプレートを使用すると、作成済のワークフローを簡単に再利用できます。各ワークフロー・テンプレートは、ワークフロー管理ツールに格納されている基本、基準またはサブワークフローのアウトラインです。ワークフロー・テンプレートは、セキュリティ・グループに結び付けられていないため、ステップ・イベント・スクリプトを含めることはできません。スクリプト・テンプレートを使用すると、ステップ・イベント・スクリプトを保存できます。
テンプレートの作成で使用する手順は、ワークフローの作成手順と似ています。この項では、プロセスの概要について説明します。詳細は、第4.3.2項「基準ワークフローの設定」または第4.4.3項「基本ワークフローの設定」を参照してください。
この章には次の項があります。
|
重要: ワークフロー・テンプレートを使用する場合、レビューアが、選択したテンプレートに定義されているレビューアと異なる場合は、レビューアを変更します。 |
ワークフロー・テンプレートを作成または変更するには、次の手順に従います。
「ワークフロー管理」: 「テンプレート」タブを表示します。
新規のテンプレートを作成するには、「追加」をクリックします。既存のテンプレートを変更するには、そのテンプレートを選択して「編集」をクリックします。
「テンプレート名」フィールドにテンプレート名を入力します。テンプレートの作成後に、テンプレート名を変更することはできません。
「説明」フィールドに、詳細を入力します。
適切なチェック・ボックスを選択して、コンテンツ・アイテムが却下された場合に、最初の作成者に既存リビジョンの編集を許可するか、新規リビジョンの作成を許可するかを指定します。
ステップを追加するには、「追加」をクリックします。
「名前」および「説明」に、ステップの適切な名前および説明を入力します。
ステップのユーザーの認可レベルとして、「ユーザーは現在のリビジョンをレビューできます」、「ユーザーは現在のリビジョンをレビューおよび編集(置換)できます」または「ユーザーは現在のリビジョンをレビューするか、新規リビジョンを作成できます」を指定します。
「OK」をクリックします。
ステップのユーザーのタイプを選択します。1つのステップに対して、複数のタイプのユーザーを定義できます。
「OK」をクリックします。
「終了条件」タブをクリックします。
リビジョンが次のステップに進むには、何人のレビューアの承認が必要であるかを指定します。
必要に応じて、追加の終了条件を指定します。
ワークフローに条件付ステップまたは特別な処理が必要な場合は、「イベント」タブをクリックし、適切なスクリプトを追加してください。
「OK」をクリックします。
スクリプト・テンプレートを使用すると、作成済のステップ・イベント・スクリプトを簡単に再利用できます。スクリプト・テンプレートは、イベント・スクリプトを作成する手掛かりとして使用されます。各スクリプト・テンプレートは、ワークフロー管理ツールに格納されているIdocスクリプトの一部です。
スクリプト・テンプレートを作成するには、次の手順に従います。
「ワークフロー管理」画面で、「オプション」メニューから「スクリプト・テンプレート」を選択します。
「追加」をクリックします。
「スクリプトの追加」/「スクリプトの編集」画面が開きます。
「スクリプト名」フィールドにスクリプト名を入力します。スクリプトの作成後に、スクリプト名を変更することはできません。
「説明」フィールドに、詳細を入力します。
「ジャンプ」タブで、「追加」をクリックします。
ジャンプ名を入力します。ジャンプの作成後に、ジャンプ名を変更することはできません。
ジャンプにリターン・ポイントを指定する必要がある場合は、「リターン・ポイントを設定する」チェック・ボックスを選択し、リストからリターン・ポイントを選択します。
ジャンプに入ったときにユーザーに通知しない場合は、「実行時にユーザーに通知しない」チェック・ボックスを選択します。
承認される前にコンテンツ・アイテムをリリースする場合は、「ドキュメントの編集状態の解除」チェック・ボックスを選択します。
カスタム・サイド・エフェクトを「カスタム効果」フィールドに入力します。
ジャンプに入ったときにユーザーに通知する場合は、「メッセージ」タブをクリックし、通知メッセージを入力します。
「OK」をクリックします。
「フィールド」リストからメタデータ・フィールドを選択します。
「演算子」リストから演算子を選択します。
「値」リストから値を選択します。
「追加」をクリックしてスクリプトに条件文を追加します。
「テスト」タブをクリックします。
「選択」をクリックします。
「コンテンツ・アイテムの表示」画面が開きます。
コンテンツ・リストを絞り込むには、「フィルタの使用」チェック・ボックスを選択して「フィルタの定義」をクリックし、フィルタ基準を選択して「OK」をクリックします。
テストするコンテンツ・アイテムを選択し、「OK」をクリックします。選択したコンテンツ・アイテムが現在ワークフローにない場合でも、そのコンテンツ・アイテムはスクリプトのテストに使用できますが、ワークフロー内では新しいコンテンツ・アイテムと同様に処理されます。
「ワークフローの選択」をクリックします。
「ワークフロー・ステップの選択」画面が開きます。
「ワークフロー」ペインでワークフローを選択し、「ステップ」ペインでステップを選択し、「OK」をクリックします。スクリプト・テンプレートが使用されるステップに類似したワークフロー・ステップを選択します。
「アイテムのワークフロー状態のロード」をクリックします。
選択したコンテンツ・アイテムがワークフローにある場合は、コンパニオン・ファイルが「データの入力」フィールドにロードされます。
「テスト・スクリプト」をクリックします。
テストの結果が「結果」フィールドに表示されます。
スクリプトの各パラメータの値が表示されます。
Idocスクリプトのエラーが発生した場合は、エラーおよびエラーが含まれているスクリプトが表示されます。
スクリプト・テンプレートを保存するには、「OK」をクリックします。
既存のスクリプト・テンプレートを変更する手順は、次のとおりです。
「ワークフロー管理」画面で、「オプション」メニューから「スクリプト・テンプレート」を選択します。
「ワークフロー・スクリプト」画面が開きます。
変更するスクリプト・テンプレートを選択します。
「編集」をクリックします。
「スクリプトの追加」/「スクリプトの編集」画面が開きます。
「ジャンプ」ペインの「追加」、「編集」または「削除」をクリックして、ジャンプを変更します。
「スクリプトの句」ペインの「フィールド」、「演算子」、「値」フィールドおよび「追加」ボタンと「更新」ボタンを使用して、ジャンプの条件文を変更します。
「ターゲット・ステップ」リストを使用して、ジャンプのターゲット・ステップを変更します。
自動的に生成されたスクリプトを変更するには、「カスタム」タブをクリックし、「カスタム・スクリプトの式」チェック・ボックスを選択して、テキストを編集します。
|
注意: 「カスタム・スクリプトの式」チェック・ボックスの選択を解除した場合、その式は元の定義に戻り、変更は失われます。 |
スクリプトをテストし、保存します。「ジャンプの作成」を参照してください。
変更を保存する場合は、「OK」をクリックします。
既存のスクリプト・テンプレートを変更する手順は、次のとおりです。
「ワークフロー管理」画面で、「オプション」メニューから「スクリプト・テンプレート」を選択します。
「ワークフロー・スクリプト」画面が開きます。
削除するスクリプト・テンプレートを選択します。
「削除」をクリックします。
確認画面が開きます。
「はい」をクリックします。
次のワークフローのシナリオでは、特定のワークフロー・タスクの実行に必要な計画プロセスおよびアクション・タイプについて説明します。次のワークフロー例が記載されています。
シナリオ1: 基準ワークフロー。基準ワークフローの設定に使用するステップの詳細は、第4.3.2項「基準ワークフローの設定」を参照してください。
シナリオ2: トークン。トークンの作成の詳細は、第4.5.2.2項「トークンの作成、編集または削除」を参照してください。
シナリオ3: メタデータに基づいたジャンプ。ジャンプの設定の詳細は、第4.5.3.2項「ジャンプの作成」を参照してください。
シナリオ4: 時間依存のジャンプ。変数を使用したジャンプの設定の詳細は、第4.5.3.1.3項「ジャンプの変数およびステップ」を参照してください。
マーケティング部門のすべてのマーケティング・パンフレットは、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日で発生するように、スクリプトを編集します。
この項では、ワークフローのヒントおよび要領について説明します。次の項目について説明します。
この機能に加えて、コンサルティング・サービスを介してその他のカスタマイズを入手できます。詳細は、第4.8.6項「その他のカスタマイズ」を参照してください。
ワークフローの特定のステップでは、ユーザーの再認証が必要になる場合があります。承認の前に認証を要求するワークフロー・ステップごとに、次の手順に従います。
IntradocDir/config/config.cfgファイルに、次の行を追加します。
<workflow step name>:isRepromptLogin=true
複数のワークフロー・ステップで検証が必要な場合は、別々の行にそのステップを追加します。
Oracle WebCenter Content Serverを再起動します。
ワークフローを設定して有効にし、検証が必要なステップに対しては、構成エントリで指定したステップ名を必ず使用します。
ワークフローを開始すると、構成変数isRepromptLoginで指定されたワークフロー・ステップのユーザーは、そのワークフロー・ステップでコンテンツを承認する前に、ログインするよう求められます。
次の例では、VIPApprovalおよびCEOsignoffという名前のステップで検証が必要です。次のエントリをconfig.cfgファイルに追加します。
VIPApproval:isRepromptLogin=trueCEOsignoff:isRepromptLogin=true
Oracle WebCenter Content Serverを再起動し、VIPApprovalおよびCEOsignoffという名前のステップでワークフローを設定して有効にします。VIPApprovalステップには複数のユーザーが割り当てられ、CEOsignoffステップには1人のユーザー(会社のCEO)のみが割り当てられます。
これらのステップでユーザーがワークフロー・アイテムを承認するには、その前に再度ログインする必要があります。
この機能は、Oracle WebCenter Content Server 7.5以上のバージョンで使用可能です。
2つの別個のユーザー・グループがワークフローのコンテンツ・アイテムを同時にレビューできるようにし、コンテンツがワークフロー内を進む前に、各グループから指定された数のユーザーがコンテンツを承認できると便利な場合があります。
Oracle WebCenter Content Serverを使用している場合、先に進むためには、すべてのユーザーまたは指定した数のユーザーがコンテンツを承認する必要があります。通常、ワークフローでは承認元は区別されません。そのため、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 WebCenter Content 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.\nThe 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.\nThe 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つが満たされます。
多くの場合、コンテンツ・アイテムは、リリースされる前に(様々な形式で)処理されます。リリースされたコンテンツ・アイテムは、索引付けされた後、検索結果、アーカイブおよび他のプロセスやアプリケーションに含めることが可能になります。
ワークフローのコンテンツ・アイテムを完了前にリリースできると、便利な場合があります。たとえば、コンテンツ・アイテムをレプリケートするには(後で障害時リカバリなどで使用するために)、そのコンテンツ・アイテムをリリース状態にする必要があります。レプリケータでは、リリースされていないアイテム(ワークフロー内のアイテムなど)を使用できません。
ワークフロー・アイテムがワークフロー内にある間に、そのアイテムをリリース済として指定できます。更新、チェックアウト、チェックインなどの通常のワークフロー・アクションは、引き続き使用できます。また、これらのアイテムは、索引付けされて検索結果に表示され、レプリケーション、アーカイブ、他のプロセスまたはアプリケーションで使用できます。
|
重要: ワークフロー・アイテムをレプリケートするには、その前に、いくつかの検討事項があります。この項では、プロセスを説明しますが、詳細には触れません。ワークフロー・アイテムのレプリケーションを設定する前に、コンサルティング・サービスに問い合せてください。 |
自動レプリケーションを設定するには、その前に、いくつかの点に留意する必要があります。
データの整合性の消失: 意図的かどうかに関係なく、コンテンツを途中でリリースすると、ビジネス・プロセス管理、コンテンツのアクセス可能性および情報整合性に予期しない影響を与える可能性があります。ワークフロー内にあるアイテムのリリースを検討する前に、起こり得る悪影響について十分に考慮する必要があります。
ワークフロー情報を取得できない: ワークフローは、プロセスとコンテンツの組合せです。コンテンツをリリースし、レプリケーションおよび他のプロセスで使用することは可能ですが、ワークフローの状態情報の取得およびレプリケートは、(カスタマイズおよびコンサルティング・サービスの支援がないと)実行できません。
ソース・インスタンスでワークフローのコンテンツをレプリケートし、そのインスタンスのワークフロー内を通過せずにターゲット・インスタンスでリリースした場合は、コンテンツのワークフロー状態を手動で再設定する作業がリカバリ・プロセスに必要となります。
以前のワークフロー状態へのリカバリは、実際の障害時リカバリでのみ必要となるため、ほとんどの場合、ワークフロー情報のクローニングは不要です。他のすべての場合は、ワークフローの終了後にコンテンツ・アイテムが通常どおりレプリケートされ、ワークフローの途中でレプリケートされたバージョンまたはリビジョンよりもそのコンテンツ・アイテムが優先されます。
インポートしたコンテンツ・アイテムがワークフローに入らない: ソース・インスタンス上のワークフロー内にある間にレプリケートされたコンテンツ・アイテムは、追加のカスタマイズおよびコンサルティング・サービスからの支援がないと、ターゲット・インスタンス上のワークフローに入りません。レプリケートされたコンテンツ・アイテムは、ターゲット・インスタンスにチェックインされ、リリースされます。
レプリケートされたワークフロー・アイテムのリストアには手動操作が必要: 一部のワークフロー情報はメタデータとして取得してワークフローの手動リストアに使用できます。コンテンツ・アイテムがワークフローに入るトリガーとなるのは、チェックイン・アクションのみです。アイテムをリストアしてワークフローに戻るには、リビジョンを作成する必要があります。
ターゲット上のコンテンツ・アイテムを、ソースでの以前の状態にできるだけ近い状態にリカバリするために、ソース・インスタンスとターゲット・インスタンスのリビジョンの数の不一致が意図的に導入されており、回避できません。
ワークフロー内にある間にリリースされていないコンテンツ・アイテム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 is based
終了したら、「追加」をクリックします。
ターゲット・ステップとして「終了して親ステップへ移動」を選択し、両方の0パラメータを10に変更します(例: @wfExit(10,10))。フォルダにないドキュメントはワークフローの外へ出されます。
入力イベントで「OK」をクリックし、「新しいステップの追加」ダイアログで「OK」をクリックします。
ワークフローのその他の部分に必要なジャンプ、ステップおよびイベントを追加し、ワークフローを有効にします。
ワークフロー・ステップでGET_SEARCH_RESULTSサービスを実行すると、ワークフローのデータ・バインダがサービスによって使用されるため、データの破損が発生する可能性があります。
この問題を解決するには、セキュリティ・グループの値を一時変数として一時的に設定します。次に、現行のセキュリティ・グループ値を消去し、検索結果をコールした後で、セキュリティ・グループを元の設定に戻します。
複数の承認者が必要なワークフロー・ステップでは、時間指定されたワークフロー更新サイクル中に、ドキュメントをすでに承認したユーザーに通知が再度送信される可能性があります。追加の通知を抑止するには、wfSetIsNotifyingUsersワークフロー関数を使用します。ワークフローのスクリプト・セクションにあるワークフロー・ステップで使用すると、現行のドキュメント・アクション(チェックイン、承認、更新など)を実行する際にワークフロー通知を送信するかどうかを判定する内部フラグが設定されます。この抑止は、電子メールおよびキュー内のワークフローの更新に適用されます。
この関数をwfIsFinishedDocConversionと組み合せて使用すると、変換が終了するまで通知を抑止できます。これは、自動コントリビューション・ステップからのドキュメントの進行は阻止せず、キュー内のワークフローの更新および電子メール通知を停止します。
これらの通知は、失われていません。今後のワークフロー・イベントで、wfSetIsNotifyingUsers関数を使用して通知(キュー内のワークフローの更新およびワークフロー・メール)を抑止しない場合、現行のステップに参加しているすべてのユーザーに通知されます。
スクリプト・セクションでは次の追加の関数を使用できます。
wfIsFinishedDocConversion: 現行のドキュメント・アクションの終了後に、ドキュメントが「WWW生成」ステータスであるかどうかを示す結果を返します。
wfIsNotifyingUsers: ワークフローで、この特定のワークフロー・イベントに関するすべてのワークフロー通知が現在抑止されているかどうかを示す結果を返します。
これらすべての関数の使用方法の詳細は、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。
この項では、いくつかの一般的なワークフローの問題に対する解決策を提供します。
現象
ワークフローのコンテンツ・アイテムが「編集」ステータスまたは「WWW生成」ステータスで、アクションが必要なことを示す電子メールがレビューアに通知されていません。
問題
Inbound Refineryでファイルが正しく変換されていません。
推奨事項
リポジトリ・マネージャまたはワークフローのコンテンツ・アイテム・ページで、コンテンツ・アイテムのステータスを表示します(「コンテンツ・マネージャ」→「アクティブなワークフロー」→「<Workflow_Name>」の順に選択してアクセスします)。変換の失敗に関する詳細を確認するには、コンテンツ情報ページを表示します。
変換に失敗した理由を判断します。
Inbound Refineryまたは変換アドオン製品が問題の原因となっている場合:
ファイルが正しく変換されるように問題を修正します。
リポジトリ・マネージャ・ページまたはコンテンツ情報ページから変換対象ファイルを再送信します。コンテンツ・アイテムは再びワークフロー内を進みます。
基準ワークフローのファイルが問題の原因で、ワークフロー内にコンテンツ・アイテムが1つのみある場合:
ネイティブ・ファイルのコピーを保存します。
ワークフローを無効にしてコンテンツ・アイテムをリリースします。
リポジトリ・マネージャまたはコンテンツ情報ページを使用して、リリースされたリビジョンを削除します。
ファイルが正しく変換されるように問題を修正します。
コンテンツ・アイテムを再度チェックインし、ワークフロー・プロセス内を完全に移動できるようにします。
基準ワークフローのファイルが問題の原因で、ワークフロー内に複数のコンテンツ・アイテムがある場合:
ネイティブ・ファイルのコピーを保存します。
リポジトリ・マネージャを使用して、スタックしているリビジョンを削除します。(ワークフローを無効にすることもできますが、ワークフロー内のすべてのコンテンツ・アイテムがリリースされることになります。)
ファイルが正しく変換されるように問題を修正します。
コンテンツ・アイテムを再度チェックインし、ワークフロー・プロセス内を完全に移動できるようにします。
基本ワークフローのファイルが問題の原因で、ワークフロー内にコンテンツ・アイテムが1つのみある場合:
ネイティブ・ファイルのコピーを保存します。
ワークフローを取り消し、システムからリビジョンを削除します。
ファイルが正しく変換されるように問題を修正します。
コンテンツ・アイテムを基本ワークフローに再度コントリビュートし、ワークフロー・プロセス内を完全に移動できるようにします。
基本ワークフローのファイルが問題の原因で、ワークフロー内に複数のコンテンツ・アイテムがある場合:
ネイティブ・ファイルのコピーを保存します。
リポジトリ・マネージャを使用して、スタックしているリビジョンを削除します。(ワークフローを取り消すこともできますが、ワークフロー内のすべてのコンテンツ・アイテムがシステムから削除されることになります。)
ファイルが正しく変換されるように問題を修正します。
コンテンツ・アイテムを基本ワークフローに再度コントリビュートし、ワークフロー・プロセス内を完全に移動できるようにします。
現象
ワークフロー内のコンテンツ・アイテムが「レビュー」ステータスにあり、最小限のレビューアによって承認されているのに、リビジョンが次のステップに移動しません。
問題
コンテンツ・アイテムがワークフローの終了条件を満たしていません。
推奨事項
ワークフロー・ステップの終了条件定義をチェックし、ドキュメントが条件を満たしていない理由を確認します。
外部プロセスと相互作用してファイルが終了するかどうかを判断します。外部プロセスとの問題を解決し、ファイルが終了条件が満たしているかどうかを確認します。
終了条件、外部処理またはその両方にエラーがある場合は、ドキュメントをチェックアウトし、終了条件を満たすように修正したメタデータでドキュメントをチェックインします。
