この回で作るもの
| # | 作るもの | 役割 |
|---|---|---|
| 1 | 自動化ユーザーとAssignment group | SCTASKの担当で自動化の状態を表す |
| 2 | APIサービスユーザー | 自動化エンジンがServiceNowへアクセスするためのユーザー |
| 3 | 共通Variable Set | 全依頼種別で共通の入力と結果の保存先 |
| 4 | 個別Variable Set | 依頼種別ごとの入力値と、失敗時の引継ぎ先 |
| 5 | Catalog Item | 依頼の入口（サービス化） |
| 6 | Execution Plan | 作業の順序制御（サービスの連結） |
この回の最後には、Catalog Itemから依頼を出すと、Open + autoengine1 のSCTASKが生成される状態になります。これが、次回以降で自動化エンジンがPullする対象です。
画面のメニュー名や項目名は、ServiceNowのバージョンや言語設定によって異なる場合があります。本記事は検証用インスタンスでの最小構成を前提としています。
1. 自動化ユーザーとAssignment groupを作る
第2回で説明したとおり、自動化の状態はSCTASKの State × Assigned to で表します。そのために、状態を名前で表す自動化ユーザーを作成します。
1.1 Assignment group
| 項目 | 設定値 |
|---|---|
| Name | autoengine1group |
1.2 自動化ユーザー
| User ID | 意味 | 所属グループ |
|---|---|---|
autoengine1 |
取得待ち、または確保済みで実行待ち | autoengine1group |
autoengine1running |
自動化エンジンで実行中 | autoengine1group |
これらは「状態を表すためのユーザー」で、ログインには使いません。SCTASKのAssigned toに設定できるよう、Activeにしておきます。
設計上は、将来の拡張用に autoengine1failed（失敗）や autoengine1retry（再実行待ち）といったユーザー名も考えられます。ただし本連載では使いません。失敗時は、依頼ごとに指定した引継ぎグループへ移す方式にしています。
1.3 APIサービスユーザー
自動化エンジンがServiceNowへアクセスするためのユーザーです。状態を表すユーザーとは分けて作成します。
| 項目 | 設定値 |
|---|---|
| User ID | svc_autoengine1_api |
| 用途 | Table APIとScripted REST APIの呼び出し |
このユーザーには、次の操作ができる権限が必要です。
- SCTASK、RITM、REQ、Catalog Variableの参照
- SCTASKのState、Assigned to、Assignment group、Work Notesの更新
- RITMの隠し変数（
execution_result_json）の更新
必要なロールは、インスタンスのACL設定によって異なります。itilロールで足りるかどうかは、実機で確認してください。本番環境では、最小権限の原則に沿ってロールとACLを設計してください。
2. 共通Variable Setを作る
全Catalog Itemで共通して使う変数です。
| 変数名 | 種類 | 表示 | デフォルト値 | 用途 |
|---|---|---|---|---|
target_host |
Single Line Text | 表示 | （空白） | 作業対象のホスト |
execution_result_json |
Single Line Text | 非表示 | [] |
自動化結果の履歴（JSON配列） |
execution_result_display |
Multi Line Text | 表示 | （空白） | 依頼者向けの結果サマリー |
ポイントは次の2つです。
-
execution_result_jsonのデフォルト値は[]にします。 結果登録APIは、この配列にSCTASKごとの結果を追記していきます。未設定や空文字の場合も[]として扱います。 -
execution_result_jsonは状態の判定には使いません。 状態はあくまでSCTASKの State × Assigned to で表し、この変数は結果データの保存専用にします。
3. 個別Variable Setを作る
依頼種別ごとに固有の入力値を定義します。例として「Linuxログ取得」の個別Variable Setを作ります。
| 変数名 | 用途 |
|---|---|
failure_assignment_group |
自動化が技術的に失敗したときの引継ぎ先グループ（Reference型: sys_user_group） |
log_path |
取得対象のログパス |
destination |
配置先の識別子 |
description |
依頼の補足（自動化では使わない場合もある） |
3.1 failure_assignment_groupは全ての個別Variable Setに必ず用意する
failure_assignment_groupは、全依頼種別に共通する変数です。ただし、引継ぎ先は依頼種別ごとに異なるため、個別Variable Set側に必ず用意するルールにしています。
| 項目 | 設定値 |
|---|---|
| Type | Reference |
| Reference |
sys_user_group（Group） |
| Default value | 引継ぎ先グループの sys_id を手入力 |
| 表示 | 依頼者に選ばせない場合は非表示 |
引継ぎ先グループのsys_idは、グループのレコードを開き、フォームのヘッダーメニューから「Copy sys_id」で取得できます。
Default value: 0a1b2c3d4e5f60718293a4b5c6d7e8f9 ← 運用チームのグループのsys_id（例）
Reference型にしておくことで、ServiceNow側で参照先が存在するグループかどうかを判定できます。結果登録APIは、この変数を使ってSCTASKのAssignment groupを変更します。値が未設定、参照先のグループが見つからない、またはグループが非アクティブの場合は、SCTASKを更新せずにエラーを返します（第6回で解説します）。
sys_idはインスタンスごとに異なります。開発環境から本番環境へ移行するときは、Default valueのsys_idを移行先のグループに合わせて設定し直してください。
3.2 automation_typeのような変数は作らない
「どの自動化処理を実行するか」を表す変数は作りません。処理のキーは、次に説明するExecution PlanのTask Templateに持たせます。
既に同様の変数がある場合は、Catalog Script、API、自動化エンジンのどこからも参照されていないことを確認してから削除します。
4. Catalog Itemを作る
依頼種別ごとにCatalog Itemを作ります。
| 項目 | 設定例 |
|---|---|
| Name | Linuxログ取得 |
| Variable Sets | 共通Variable Set、Linuxログ取得用の個別Variable Set |
| Execution Plan | 次章で作成するExecution Plan |
Catalog ItemにWorkflowやFlowを設定していると、Execution Planが使われない場合があります。本連載ではExecution Planで順序を制御するため、WorkflowやFlowは設定しません。インスタンスでの挙動は実機で確認してください。
5. Execution Planを作る
5.1 Task Templateの設定
自動化エンジンに実行させる作業のTask Templateを、次のように設定します。
| フィールド | 設定例 |
|---|---|
| Short description | REQTYPE_LINUXLOG_ACTION1 |
| Description | Automation Execution |
| Assignment group | autoengine1group |
| Assigned to | autoengine1 |
| State | Open |
Short descriptionは、自動化エンジンが処理を選ぶためのキーです。人が読む説明文ではなく、機械が判読できる値にします。
<REQUEST_TYPE>_<ACTION_NUMBER>
REQTYPE_LINUXLOG_ACTION1 Linuxログ取得の作業1
REQTYPE_LINUXLOG_ACTION2 Linuxログ取得の作業2
REQTYPE_LSOF_ACTION1 lsof取得の作業1
人向けの説明はDescriptionに書きます。キーは自動化エンジン側の処理と1対1に対応させ、重複しないように管理します。
5.2 人の作業と複数の自動化エンジンを組み合わせる
Execution Planは、前のSCTASKが正常に完了すると次のSCTASKを生成します。各Task Templateの担当を変えるだけで、人の作業と自動化の作業を1つの依頼の中に並べられます。
| 順序 | Short description | Assignment group | Assigned to | 実施者 |
|---|---|---|---|---|
| 1 | REQTYPE_LINUXLOG_ACTION1 |
autoengine1group |
autoengine1 |
自動化エンジン1 |
| 2 | 例: 取得ログの確認
|
運用チームのグループ | （空欄） | 人 |
| 3 | REQTYPE_LINUXLOG_ACTION2 |
autoengine2group |
autoengine2 |
自動化エンジン2 |
- 人が担当する作業は、通常のSCTASKとして運用チームのキューに入ります。
- 自動化エンジン2を使う場合は、1章と同じ要領で
autoengine2group、autoengine2、autoengine2runningを作成します。 - 今は人が担当している作業2も、自動化できた時点でTask Templateの担当を自動化ユーザーに変えるだけで切り替えられます。Catalog Itemは変わりません。
第7回で紹介する、進捗をRITMへ転記するBusiness Ruleは、サンプルではautoengine1系のユーザー名で判定しています。複数の自動化エンジンを使う場合は、判定条件を拡張してください。
6. 動作確認
Catalog Itemから依頼を1件出し、次の点を確認します。
- RITMが作成され、変数に入力値が保存されている
-
execution_result_jsonが[]になっている -
failure_assignment_groupに引継ぎ先グループが設定されている（表示名でグループ名が見える） - SCTASKが1件生成されている
-
SCTASKのShort descriptionが
REQTYPE_LINUXLOG_ACTION1になっている -
SCTASKのStateが
Open、Assignment groupがautoengine1group、Assigned toがautoengine1になっている - 1件目のSCTASKを手動でClosed Completeにすると、次のSCTASKが生成される（複数ステップの場合）
最後の項目では、Closed Completeにしたときに次のステップへ進むことを必ず確認してください。結果登録APIは、自動化が成功したときにSCTASKをClosed Completeへ更新します。ここが期待どおりに動かないと、Execution Planが先に進みません。
Stateの内部値（Open=1、In Progress=2、Closed Complete=3など）は、インスタンスによって異なる場合があります。後続の回で作るAPIやスクリプトの値と合っているか、ここで確認しておいてください。
次回予告
次回は、自動化エンジン側からTable APIで実行待ちのSCTASKを取得し、確保する部分を実装します。Open + autoengine1 の検索条件と、Stateを2に更新して確保する方法を紹介します。
連載記事
- 第1回 なぜ今Pull型連携なのか
- 第2回 全体アーキテクチャと設計方針
- 第3回 Catalog Item・Variable Set・Execution Planの準備（本記事）
※ 本記事の内容は個人の見解であり、所属する組織の公式な見解ではありません。