アクティビティストリーム (UI 16) のコメントが重複/欠落しています - Support and Troubleshooting

アクティビティストリーム (UI 16) のコメントが重複/欠落しています Issue .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } このナレッジ記事では、UI 16 のアクティビティストリーム上のコメントに関するさまざまな種類の問題によって、お客様がどのような影響を受ける可能性があるかを説明します。

コメントはアクティビティストリームにどのように表示されますか？

レコード（たとえばインシデント）にコメントまたはワークノートが追加され、対応するテーブルが監査用に構成されている場合（Incident テーブルなど）、その更新は sys_audit テーブルに記録されます。その結果、関連するフィールド（たとえば comments ）のレコードが作成されます。同様に、 sys_journal_field テーブルにもレコードが作成されます。

ただし、アクティビティストリームは sys_audit テーブルまたは sys_journal_field テーブルと直接やり取りするわけではありません。代わりに、関連付けられた sys_history_set レコードからデータをレンダリングします。

sys_history_set は、親レコード（インシデントなど）に変更が加えられた際に、オンデマンドで生成または更新されます。これは親レコードを参照し、履歴変更のコンテナーとして機能します。関連するすべての履歴エントリーは sys_history_line テーブルに作成され、このテーブルは対応する sys_history_set への参照を保持します。

sys_history_line レコードは、アクティビティストリームによって sys_history_set がトリガーされるたびに作成されます。これらは以下からデータを取得することでリアルタイムに生成されます。

sys_audit sys_journal_field sys_email お客様が重複コメント問題の影響を受けていないのはどのような場合ですか？ アクティビティストリーム内で同じコメントが 2 回表示されるが、更新時刻が異なる状況があります。そのような場合、重複は意図されたもの、または想定されたものであり、 sys_audit テーブルと sys_journal_field テーブルの両方に同じコメントの複数のレコードが存在しています。

これは次の理由で発生する可能性があります。

ユーザーが誤って同じコメントを 2 回投稿した。 スクリプト、ビジネスルール、またはバックグラウンドプロセスが意図せずコメントを重複させた。 一般的な原因: ビジネスルールによって発生する重複

このような意図しない重複の一般的な根本原因はビジネスルール（BR）であり、特に GlideRecord の update 呼び出しが使用される場合です。これによりループまたは再帰的な動作が作成され、同じコメントが複数回投稿される可能性があります。

例: sc_task と sc_req_item 間の再帰的 BR ループ

sc_task レコードにコメントが追加される。 sc_task テーブル上の "After" Business Rule（ sc_task_br1 ）が最新のコメントを関連する sc_req_item にコピーする。 sc_req_item テーブル上の別の Business Rule が関連する sc_task に対して GlideRecord update を実行する。 この更新によって sc_task_br1 が再度トリガーされ、その結果、同じコメントが sc_req_item に 2 回コピーされる。 これは、Business Rule 内に update 呼び出しを含めるべきではない理由の 1 つです。Business Rule のベストプラクティスについては次を参照してください。

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0715782

重複コメントの問題はいつ発生しますか? 重複コメント問題は、 sys_audit テーブルと sys_journal_field テーブルの両方に単一のジャーナルエントリー（コメントまたはワークノートなど）しか存在しないにもかかわらず、同じコメントがアクティビティストリーム内に 2 回表示される場合に発生します。これは通常、同じコメントが対応する sys_history_set レコードに 2 回ロードされた場合に発生します。

この問題の重要な指標の 1 つは、重複したコメントのタイムスタンプです。アクティビティストリーム内の両方のエントリーが同一の更新時刻を持つ場合、システムがこの重複問題の影響を受けている可能性があります。

追加のユースケースおよびトラブルシューティング手順は、この KB 記事の後半で説明されており、これらのシナリオを識別して対処する方法を案内しています。

お客様がコメント欠落問題の影響を受けるのはどのような場合ですか？

一部のコメントが sys_audit テーブルおよび sys_journal_field テーブルには存在するにもかかわらず、アクティビティストリームに表示されません。 Facts .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Washington Patch 6 より前は、ほとんどの更新は sys_audit テーブル自体からロードされており、 sys_journal_field テーブルは親レコード作成時に作成されたコメントをロードするためだけに使用されていました。しかし、workflow を false に設定することでレコードの監査を制限するスクリプトが存在する可能性があり、そのような場合に追加された対応するワークノートは sys_audit テーブルに記録されず、 sys_journal_field テーブルのみに存在することになります。そのため、いずれの更新も見逃さないために、 sys_journal_field を参照することも不可欠になりました。

この変更に伴い、HistorySetLoader フローが変更され、ジャーナルフィールドについては、システムは sys_audit と sys_journal_field の両方のテーブルからデータを取得して比較するようになりました。エントリーが異なる場合は、その両方が sys_history_line テーブルに追加されました。しかし、 sys_audit と sys_journal_field のジャーナルフィールドレコード間の不一致によってコメントの重複が発生しました。これが、WP6 以降に重複コメントが表示されるようになった理由です。

Release .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } PRB1767585 (Washington パッチ 6、Xanadu)

PRB1767585 のリリースにより、"HistorySetLoader" フローが更新され、ワークノートの重複に関する懸念へ対応しました。この変更の一環として、プロパティ glide.history_set.pull_journal_entries_from_journal_table が導入されました。

1. History Set の形成 History Set は以下のテーブルからデータを取得して構築されます。

sys_audit : すべてのレコードフィールドの履歴データを保存します。 sys_journal_field : ユーザーが追加したコメントおよびワークノートを含みます。 sys_email : レコードによってトリガーされたメールを含みます。 2. PRB1767585 より前の動作 PRB1767585 より前は、システムは sys_audit と sys_journal_field の両方からデータを取得し、 sys_history_set および sys_history_line テーブルを作成していました。ジャーナルフィールドについては両方のソースからデータを取得して比較し、エントリーが異なる場合は両方が sys_history_line に追加されていました。しかし、 sys_audit と sys_journal_field 間の不一致によって重複が発生していました。

3. プロパティの導入 重複を軽減するため、 glide.history_set.pull_journal_entries_from_journal_table プロパティが導入されました。有効化すると、ジャーナルフィールドデータは sys_journal_field テーブルのみから取得され、 sys_audit との比較が行われなくなります。

4. PRB1767585 後の観察結果 このプロパティによって多くの重複問題は解消されましたが、依然として重複コメントにつながる一部のエッジケースが発見されました。

PRB1806563 (Washington パッチ 9、Xanadu パッチ 4、Yokohama)

この PRB では、プロパティ glide.history_set.pull_journal_entries_from_journal_table が有効な場合に、特定の条件下でアクティビティストリームに重複コメントが表示される可能性があることが確認されました。

以下、そのようなシナリオの 1 つです。

ユーザーがインシデントにコメントを追加する。その結果、次の関連レコードが作成される。 sys_updated_on of the incident: 2025-01-01 00:00:00

sys_created_on of the sys_audit record: 2025-01-01 00:00:00

sys_created_on of the sys_journal_field record: 2025-01-01 00:00:01

PRB1806563 より前 システムは sys_audit テーブルを使用して最後に記録されたタイムスタンプを判定していました。 sys_audit 内に適切なエントリーが見つからない場合、インシデントの sys_updated_on （ 2025-01-01 00:00:00 ）を使用していました。 最初のコメント後に sys_history_set が更新されると、 sys_journal_field テーブルからジャーナルエントリーを取得します。しかし、システムは最後に記録されたタイムスタンプを 2025-01-01 00:00:00 （ sys_audit または sys_updated_on ベース）に設定します。 ユーザーが別のコメントを投稿したとき:最後に記録された時刻が依然として 2025-01-01 00:00:00 であるため、システムは誤って前回のコメントを再度含めます。その結果、 sys_history_set （ sys_history_line 経由）に重複エントリーが作成され、同じコメントがアクティビティストリームに 2 回表示されます。 PRB1806563 後 システムは sys_journal_field レコードの sys_created_on を最後に記録された時刻として使用するようになりました。 この場合、最後に記録された時刻は正しく 2025-01-01 00:00:01 に設定され、以前のコメントの再ロードを防止します。 これにより、アクティビティストリームでの重複を効果的に回避します。

PRB1826101 (Washington パッチ 10、Xanadu パッチ 5、Yokohama) ジャーナルフィールドのデータは sys_audit テーブルと sys_journal_field テーブルの両方に格納されていますが、特定のメタデータ、具体的にはコメントが追加された時点の更新回数（update count）および内部チェックポイント（internal checkpoint）は、 sys_audit テーブルにのみ存在します。

プロパティ glide.history_set.pull_journal_entries_from_journal_table が有効な場合、システムはジャーナルフィールドの sys_history_line レコードを sys_journal_field テーブルのみから生成します。その結果、このデータは sys_audit から取得されないため、すべてのレコードの更新回数はデフォルトで 0 になります。

この動作は、いくつかの下流の問題を引き起こします。

1. カレンダーの動作 カレンダー機能は、履歴エントリーを更新回数に基づいてグループ化します。すべてのジャーナルエントリーの更新回数が 0 になるため、それらは親レコードの sys_created_on タイムスタンプを基準とする単一のグループにまとめられます。

2. HistoryWalker.java の API HistoryWalker コンポーネントは、 sys_history_line テーブルのデータを使用してレコードの履歴を再生します。

これらの API は変更を正確に再構築するために更新回数へ依存しています。すべてのジャーナルフィールドが 0 になると、履歴再生ロジックが損なわれます。

3. アクティビティストリームでのエントリー欠落 glide.history.max_entries プロパティが次の場合:

sys_history_line レコード総数以上である場合、すべてのエントリーが返され、更新時刻順に並べられるため、問題は発生しません。 総数未満である場合、すべてのジャーナルエントリーが internal_checkpoint = 0 を共有しているため、システムは最新レコードを特定することが困難になり、アクティビティストリーム内のジャーナルエントリーが欠落します。

PRB1826101 で導入された新しいメカニズム

sys_audit テーブルの update count と internal checkpoint を保存するために HashMap が使用されます。

キーは JournalFieldKey オブジェクトによって定義され、次を組み合わせています。

fieldName newValue createdOn （±2 秒の許容範囲付き） このマッチングロジックを使用することで、システムは各 sys_journal_field エントリーを対応する sys_audit レコードへ関連付け、update count と internal checkpoint の値を sys_history_line に正しく設定します。

WP10、XP5、および Y バージョン以降では、 glide.history_set.pull_journal_entries_from_journal_table が有効であっても、update count は常に追跡されます。 上記変更の制限事項 このマッチングロジックは、ジャーナルと監査の内容の差異が大きくなり過ぎた場合、または sys_audit テーブルと sys_journal_field テーブルで異なる動作が示される場合に機能しなくなります。たとえば、以下のようなスクリプトベースの更新です。

var gr = new GlideRecord('incident'); if (gr.get('57af7aec73d423002728660c4cf6a71c')) { gs.info("found incident"); gr.setDisplayValue('work_notes', 'Comment 1'); gr.setDisplayValue('work_notes', 'Comment 2'); gr.update(); } このシナリオでは:

「Comment 1」と「Comment 2」の値を持つ 2 つのジャーナルレコードが作成されます。 「Comment 2 Comment 1」という連結された値を持つ 1 つの監査レコードが作成されます。 この不一致により、JournalFieldKey を使用した update count の正しい追跡ができなくなります。

sys_audit と sys_journal_field の整合性を確保するため、新しいプロパティ glide.split_journal_audit_records が導入されました。

glide.split_journal_audit_records を有効にすると、このようなケースにおいて sys_audit と sys_journal_field が同じ数のレコードを維持することが保証され、状況に関係なく update count を追跡できるようになります。

「Comment 1」と「Comment 2」を持つ 2 つの sys_journal_field レコードが作成される。 「Comment 1」と「Comment 2」を持つ 2 つの sys_audit レコードが作成される。 しかし、このような変更を行った後でも、History Set が原因となって重複コメント問題またはコメント欠落問題を引き起こす新しいユースケースが発見されており、以下の PRB がそれらのユースケースを記録するために定義されています。

History Sets に関連する新たな問題 - 重複コメント問題またはコメント欠落問題を引き起こすケース（WP10、XP5、および Y バージョンでも確認される可能性があります）

PRB1869081 (XP9、YP5、Zurich)

snc_read_only ユーザーロールが、アクティビティストリームにおいてコメント／ワークノートの重複を引き起こします。

問題の再現手順 1) 以下のスクリプトを実行し、レコードを開かないでください。

var myGr = new GlideRecord('incident'); myGr.get('57af7aec73d423002728660c4cf6a71c'); myGr.comments="TEST COMMENT"; myGr.update();

2'David.Miller' を Impersonate する（ snc_read_only ロールのみを保有）

3) David Miller としてレコードへ移動します。

4) リフレッシュし、エントリーが重複することを確認する。この現象はリフレッシュするたびに発生します。

5) Impersonate を解除し、 [sys_audit] へ移動します。追加エントリーは作成されていません。同様に [sys_journal_field] にも追加エントリーはありません。重複は [sys_history_line] にのみ存在します。

根本原因: David.Miller ユーザーには sys_history_set テーブルへの書き込み権限がありません。その結果、システムは更新が対応する sys_history_set レコードへロード済みであることを記録できません。

このようなケースでは、以下のログが確認されます。

2025-03-17 05:02:58 (953) Default-thread-5 0CDC381E2B50EA50EE42FDA6CE91BF1A txid=0f2709522bd0 ReadOnlyRoleAccessHandler DEBUG: Security restricted: access for table: sys_history_set, user: David.Miller, operation: write -- from class: ReadOnlyRoleAccessHandler

PRB1837173 (XP9、YP5、Zurich)

複数のユーザーが同じ Incident フォームで同時に作業し、ほぼ同じタイミングで更新を行うと、Activity Stream、特に History Set が、あるユーザーの更新がロードされた後に早過ぎるタイミングで進行する可能性があります。

その結果、他のユーザーの後続更新が意図せずスキップされる場合があります。これは、システムが最新の記録済みタイムスタンプまでの更新がすべて取得済みであると判断するためであり、アクティビティストリームで一部コメントが欠落しているように見える原因となります。

ユースケース 2 人のユーザーが異なるセッションで同じ Incident レコードを開く。 両ユーザーがほぼ同時に異なるコメントを追加する。たとえば 2025-01-01 00:00:00 。実際のタイムスタンプはミリ秒レベルでわずかに異なる可能性があります。 最初のコメントがロードされると、システムは最後に記録したタイムスタンプを 2025-01-01 00:00:00 に設定する。 2 番目のコメントが追加され History Set Loader が再実行されると、システムは先ほどのタイムスタンプをカットオフとして使用し、それより新しいレコードのみ取得する。 2 番目のコメントは秒単位では同じタイムスタンプを共有しているため（ミリ秒単位では異なる可能性がある）、スキップされ、アクティビティストリームに表示されない。 PRB1860893 (XP9、YP5、Zurich)

監査レコードとジャーナルレコード間の時間差によって、コメントが Activity Stream に表示されない問題。

特定のシナリオでは、 sys_audit テーブルと sys_journal_field テーブルのレコード間でタイムスタンプが一致しないため、コメントが Activity Stream に表示されない場合があります。

背景 HistorySetLoader クラスでは、システムはまず sys_audit テーブルを照会し、その結果を反復処理して sys_history_line にエントリーを生成します。

プロパティ glide.history_set.pull_journal_entries_from_journal_table が有効な場合:

システムはジャーナルフィールドに関連する監査レコードをスキップします。 代わりに、対象フィールドのデータを sys_journal_field テーブルから直接取得します。 重要なメタデータを維持するため、HashMap が利用されます。

Key: JournalFieldKey object ( fieldName 、 newValue 、 createdOn の組み合わせ） Value: 対応する sys_audit レコードから取得した update count と internal checkpoint 2 つの JournalFieldKey が等しいと見なされる条件: fieldName が一致する newValue が一致する createdOn の差が 2 秒以内である 根本原因 一部ケースではジャーナルエントリーの update count が 0 のままとなり、Activity Stream で正しく処理または表示されません。

これは sys_audit と sys_journal_field の createdOn タイムスタンプ差が 2 秒を超えた場合に発生し、HashMap のマッチングロジックが破綻するためです。

PRB1844946 (XP9、YP5、Zurich)

この重複は、特定の条件下で発生します。

コメントが追加されると、インシデントの sys_updated_on タイムスタンプが、対応する sys_journal_field レコードの sys_created_on タイムスタンプより 1 秒早くなります。 インシデント更新によってメールがトリガーされた場合、関連する sys_history_set 内での sys_email レコードのロードが、 sys_history_set の last_update_recorded フィールドに影響を与えます。 この影響によって、インシデントが再度更新された際にコメントの重複が発生します。 Resolution .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Activity Stream の問題に関連する複数の PRB に共通する根本原因 WP10、XP5、および Y リリース以降に発見されたすべての PRB は、それぞれ異なる症状を報告していますが、根本的には同じコンポーネントである HistorySetLoader フローに起因しています。

これらは独立した不具合ではなく、同一の根本問題の異なる現れ方です。

PRB1844946 で導入された修正は、以下の関連 PRB を包括的に解決するため、これらは重複として扱われています。

PRB1869081 - 'snc_read_only' causes duplicate comments/work notes in the activity stream PRB1860893 - Comments not visible in Activity Stream due to time difference in audit and journal records (Extension to DEF0601311) PRB1837173 - Additional comments or work notes not displaying for all users when posted from a script while property glide.history_set.pull_journal_entries_from_journal_table is true 修正内容における主な改善点 ( PRB1844946 ) 1. 新しい journal_sysid 列 sys_history_line テーブルに追加されました。

この列は、ロード済みの sys_journal_field レコードを一意に識別および追跡するために使用され、データベースレベルで直接重複を防止します。

2. glide.split_journal_audit_records プロパティ sys_journal_field と sys_audit レコードの間で 1 対 1 の対応付けを保証し、正確かつ一貫した同期を実現します。

3. 正確なタイムスタンプマッチング システムは sys_journal_field へのクエリーに startTimestamp を含めるようになりました。

これにより、同じ秒に作成されたエントリーをスキップしないよう保証されます。

4. glide.history_set.journal_audit_time_tolerance による柔軟なマッチングロジック 構成可能なプロパティ（デフォルト: 5000 ミリ秒 / 5 秒）が導入されました。

これにより、タイムスタンプにわずかな差異がある場合でも、ジャーナルレコードと監査レコードのマッチングが可能になります。

5. sys_history_line のスキーマ更新 sys_history_line テーブルに新しい列を追加しましたが、アップグレード時にはスキーマ変更を実施しない方針であるため、顧客が修正版へアップグレードした後、以下を実行する必要がある場合があります。

Table Rotations → sys_history_line → 「Synchronise shards」関連リンクをクリック

注意 PRB1844946 の修正には、 sys_history_line テーブルのスキーマ更新が含まれており、具体的には 「Journal sysid」 という新しい列が追加されます。

sys_history_line はローテーションテーブルであるため、この列はアップグレード時に即座には追加されません。

代わりに、システムはすべてのテーブルローテーションが完了するのを待機します。デフォルトのローテーションスケジュールでは、これに最大 28 日かかる場合があります。

スキーマ変更を即時適用するには、 sys_history_line 用の対応する sys_table_rotation レコードで 「Synchronise Shard」 アクションを手動実行できます。

特定レコードの重複コメントを修正する回避策 単一のレコード（例: インシデント）で問題を解決するには、以下を実施します。

プロパティ glide.history_set.pull_journal_entries_from_journal_table を作成し、値を true に設定する。 影響を受けるレコード（例: INCxyz）を開く。 バナーを右クリック → History → List 対応する sys_history_set レコードが開く。 その History Set レコードを削除する。 インシデントフォームを再読み込みする。重複コメントを含まない新しい sys_history_set が生成される。

複数のレコードの一括クリーンアップ 多数のレコードが影響を受けている場合は、関連する sys_history_set エントリーを削除するために以下のスクリプトを使用します。 var gr = new GlideRecord('sys_history_set'); gr.addQuery('sys_id', 'IN', ); gr.query(); gr.deleteMultiple(); は、影響を受けるレコードの sys_id をカンマ区切りで指定してください。 問題のあるスクリプト

プロパティ glide.history_set.pull_journal_entries_from_journal_table は、以下のようなスクリプトによって引き起こされる問題に対応するために導入されました（Business Rule で current.comments を使用する場合も同様のケースです）。

var gr = new GlideRecord('incident'); if (gr.get('57af7aec73d423002728660c4cf6a71c')) { gs.info("found incident"); gr.work_notes= 'Comment 1'; gr.work_notes = 'Comment 2'; gr.update();

このプロパティが無効であるか存在しない場合、システムは sys_audit と sys_journal_field の両方からデータを取得して sys_history_set および sys_history_line を生成します。

システムは両方のソースのエントリーを比較するため、不一致があると重複が発生します。

このシナリオでは:

「Comment 1」と「Comment 2」の値を持つ 2 つのジャーナルレコードが作成されます。 「Comment 2 Comment 1」という連結された値を持つ 1 つの監査レコードが作成されます。 その結果、sys_history_set に 3 つのレコードが表示されます。内訳はジャーナルレコード由来が 2 件、監査レコード由来が 1 件です。 推奨される修正は、 glide.history_set.pull_journal_entries_from_journal_table を有効化することです。このプロパティは重複コメントを防止するために設計されており、History Set にコメントを sys_journal_field テーブルからのみ取り込みます。

XP5 および Y バージョン以降では、 glide.split_journal_audit_records という新しいプロパティが導入されました。

glide.split_journal_audit_records を有効にすると、システムは sys_audit と sys_journal_field が同じ数のレコードを維持するようにし、重複を解消します。

「Comment 1」と「Comment 2」の値を持つ 2 つの sys_journal_field レコードが作成されます。 「Comment 1」と「Comment 2」の値を持つ 2 つの sys_audit レコードが作成されます。 glide.history_set.pull_journal_entries_from_journal_table が無効のままであっても、 glide.split_journal_audit_records を有効化することで、このようなケースで 3 件のレコードが作成されることを防止できます。

----------------------------------- XP9 の機能変更 -----------------------------------

glide.split_journal_audit_records システムプロパティの動作は、以下のように変更されました。

1. glide.split_journal_audit_records = true の場合 「Comment 1」と「Comment 2」の値を持つ 2 つの sys_journal_field レコードが作成されます。 同様に、「Comment 1」と「Comment 2」を含む 2 つの sys_audit レコードが作成されます。 2. glide.split_journal_audit_records = false の場合 「Comment 2 Comment 1」という連結された値を持つ 1 つの sys_journal_field レコードが作成されます。 同じく「Comment 2 Comment 1」という連結された値を持つ 1 つの sys_audit レコードが作成されます。 重要な注意事項 デフォルトでは、 glide.split_journal_audit_records プロパティは false に設定されています。

XP9 リリース以降、顧客は動作の変化を確認する可能性があります。

以前は、上記のようなスクリプトを実行すると、2 つの個別の sys_journal_field エントリーが作成されていました。

現在は、デフォルト設定のままでは、スクリプトは連結されたコメントを含む 1 つのジャーナルフィールドエントリーのみを生成します。

顧客が従来の動作、すなわち個別のジャーナルフィールドレコードの作成を維持したい場合は、 glide.split_journal_audit_records プロパティを true に設定できます。

----------------------------------- XP 10 以降: -----------------------------------

1. glide.split_journal_audit_records = true の場合 「Comment 1」と「Comment 2」の値を持つ 2 つの sys_journal_field レコードが作成されます。 「Comment 1」と「Comment 2」の値を持つ 2 つの sys_audit レコードが作成されます。 2. glide.split_journal_audit_records = false の場合

「Comment 1」と「Comment 2」の値を持つ 2 つの sys_journal_field レコードが作成されます。 「Comment 2 Comment 1」という連結された値を持つ 1 つの sys_audit レコードが作成されます。

---------------------------------------------------------------------- 推奨構成： ---------------------------------------------------------------------- 有効化: glide.history_set.pull_journal_entries_from_journal_table

有効化: glide.split_journal_audit_records