インスタンスにより生成される重複メールのトラブルシューティングIssue インスタンスから重複したメールが送信される理由はいくつかあります。この資料では、この動作の原因を見つける方法について説明します。 メール メッセージ ID について Message-ID は、システム内の各メールメッセージに対して一意のものとして生成され、メールヘッダー内に表示されます。 メールがまったく同じに見えるが、 message-IDが異なる場合、それはメッセージがメールが生成された送信サーバーによって作成された重複であることを示しています。 message-ID が同じ場合は、重複したメールは送信されていないが、メッセージを送受信するメールサーバーがまったく同じメッセージを複数回配信していることを示しています。 トラブルシューティングのシナリオ 受信側の電子メール サーバーによって同じメッセージが複数回配信される可能性があるシナリオの 1 つは、同じ受信者が個々の電子メール アドレスと、その受信者がメンバーである配布リストと共に一覧表示されている場合です。メールサーバー管理者は、このシナリオでのメールサーバーの動作を制御できます。 インスタンス内のメールの受信者リストを確認します。配布リストと個々の受信者は表示されますか?配布リストで複製を受け取り、個々の受信者として追加されているユーザーですか?送信サーバーによって重複が作成される懸念がある場合は、受信者に配布リストが含まれない重複メールの例を表示する必要があります。 まったく同じように見える複数のメールで message-ID が一意でない場合は、システムプロパティ glide.pop3.debug をオンにします。メッセージを再度送信すると、インスタンスログに「duplicate of message-id」のような出力が出力されます。 重複メールの識別 重複が疑われるメールメッセージを見つけて取得し、メールアドミニストレーターに提供するには、次の操作を行います。 sys_emailテーブルに移動し、タイムスタンプ、件名、送信者などに適切なフィルターを使用します。リストビューをカスタマイズして message-ID を表示します。疑わしいメールのメッセージ ID が同じか異なるかを確認します。これらのメッセージ ID をメールアドミニストレーターに提供して、メールサーバーがこれら 2 つのメールメッセージを送信したかどうかを確認します。 同じメール通知に対するメールなのか、または同時に送信された異なるメール通知なのかを判断するため。以下の手順に従って、問題のすべての重複メールのリストを取得します。 メールの問題を示すレコードに移動し、sys_idを取得します。テーブル [sys_email] に移動し、target=sys_id で検索します。タイム スタンプと受信者を確認して同じメールを見つけ、リストを同じメールに制限します。これらのメールを開きます。メールログ関連リストを確認します。使用されたメール通知とイベントをメモします。イベントとメール通知の値が同じメールのような重複メールに注意してください。 たとえば、送信されたメールレコードが 3 つあり、1 つは「incident.assigned」というイベントによって生成され、他の 2 つは「incident.assigned.to.group」というイベントによって生成され、重複した通知が発生したとします。 該当するメール通知 (System Policy > Email Notifications) のレコードに移動し、メール通知の条件をメモします。 ビジネスルールのトラブルシューティング [スクリプト] フィールドで current.update が使用されているメール通知をトリガーしている可能性があるすべてのビジネスルールを取得します。ビジネスルールが「After」で実行されていて、それに「current.update」が含まれている場合、これがメールの重複の原因である可能性があります。ビジネスルールの条件と、現在のレコードのどのフィールドが更新されるかをメモします。例： この「後」ビジネスルールの条件は、「アサイン先グループ」が設定され、「アサイン先」が設定されていない場合に実行されます。"!current.assignment_group.nil() & current.assigned_to.nil()"このビジネスルールは、current.assigned_toフィールドを変更してから、current.update() を実行します。 [英語]The condition on this "After" business rule runs if "Assignment Group" IS set, and "Assigned To" IS NOT set."!current.assignment_group.nil() && current.assigned_to.nil()" This business rule will modify the current.assigned_to field, and then run current.update(). 該当するレコードの アクティビティ履歴 を参照し、各更新時のレコードのフィールドの状態をメモします。レコード内のフィールドのステータスをメール通知の条件に一致させます。 注意: 最初の更新は、メールの条件と一致する必要があります。 レコード用に作成された問題のイベントを検索すると、同じイベントに対して同時に作成された 2 つの一意のレコードが表示されます。挿入された最初のイベントは、インシデントの最初の挿入または更新 (いずれか) を指し、2 番目のイベントは、「current.update()」を実行する After ビジネスルールの実行中に発生した *updated* レコードを参照します。これが、ビジネスルールで current.update または current.insert を実行しないことをお勧めする理由の 1 つです。 実際には最初の挿入または更新と 2 回目の更新の 2 つのアクションがあるため、2 つのイベントが生成されます。ビジネスルールの current.update() が実行されたときには、最初の挿入または更新がまだ完了していないため、これは特殊なケースです。したがって、「イベントの処理」を担当するビジネスルールが 2 回評価され、どちらの場合もレコードは「更新済み」と見なされます。メール通知条件は true と評価され、2 つのイベントが生成されます。 この一連のイベントを変更して、現在のレコードの更新が「前」ビジネスルールで行われるようにする必要があります (current.update の呼び出しが不要になります)。1 つのイベントが原因で 2 つのメールが同時に送信される可能性もあります。 注意: 通知内のテーブルと同じテーブル (および影響を受けるレコード) に x.update() がある場合、アフタービジネスルールを使用すると、重複するメールが表示されることもあります。これにより重複した状況が解決されるかどうかを確認するには、ビジネスルールの順序を高い数値 (99,000 など) に設定して、問題が解決されるかどうかを確認します。