記事 (1/10)
このモジュールの内容は次のとおりです。
前提条件:このモジュールは、Flow Designer の以下のトピックに精通していることを前提としています。
Flow Designer については、「Flow Designer の使用」学習モジュールで学ぶことができます。
記事 (2/10)
重要:この学習モジュールの内容は、Quebec ServiceNow リリース用に最後に更新されたもので、Rome リリースでは更新されていません。Rome リリースとこの学習モジュールのコンテンツとの間に違いが見られる場合があります。
Asset Management Spoke アプリケーションは、アプリケーション作成の背後にある概念とプロセスを紹介し、デモンストレーションするために、この学習モジュール全体で使用されます。Asset Management Spoke アプリケーションは構築しません。
演習では、NeedIt アプリケーションを開発します。
演習は、次の 3 つの方法で示されます。
NeedIt アプリケーションを使用すると、ユーザーは複数の部門からのサービスを要求できます。ソースコントロールを使用して、この学習モジュールに必要なすべての NeedIt アプリケーションファイルから始めます。
演習 (3/10)
ServiceNow は GitHub を使用して、開発者サイトの学習コンテンツをコピーして使用するアプリケーションリポジトリを提供します。リポジトリには、アプリケーションファイルの固定セットであるタグが含まれているため、部分的に構築されたアプリケーションを使用して作業を開始できます。ServiceNow が提供するリポジトリを個人開発者インスタンス (PDI) にコピーしてインポートすることで、モジュール内の実践的な演習に必要なすべてのファイルを取得できます。
注意:ServiceNow が開発者プログラムの学習コンテンツで GitHub を使用する方法の詳細と、リポジトリをフォークしてアプリケーションをインポートする方法に関するビデオを見るには、『GitHub ガイド』を参照してください。
この演習では、次のことを行います。
重要:リポジトリを既にフォークしてインポートしている場合は、次の演習に進み、タグから分岐を作成して、アプリケーションファイルを PDI にロードできます。モジュールを完了するには、NeedIt アプリケーションファイルが必要です。
演習のこのセクションでは、開発者サイトの学習コンテンツで使用するアプリケーションリポジトリのパーソナルフォークを作成します。
演習のこのセクションでは、アプリケーションリポジトリを ServiceNow にインポートします。プロセスの一環として、まず GitHub アカウントの資格情報レコードを作成してから、Studio を使用してアプリケーションリポジトリを PDI にインポートします。
演習 (4/10)
この演習では、モジュールで使用するアプリケーションファイルを含む「Flow Designer:意思決定」モジュールのために、NeedIt アプリケーションの分岐を作成します。
注意:この演習を開始する前に、「演習:Flow Designer :意思決定モジュールのためにリポジトリをフォークしてアプリケーションをインポートする」で説明したように、NeedIt リポジトリをフォークしてインポートしておく必要があります。
記事 (5/10)
複数の条件付きパスが必要な状況では、ネストされた If、Else If、または Else フローロジックの代わりに、意思決定分岐を使用します。意思決定分岐により、フローでのロジックの構成方法が簡素化されます。
コスト、要求のタイプ、および既存の在庫または権利の可用性に基づいて、複雑な要求承認構造を検討します。以下のテーブルは、このような構造の例です。コスト、アイテムタイプ、および可用性は、必要な承認レベルを意思決定するために使用される入力です。たとえば、ユーザーが価格 3500 ドルの新しいラップトップを要求し、要求されたモデルが在庫にない場合、ディレクターが購入を承認する必要があります。
次の表は、ハードウェアの承認レベルをまとめたものです。
次の表は、ソフトウェアの承認レベルをまとめたものです。
If、Else If、Else のフローロジックを使用すると、要求を承認するフローは以下のように、ネストされたフローロジックの複雑な構造になります。
[意思決定] フローロジックを使用して、同じ複雑な承認ロジックを適用すると、フローがより管理しやすく、読みやすく、拡張しやすくなります。
[意思決定] テーブルは、意思決定入力を意思決定にマッピングします。意思決定入力は、意思決定に必要な情報を指定する構成フィールドです。
各意思決定レコードは、1 つの回答に到達するために使用される条件のリストです。
[意思決定] テーブルは、[回答] テーブルに関連付けられています。[意思決定] は [回答] テーブルのレコードにマッピングされます。[回答] テーブルのレコードは、[意思決定] フローロジックの分岐です。
記事 (6/10)
[意思決定] テーブルレコードを作成する前に、目的の回答を特定します。
回答はテーブルに既に存在しますか?
承認レベルの例のテーブルが存在しませんでした。カスタムテーブルには、各承認レベルのレコードがあります。
[意思決定] テーブルを作成するには、Application Navigator を使用して [システム定義] > [意思決定テーブル] を開きます。[新規] ボタンをクリックします。[意思決定] テーブルを構成します。
[他のアクション] () メニューをクリックして、[保存] メニューアイテムを選択します。
意思決定に必要な入力ごとに意思決定入力レコードを作成します。[意思決定入力] 関連リストで [新規] ボタンをクリックします。テーブルの他のフィールドと同じ方法で意思決定入力を構成します。構成フィールドは、入力タイプによって異なります。
意思決定入力は、Flow Designer の[意思決定] フローロジックを作成するための構成オプションです。関連リストで [注文] を設定し、[意思決定] フローロジックの意思決定入力の順序を構成します。
意思決定レコードを作成して、意思決定入力値を[回答] テーブル のレコードにマッピングします。[意思決定] 関連リストで [新規] ボタンをクリックします。意思決定を構成します。
一意の各回答レコードが意思決定にマッピングされます。複数の意思決定が同じ回答レコードを指している場合、回答は 1 回だけ分岐します。
記事 (7/10)
[意思決定] フローロジックをフローに追加するには:
意思決定分岐を構成します。
意思決定分岐にアクションや追加のフローロジックを追加するには、分岐の [アクションまたはフローロジックを追加] ボタンをクリックします。アクションを構成します。意思決定ブランチで、回答レコードを変数として使用できるようになってから追加されたアクション。
意思決定から分岐することで、開発者はさまざまなロジックやプロセスをさまざまな状況に適用できます。この例では、承認ポリシーのプロセスは、必要な承認レベルに応じてわずかに異なります。マネージャーまたはディレクターの承認が必要な場合、必要なアクションは承認のみです。より高いレベルの承認では、追加の手順が必要です。
プロセスが各意思決定で同じであり、回答を変数として使用できる場合は、[意思決定] フローロジックの作成に分岐は必要ありません。たとえば、意思決定テーブルが承認のグループを識別し、グループを承認者として承認を設定するだけでよい場合、ブランチなしでプロセスは簡単になります。
分岐を削除するには、[分岐を使用] オプションをオフにします。確認を求めるダイアログが表示されます。[削除] ボタンをクリックして、分岐を削除します。
[意思決定] 分岐の変数は、分岐が実行しない可能性があるため、分岐の外部では使用できません。この例では、各 [意思決定] 分岐が、[承認の要求] アクションの結果を個別に処理する必要があります。画像が制御不能になるのを防ぐため、If フローロジックは含まれていません。
開発者はいつブランチを使用する必要がありますか?
デフォルトでは、一致する最初の意思決定に対して [意思決定] フローロジックが実行され、意思決定の処理が停止されます。フローロジックで一致するすべての意思決定を実行する必要がある場合は、[実行] の値を [一致するすべての意思決定を実行] に設定します。一致するすべての意思決定の実行は、ブランチに関係なく機能します。
[分岐を使用] を選択すると、一致する各意思決定の分岐が実行されます。
[分岐を使用] が選択されていない場合、[意思決定] フローロジックは回答レコードのリストを返します。[For Each] フローロジックを使用して、返された各回答を循環します。この例では、[意思決定] フローロジックは、分岐を使用せず、一致するすべての意思決定を実行するように構成されています。[承認レベルレコード] データピルは、返されたすべての意思決定のリストです。[For Each] フローロジックは、返された各意思決定を循環し、複数の決定が返されている場合は複数の承認を生成します。
演習 (8/10)
この演習では、NeedIt 要求レコードの詳細を使用して、関連付けられた NeedIt タスクを誰に割り当てるかを決定する [意思決定] テーブルレコードを作成します。テーブルは、NeedIt レコードの詳細をアサイニーカテゴリにマッピングし、アサインします。たとえば、[必要なもの (What needed)] が [優先度] を持つ [施設サービス 1 (Facilities 1)] である施設サービスの NeedIt 要求には、[アサイニーカテゴリ (Assignee category)] が [施設サービス 1 (Facilities 1)] で [アサイニー (Assignee)] が [Howard Johnson] の NeedIt タスクが必要です。
次に、意思決定に基づいて分岐するように [NeedIt の実行 (Fulfillment)] フローを更新し、[意思決定] フローロジックからの情報を使用して、NeedIt タスクを作成します。
演習のこのセクションでは、アサイニーカテゴリを定義し、ユーザーをアサイニーカテゴリレコードに関連付けるテーブルを作成します。別のテーブルを使用すると、意思決定の抽象化レイヤーが追加されます。アサイニーが変更された場合は、フローの代わりにテーブルを更新します。
この演習セクションでは、[要求タイプ (Request type)]、[必要なもの (What needed)]、および [優先度 (Priority)] の [意思決定入力] を作成します。
この演習セクションでは、各アサイニーカテゴリの意思決定レコードを作成します。
演習のこのセクションでは、[NeedIt の実行 (NeedIt Fulfillment)] フローに [意思決定] フローロジックを追加します。このフローにより、アサイニーカテゴリ値に基づいて適切なユーザーにアサインされた NeedIt タスクが作成されます。
この演習セクションでは、意思決定のデータを使用して、NeedIt タスクを作成します。
演習 (9/10)
開発者は、GitHub のようなソースコントロールアプリケーションを使用して、個人開発者インスタンス (PDI) の外部で変更をコミット (完了した作業を保存) できます。アプリケーションに対する変更内容をコミットして、作業をソースコントロールに保存します。
この演習では、このモジュールで完了した作業を GitHub リポジトリに保存します。
注意:ServiceNow が開発者プログラムの学習コンテンツで GitHub を使用する方法の詳細と、作業を保存する方法に関するビデオを見るには、『GitHub ガイド』を参照してください。
記事 (10/10)
コアコンセプト: