［ServiceNow］Scriptingについて

※この記事はServiceNow初心者が学習用のために記載した記事です。内容について誤っている場合がございます。不足点などございましたらコメントいただけますと幸いです。
https://servicenow-lab.com/scripting-overview/
さんの記事を丸写しになっております。学習用です。ご容赦ください。

# Scriptingの使用目的
- アプリケーションにおいて、何らかのCustomization（カスタマイズ）を行う必要があるため

# Scriptingとは
- ServiceNowはクライアントサーバシステムである
    - クライアントサーバーシステムとは、役割を分担したコンピュータ間の通信モデルのこと
        - クライアント: ユーザーが利用する端末やアプリケーション。必要なデータや処理をリクエストする
            - （例: Webブラウザやスマホアプリ）
        - サーバー: リクエストを受け取り、データを提供したり処理を実行したりする役割を担います。
            - （例: Webサーバーやデータベースサーバー）
- 開発者は、クライアントサイドとサーバーサイドにおいて、様々なタイミング、条件で任意の処理を行うためのスクリプトを書くことができる

- ServiceNowのSpriptingでは、JavaScriptとServiceNowのAPIを組み合わせて処理を記載する
- Spriptingには、大きく分けて以下の２種類に分けられる
    - Client-side scripting
    - Server-side scripting

![スクリーンショット 2025-01-17 074804.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3624279/3ac3ac37-a420-e30c-b76d-9e041032081b.png)


# Client-side scripting（クライアントサイドスクリプト）

- クライアントサイド=ウェブブラウザで動作するスクリプトを記述する
    - 記載方法
        - Client Script
        - UI Policy（Script）
        - UI Action
        - UI Script
    - Client Script
        - Client Scriptを用いることで、フォームやリストに次のような処理を埋め込むことができる
        - Client-sideのみで動作する
        - 例
            - ある項目の値が変更されたとき、入力された値をチェックし、不適当な値の場合はエラーメッセージを表示
                - フォームが送信されたとき、複数の項目の値の整合性をチェックし、必要に応じてエラーメッセージを表示しフォーム送信を中断する

    - UI Policy（Script）
        - UI Policyは、基本的にはノーコードで条件に応じた項目の表示/非表示などを制御するための機能
        - Client Scriptと同様にScriptを記載することも可能
        - 例
            - セレクトボックス型の「カテゴリ」項目で”その他”が選ばれたとき、テキスト型の「その他詳細」項目を表示して入力を必須にする
                - ある項目の値が削除された（空になった）とき、別のある項目の値も削除する
    - Client ScriptとUI Policyの記載方針（例）
        - UI Policy（no-code）実装できるものはすべてUI Policyで実装する
        - それ以外はすべてClient Scriptで実装する。つまりUI Policy（Script）は使わない
    - UI Action（Client-side）
        - フォームやリスト上に”ボタン”や”リンク”を表示し、それが押下されたときに実行されるスクリプトを埋め込むための機能
        - ボタン押下などの明示的なトリガーにたいおう
        - クライアントサイドスクリプトもサーバーサイドスクリプトも埋め込むことができる
        - 例
            - “削除”ボタンが押下されたときに、「本当に削除しますか？」というポップアップを表示する
    - UI Script
        - UI Scriptはクライアントサイドスクリプトの共通処理を再利用可能なパッケージ化（共通化）するための機能
        - 複数のクライアントサイドスクリプトから利用できる共通処理

# Server-side scripting（サーバーサイドスクリプト）
- サーバーサイド=インスタンスで動作するスクリプトを組み込むことのできる機能
- サーバーサイドスクリプトは、インスタンス上で動作するため、データベースに対する操作が可能
    - 例
        - 特定のレコードが更新された際に、関連するレコードを連鎖的に更新する
    - 記載方法
        - Business Rule
        - UI Action（Server-side）
        - Script Action
        - Scheduled Job
        - その他のサーバーサイドスクリプトを埋め込むことのできる機能
            - Access Control List（ACL）
            - Transform Map（変換マップ）
            - Reference（参照）型項目のReference qualifier（参照修飾子）
            - Default value（デフォルト値）の設定
            - Flow designer
        - Script Include
    - Business Rule
        - 主にデータベース操作の前後で動作するスクリプトで、SQLでいうTriggerのようなもの
            - Trigger
                - データベース内で特定の操作が行われたときに発動する
                - トリガーは事前に設定しておくと、該当する操作が行われた際に自動的に処理を実行される
                - 主な用途
                    - データの整合性を保つ
                    - ログを記録する
                    - 自動計算や通知の実行
        - 例
            - 「担当者」項目が設定された際に、ServiceNow上でその担当者の上長に設定されているユーザを「承認者」項目に自動で設定する
            - レコードが挿入される前にレコードのチェックを行い、問題があればエラーメッセージを表示し、レコードの挿入を中止する
            - レコードが更新されたとき、そのレコードに紐づく別のレコードを連鎖的に更新する
    - UI Action（Server-side）
        - フォームやリスト上に”ボタン”や”リンク”を表示し、それが押下されたときに実行されるスクリプトを埋め込むための機能
        - クライアントサイドスクリプトもサーバーサイドスクリプトも埋め込むことができる
        - 例
            - ボタンが押下されたときに、フォームに入力された内容をデータベースの指定のテーブルに挿入する
            - ボタンが押下されたときに、外部システムとの連携を行い、フォームに入力された内容を送信する
        - 標準で用意されている、”Submit（送信）”ボタン、”Update（更新）”ボタン、”Delete（削除）”ボタンはUI Actionで作られる
    - Script Action
        - 特定のイベントが発生した場合に処理を起動したい場合に使う
        - イベントの種類
            - ServiceNowの標準で定義されていて特定の条件を満たすと自動で生成されるもの
            - ユーザが定義しサーバーサイドスクリプト内で生成したもの
        - 例
            - ログイン失敗のイベントが発生したとき、ログイン連続失敗回数を1つ増やす（標準の例）
    - Scheduled Job
        - 名前の通り予め設定されたタイミングで処理を実行する機能
        - 指定可能なタイミング
            - オンデマンド（運用者が実行ボタンを押したときに実行）
            - 日次・月次などの定期実行
        - 例
            - 日次で未承認の承認レコードをチェックし、承認者にリマインドのメール（チャット）を送信する
        - ※ある処理をスケジュール実行したい場合、Flow desginerを用いて可能な限りノーコードで作るべきなので、まずはFlow designerでの実装を検討
            - Flow Designer：コーディング不要で業務プロセスを自動化できるツール
            - 視覚的なインターフェースを使い、フロー（処理の流れ）を簡単に作成
    - その他のサーバーサイドスクリプトを埋め込むことのできる機能
        - Access Control List（ACL）
            - ServiceNowのデータ操作権限を制御する仕組み
            - データへの操作（CURD）を許可する条件をスクリプトを用いて指定することができる
        - Transform Map（変換マップ）
            - ファイルや外部システムからデータを取り込む機能
            - ransform Map（変換マップ）において、スクリプトを組み込むことで、データ取り込み前にデータの形式チェックを行うことができる
        - Reference（参照）型項目のReference qualifier（参照修飾子）
            - 特定のテーブルから値を選択させるReference（参照）型項目において、選択肢となるレコードを絞り込む条件をスクリプトで指定することができる
        - Default value（デフォルト値）の設定
            - スクリプトを用いて動的にデフォルト値を設定することができる
            - 例
                - 日付型の項目に今日の日付を設定する
                - Incident（テーブル）を始めとしたTask（タスクテーブル）のNumber（番号）項目の自動採番も、Default valueに設定されたスクリプトによって行われている
        - Flow designer
            - ワークフローを作成する機能であるFlow designerは、基本的にノーコードで自動化ワークフローを作成するための機能
            - 必要に応じてワークフロー中の任意の個所にスクリプトを埋め込むことができる
    - Script Include
        - サーバーサイドスクリプトの共通処理を再利用可能なパッケージ化（共通化）するための機能
            - クライアントサイドスクリプトはUI Script
        - クライアントサイドスクリプトの共通化機能であるUI Scriptと異なる点は、一つのScript Includeは一つのクラスとして定義される
    - UI ActionとBusiness RuleとClient Script（onSubmit）の使い分け（例）
        - UI Action（ボタン）でバリデーションは行わない
            - フォーム送信を行うUI Action = “Submit(送信)”ボタンにバリデーションを入れる場合、そのテーブルにおいてSubmitボタンを上書きする必要があり、OOTBを上書きしてしまうため
        - バリデーションの結果に応じて、フォーム送信前に「〇〇ですが送信しますか？」といった警告を出したい場合は、Client Script（onSubmit）を用いる
            - 仕組み上Business Ruleではできないため
        - データの更新経路がフォーム以外もある場合はBusiness Ruleを用いる
            - Client Scriptはクライアント側でしか動かすことができないため、スクリプト経由でのデータの更新が考えられる場合は、Business Ruleが適している


# 参考
https://servicenow-lab.com/develop-transfer/
https://servicenow-lab.com/scripting-overview/