script-sync

スクリプトの取得、編集、プッシュのワークフロー

概要

Happy Platform MCP 5.1 には、自動スクリプト同期や監視ツールはありません。 この明示的なワークフローを使用して、現在のレコードを取得し、ローカルコピーを編集し、リモートレコードが変更されていないことを確認してから、SN-Update-Record で意図したスクリプトフィールドをプッシュします。

このワークフローでは、バックグラウンドでの自動化よりも、レビュー可能な変更と競合の検出を優先します。Business Rules、Script Includes、Client Scripts、UI Scripts、UI Actions、Scheduled Jobs、およびスクリプトがテーブルフィールドに保存されているその他のレコードで使用できます。

前提条件

• 対象のスクリプトテーブルへの読み取りおよび書き込みアクセス
• 対象の ServiceNow インスタンス名
• インストール済みの npm パッケージの外部にあるローカルディレクトリ
• Git またはその他のローカルバージョン管理システム
• テーブル名、レコードの sys_id、スクリプトフィールド名
• プッシュする前に、正しいアプリケーションスコープと更新セットを選択していること

手順

1. レコードを特定する

フィールドを明示した、上限付きのクエリを使用します。リクエストは必ず対象のインスタンスにルーティングしてください。

Tool: SN-Query-Table
Parameters:
  table_name: sys_script_include
  query: name=IncidentUtils
  fields: sys_id,name,script,sys_updated_on,sys_mod_count,sys_scope
  limit: 5
  instance: dev

クエリの結果が曖昧な場合は、そこで中止してください。sys_id を1つ選択し、同じ名前のスクリプトを複数更新すると決めつけないでください。

2. 正式なレコードを取得する

Tool: SN-Get-Record
Parameters:
  table_name: sys_script_include
  sys_id: <script_sys_id>
  fields: sys_id,name,script,sys_updated_on,sys_mod_count,sys_scope
  instance: dev

返された script の値だけをローカルの .js ファイルに書き込みます。隣接するローカルメタデータには、この取得時のテーブル、sys_id、インスタンス、sys_updated_on、sys_mod_count を記録します。ServiceNow の認証情報をファイルやリポジトリに入れないでください。

レイアウト例：

scripts/servicenow/script_includes/IncidentUtils.js
scripts/servicenow/script_includes/IncidentUtils.metadata.json

3. ローカルで編集してレビューする

IDE で JavaScript を編集し、該当する静的チェックやテストを実行して、Git の差分を確認します。変更は、デプロイする予定のスクリプトフィールドに限定してください。

4. プッシュ前にリモートの最新状態を確認する

更新の直前に、レコードを再取得します。

Tool: SN-Get-Record
Parameters:
  table_name: sys_script_include
  sys_id: <script_sys_id>
  fields: sys_id,script,sys_updated_on,sys_mod_count
  instance: dev

sys_updated_on と sys_mod_count の両方を、保存した取得時のメタデータと比較します。また、返されたスクリプトと元のローカルベースも比較してください。いずれかの値が変わっている場合は中止し、新しいバージョンを取得してリモートの変更を確認し、ローカルでマージします。より新しいリモート編集を自動的に上書きしてはいけません。

5. レビュー済みのスクリプトフィールドをプッシュする

最新状態の確認に合格したら、意図したフィールドだけを更新します。

Tool: SN-Update-Record
Parameters:
  table_name: sys_script_include
  sys_id: <script_sys_id>
  data:
    script: <reviewed_local_script>
  instance: dev

通常のレコード更新にバックグラウンドスクリプトを使用しないでください。汎用 MCP 更新が主要な操作であり、呼び出しごとのインスタンスルーティングを維持します。

6. プッシュを検証する

SN-Get-Record でレコードを再度読み取ります。リモートの script がレビュー済みのローカル内容と一致することを確認し、新しい sys_updated_on と sys_mod_count を記録します。その後、上限付きの SN-Query-Table クエリを使用して、現在の更新セット内に関連する sys_update_xml のキャプチャがあることを確認します。

7. 後続の編集でも明示的に繰り返す

Happy Platform MCP 5.1 に監視モードはありません。変更のたびに、最新状態の確認、更新、検証を繰り返します。ローカルのファイル監視ツールでリンティングやテストを実行してもかまいませんが、上記の明示的な競合チェックと更新手順を経ずに ServiceNow の変更をプッシュしてはいけません。

サポートされるレコードパターン

スクリプトの種類	テーブル	一般的なスクリプトフィールド
Business Rule	sys_script	script
Script Include	sys_script_include	script
Client Script	sys_script_client	script
UI Script	sys_ui_script	script
UI Action	sys_ui_action	script
Scheduled Job	sysauto_script	script
Fix Script	sys_script_fix	script

このワークフローを応用する前に、不慣れなテーブル名やフィールド名は SN-Get-Table-Schema で確認してください。

ベストプラクティス

• 設定をプッシュする前に、アプリケーションスコープと更新セットを設定します。
• ライブレコードを呼び出すたびに、明示的に instance を指定します。特に、並行作業や重要な環境では必ず指定してください。
• 編集の直前にプルし、プッシュの直前に鮮度を確認します。
• 必要なスクリプトと並行処理メタデータのみに、フィールドの選択を絞ります。
• 検証が成功するまで、プルした元のバージョンを保持します。
• 差分とリモートでの検証を確認してから、ローカルの変更をコミットします。
• インスタンスの認証情報やアクセストークンを、ローカルのスクリプトファイルに保存しないでください。

トラブルシューティング

プル後にリモートレコードが変更された

プッシュしないでください。ローカルの編集内容を保存し、新しいリモートスクリプトを取得して、元のプルをベースに三者間マージを実施します。マージの解決後、鮮度チェックを再実行します。

更新は成功したのに、更新セットのレコードが表示されない

正しいアプリケーションスコープと現在の更新セットが設定されていることを確認し、sys_update_xml を調べます。むやみに再試行せず、まず対象のテーブルまたはフィールドが更新セットのキャプチャ対象かどうかを確認してください。

更新後にローカルとリモートのスクリプトが異なる

レコードを再取得し、内容を厳密に比較します。ビジネスルール、フォーマッター、またはスコープ付きアプリのポリシーによって値が変換されていないか確認します。不一致の原因が明らかになるまでは、リモートレコードを正とします。

継続的な同期が必要な場合

Happy Platform MCP 5.1 には、自動プル、プッシュ、または監視のツールはありません。明示的なワークフローを維持するか、同等の鮮度チェックと検証のゲートを備えた、別途レビュー済みのデプロイパイプラインを構築してください。

関連スキル

• admin/update-set-management
• development/business-rules
• development/script-includes