Java EWS API を使用して、アプリケーションを MS Exchange に接続し、ユーザーの電子メール リクエストを読み取ります。これらのリクエストは、システム ワークフローを通じて処理されます。1 日のメール数は 50 に制限されているため、全体の量は少なくなります。ただし、EWS API を使用して Exchange サーバーから読み取るための効率的で信頼性の高いメカニズムを検討しています。また、電子メールが処理されると、サブフォルダーに移動されるため、受信トレイには未処理の要求のみが含まれます。
現在、私が理解しているように、次のスキームを使用して Exchange サーバーに接続し、メールボックスでさまざまな操作を実行します。
ポーリング - 標準の Exchange サービス インターフェイスを使用して Exchange に接続します。すべての新しい電子メールを見つけて、順番に処理します。クライアントは、読み取りと処理済みフォルダーへの移動の間の障害と同期をより適切に制御できます。マイナス面としては、エクスペリエンスはリアルタイムではなく、アクティビティがなくても接続が交換されます。
プル通知 - この方法は前の方法とほぼ同じです。間隔を使用してプル通知をサブスクライブし、タイマー イベントが発生するたびに受信トレイから電子メールを読みます。長所と短所はアプローチ 1 と同様です。
プッシュ通知 - クライアントは、特定のイベントに自身を登録することで、プッシュ通知を受信するために Exchange サーバーにサブスクライブし、通知を受信するためのコールバック メカニズム (クライアント Web サービス) を定義します。利点として、通知はほぼリアルタイムであり、接続はイベントがある場合にのみ行われます。欠点として、イベントが失われないように、サブスクリプションとウォーターマークをクライアント側で管理する必要があることがわかりました。サブスクリプションを確立する前に既に受信トレイにあるメッセージに何が起こるかとして、これがまだ信頼できるアプローチであるかどうかはわかりません。これらのイベントはサーバーの起動時に再生されますか? それははっきりしていません。
ストリーミング サブスクリプション - クライアントはストリーミング接続を確立し、サーバーとの間で最大 30 分間開いたままにします。この間、Exchange は登録されたイベントを通知します。接続が切断されると、サブスクリプションが存続するように接続を復元する機能があります。フォルダ項目を同期して同期状態を維持するための追加の手順があると聞き始めるまでは、これが最善のアプローチのように思えました。イベントが接続/切断から失われないように、定期的に必要です。
私のニーズ (Exchange サーバーから電子メールを確実に読み取る) とさまざまなオプションの分析を検討すると、アプローチ 1 はプロセス全体をより適切に制御できるため、シンプルで信頼性が高いと感じています。しかし同時に、賛否両論に関するフレームワークの私の理解が間違っている場合は、API に精通している他の人たちと一緒に私を訂正してもらいたいと思っていました。
メールを見逃さないことが目的であるため、これを改善するためにグループからの提案をお待ちしています。