Lotus Notes/Domino (R) をこよなく愛して。。。。

ようこそ、Notes/Domino ファン & ブロガーのみなさん !


【ご注意】 このブログはビジネスに活用いただくためのものですので、以下の点を守ってご利用願います。


1. 他社あるいは他人への誹謗中傷のコメントはご遠慮ください。

2. コメントはビジネスとして問題のない言葉、表現を使ってください。

3. Webで一般公開されていない、具体的な個人や法人を特定するコメントはご遠慮ください。

4. 個人情報の記載は行わないでください。


上記を守られないコメントは、こちらの判断で削除させていただきますのでご了承願います。


尚、このサイトの掲載内容は私自身の見解であり、メーカーとは全く関係はありません。

また、メーカーのビジネスに利害を及ぼすために記載している訳ではありません。


ここに記載されている内容は、私自身の経験からの記載であり、内容が正確でない場合もあることをご理解の上、ご利用願います。


ご利用に際しては、左側のフレームに記載しております【注】をご一読の上、利用条件を守ってご利用ください。

1 | 2 | 3 | 4 | 5 | 最初次のページへ >>
April 22, 2019

送信済Mailを編集して送信した再送Mailを回収(Recall)する -2-

テーマ:Mail Template

<話題の履歴>

送信済Mailを編集して送信した再送Mailを回収(Recall)する -1-

 

前回は、送信済Mailを編集して再送した場合のRecallの問題点を検証してみました。

今回は、この問題の原因と問題を解消するための解決策を考えてみたいと思います。

 

そもそも、Recallはどのように動いているのでしょうか?

Message Recallを行うと、Recall要求がRouterにMailとして送信されます。

RouterはUserがRecall許可しているか?などの条件を調べた上で、Mailの削除を行うのです。

勿論、Soft Deletionsでゴミ箱に入った状態のMailであっても、完全に削除されます。

詳しくは「Using the Message Recall feature in IBM Lotus Notes and Domino V8」を参照ください。

 

このSiteにも書かれていますが、Message Recallで文書を特定するために使われるのは文書のUNIDなのです。

 

The document UNID is used to identify the message in the recipient’s mail file. If the server is capable of performing a recall, the message is located and deleted. The router removes the message completely and leaves only a deletion stub, allowing the message to be removed from replica copies as well. Even if the recipient has soft deletions enabled, the message is never left in the Trash folder. Because the UNID of the document is used to locate the message, any copies that have been moved to folders are also removed.

 

これが、送信済Mailを編集して再送した際にRecallが正常に動作しなくなる原因となっているのです。

文書のUNIDは、文書を作成して保存した際に日時から計算してUniqueなKeyとして使われていますが、あくまで最初の保存時に生成されそれ以降は変更されることはありません。

毎回保存時に変えてしまったのでは、DBのReplicaがある場合にReplica間で同一文書とみなされず、正常にReplicaが行われないためです。

送信済Mailも同じで、最初に送信した際にUNIDが生成され、そのMailを編集して再送信してもUNIDは変わりません。

つまり、既にRecallが実行され、削除StubにUNIDが存在する場合は、「削除済」と判断されているのです。

Recallが実行されていない場合は、UNIDで検索して最初の文書を削除するという動作をして、同じUNIDの文書が2個存在することは考慮されていないという訳です。

 

前回実験した結果から見る限りは、最初に削除Stubを検索して削除済のUNIDが無いかをCheckし、その後DBの文書をCheckして削除していると考えるのが妥当です。

つまり、削除Stubが完全に消え去った場合は送信済MailであってもRecallが成功すると思いますが、通常のMailではCutoff DateがDefaultの90日で設定されているため、そんな古いMailをRecallすることは無いため、実質的に使えないという訳です。

 

ここまで動作を把握すると、解決策は明らかです。

送信済Mailを編集して再送する際には、UNIDを変更することが解決策になります。

実際に送信済Mailを編集して送信すると言う利用をされる方にとっても、過去のMailは残し、編集再送したMailも残したいのではないでしょうか?

私は、その方がMailの機能としては当たり前のような気がします。

Mailを再送した場合は、新規Mailであり、UNIDを引き継ぐ必要は全くないからです。

 

今回は、送信済Mail再送時のRecallの問題の原因と問題を解消するための解決策を考えてみました。

次回は、実際にUNIDを変更して送信する解決策を試してみます。

 

<続く>

 

 

April 18, 2019

送信済Mailを編集して送信した再送Mailを回収(Recall)する -1-

テーマ:Mail Template

Notes/Domino V8以降、Mailを送信した後で、Mailの回収(Recall)を行うことが出来るようになっています。

 

皆さんは、送信済Mailをひな型のように扱い、編集して再送するということを行われる場合があると思いますが、このRecall機能は既に送信済のMailを編集して送信した場合にはRecallを行うことが出来ません。

送信済Mailをひな型のように利用する場合は、代替策としてCopyInto機能を使って送信すれば、新規のMailとして生成されるため、正常にRecallを行うことは可能ですが、あまり利用されていないのではないかと思われます。

或いは、Mail送信後に内容や宛先に間違いを発見し、Recallした後に送信済Mailを編集して再送し、再度誤りを発見してRecall/再送するといったことがあるかも知れませんが、この場合もRecallは行われないのです。

 

Recall機能が実装された際に、この問題を指摘しましたが、「製品の制限」ということで、現在でも送信済MailのRecallは出来ないのです。

また、Notes/Domino V10で実装されたScheduled Messageに関しても、間違えてしまった場合にはRecall機能を利用して送信を取り消す必要がありますが、この場合も送信済のMailを編集して送信した場合にはRecallを行うことが出来ないのです。

 

では、実際に送信済Mailを編集して再送し、Recallするとどのようになるか見てみましょう。
 
まず、新規にMailを作成して送信し、直ぐにRecallします。
以下のように、Recall成功のMessageが戻ってきます。
 
 
次に、送信済Mailを編集して再送し、再度Recallを行います。
以下のように、Mailは削除済という理由でRecallは失敗します。
 
 
次に、新規Mailを送信してRecallせずに、送信済Mailを編集して再送します。
以下のように、相手先に2通のMailが届いています。
 
 
この状態でRecallを行ってみると、以下のようになります。
 
 
送信済Viewには2回目に送信したMailしか残っていませんので、2回目のMailをRecallした積りが、相手先では1回目に送信したMailが削除され、2回目のMailは削除されないのです。
勿論、再度2回目に送信したMailをRecallしても、「Mailが削除されている」という理由でRecallは行われないのです。
 
これでは、送信済Mailをひな型のように扱い再利用するユーザーにとっては全く役に立たない状況です。
 
では、この問題を解決する方法はあるのでしょうか?

 

今回は、送信済Mailを編集して再送した場合のRecallの問題点を検証してみました。

次回は、送信済Mail再送時のRecallの問題の原因と問題を解消するための解決策を考えてみたいと思います。

 

<続く>

 

April 15, 2019

ND V10で実装されたその他の機能の感想

テーマ:Notes/Domino 10.x

Notes/Domio V10では、他にも幾つか新機能が搭載されています。

 

今回、評価することはしませんが、新機能の概要を読んだ感想だけ述べておきたいと思います。

Knowledge Centerの10.0や10.0.1は未だに日本語訳されていないようで(2019/02/03時点)、英語の文書を読まなければならず疲れます。

※詳細は調べておりませんので悪しからず。

 

【Notes Client】

 

・ Pushing a custom color theme to Notes clients

Notes Clientではテーマなどの色のCustomizeが出来ますが、その色をServerのDesktop Policyを使ってNotes.ini変数で配布できると言うものです。

CUSTOM_THEME_COLOR=<R>,<G>,<B>

まあ、どれだけのお客様がNotes ClientのテーマをCustomizeしているのか私には分かりませんが、個人的には些細な機能だと思いますので、余り興味がありません。

 

・ Pushing icalendar refresh interval, pushing new calendars

NotesのiCal CalendarをGoogle CalendarにPushして同期させるという機能です。

以下のNotes.iniをNotes Clientに設定することでPush先とPushする間隔を指定できるようになるとのことです。

AddCalendarURL

FeedRefreshInterval

GoogleにCalendar情報をPushできるということは、企業によってはSecurity Policyの観点からUserに許したくないという場合もあるかと思いますが、今回の機能ではNotes.iniで設定できてしまうため、幾ら管理者がDesktop Settings Plicyで設定をクリアするように設定(Notes.iniのパラメータをクリア)していたとしても、Userが設定し直せば使えてしまうのではないかと思います。

実装するなら、Notes.iniではなく、Preferenceでのみの設定にして、Desktop Settings Policyで値の設定を禁止する設定(設定自体を表示させないかグレーアウトして設定できなくする)がないといけないのではないかと思います。

 

・ Using Notes Auto Update

10.0.1以降でサポートされるNotes Clientの自動Upgradeの機能です。

概要を読むだけでは、これまで提供されてきたSmart Upgradeと何が違うのかが今一つ分かりませんでした。

管理者がDesktop Setting Policyで設定したVersionをNotes ClientからHTTPSを使ってUpgrade(AUT) ServerにAccessしてUpgrade Packageを入手し、ClientのUpgradeが行われると言うことですが、Smart Upgradeも同様だったと思います。

Smart UpgradeはUserが適用するまでの猶予期間の設定や猶予期間を過ぎた場合の強制適用などが行えたと思いますし、管理者がSilent Install Moduleを提供すれば、自動的にInstallが行われたと思います。

今回は、IBMがWebで提供するInstall Moduleのみが利用できるとのことですが、Silent Installされるのかは分かりません。

また、AUT ServerのUpgrade用カタログにIBM/HCLのSiteからUpgrade Kitを自動取得してくれているのなら尚良いのですが。

Windows Updateのように標準では有無を言わさず適用してしまうのはNetworkに負荷を掛けてしまうので、企業内では論外だとは思いますが、内部ServerにUpdate Kitを自動的に準備して、管理者の設定により、New Release/FP/IFを配布できるのであれば、非常に有効な機能ではないかと思います。

更に、この機能と連動して、ServerにAccess可能な最低Releaseの更新が行えるのであれば、尚良いでしょう。

 

【Domino Server】

 

・ Dynamic indexing of high-usage views

使用率の高いViewを自動的に判断して、優先的にView Indexを更新する機能のようです。

管理者側では、制御することはできません。

残念ながら、私にはこの動きの検証方法が全く思いつきませんので、検証はできません。

9.0.1 FP9からInline Indexの機能が提供されていますが、この機能であれば、管理者がViewを即時更新するDBの指定が可能です。

Inline IndexやNIFNSFの評価の際に、names.nsfのSystem Viewが更新されていたのはこの機能によるものかも知れません。

 

・ Symmetrical clusters

Cluster MamberのDBが壊れたりすると、他のMemberにあるDBで自動式に修復するという機能です。

自動的に修復してくれるのはありがたい機能だと思います。

運用担当者が手動で消した場合はどういう処理になるのか興味がありますが、明示的に管理者が消しているので、再配置はされないと思います(でなければ、ClusterからDBをCluster対象外にできないので)。

ただ、Cluster MemberからDBが無くなった場合に("Any missing or damaged databases are repaired"と記載されていますので)、どういう判断で処理するのかは非常に興味があります。

 

・ Improved streaming cluster replication during server restarts

Cluster ReplicationはStreaming Modeで高速に行われますが、これまでは、この途中でServerがRestartされてしまった場合、最初からやり直していたのを、途中から再開すという機能です。

これも非常に期待したい機能です。

特に災害対策などで、WAN越しにClusterしているような場合は、一から再開されるとNetworkに負担を掛けてしまいますし、時間の無駄となります。


・ New way to synchronize database replicas

Server間のReplicaの内容を一致させるために新しいReplica Optionとして-Fが提供されました。

また、-L Optionを使うと、実際にはReplicationは行わずに、-F Optionを使った際にReplicaされる文書をLogしてくれるようです。

これまで、Replica間で文書数不一致が起こってしまった場合は、DBのReplica履歴を消してから、全ての文書を比較してReplicaするようにする必要がありましたが、このReplica Optionがあれば簡単にReplica DB間の相違を解消できると思います。

また、Server移行などの際にも、Serverを止めてしまいOS Copyで移行すると長い停止時間が必要になりますが、この機能があれば、事前にReplicaしておき、移行当日に-L Optionで追加でReplicaしなければならない文書を判断した上で-F OptionでReplicaすれば、Server停止時間も短くできるのではないかと思います。

 

・ Detect delays in database replication within a cluster

Cluster間のDBのReplicationの遅延を把握してくれる機能です。

遅延を発見すると、Server Logに記録されるとのことですので、Event Handlerで管理者に通知すると活用できるかも知れません。

また、統計情報にも記録され、Cluster Replica遅延が発生しているDBを確認することも可能なようです。

show stat replica.cluster.currency.*

従来であれば、統計情報のCluster Queueの数を見て、Queueの溜まり具合から管理者が判断して、Cluster Replicatorの数の調整などを行っていましたが、どのDBで遅延が起こっているかの把握はできませんでした。

とても興味のある機能です。

 

・ Full-text search resiliency

全文検索をする際に、未Indexの文書を最大200文書まで全文索引してくれ、かつ200文書を超える場合は、即時のIndex更新を要求してくれる機能です。

また、Index中や検索中にIndexの問題を発見した場合は、自動的に再構築要求を発行してくれるようです。

全文索引は、基本的には1時間に1回、cronosが処理して索引を更新しますが、遅延することもあり、FTSearch Methodなどを使ったApplicationの場合、最新の文書が検索できませんでした。

この機能により、検索前にFTIndexが更新されるのであれば、FTSearchを使ったApplicationもより信頼性が上がるかも知れません。

但し、検索前に200文書の索引作成が行われるため、Application Performanceの考慮が必要かも知れません。

また、運用管理者も、つい全文索引で探してしまう人が多いようですが(私は即時性を考慮してViewの検索を利用します)、そういう方にもメリットはあるのではないかと思います。

まあ、上限が200ということなので、1時間に200文書以上登録/更新があるようなDBの場合は、直ぐに検索は出来ないとは思いますが、一般的なDBであれば有効活用できるのではないでしょうか?

 

あと、Security関連でも幾つか新機能が紹介されていますが、今回は割愛させて頂きます。

 

また、上記はあくまで私の解釈であり、誤っていることもあるかと思いますので、詳細はメーカーのセミナーなどで確認してください。

 

これにて、ND V10の機能検証関係の記事は終わりとさせて頂きます。

1 | 2 | 3 | 4 | 5 | 最初次のページへ >>

Ameba人気のブログ