არსებულ ლოკალურ EWS Managed API აპლიკაციაში მიაკუთვნეთ შუამავალი სერვისს მის HTTP ოპერაციებამდე:

using System.Net;

var proxy = new WebProxy("http://proxy.example:8080")
{
    Credentials = new NetworkCredential(proxyUser, proxyPassword)
};
exchangeService.WebProxy = proxy;

exchangeService უკვე შეიცავს EWS-ის საბოლოო წერტილსა და სერვისის პარამეტრებს. მისი Credentials არის Exchange ანგარიში; proxy.Credentials არის შუამავლის ანგარიში. სერვისის ნაგულისხმევი სერტიფიკატების ვარიანტი ამ პროქსის ობიექტს ავტომატურად არ ავსებს.

განზრახ პირდაპირი კავშირისთვის ამ API სტეკში:

exchangeService.WebProxy = new WebProxy();

ცარიელი WebProxy ირჩევს პირდაპირ ქცევას. სერვისზე არსებული null WebProxy კი ძირითადი მოთხოვნის ნაგულისხმევ პროქსის პოლიტიკას უცვლელად ტოვებს.

მხოლოდ ერთი ლოკალური ჰოსტისთვის გამოიყენეთ განზრახული გვერდის ავლა, რომელიც შეესაბამება მის ფაქტობრივ ჩანაწერსა და არანაგულისხმევ პორტს, ნაცვლად მთელი მანქანის მარშრუტის შეცვლისა. შეადარეთ EWS URL და პროქსის ობიექტი, როცა Outlook მუშაობს: იმ სხვა კლიენტს შეიძლება ჰქონდეს განსხვავებული მარშრუტი და შუამავლის ანგარიში.

დაკავშირებული სტატიები