更新セットのsys_ID: インスタンス間で移動する際に実際に何が起きるのですか？

[JunshuO]

2つの転送方法と共通の動作

更新セットがターゲットインスタンスに適用される一般的な方法は 2 つあります。

更新セットを取得 は、リモートインスタンスから更新セットをプルするためのプラットフォームネイティブなメカニズムです。これは、ReleaseOpsがパイプラインステージ間で展開する際に内部的に利用するものです。

XMLのエクスポート/インポート は手動で行う方法です。更新セットをXMLにエクスポートした後、[XMLから更新セットをロード]機能を使用してターゲットにアップロードします。

どちらの方法も同じ結果をもたらします。更新セットは、 sys_remote_update_set テーブル（取得済み更新セット）に、 まったく新しいsys_id とともに格納されます。ソースインスタンスからの元のsys_idは、ターゲットの sys_update_set テーブルからはなくなりますが、失われたわけではありません。

元のsys_idはどこへ行くのですか？

ServiceNowは、ソースsys_idを sys_remote_update_set レコードの remote_sys_id フィールドに保持します。

<remote_parent_id/>
<remote_sys_id>662e2bb487cc8fd07c54db183cbb3568</remote_sys_id>

このフィールドは、インスタンスを跨いだ更新セットの 安定したID です。更新セットがどのように転送されたかに関わらず、 remote_sys_id は常にその元を指し示します。

これは、同じXMLを2回目にアップロードしたときに何が起こるかについても説明しています。ServiceNowは重複を作成するのではなく、 remote_sys_id をキーとして照合し、既存の取得済み更新セットレコードを上書きします。ローカルのsys_idではなく、作成元のsys_idがキーとなります。

コミットすると、さらに別のsys_idが作成されます

取得した更新セットをコミットすると、ServiceNowは sys_update_set （ローカル更新セットテーブル）に新しいレコードを作成します。このコミットされたレコードは、ソースsys_idとターゲットの取得済み更新セットのsys_idの両方とは異なる独自のsys_idを取得します。

これは、概念的に同じ更新セットに対する3つの異なるsys_idsです。

1. ソースインスタンス上の元のsys_id（DEVインスタンスの sys_update_set ）
2. ターゲット上の取得済み更新セットのsys_id（TESTインスタンスの sys_remote_update_set ）
3. ターゲット上のコミット済みローカル更新セットのsys_id（TESTインスタンスの sys_update_set ）

#3と#2の間のリンクは、 sys_update_set テーブルの remote_sys_id 列です。これは、 sys_remote_update_set レコードを指し示す参照フィールドです。この参照を辿れば、コミットされた更新セットがどこから来たのかをいつでも追跡することができます。

2 ステップルックアップ

ターゲットインスタンスでローカルにコミットされたsys_idが必要な場合（たとえば、ReleaseOpsパイプラインの[インスタンススキャンを実行]アクティビティに渡す場合）、ソースsys_idを直接使用することはできません。解決が必要です：

ステップ1 — ターゲットで取得済み更新セットレコードを見つけます：

Table: sys_remote_update_set
Query: remote_sys_idSTARTSWITH662e2bb487cc8fd07c54db183cbb3568

ステップ2 — コミットされたローカル更新セットを見つけます：

Table: sys_update_set
Query: remote_sys_id=<sys_id from step 1>

ステップ2で取得するsys_idは、ターゲットインスタンスが認識しているものであり、ターゲットインスタンスに対してローカルで実行されるあらゆる処理に必要なものです。

ReleaseOps の実践的なポイント

DEVのsys_idを指定し、TESTを対象とした場合、OOTBの[インスタンススキャンを実行]アクティビティは失敗します。そのレコードは単にそこには存在しないためです。代わりに、コミットアクティビティの後に上記の2ステップルックアップを組み込み、解決されたTESTのsys_idをスキャンに渡してください。

覚えておくべき1つの注意点として、コミット時にTESTのsys_idをキャプチャして、後で使用するために保存してはいけません。フローが失敗し、コミットが既に完了した後に再開された場合、最初のコミット処理は再度実行されません。常にルックアップを通じてsys_idを新たに解決してください。更新セットがコミットされた後はいつでも信頼性があります。

メンタルモデル

ステージ	テーブル	sys_id	追跡方法
ソースインスタンス	sys_update_set	元のsys_id	—
ターゲットで取得済み	sys_remote_update_set	新しいsys_id	remote_sys_id →ソース
ターゲットにコミット済み	sys_update_set	新しいsys_id	remote_sys_id → 取得済みレコード

この remote_sys_id フィールドは、すべての段階における一貫した連携の鍵となります。更新セットがどこに移動しても、このフィールドによってServiceNowと自動化は常にそれを特定できるようになります。

---

この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/developer-blog/update-set-sys-ids-what-actually-happens-when-yo...。

免責事項: 一部の日本語は、翻訳ソフトウェアを使用してお客様の便宜のために翻訳されています。正確な翻訳をご提供できるよう相当な努力を払っておりますが、いかなる自動翻訳も人間の翻訳者に代わすることはなく、そのようなことは意図されておりません。翻訳は「現状のまま」提供されています。他言語への翻訳の的確性、信頼性または正確性については、明示または黙示を問わず、いかなる保証も行われません。翻訳ソフトには限界があるため、一部のコンテンツが正確に翻訳されていない場合があります。これらの資料の公用言語は英語です。翻訳の際に生じる相違または不一致は、コンプライアンスまたは履行の目的に関しては拘束力を有さず、法的効力はないものとします。

This article was machine translated and replicated from the original source: https://www.servicenow.com/community/developer-blog/update-set-sys-ids-what-actually-happens-when-yo...。

[JunshuO]

更新セットがターゲットインスタンスに適用される一般的な方法は 2 つあります。

更新セットを取得 は、リモートインスタンスから更新セットをプルするためのプラットフォームネイティブなメカニズムです。これは、ReleaseOpsがパイプラインステージ間で展開する際に内部的に利用するものです。

XMLのエクスポート/インポート は手動で行う方法です。更新セットをXMLにエクスポートした後、[XMLから更新セットをロード]機能を使用してターゲットにアップロードします。

どちらの方法も同じ結果をもたらします。更新セットは、 sys_remote_update_set テーブル（取得済み更新セット）に、 まったく新しいsys_id とともに格納されます。ソースインスタンスからの元のsys_idは、ターゲットの sys_update_set テーブルからはなくなりますが、失われたわけではありません。

元のsys_idはどこへ行くのですか？

ServiceNowは、ソースsys_idを sys_remote_update_set レコードの remote_sys_id フィールドに保持します。

<remote_parent_id/>
<remote_sys_id>662e2bb487cc8fd07c54db183cbb3568</remote_sys_id>

このフィールドは、インスタンスを跨いだ更新セットの 安定したID です。更新セットがどのように転送されたかに関わらず、 remote_sys_id は常にその元を指し示します。

これは、同じXMLを2回目にアップロードしたときに何が起こるかについても説明しています。ServiceNowは重複を作成するのではなく、 remote_sys_id をキーとして照合し、既存の取得済み更新セットレコードを上書きします。ローカルのsys_idではなく、作成元のsys_idがキーとなります。

コミットすると、さらに別のsys_idが作成されます

取得した更新セットをコミットすると、ServiceNowは sys_update_set （ローカル更新セットテーブル）に新しいレコードを作成します。このコミットされたレコードは、ソースsys_idとターゲットの取得済み更新セットのsys_idの両方とは異なる独自のsys_idを取得します。

これは、概念的に同じ更新セットに対する3つの異なるsys_idsです。

1. ソースインスタンス上の元のsys_id（DEVインスタンスの sys_update_set ）
2. ターゲット上の取得済み更新セットのsys_id（TESTインスタンスの sys_remote_update_set ）
3. ターゲット上のコミット済みローカル更新セットのsys_id（TESTインスタンスの sys_update_set ）

#3と#2の間のリンクは、 sys_update_set テーブルの remote_sys_id 列です。これは、 sys_remote_update_set レコードを指し示す参照フィールドです。この参照を辿れば、コミットされた更新セットがどこから来たのかをいつでも追跡することができます。

2 ステップルックアップ

ターゲットインスタンスでローカルにコミットされたsys_idが必要な場合（たとえば、ReleaseOpsパイプラインの[インスタンススキャンを実行]アクティビティに渡す場合）、ソースsys_idを直接使用することはできません。解決が必要です：

ステップ1 — ターゲットで取得済み更新セットレコードを見つけます：

Table: sys_remote_update_set
Query: remote_sys_idSTARTSWITH662e2bb487cc8fd07c54db183cbb3568

ステップ2 — コミットされたローカル更新セットを見つけます：

Table: sys_update_set
Query: remote_sys_id=<sys_id from step 1>

ステップ2で取得するsys_idは、ターゲットインスタンスが認識しているものであり、ターゲットインスタンスに対してローカルで実行されるあらゆる処理に必要なものです。

ReleaseOps の実践的なポイント

DEVのsys_idを指定し、TESTを対象とした場合、OOTBの[インスタンススキャンを実行]アクティビティは失敗します。そのレコードは単にそこには存在しないためです。代わりに、コミットアクティビティの後に上記の2ステップルックアップを組み込み、解決されたTESTのsys_idをスキャンに渡してください。

覚えておくべき1つの注意点として、コミット時にTESTのsys_idをキャプチャして、後で使用するために保存してはいけません。フローが失敗し、コミットが既に完了した後に再開された場合、最初のコミット処理は再度実行されません。常にルックアップを通じてsys_idを新たに解決してください。更新セットがコミットされた後はいつでも信頼性があります。

メンタルモデル

ステージ	テーブル	sys_id	追跡方法
ソースインスタンス	sys_update_set	元のsys_id	—
ターゲットで取得済み	sys_remote_update_set	新しいsys_id	remote_sys_id →ソース
ターゲットにコミット済み	sys_update_set	新しいsys_id	remote_sys_id → 取得済みレコード

この remote_sys_id フィールドは、すべての段階における一貫した連携の鍵となります。更新セットがどこに移動しても、このフィールドによってServiceNowと自動化は常にそれを特定できるようになります。