アップグレード後にスキップされた更新レコードを解決する方法<!-- /*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タイプのフィールドを持つテーブルなどのレコードが含まれます。sys_userなどのユーザーデータレコードは、スキップされた変更をトリガーしません。 スキップされたレコードリストを処理する ビジネスルールやスクリプトなど、アップグレードの影響を受けるレコードをカスタマイズすると、スキップされたログレコードが生成されます。スキップされたレコードリストを処理して、アップグレードされたバージョンとカスタマイズされたバージョンの相違を解決する必要があります。 スキップされたレコードの更新解決トラッキング Paris リリース以降、「スキップされた更新レコード解決の追跡」機能を使用すると、更新セット内のカスタマイズとスキップされたレコードの状態とコメントをキャプチャできます。この機能はデフォルトで有効になっています。glide.save.skiplist.decision システムプロパティはこの機能を制御し、デフォルトでは true に設定されています。 例 ソースインスタンスをターゲットのリリースバージョンにアップグレードします。スキップされたレコードをキャプチャして現在のものにするローカル更新セットを作成します。ソースインスタンスでスキップされたレコードリストを処理します。更新セットを完了としてマークします。ターゲットインスタンスをソースインスタンスと同じリリースバージョンにアップグレードします。ソースインスタンスからスキップされたレコードの更新セットを取得します。ターゲットインスタンスの更新セットをプレビューしてコミットし、キャプチャされた変更を適用します。スキップされたエラーリストは更新セットによって更新されますが、それでもターゲットインスタンスでスキップされたレコードリストを処理する必要があります。 詳細 スキップされたレコードリストを処理し、ソースインスタンスの更新セットの変更をキャプチャした後、同じアップグレードを実行した後にその更新セットをターゲットインスタンスに転送できます。 プラットフォームは、スキップされたレコード解決を適用する前に、以下をチェックします。 glide.save.skiplist.decision プロパティが true である。対応するログレコードがターゲットインスタンスに存在します。同じファイル名がターゲットインスタンスに存在します。sys_upgrade_stateキーは受信バージョンのペイロードハッシュと一致します。[ レコード変更済み フィールドが true である。レコード解決ステータスが「not_reviewed」ではありません。処理は、スキップ済み、スキップ済みエラー、スキップ済み手動結合、取得済みのいずれかです。スキップされたレコードは、最新のアップグレードの一部です (glide.war バージョンは sys_upgrade_history_log の [アップグレード履歴] 列と一致します)。 すべてのチェックに合格すると、スキップされたレコード解決コード、コメント、およびカスタマイズがターゲットインスタンスに転送されるため、アップグレード後の時間を節約できます。 いずれかのチェックに失敗すると、更新セットエラーが報告されます。 更新セットの警告メッセージ ターゲットインスタンスで glide.save.skiplist.decision プロパティが false の場合: 「スキップされたアップグレードレコードの解決トラッキングが無効になっているため、この更新ではアクションは発生しません。」 使用可能な唯一のアクションは、リモート更新をスキップすることです。 その他の問題の場合: 「この更新は無効であるためアクションは発生しません。その後、リモート更新をスキップします。」使用可能な唯一のアクションは、リモート更新をスキップすることです。これらのメッセージを理解するには、上記のセクションの条件を確認してください。 その他の注意事項 更新セットに顧客の更新に適用されない状態が含まれている場合、たとえば、ターゲットインスタンスでは更新と削除のみが許可されているが、更新セットには競合の解決が含まれている場合、エンジンは警告を報告します。これは、ソースインスタンスとターゲットインスタンスのアップグレードの違いを示します。ターゲットインスタンスで参照されているアップグレード履歴レコードを確認して、違いを理解します。更新セットを使用しているプラグインの履歴ログからスキップされたレコードを移動または処理することはできません。更新セットはインスタンスのアップグレードに対してのみ機能し、プラグインのアップグレードでは機能しません。手作業を減らすために、システムアドミニストレーターは更新セットを使用してソースインスタンスから顧客アップデートをキャプチャし、同じアップグレード中のターゲットインスタンスに転送することができます。ターゲットインスタンスで更新セットを適用すると、ソースからスキップされた変更に対処し、アップグレード後の手動作業を最小限に抑えることができます。 関連リンク KB0726987:アップグレード後のインスタンス間でスキップされたアイテムレコードの数が異なる KB0678054 - アップグレードに関する FAQ - よく寄せられる質問