ServiceNow での選択肢の使用 - Support and Troubleshooting

ServiceNow での選択肢の使用 Issue border-color:#E0E0E0; background-color: rgb(245, 245, 245); padding-top: .6em; padding-bottom: .6em; padding-left: .9em; padding-right: .6em; } table.noteTable{ border:1px solid; border-color:#E0E0E0; background-color: rgb(245, 245, 245); width: 100%; border-spacing:2; } table.internaltable { white-space:nowrap; text-align:left; border-width: 1px; border-collapse: collapse; font-size:14px; width: 85%; } table.internaltable th { border-width: 1px; padding: 5px; border-style: solid; border-color: rgb(245, 245, 245); background-color: rgb(245, 245, 245); } table.internaltable td { border-width: 1px; padding: 5px; border-style: solid; border-color: #E0E0E0; color: #000000; } .title { color: #D1232B; font-weight:normal; font-size:28px; } h1{ color: #D1232B; font-weight:normal; font-size:21px; margin-bottom:-5px } h2{ color: #646464; font-weight:bold; font-size:18px; } h3{ color: #000000; font-weight:BOLD; font-size:16px; text-decoration:underline; } h4{ color: #646464; font-weight:BOLD; font-size:15px; text-decoration:; } h5{ color: #000000; font-weight:BOLD; font-size:13px; text-decoration:; } h6{ color: #000000; font-weight:BOLD; font-size:14px; text-decoration:; } --> 概要 この記事では、ServiceNowでの選択肢の使用について説明します。選択肢は特別な方法で処理され、特別なハンドラーとして扱われます。これは、インスタンスで選択肢がどのように機能するかを理解する上で極めて重要であるため、大切な知識です。選択肢は、sys_choice_set と呼ばれる特別なハンドラーで囲みます。新しい選択肢を既存の要素に追加すると、その選択肢は該当する要素の sys_choice_set にキャプチャされます。

顧客アップデートの観点から見ると、選択肢を追加または更新すると、sys_update_xml の名前または更新名に [sys_choice] テーブルの変更が表示されます。次に例を示します。

sys_update_xml レコードのペイロードを表示すると、加えられた変更だけでなく、特定のテーブルの特定の要素のすべての選択肢がコンテンツに含まれていることが分かります。 これは、加えられた変更が sys_choice_set としてキャプチャされるためです。つまり、既存の sys_choice_set 内のすべての選択肢をキャプチャします。

これが重要な理由 選択肢がどのようにキャプチャされるかを把握することが重要です。その理由は、主に更新セットまたはスコープ対象のアプリケーションを介して選択肢を移動すると、変更がどのように適用されるかをより良く理解できるからです。選択肢は sys_choice_set 単位でキャプチャされるため、選択肢を含むインスタンスに適用される変更はすべて、変更が適用されるインスタンス上の既存の選択肢セットを常に上書きします。あるインスタンスの選択肢を別のインスタンスに適用すると、変更は追加または連結されません。これは、インスタンス間で選択肢の変更を移動させるときによく発生する現象です。次に例を示します。

インスタンス 1： インスタンス 1 では、要素がステータスのインシデントテーブルに、値が 9 と 10 の新しい選択肢が 2 つ作成されています。選択肢は Happy(9) と Sad(10) です。sys_choice_set 内には、要素がステータスであるテーブルインシデントに選択肢が合計で 8 つあります。これらの変更は、 選択肢 と呼ばれるローカル更新セットにキャプチャされています。

インスタンス 2： インスタンス 2 では、要素がステータスのインシデントテーブルに、値が 14 と 12 の新しい選択肢が 2 つ作成されています。選択肢は Bashful(14) と Grumpy(12) です。ここでも、sys_choice_set 内には、要素がステータスであるテーブルインシデントに選択肢が合計で 8 つあります。これらの変更は、デフォルトの更新セットにのみキャプチャされています。

変更がインスタンス 1 からインスタンス 2 に適用されると、現在の選択セットにはインスタンス 1 にある選択セットの選択肢が表示されるため、インスタンス 2 に追加された選択肢 (Bashful と Grumpy) は存在しなくなります。このシナリオでは、更新セットの 選択肢 から適用される変更がターゲットに存在する変更よりも古いため、エラー/警告が生成されます。 サポートで目にするケースのほとんどは、お客様がインスタンスに直接選択肢を追加します。この場合は、最終更新日が常に、ターゲットに適用されていた更新セットの変更よりも新しくなるため、プレビューエラーは生成されません。この例では、更新セットの変更が適用されるターゲットで行われた最初の変更が、更新セットから適用される変更よりも新しいと仮定しています。

意図しない選択肢の更新/修復方法 変更を適用したターゲットインスタンスの既存の選択肢を上書きしてしまう sys_choice 変更の問題を修正するには、簡単な方法があります。sys_update_version レコードは選択肢が変更されるたびに作成されます。問題を解決する最も簡単な方法は、更新バージョンテーブルから旧バージョンの sys_choice レコードを見つけ、必要な該当するバージョンに戻すことです。この修正ステップは他の ServiceNow アーティファクトにも適用できますが、お客様は本番環境でバージョンを戻す前にテストする必要があります。

上記の例の続きで、選択肢が上書きされたことにアドミンが気付き、Bashful と Grumpy の選択肢を復元する必要があるという例を説明します。これに対する修正手順：

顧客アップデートテーブル [sys_choice_incident_state] の名前フィールドから値を取得します [sys_update_version] テーブル > sys_update_version.list に移動します。 sys_choice 変更に関する顧客アップデートの名前フィールドの値を含む名前のクエリを作成します。 ステータスが [現在] のレコードを見つけます。これは、この特定のアーティファクトに使用している現行バージョンを識別するためです。変更は choices と呼ばれる更新セットから適用されたため、[ ソース ] フィールドにこれが反映されているはずです。 [ 作成済み ] でリストをソートし、更新セットが適用される前に現行バージョンだった旧バージョンを見つけます。 このレコードを開き、関連リンクで [ 現在と比較 ] をクリックします。 これにより、現行バージョンと更新が適用される前の最後の既知のバージョンを比較する差分チェッカーが表示されます。 差分チェッカーから、適用される以前の更新セットに存在していた変更を確認します。 差分チェッカーで、[ このバージョンに戻す ] をクリックします。 要素がステータスであるインシデントの現在の sys_choice セットが、更新セットが適用される前の状態に戻るはずです。

お客様は、必要に応じて更新バージョンテーブルの任意のバージョンに戻すことができます。何らかの理由で更新セットバージョンを元に戻す必要がある場合は、sys_choice レコードの更新セットバージョンに対して実行したのと同じ手順を実行することで簡単に実行できます。

推奨事項 お客様にお勧めする最善の方法は、1 つのインスタンスでのみ選択肢を変更し、必要に応じてこれらの変更を環境全体に移動することです。お客様は、複数のインスタンスに手動で選択肢を作成しないことをお勧めします。本番環境からすべての環境にクローンを作成するプラクティスに従って、選択肢が例外なくすべて同期、または同じになるようにする必要があります。選択肢に対する追加または変更は、通常の開発サイクル (開発>テスト>本番) に従う必要があります。これにより、更新セットまたはスコープ対象のアプリケーションを適用するときに、インスタンス内で選択肢が意図せず上書きされる可能性が軽減されます。