問題タブ [ews-managed-api]

連絡先データを使用して、Exchange Web サービス マネージ API を使用しています。次のコードがあります。これは機能的ですが、理想的ではありません。

私が言ったように、このコードは動作します。可能であれば、もう少し吸うようにしたいと思います。

アクセスしようとする前に辞書内のキーの存在を確認できるメソッドが見つかりません。( を使用して) キーを読み取ろうとして.ToString()存在しない場合、例外がスローされます。

500
指定されたキーはディクショナリに存在しませんでした。

このコードをリファクタリングして、（まだ機能している間）吸う回数を減らすにはどうすればよいですか?

カスタム スケジューリング アプリケーション (マスターの役割) を Microsoft Exchange Server 2010/2007 (スレーブの役割) と同期できるようにするソフトウェアを開発しています。当社のソリューションは、.NET 4.0、EWS マネージ API、Parallel Fx、そしてもちろん独自の C# コードに基づいています。「ExchangeService」クラスのインスタンスは複数のスレッドで同時に使用されず、インスタンスの総数に関して保守的であるという事実に特に注意を払いました (現在、常に 10 個のライブ インスタンスがあります)。ただし、多くの呼び出しを行います (FindItems、CreateItems、UpdateItems、DeleteItems、LoadPropertiesForItems)。

さらに掘り下げてみると、このアプローチではあまりメリットがないことがわかりました。操作が発行されるたびに、新しい HttpWebRequest が作成され、実行され、閉じられます。認証された要求 (この場合: https + WebCredentials) の場合、基礎となる tcp 接続が TIME_WAIT の状態で OS に返されるようです (この記事で説明されているように: msdn.microsoft.com/en-us/library/aa560610( BTS.10).aspx) を実行し、そこに座って、4 分間何もしません (デフォルト)。上記の記事の提案を既に適用しており (詳細な議論はここにあります: blogs.msdn.com/b/dgorti/archive/2005/09/18/470766.aspx)、「そこに座っている」時間を 30 に短縮しました。秒。これはテスト環境ではすべて問題ありませんが、tcp 接続がより希少なリソースであり、アプリがそれらを使用する唯一のものではない実稼働システムではそうではありません。

問題は、EWS マネージ API が HttpWebRequest (または System.Net のさらに深い部分) を使用する方法に関係していると思います。msdn.microsoft.com/en-us/library/system.net.httpwebrequest.unsafeauthenticatedconnectionssharing.aspx と msdn.microsoft.com/en-us/library/6y3d5dts.aspx をいじりたいと思っていましたが、すべて EWS マネージ API内部または密閉されていると、これを拡張/試すことが難しくなります。

進め方のアドバイス大歓迎！

特定の交換メールボックスを監視する簡単なコンソールアプリを作成中です。特定の条件を満たすメールを受信すると、アプリはXMLファイルの添付ファイルをダウンロードし、メールをアーカイブします。

EWS OKに接続し、すべての電子メールをループできましたが、添付ファイルにアクセスするために使用できるEmailMessageオブジェクトを作成するのに苦労しています。

以下のサンプルコードでは、EmailMessage message = EmailMessage.Bind(...)行はエラーなしで実行されますが、有効なメッセージを返さないため、プロパティまたはメソッドにアクセスすると、エラーが発生します：'オブジェクト参照がオブジェクトのインスタンスに設定されていません'。

私はEWSはもちろんC＃を初めて使用するので、どこから始めればよいかわからないのです...

コードスニペット：

添付ファイルにアクセスするための私のコードはMSDNから直接のものなので、そこにあることを願っています...何かアイデアはありますか？

Exchange 2007 サーバーに接続しようとしています。エラーをキャッチしてアプリケーションログに記録するために、多くの例外処理を配置しました。まず、ユーザーが提供された資格情報を使用して交換サービスにアクセスできるようにする機能があります。

この関数が false を返す場合、ユーザーがログインに失敗したことを報告するエントリがアプリケーション ログに配置され、プロセスは終了します。

関数が成功した場合、どこかでこの関数を呼び出します。次の 10 分で開始されるユーザーのすべての予定を取得します。

ご覧のとおり、関数はすべての例外をキャッチしてログに記録します。ログに表示されるのは、関数Request failed. The remote server returned an error: (401) Unauthorized.へのスタック トレース ポイントservice.FindItems()です。

だから私は少し混乱していて、おそらく交換やウェブサービスなどについて十分に知りません. ログオン関数は true を返していますが、認証は後で失敗します。助言がありますか？

Exchange Webサービス2010での作業は、特に.NET以外では少しばかげているため、他の言語がExchangeと対話するためのパススルーとして機能するSOAPWebサービスに一部の機能をラップする必要があります。環境。

[その他] <-（SOAP）-> ASP.NET ASMX Webサービス<-（EWSマネージAPI）-> Exchange2010

ユーザーがすべてのアクションでパスワードを入力する必要がないように、偽装アカウントを使用しているため、必要なのは変更するアカウントのアカウント名だけです。

これはすべてかなりうまく機能します。なりすましアカウントの1つを使用します。偽装アカウントは、監査を簡素化する目的で、APIキーと1：1の関係にあります。設定した他の偽装アカウントは、名前とパスワードが異なることを除いて、作業アカウントの正確なコピーのように見えますが、EWSマネージAPIからそれらを使用しようとすると、次のエラーが発生します。

要求が失敗しました。リモートサーバーがエラーを返しました：（401）許可されていません。

スタックトレース：

私が言ったように、これと同じコードは、特定の他の偽装アカウントに対応するAPIキーを使用する場合に正常に機能します。また、機能しないapiキーを機能する偽装アカウントを使用するように設定すると、apiキーが機能し始めます。

1つのアカウントは機能し、別のアカウントは機能しないため、問題はWebサービスコードにあるのではなく、偽装アカウントのセットアップまたはWebサーバーとExchangeサーバーの間に存在するある種の構成にあると解釈します。ただし、サーバー間の構成の場合は、すべてのアカウントが機能しなくなると思います。

同時に、私たちは非常に有能な取引所管理者であると私が信じているものを持っており、少なくとも2人はなりすましアカウントを調べて、問題ではないと結論付けています。

ここからどこへ行けますか？考えられる解決策の1つは、すべてのリクエストを実際のなりすましアカウントに転送し、監査の影響に対処することだと思いますが、それを回避できるのであれば、そうしたいと思います。何か案は？

「EWS マネージ API 初心者」として、タスクの作成と管理に関する例やドキュメントを見つけるのに苦労しています。

問題なく自分用のタスクを作成できました。ただし、私は本当に次のことができる必要があります-誰かが私に何かポインタを与えることができれば、本当に感謝しています...

1. タスクを作成し、別のユーザーに割り当てます。
2. そのタスクがそのユーザーに割り当てられている間、そのタスクのステータス (完了率など) を問い合わせることができます。
3. タスクに関するメモはいつでも更新できます。

ご指摘ありがとうございます。

タスク (Exchange 2007 SP1) を操作するために Exchange Web サービス マネージ API を使用しています。私はそれらをうまく作成できます。ただし、更新を行おうとすると、.Body フィールドを除くすべてのフィールドで機能します。そのフィールドにアクセス (読み取り/更新) しようとすると、次のエラーが発生します。

私が使用しているコードは次のようになります。

奇妙なことに、プロパティ バッグを調べると、オブジェクトに 33 個のプロパティが含まれていることがわかりますが、{Body} はその 1 つではありません。そのプロパティは、基本クラス .Item などから継承されているようです。

では、オブジェクトを Item 型として再ロードする必要がありますか? または、.Bind などを介してリロードしますか? 何千ものアイテムでこれを行う必要があることに注意してください。そのため、効率が重要です。

Exchange（2007）の開発は初めてですので、ご容赦ください。:-)。Exchange開発には無数のテクノロジー（最新のものはExchange Webサービス）があり、それに関連するマネージドAPIがあるようです。さまざまな基準を満たすメッセージをパージする目的で、必要に応じてExchangeサーバー上で実行できるプログラムを作成してユーザーのメールボックスをスキャンする必要があります（この説明には関係ありません）。

他のほとんどのテクノロジ（WebDav、MAPI、CDO）は、Exchange2007およびExchange2010に関して非推奨になっていることを理解しています。したがって、これはグリーンフィールドアプリケーションであるため、ExchangeWebサービスマネージAPIを使用することにしました。

1時間にスキャンできるアイテムの数が心配です。これはWebサービスベースであるため、ネットワークホップが関係しています。そのため、通信相手のサーバーでこのユーティリティを実行したいと思います。 「ハブ」サーバーと通信する必要があるというのは正しいですか？。自動検出を使用していますが、スキャンしている実際のメッセージストアがどのメールサーバーに含まれているかに関係なく、「ハブ」サーバーに解決されるようです。

ExchangeService.FindItemsを使用し、ページサイズ500を指定して複数のアイテムをプルダウンすると、ワークステーションからハブサーバーへのスループットがかなり向上します。47秒で22,000通のメールを検索できました。それは合理的なようです。 ただし、その方法で取得した場合、すべてのプロパティが「バインド」されているわけではないことがわかります。ToRecipientsやCcReipientsなどの特定のプロパティは入力されていません。これらを（個別に）明示的にバインドする必要があります。

これはサーバーへの個別のラウンドトリップであり、スループットが約460アイテム/秒から3アイテム/秒に低下します。これは実行不可能です。

だから-他のいくつかの質問。FindItemsの呼び出し中に、欠落しているプロパティを強制的にバインドする方法はありますか？それができない場合、一度に複数のアイテムをバインドする方法はありますか？

最後に、私はこの種の作業にExchangeWebサービスを選択するのは正しいのでしょうか。私はプログラミングモデルのシンプルさが大好きで、（a）より複雑であるか、（b）廃止されている場合は、別のテクノロジーに移行したくありません。別のテクノロジーがこの仕事をより良くし、それが非推奨にならないのであれば、私が必要に応じてそれを使用することを検討するよりも。ご意見・ご感想をいただければ幸いです。

EWS マネージ API を使用して Exchange を検索し、すべてのフォルダーのすべての電子メール メッセージを検索する方法はありますか? FindItems API 呼び出しを使用していますが、検索を 1 つのフォルダーに限定する必要があるようです。

Exchange Web Services Managed API 1.0 を使用して、組織内の Exchange サーバー (2007) にアクセスしています。特定のサーバー上のすべてのメールボックスを反復処理する必要があります。特定の Exchange サーバー用に定義されたメールボックスのリストを取得する方法を見たことがありません。AutoDiscover サービスを使用して、特定のメールボックスのハブ サーバーのアドレスを見つけることができましたが、すべてのメールボックスのリストを取得したいと考えています。誰かが私を正しい方向に向けることができますか?