スキップされた更新レコードの解決トラッキング<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } はじめに インスタンスのアップグレード後にスキップされた変更を確認することは、アップグレードプロジェクトの重要な部分です。「スキップされた変更のレビュープロセス」で、システムアドミニストレーターはレコードのアップグレードされたバージョンとカスタマイズされたバージョンの相違を解決します。多くの場合、これは大量のスキップされたレコードが原因で、面倒でエラーが発生しやすい手動プロセスです。アップグレードは準本番インスタンス (理想的には本番インスタンスの完全クローン) でテストする必要があるため、システム管理者はスキップされたレコードを異なるインスタンスで複数回処理する必要があります。 必要な手作業を減らすために、システム管理者は更新セットを使用して、インスタンスに加えられた顧客の更新をキャプチャし、同じアップグレードが行われる別のインスタンスに転送できます。この方法では、ターゲットインスタンスに更新セットを適用して、ソースインスタンスで認識されたスキップされた変更に対処するだけで十分です。このアプローチにより、アップグレード後に必要な手作業を減らすことができます。 スキップされた変更 スキップされた変更は、インスタンスに変更 (構成またはカスタマイズ) を加えたときに作成され、新しいリリースの一部として同じレコードを更新するレコードです。アップグレードによって行った変更が上書きされることはないため、スキップした変更を確認し、基本に戻すか、結合するか、変更を保持するかを決定する必要があります。スキップされる変更には、ハードコードされたレコードのsys_ui_form_section、sys_ui_related_list、sys_choice_setなどの変更や、HTML、XML、スクリプト、またはscript_plainタイプのフィールドが少なくとも 1 つあるテーブルへの変更が含まれます。ユーザーデータレコード (つまり、sys_user) はスキップされた変更をトリガーしません。 スキップされたレコードリストを処理する ビジネスルールやスクリプトなど、このアップグレードの影響を受けるレコードをカスタマイズまたは変更した場合、アップグレードによってスキップされたログレコードが生成されます。スキップされたレコードリストを処理、つまりスキップされたリストを処理して、アップグレードされたバージョンとカスタマイズされたバージョンのレコードの相違を解決する必要があります。 更新セット内のスキップされたレコードのキャプチャ:Paris 以前 更新セット内のレコードの変更が追跡されるため、これらの変更を後で別のインスタンスに適用できます。ただし、1 つのインスタンスから次のインスタンスにアップグレードの詳細レコードは移行されません。これらのレコードは、特定のインスタンスの特定のアップグレードに適用されます。スキップされたリストのコメント、解決策、またはその他の情報を保持する場合は、XML のエクスポート機能を使用してこのインスタンスからエクスポートします。 アップグレードの例 - Paris 前開発インスタンスの手順。 ニューヨークからオーランドにアップグレードします。ローカル更新セット NY to O スキップされたレコード を作成し、現在のものにします。スキップされたレコードリストを処理します。更新セットを NY から O スキップされたレコードに 完了させます。オプションで、スキップされたレコード、処理、コメント (ドキュメント用) を保存するには、 sys_upgrade_history_log テーブルから XML レコードをエクスポートします。 テストインスタンスのステップ。 New York から Orlando にアップグレードします (Dev インスタンスでの前回のアップグレードと同じアップグレードソースおよびターゲットバージョン)。開発インスタンスから NY から O スキップされたレコード 更新セットを取得します。DEV インスタンスでキャプチャされたテストインスタンスに変更を適用するために、 NY から O スキップされたレコード の更新セットをプレビューしてコミットします。スキップされたレコードリストを処理します。ステップ 3 で更新セットを適用してカスタマイズされたレコードに変更を加えても、スキップされたレコードリストはそのまま残ります。この時点では、インスタンスのカスタマイズはスキップされたレコードリストのコンテンツと同期していません。オプションで、スキップされたレコード、処理、コメント (ドキュメント用) を保存するには、 sys_upgrade_history_log テーブルから XML レコードをエクスポートします。 手順 4 のメモ。2 つのインスタンスのアップグレードで、スキップされたレコードリストに関してまったく同じ結果が生成されることは非常にまれです。その理由は、同じ本番インスタンスの完全なクローンであっても、インスタンス間には常に微妙な違いがあるためです。説明は KB0726987 KB記事にあります。 Paris 以降では、 スキップされた更新レコードの解決のトラッキング と呼ばれる新機能を利用できます。 スキップされた更新レコードの解決トラッキング アップグレードの例:Paris (以降) から開発インスタンスの手順。 Paris から Quebec にアップグレードします。ローカル更新セット P から Q スキップされたレコード を作成し、現在のものにします。Paris 以降、 glide.save.skiplist.decision システムプロパティはデフォルトで true になっていることに注意してくださいスキップされたレコードリストを処理します。更新セットを P から Q に スキップされたレコード 完了させます。 テストインスタンスのステップ。 Paris から Quebec にアップグレードします (開発インスタンスでの前回のアップグレードと同じアップグレードソースおよびターゲットバージョン)。開発インスタンスから P から Q スキップされたレコード 更新セットを取得します。DEV インスタンスでキャプチャされたテストインスタンスに変更を適用するために、[ P to Q Skipped 更新セットをプレビューしてコミットします。スキップされたエラーリストも更新セットによって更新されますが、スキップされたレコードリストを処理するためにも必要です。 スキップされた更新レコードの解決トラッキングの詳細。 スキップされた更新レコード解決トラッキングは、Paris バージョンで導入された新機能です。これにより、カスタマイズだけでなく、スキップされたレコードの処分コメントを更新セットにキャプチャできます。この機能は、Paris バージョンからデフォルトで有効になっています。glide.save.skiplist.decision システムプロパティは、この機能を制御します (デフォルトでは true に設定されています)。ソースインスタンスのアップグレード後にスキップされたレコードリストが処理され、更新セットに変更がキャプチャされると、更新セットをターゲットインスタンスに転送できます。 ターゲットインスタンスで同じアップグレードを実行した後 (同じアップグレードバージョンを使用して)、ソースインスタンスからの更新セットをインポートしてコミットできます。スキップされたレコード解決コード、コメント、およびカスタマイズを正常に取り込むために、プラットフォームは次のチェックアクションを実行します。 システムプロパティ glide.save.skiplist.decision の値を確認します。プロパティの値が true の場合、機能が有効になりますターゲットインスタンスで対応するログレコードが見つかりましたターゲットインスタンスで同じファイル名が見つかりましたsys_upgrade_stateキー値が XML ペイロードの受信バージョンペイロードハッシュと同じかどうかを確認しますレコードの変更されたフィールドを確認します。変更された = true の場合にのみ更新が適用されます更新セットにキャプチャされた「not_reviewed」以外のレコード解決ステータスを確認します処分を確認してください。スキップ済み、スキップ済みエラー、スキップ済み手動結合、取得済みである必要がありますスキップされたレコードは、最新のアップグレードの一部である必要があります。glide.war システムプロパティを確認します。glide.war バージョンは、更新が予想されるアップグレードの詳細 [sys_upgrade_history_log] レコードの [アップグレード履歴] 列と一致する必要があります (これは基本的に、レコードが最新のアップグレードに属していることを確認する方法です)。 上記のすべての条件が満たされ、すべてのチェックに合格した場合、スキップされたソースインスタンスからのレコード解決コード、コメント、およびカスタマイズがターゲットインスタンスに転送されます。これにより、アドミニストレーターはアップグレード後のプロセスで多くの作業と時間を節約できます。 上記の条件のいずれかが当てはまらない場合、またはいずれかのチェックに合格しなかった場合、更新セットエラーが報告されます。 更新セットの警告 ターゲットインスタンスで glide.save.skiplist.decision システムプロパティが false の場合: 「スキップされたアップグレードレコードの解決追跡が無効になっているため、この更新ではアクションは発生しません」 使用可能な唯一のアクションは、「リモート更新をスキップ」です その他の状況の場合: 「この更新は無効であるため、アクションは実行されません。その後、リモート更新をスキップします」 使用可能な唯一のアクションは、「リモート更新をスキップ」です メッセージの理由を理解し、上記のいずれかの条件が失敗した場合に上記の条件を確認するための推奨アクション (2 〜 8)。 更新セットに特定の顧客更新プログラムに適用されない処理が含まれている場合の別の一般的なシナリオ。 たとえば、特定のアップグレード履歴レコードのターゲットインスタンスでは、使用可能なオプションは 更新と削除のみです。ソースインスタンスからの更新セットに、性質が異なる同じアップグレード履歴 (競合の解決 など) の顧客更新が含まれている場合、アップグレードセットエンジンは「この更新は無効であるためアクションは実行されません。リモート更新をスキップします」という警告メッセージを表示します。これは、アップグレードの違いを示すものです。ソースインスタンスのアップグレードは、スキップされたエラーやカスタマイズの点でターゲットインスタンスのアップグレードと異なっていました。(ソースインスタンスと比較して) 相違点に対処して理解するために、ターゲットインスタンスで参照されているアップグレード履歴レコードをさらにレビューすることをお勧めします。 注意:プラグインの履歴ログからスキップされたレコードを移動または処理することは、更新セットでは適用できません。更新セットは、プラグインのアップグレードではなく、インスタンスのアップグレードでのみ機能します。 関連リンク KB0726987:アップグレード後のインスタンス間でスキップされたアイテムレコードの数が異なる KB0678054 - アップグレードに関する FAQ - よく寄せられる質問