こんにちは。ざわかける！のざわ(@zw_kakeru)です。
ServiceNowが提供する様々な機能の中で、ServicePortalとServiceCatalogを使ってトライアル実装をしてみようと思います。
前編の続きとなっていますので、前編をまだ読んでないという人は先にそちらをご覧ください。
ワークフローの作成
ここからは、ユーザーからの商品注文に対して裏で実行されるワークフローを作成していきます。
Service Managementから『Flow Designer』を開きます。
このFlow Designer上からワークフローの作成/編集を行うことができます。
すでにデフォルトで数多くのワークフローが登録されていますが、画面右端の『New』ボタンから『Flow』を選択して新規作成を行います。
プロパティ設定画面になりますので、『Flow name』を『お花注文申請』として「Submit」します。
すると、新たなフロー作成画面が表示されます。
ここから実際にモジュールをつなぎ合わせて一連の承認フローを組み立てていきます。
(追記：今、フロー名を「お花注文申請」としましたが、このような全角文字でのフロー名はServiceNow環境につき1件しか作成できないことが分かりました。
理由は、このフロー名の蘭からシステム内部(で扱う)フロー名が自動設定されるのですが、全角文字を含んでいる場合はここがうまく設定できずに空白になってしまいます。
そのため、全角文字でのフロー名が1件登録されると、2件目以降は内部フロー名が空白ですでに存在しているためにエラーとなります。
全角文字を使わずに「FlowerFlow」などの名前にしておく方がいいかもしれません。)
まず、このフローのトリガー(どのタイミングでフローを起動するか)を設定します。
『TRIGGER』項目の下の『Add a Trigger』を選択し、出てきた『Select a Trigger』ピッカーから『Service Catalog』を選択します。
正しく設定できたら「Done」してください。
これでトリガーの設定は完了です。
分かりやすくするためにコメントを入れておきましょう。
今作成したトリガー行の右端の吹き出しボタンをクリックするとコメントフォームが出現するので、「お花の注文があった場合に実行する。」と入力します。
今後このコメント挿入の手順は何度も出てくるので、やり方を理解しておいてください。
トリガー設定ができたら、具体的なアクションの作成に移ります。
『ACTIONS』項目の下の『Add an Action, Flow Logic, or Subflow』をクリックします。
選択肢が現れるので『Action』を選択し、『ServiceNow Core』から『Ask For Approval』をクリックします。
これで、注文申請を承認者に飛ばすアクションを生成できました。
ここから詳細設定を行っていきます。まず「許可を依頼。」コメントを入力してください。
そして、右側の『Data』タブから『Trigger – Service Catalog』下にある『Requested Item Record』を『Record』項目にドラッグ&ドロップします。
この右側の『Data』タブは各アクション時点で保持されているオブジェクトが一覧表示されており、必要に応じてドラッグ&ドロップで参照することができます。
設定中のアクションよりも後のアクションで生成されるオブジェクトを参照することは(当然ですが)不可能です。
今回はTrigger実行時に入ってきたRequested Item Record (つまり注文された商品)のデータをここで参照しています。
次に承認ルールですが、『Rules』に『Anyone approves』を設定し、右に4つ並んでいるボタンのうちの右から2つ目の『Add Group』をクリックして、出てきたピッカーの中から『Team Development Core Reviewers』を選択します。
『Team Development Core Reviewers』はSystem Administrator (自分自身)が含まれているグループであり、今回は自分で注文した商品を自分で承認できるように設計します。
下の図を確認して、問題なさそうであれば「Done」しましょう。
これで申請の承認を飛ばすフローができました。
次にやることは、承認/非承認の処理の分岐です。
『Add an Action, Flow Logic, or Subflow』から『Flow』の『If』を選択してください。
『Condition』に「購入が許可されなければ」と入力します。
直前のモジュールとの関連で『Condition 1』にはデフォルトで『Approval State』が入っています。入っていない場合は右側の『Data』タブから『Ask For Approval』下の『Approval State』をドラッグ&ドロップしてください。
そして続くピッカーで『is not』『Approved』を設定し、「Done」します。
ここから処理が分岐していきます。
『then』の方(承認されなかった場合)から『Update Record』アクションを追加します。
コメントに「申請を処理済みとする。」と入力し、『Record』に『Trigger』下の『Requested Item Record』をドラッグ&ドロップします。
『Fields』は『State』を『Close Complete』するように設定し、「Done」してください。
このままだと『then』句のフローを終えた後にメインフローに戻って処理が続行されてしまうため、明示的に終了してあげる必要があります。
『Flow Logic』の続きに『End』を設置しましょう。
これでフローを終了することができます。
メインフローに戻ります。
新たに『Update Record』アクションを追加します。
先ほどと全く同じように、「申請を許可済みにする。」コメントを入力してください。
そして『Requested Item Record』をセットして『State』『Closed Complete』して「Done」します。
一旦これで形だけは完成しましたが、今の段階だとどちらに分岐しても申請を閉じて終了しているだけなのでここからさらに改変を加えていきます。
まず、今のフローではRequested Item(注文された商品)の処理は行えていますが、それに紐づくRequest (注文)自体の処理を全く行えていません。
商品は発送したのに注文は通っていない、みたいなおかしな状況が発生すると困るので、Requestの処理も正しく実装ずる必要があります。
『ACTIONS』項目の『Ask For Approval』と『If』の間にマウスカーソルを持っていくことで、この間にモジュールを追加することができます。
『ServiceNow Core』から『Look Up Record』を選択します。
『Look Up Records』ではないので注意してください。
モジュールが開けたらコメント「申請アイテムから申請(sc_request)を取得。」を入力しておきます。
そして『Table』に『Request[sc_request]』、Conditionsの最初の項目に『Sys ID』『is』を設定します。
Sys IDとの比較項目には右側の『Data』タブから、『Trigger』下の『Requested Item Record』内にある『Request』オブジェクトをドラッグ&ドロップしてください。
確認出来たら「Done」します。
要するに、裏で一元管理されているRequest(注文)のデータベースから、トリガーされた商品を含む注文のIDで検索をかけて注文情報全体を引っ張ってきているわけですね。
ここで取ってきた注文情報を処理に使用していきます。
『then』句の下、『End』の前に『Update Record』アクションを追加してください。
コメントに「申請を棄却とする」と入力し、『Record』は右側の『LookUp Record』の『Request Record』をドラッグ&ドロップします。
『Table』に『Request[sc_request]』を選択し、『Fields』には『Request State』『Close Rejected』を入れます。
これで承認が許可されなかった場合は棄却して終了することが出来るようになりました。
承認が許可された場合も同じ流れで作成します。
フローの最後に『Update Record』を追加します。コメントは「申請を完了して閉じる。」です。
『Fields』を『Closed Complete』に設定することで、申請を正常処理して終了とすることができます。
これでようやくフローが完成しました。
手順に誤りが無いか今一度確認し、問題なければ「Save」で保存してください。
商品とフローの紐づけ
フローは完成したので、あとはこれを実際の商品を紐づける作業をすれば完了です。
その前にこのフローを有効化(Activate)する必要があります。
Flow Designerのヘッダーから「Activate」ボタンをクリックします。
十数秒間待機したのち、緑色の「Activate」という文字列が表示されたらOKです。
これでFlow Designer上での操作は全て終了です。タブごと閉じていただいて構いません。
Service Managementに戻ります。
『Maintain Items』から、自分が作成した商品の詳細画面を開きます。ここではバジルを開いたとします。
設定項目の『Process Engine』タブから『Flow』をクリックし、プルダウンから『お花注文申請』を選択します。
確認できたら「Update」してください。
自分が作成した他の商品に関しても全て同じ手順で『お花注文申請』を設定してください。
これで、その商品の注文がされた際に先程作成したフローが流れるようになります。
商品の注文
これでFlowerDeliveryシステムの実装は完了です。実際に注文をしてみましょう。
Service Portalから商品を選択し、注文を行います。
注文すると、フロー作成以前には表示されなかった『Applovals』という項目が出現しています。
これは注文に対する承認者として設定したSystem Administrator (を含むTeam Development Core Reviewerのメンバー) に申請が届いた、ということですね。
詳細を開いてみると、確かに今行った注文情報の照会とApprove/Rejectの操作ができるようになっています。
きちんとフローが注文に紐づいていることが確認できました。
終わりに
このように、ServicePortalとServiceCatalogを用いたチュートリアル実装ができました。
足りない機能も数多くありますが、このチュートリアルを通じてServiceNowの使い方、考え方などの理解が深まればいいのではないかと思います。
以上です。
