ServiceNowでボタンが出ないときの切り分けチェックリスト：6層を10分で潰す

昨日まで押せていたResolveボタンが、今日は消えている。管理者に聞いても「設定は変えていない」と言われる相談は珍しくありません。ServiceNowのボタンや右クリックメニューの多くはsys_ui_actionという1つのテーブルで管理されていますが、表示・非表示を決める場所は6層に分かれています。ZurichのPDIでResolveボタンを実際にたどり、6層のどこで止まっていたかを確認しました。

結論：ボタンが出ない原因は6層のどれか

先に全体像です。

• ボタンが出ない原因は、active・table・form_button／list_button・condition・条件スクリプト・ロールという6層のどれかにあります。上から順に潰していけば、途中で当たりが付きます。

• sys_ui_action 2,484件のうち、83%にcondition、89%に条件スクリプトが設定されていました。「ボタンが出ない」の大半は、スクリプトの評価結果で決まります。チェックボックスの設定値だけを追っても行き止まりになります。

• Incidentの Resolve ボタンの condition は new global.IncidentUtils().canResolveIncident(current) でした。条件式ではなくScript Include呼び出しのため、condition欄を読むだけでは判定できません。

上から下へ、コストの低い層から順に確認します。図の色は確認コストの大きさに対応しています。濃紺は最初に見る箇所、緑はすぐ分かる層です。橙は件数が多く時間がかかる層、赤は原因が確定した状態を示します。灰は今回の確認対象から外れる範囲です。

各層の実測件数は上の表のとおりです。件数を見ると、④condition以降の2層に大半の判定が集中していることが分かります。

なぜ「condition を読むだけ」では判定できないのか

理由は単純です。sys_ui_action全体2,484件のうち、conditionが入っているのは2,073件で83%にのぼります。さらに、条件スクリプト（script欄）を持つものは2,220件で89%です。フォームボタンとして使われているのはこのうち865件、一覧側のボタンはわずか13件でした。数の少ない一覧ボタンより、フォームボタンの方が調査対象になりやすい計算です。

condition欄には、current.active==true のような単純な式だけが入っているとは限りません。Incidentの Resolve ボタンを開くと、condition欄には次の1行だけが入っていました。

new global.IncidentUtils().canResolveIncident(current) という呼び出しだけで、判定式そのものは書かれていません。この1行を見ても、どんな条件でボタンが出るかは分かりません。呼び出し先のメソッドまで開く必要があります。

Resolveボタンの実例

canResolveIncident の中身を開くと、判定は3段階でした。まずincident_stateがClosed・Resolved・Canceledのいずれかなら、ロールに関係なくfalseになります。次にユーザーが itil_admin・itil・sn_incident_write のいずれかのロールを持っていれば、trueを返します。どちらでもない場合は、申告者本人かつMajor Incidentでなければtrueという判定でした。

ここで意外だったのが、このメソッドの置き場所です。UI Actionのconditionには global.IncidentUtils というクラス名が書かれていますが、canResolveIncident は IncidentUtils の中には存在しません。IncidentUtils は IncidentUtilsSNC というクラスを継承しており、メソッドの実体は継承元にありました。名前だけを頼りにスクリプトを開いても、目的の処理は見つからないことになります。

実機で気づいたこと

候補は1つではありませんでした。Script Includeを名前で検索すると、思ったより数が多く出てきます。「IncidentUtils」を含む名前で検索すると8件ヒットしました。内訳はIncidentUtils・IncidentUtils2・IncidentUtils2SNC・IncidentUtilsSNCの4件です。もう4件は、Service Operations Workspace側のSOWIncidentUtils系でした。UI Actionのconditionに書かれたクラス名と同じ名前を検索欄に入れても、似た名前が並んで一瞬迷います。

ロールの置き場所も1つではありませんでした。sys_ui_action_roleには512件のレコードがありますが、Archive RecordのようにUI Action自体のconditionへ gs.hasRole("itil") を直接書いているケースもあります。sys_ui_action_roleだけを確認して「ロール制限なし」と判断すると、スクリプト側の条件を見落とします。

もう1つ目についたのが、form_buttonとlist_buttonの差です。フォーム上のボタンは865件ある一方、一覧のボタンはわずか13件でした。一覧画面に特定のボタンが出ないという相談は、フォームに比べて設定できる余地そのものが小さいという前提を持って調査した方が早く終わります。

購入すると何が手に入るか

ここから先は、6層それぞれを「どのURLを開き、どのフィールドを見て、どう判定するか」まで落とし込んだチェックリストです。チェック項目を上から順に潰していけば、原因が確定した層でその先の確認をやめられます。層ごとの実機スクリーンショットとScript Includeを継承元までたどる手順を載せました。ロールが2か所に散らばる問題への対処、つまずきやすい点、よくある質問5問も収めています。次に同じ相談を受けたときに、そのまま画面を開きながら潰していける分量にしてあります。