Domino 8 Beta-2を試してみよう ! -11-
＜話題の履歴＞
前回は、Message Recall機能を簡単に試してみました。
今回は、Message Recall Request文書の内容を少し調べて見ることにします。
まず、Message Recall Request文書のPropertyを見てみましょう。以下のようになっています。
RecallCriteria、RecallMessageID、RecallRecipients、RecallReport、RecallUNIDという5つのRecall関係のFieldがあります。
Recall CriteriaはMessage Recallを行う時の、対象文書の指定であり、"4"が指定されている場合は、Read MailでもRecallする設定となり、"2"が指定されている場合はUnread MailのみRecallする指定となります。
このことは、Recallを設定している、「(subRecallRequest)」Subformを見るとご理解頂けると思います。
このSubformを使って、以下のDialog Boxを表示しているのです。
"RecallReport" Fieldも、このDialogで指定するReportの要求の指定となっており、"1"が指定されている場合はRecall Reportを要求するということになっています。
"RecallRecipients" Fieldも、このDialogで指定するRecall対象Userの指定となります。
RecallUNIDとRecallMessageIDは、Recall対象になる送信Mailの文書のUNIDとMessageIDを保存しているのです。
これにより、RouterがRecall対象文書を把握して、相手のMail DBから文書を削除するという動きになります。
また、Recall RequestやRecall Reportを表示しているFormは"(Recall Request) | Recall Request | Recall Response"というFormです。
このAliasからお分かり頂けるように、RequestもResponseも同じFormを使っています。
つまり、Recall Requestの文書を開いても、Recall Reportの文書を開いても同じFormで表示されますので、全く同じReportが参照されることになっているのです。
また、このFormでは、Post Open Eventで以下のような処理を行っています。
Sub Postopen(Source As Notesuidocument)
Set cRecallObject = New RecallObject(Source)
Call cRecallObject.Init()
End Sub
つまり、文書を開いた後で、Recall Reportを生成するようになっているのです。
前回、Previewした場合に正常なReportが表示されないという問題がありましたが、どうやらこの辺が関係していそうです。
Previewで正常に表示できない問題は既に問題報告されていますので、製品出荷までには修正されるのではないかと思われます。
今回は、Message Recall Request文書の中身を少し調べてみました。
次回は、もう少しMessage Recallの機能について試してみたいと思います。