1

Exchange (2007) 개발에 익숙하므로 나와 함께하시기 바랍니다. :-). 최신 Exchange Web Services 인 Exchange 개발을위한 수많은 기술과 관련 Managed API가있는 것으로 보입니다. 필요한 경우 Exchange 서버에서 실행할 수있는 프로그램을 작성하여 다양한 기준 (이 토론과 관련 없음)을 충족하는 메시지를 제거 할 목적으로 사람들의 사서함을 검사해야합니다.Exchange 웹 서비스 (관리 API)와 WebDav 성능 질문

다른 기술 대부분 (WebDav, MAPI, CDO)은 이제 Exchange 2007 및 Exchange 2010과 관련하여 더 이상 사용되지 않습니다. 따라서 Greenfield 응용 프로그램이므로 Exchange 웹 서비스 관리 API.

시간당 스캔 할 수있는 항목 수가 걱정됩니다.. 웹 서비스 기반이므로 네트워크 홉이 관련되어 있습니다. 그래서 나는이 유틸리티를 통신하고있는 서버에서 실행하고 싶습니다. "허브"서버와 얘기해야한다는 점을 고치겠습니다.. 자동 검색을 사용하고 있으며 메일 서버에 실제 메시지 저장소가 있는지에 관계없이 "허브"서버로 확인되는 것으로 보입니다.

ExchangeService.FindItems를 사용하고 페이지 크기를 500으로 지정하면 여러 항목을 가져올 때 워크 스테이션에서 허브 서버로 처리량이 상당히 좋아집니다. 47 초 만에 22,000 개의 메일 항목을 검색 할 수있었습니다. 그것은 합리적으로 보인다. 그러나은 그런 식으로 검색 할 때 모든 속성이 "바운드"되는 것은 아닙니다. 특정 속성 - ToRecipients 및 CcReipients 같은 -에 채워지지 명시 적으로 (개별적으로)를 바인드 할 필요가 -. 전화로

Item.Bind(Server, Item.Id) 

이 서버에 별도의 왕복이며,이 강하에 약 460 개의 항목/초에서 3 개의 항목/초까지의 처리량은 작동하지 않습니다.

몇 가지 다른 질문이 있습니다. FindItems 호출 중에 누락 된 속성을 강제로 바인딩 할 수있는 방법이 있습니까? 그것이 실패하면, 즉시 항목을 구속하는 방법이 있습니까?

마지막으로,이 유형의 작업에 Exchange Web Services를 선택하는 것이 맞습니다. I 은 프로그래밍 모델의 단순함을 좋아하고 (a) 더 복잡하거나 (b) 비추천 인 경우 다른 기술로 이동하는 것을 원하지 않습니다. 다른 기술이이 작업을 더 잘 수행 할 것이고, 필요하다면 사용하는 것보다 비난하지 않는 것이 좋습니다. 귀하의 의견과 조언을 부탁드립니다.

답변

1

사용자는 서비스를 사용하여 한 번의 호출로 많은 항목에 대한 많은 속성을로드 할 수 있습니다.이 서비스는 문제에 맞게 설계되었습니다. Managed API 문서가 여전히 매우 얇은 것은 불행한 일입니다. 에로드

PropertySet s = new PropertySet(BasePropertySet.IdOnly, ItemSchema.Subject, customDefinitions); 

를 사용하여 다양한 xSchema 클래스 :

결과 =의 folder.findItems ... 속성 집합이 같은 일이

service.LoadPropertiesForItems(results, propertySet); 

인 경우 (또는 무엇이든 찾을하면하고 있습니다 전화) 많은 양의 레코드를 가져 오는 경우로드를 최소화하려는 특정 필드