はじめに
- AI（Claude）に対して、「ServiceNowのSoftware Asset Management（SAM）のスケジュールジョブをPDIから取得し、代表的な機能の処理フローを作成してみて」とお願いしてみました。
- もちろん、SAMの機能はスケジュールジョブだけで構成されているわけではないので無茶振りはありますが、それを踏まえての結果です。
- 結論から言いますと、ポイントは掴めている感じでした。何もするにも、ソフトウェア正規化が大事だと。
（おそらくServieNowマニュアルやコミュニティの知識で保管しているでしょう）
Claudeの実行結果
調査結果
SAM 中核ジョブ 処理フロー(★★★)
SAM のライセンス計算は、以下の3ジョブが 順番に 動くことで成立する。
前段の出力が次段の入力になる「データパイプライン」を形成している。
[検出データ] → ① 正規化 → ② ソフトウェアモデル突合 → ③ ライセンス照合 → [ELP/コンプライアンス]
テーブル名は SAM Pro のバージョンにより差異あり。代表的なものを記載。
① SAM - Normalize discovery models using content library rules
- 種別: daily (08:00) / スコープ: Global
-
目的: Discovery・SCCM 等が収集した「生の検出ソフトウェア」を、ServiceNow
コンテンツライブラリの正規化ルールに照合し、標準的な publisher / product /
version / edition に整える。以降の全計算の前提。
入力
- 未正規化の検出モデル
samp_sw_discovery_model(生の publisher/title/version 文字列) - コンテンツライブラリ正規化ルール(SaaS 提供の normalization content)
処理
- 正規化ステータスが未処理の検出モデルを抽出
- 生文字列(publisher 名・製品名・バージョン)をコンテンツ規則と突合
- 一致 → 正規化済みの publisher/product/version/edition を割当
- 正規化ステータスを更新(normalized / not found)
- 未一致は 正規化候補(suggestion) として残す
→SAM - Find Normalization Suggestionsが後で拾う
出力
- 正規化済み検出モデル(ソフトウェアモデルと突合可能な状態)
② SAM - Discovery Model to Software Model matching
- 種別: weekly (Tue 10:00) / スコープ: Global
-
目的: 正規化済みの検出モデルを、ライセンス計算の単位である
Software Model(製品モデル)に紐づける。
入力
- ①の出力(正規化済み検出モデル)
- Software Model
cmdb_software_product_model
処理
- 正規化された publisher/product/version/edition をキーに Software Model を検索
- 一致する Software Model に検出モデルを関連付け(多対多)
- Software Model が存在しない場合は新規作成 or サジェスト
- 検出モデルに紐づく インストール
samp_sw_installが、
Software Model 経由で「ライセンス消費」として認識される
出力
- Software Model に紐づいたインストール群(=消費側の集計対象)
③ SAM - Software License Reconciliation
- 種別: weekly (Mon 10:00) / スコープ: Software Asset Management
-
目的: SAM の心臓部。製品ごとに「保有権利(entitlement)」と
「消費(install/usage)」を突合し、ELP(実効ライセンスポジション) と
コンプライアンス状態を算出する。
入力
- 権利
alm_license(購入したライセンス・数量・メトリック) - 消費(②の出力: Software Model に紐づく install)
- 使用状況
samp_sw_usage(SAM - Update Software Usageの出力) - ライセンスメトリック(per device / per core / PVU / named user 等)
- 割当(allocations)、アップ/ダウングレード権、スイート定義
処理
- 製品ごとに権利数(rights)を集計
- メトリックに応じた消費数(consumption)を算出
- per-core → コア/CPU 数、per-device → インストール数 など
- アップグレード/ダウングレード権・スイート展開・割当を適用
-
rights − consumption= コンプライアンスポジション- 正(余剰) = 未使用 → 回収候補へ
- 負(不足) = コンプライアンス違反(購入要)
-
alm_licenseのコンプライアンス状態/数値を更新 - 余剰分は
SAM - Identifying New Reclamation Candidatesに連携
出力
- ELP(実効ライセンスポジション)
- 製品別コンプライアンス状態(compliant / 違反 / 余剰)
- リクラメーション(回収)候補
パイプライン全体の依存関係
| 順 | ジョブ | 依存(前提) | 主な出力先 |
|---|---|---|---|
| ① | Normalize discovery models | コンテンツライブラリ | ② |
| ② | Discovery→Software Model matching | ①の正規化済みモデル | ③(消費側) |
| ③ | Software License Reconciliation | ②の install + alm_license 権利 + usage |
ELP / 回収候補 |
ポイント: ③だけ動かしても、①②が正しく回っていなければ消費数が不正確になり、
ELP が信頼できない。トラブルシュート時は ①→②→③ の順でデータ健全性を確認する。
補助ジョブ(★★☆)の接続
中核3ジョブの各段に、以下の補助ジョブが効く(止まっても ELP は壊れないが鮮度・精度が落ちる)。
| 段 | 補助ジョブ | 種別 | 役割 |
|---|---|---|---|
| ① 正規化 | Apply latest content changes | periodically | 正規化コンテンツを最新化(精度の素) |
| ① 正規化 | Find Normalization Suggestions | weekly | 未一致を正規化候補として救済 |
| ① 正規化 | Deduplicate Install Table | daily | install 重複排除(数え過ぎ防止) |
| ② 突合 | Get install count for software model | weekly | モデル別の消費数を確定し ③ へ渡す |
| ③ 照合 | Update Software Usage | daily | per-user/per-device 判定の使用実績 |
| ③ 出力後 | Identifying New Reclamation Candidates | monthly | 余剰ライセンスの回収候補抽出 |
| ③ 出力後 | Create Calculated Software Lifecycles | weekly | EOL/サポート終了を算出 |
図解ファイル
-
中核フロー
-
拡張フロー(補助ジョブ込み)
