サービスカタログと Workflow の概要Issue この記事では、次のテーマについて詳しく説明します。 カタログアイテムへのワークフローのアサインタスクの追加 サービスカタログを使用した ServiceNow Workflow プロセスを自動化する最も強力な方法の 1 つは、サービスカタログを通じてユーザーがそれを利用できるようにすることです。 ワークフローは、カタログアイテムの定義を通じてサービスカタログ内の製品に関連付けられます。カタログアイテムに関連付けられると、ワークフローは要求アイテムを含む SC 要求アイテムが承認された後に実行されます。カタログアイテムを処理するために作成されたワークフローは、サービスカタログ要求アイテム (RITM) テーブルに関連付けられます。この関連付けを通じて、ワークフローは RITM の変数値にアクセスできるようになります。ワークフローは、RITM 変数値に基づいて意思決定を行うように記述できます。ご存じのとおり、ワークフローは特定のテーブルに対して実行されます。ワークフローで RITM 変数マッピングを利用する必要がある場合は、ワークフローをサービスカタログ要求アイテムテーブルに関連付ける必要があります。カタログアイテムに関連付けられたワークフローは、変更要求を使用した前の例とは異なり、デフォルトのワークフローエンジンの動作に従いません。前の例では、変更要求レコードが挿入されたときに、ワークフローエンジンはワークフローの条件 (この例では優先度 3 または優先度 4 ) を調べました。条件が満たされた場合にワークフローが自動的に開始されました。サービスカタログを使用する場合、ワークフローは RITM に関連付けられます。ただし、その RITM はサービス要求の一部です。サービス要求が承認されない、または成功しない場合、その要求の一部である RITM は成功しません。このように、SC 要求の承認は、それに含まれるアイテムに関連付けられたワークフローの実行をゲーティングします。そのため、SC 要求の承認はゲートウェイ承認と呼ばれます。SC 要求が承認されない限り、また承認されるまで、RITM ワークフローは実行されません。ただし、RITM は親 SC 要求と同時にデータベースに挿入されます。RITM に関連付けられたワークフローは、SC 要求の承認ステータスを評価する一連のビジネスルールの中から開始されます。 ワークフローとサービスカタログアイテムの関連付け [サービスカタログ] > [アイテムの管理] を選択します。[K14 WF 201 の例 - サブスクリプションの要求] を選択します。[詳細ビュー] への切り替えが必要となる場合があります。ビュー名をクリックして、[詳細ビュー] を選択します。注：このラボの目的は、サービスカタログと Workflow の関係を示すことです。カタログの作成方法、カタログへのアイテムの追加方法などの学習は、このカンファレンスのサービスカタログトラックの一部であり、サービスカタログアイテムのワークフローの作成に興味のある方には参加を強くお勧めします。ワークフローフィールドに注目してください。このフィールドは、サービスカタログアイテムと、このフィールドにアサインされたワークフローとの関連付けを作成します。この場合、アサインされるワークフローは、「K14 WF 201 の例 - サブスクリプションの要求」です。RITM のこのフィールドは、前に説明したゲートウェイ承認プロセスの「ワークフロー実行のビジネスルール」から読み取られます。フォームの下部までスクロールし、[変数] 関連リストを見つけます。3 つのレコードがあります。このカタログタスクに属する変数は、「K14 WF 201 の例 - サブスクリプションの要求」ワークフロー内で読み書きできます。隣接するブラウザタブのワークフローエディターに戻ります。[開く] をクリックします。[K14 WF 201 の例 - サブスクリプションの要求] を選択します。ワークフローは次のようになります。歯車メニュー > [チェックアウト] を選択する。歯車メニュー > [プロパティ] を選択する。このワークフローは、要求アイテムテーブルに対して作成されます。このワークフローに使用できる条件がないことに注意してください。ワークフローエンジンは要求アイテム Glide レコードを評価して実行すべきかどうかを判定しないため、条件を構成しても意味がないからです。質問：ワークフローエンジンが RITM に対してワークフローを実行する条件を判定しないのであれば、何を行うのですか？右上隅の [X] をクリックして、[ワークフローのプロパティ] フォームを閉じます。[マネージャー承認取得アクティビティ] をダブルクリックします。[ユーザーロック] アイコンをクリックします。 入力フィールドの右側にある [ユーザーの選択 (ツリーアイコン)] をクリックします。[作成者] > [部門] > [部門責任者] の順にドット連結します。${ } 表記は、内部の値を現在のレコードのドット連結として解釈します。この場合、現在のレコードは、sys_user 参照である参照フィールド opened_by を持つ sc_req_item Glide レコードです。sys_user テーブルには、[マネージャー] フィールドがあります。ツリーは、現在のレコード内のアサインフィールドにドット連結するためのコード支援ツールです。承認フォームの [更新] をクリックします。アクティビティツリーで、[承認カテゴリ] フォルダーを開き、[承認アクション] を選択します。[承認アクション] を [承認 - ユーザー] と [承認済みログメッセージをログに記録] の間の移行にドラッグします。承認アクションは、承認の結果に基づいて RITM レコードの承認ステータスを設定するために使用されます。以下のようにフィールドに入力します。 名前：マネージャー承認アクション：承認されたタスクをマーク [送信] をクリックします。[マネージャー承認済みアクティビティ] の白い部分を右クリックします。[アクティビティのコピー] を選択します。[承認アクション] を [承認 - ユーザー] と [却下済みログメッセージをログに記録] の間の移行にドラッグします。画面は次のようになります。複製された [マネージャー承認] をダブルクリックします。次のようにフォームに入力します。 名前：マネージャー却下アクション：却下されたタスクをマーク [更新] をクリックします。[却下] 条件の移行エンドポイントを [マネージャー却下済み承認アクション] に移動します。[マネージャーの却下] から [却下されたログ] への移行を作成します。画面は次のようになります。アクティビティツリーで、[タスクカテゴリ] フォルダーを展開します。質問：タスクフォルダーに、以前は変更要求になかった新しいタスクがあります。カタログタスクアクティビティ定義について、何が想定できますか？カタログタスクを [承認済みログ] と [ログメッセージの終了] の間の移行にドラッグします。画面は次のようになります。スラッシュバケット内の変数に注目してください。これらは、前に確認したカタログアイテムの [変数] 関連リストで宣言されている変数です。これらの変数を [選択済み] フィールドに移動して、タスクがアサインされるユーザーに提供できます。[利用可能] リストから 3 つの変数を選択し、[選択済み] リストに移動します。フォームの残りの部分を以下のように入力します。 名前：サブスクリプションタスクの履行アサイン先：K14Task – TwoUser簡単な説明：雑誌定期購読の注文処理指示：この雑誌を注文してください。 [送信] をクリックします。ワークフローは次のようになります。メインの [ServiceNow] タブに戻ります。 サービスカタログ K14 カテゴリを追加します。 [サービスカタログ] > [カタログ] に移動します。[Knowledge14 – WF 201 ラボ] カテゴリを追加します。 [+] をクリックします。[Knowledge14 – WF 201 ラボ] を選択します。上部のドロップゾーンに配置します。 [Knowledge 14 - WF 201 Lab] カテゴリを選択します。[K14 WF 201 の例 - サブスクリプションの要求] を選択します。デフォルト値をそのまま使用し、[今すぐ注文] を選択します。RITM へのリンクを選択します。カタログビューに切り替えます。[承認者] 関連リストまでスクロールします。質問：上のスクリーンショットを見て、承認ユーザーアクティビティでのドット連結のアサインを思い出してください。K14 マネージャーについて何が想定できますか？ご自分のドット連結について考えてみてください。右クリックして、[K14 マネージャーの承認] を承認します。カタログタスクレコードが追加され、ステージが更新されました。ワークフローで [ステージ] フィールドが更新されました。質問：ステージフィールドを見てください。値は、[Requested (要求済み)] から [request_approved (承認済み要求)] にどのように変わりましたか？[カタログタスク] 関連リストで、タスクレコードを開きます。質問：RITM の変数はどのようにしてカタログタスクフォームに取り込まれましたか？[決算処理タスク] をクリックします。[要求アイテム] フォームで、[関連リンク] リストの [ワークフローを表示] リンクを選択します。ワークフローコンテキストは次のようになります。 サマリー サービスカタログとワークフローエンジンは、連携してサービスカタログ要求を履行します。そのため、ワークフローエンジンは、要求されたアイテム [sc_req_item] テーブルに対して記述されたワークフローの条件を評価しません。 ワークフローは、サービスカタログアプリケーションのアイテムの管理モジュールでカタログアイテムにアサインされます。ワークフローがアサインされているカタログアイテムをサービスカタログから注文した場合、ワークフローはすぐには開始されません。要求アイテム (RITM) の進行は、ゲートウェイ承認のバックグラウンドで待機しています。ゲートウェイ承認が完了すると、RITM のワークフローが sc_req_item の「ワークフロー実行のビジネスルール」から開始されます。このビジネスルールは、親 sc_request のビジネスルールから RITM レコードが更新されたときにトリガーされます。 したがって、ワークフローエンジンは、RITM に関連付けられたワークフローを Glide イベント (挿入、更新、削除、キャンセル) の中から起動させません。代わりに、RITM ワークフローは、サービスカタログ要求のゲートウェイ承認待ちのビジネスルールによって開始されます。 ワークフローエディターには、RITM の変数値へアクセスする方法や、現在のレコードの値を読み書きする方法をデザイナーに提供するアクティビティが用意されています。