Каков наилучший способ отображения сообщения обмена на веб-странице ASP.net?

Question

У меня есть список действий, происходящих на предмет, указанный на веб-сайте ASP.net. Эти действия регистрируются в простой таблице sql, связанной с элементом. т.е .:

[2013-11-04 18:00]: Problem solved 
[2013-11-04 18:00]: Called User 
[2013-11-04 14:00]: Mail Received 

Для этого я должен запросить поддержки почтового ящика для новых почтовых сообщений. Когда получено новое сообщение, создается «полученное письмо». Запись «Полученная почта» должна быть доступна, чтобы пользователь мог видеть содержимое этого сообщения.

Вопрос: Как это показать это сообщение для пользователя поддержки?

Использование Exchange Webservices Управляемый API 2.0 Я могу найти это сообщение и его тело, но тело сообщения может иметь встроенные изображения и другие макеты.

Варианты:

1. Показать сообщение на веб-странице попытаться оказать почтовое сообщение лучший способ, которым я могу.
   -> Есть ли свободные плагины, которые это делают? Что-то вроде this, но которые могут быть использованы на веб-странице?
   

2. Используйте Outlook, чтобы отобразить это сообщение электронной почты.

2 комбинированный .. покажите предварительное текстовое сообщение и нажмите, чтобы просмотреть все сообщение, используя Outlook.

Поскольку у пользователя поддержки будет установлен Outlook 2010 или выше на его машине, 3-й вариант кажется логичным выбором, но как я могу отобразить это сообщение в Outlook?

@{ 
    HttpContext.Current.Response.AddHeader("Content-disposition", "inline;filename=message.msg"); 
    HttpContext.Current.Response.ContentType = "application/vnd.ms-outlook"; 
} 
@(new HtmlString(ViewBag.Body)) 

Очевидно, что это не работает. Файл .msg кажется двоичным. Нужен ли мне API для этого?

Но даже если это работает у меня будет эти проблемы:

1. Каждый раз, когда вы открываете сообщение, вам нужно будет нажать на кнопку «Открыть», чтобы просмотреть это сообщение.
   -> Могу ли я предотвратить это в современных браузерах (в первую очередь IE10 & IE11)?
   -> Или доступны ли встроенные зрители просмотра?
2. Когда эта поддержка пользователя отвечает на это сообщение, используя его прогноз, это сообщение будет отправлено «из» его учетной записи. Не было бы следов этого отправленного сообщения!
   -> Кто-нибудь может подумать об этом?

Мы используем локальный сервер Exchange 2010 с пакетом обновления 3 (SP3), который должен быть перенесен в Exchange Online через некоторое время в следующем году. Приложение работает на ASP.NET 4.5 с использованием среды MVC 5.0.

Answer 1

Это может быть решением использовать этот API, чтобы download messages as .msg file directly from Exchange server

Answer 2

Тинкер с различными типами тела и методами извлечения. Информация здесь:

http://msdn.microsoft.com/en-us/library/ee217562(v=exchg.80).aspx

Смотрите, если любой из них вернуть то, что это относительно легко показать, будет ли это разбор тела HTML или показывая тело RTF в браузере. Я не так много трахался и не имел сервера Exchange, или я бы проверял себя. Если Exchange не пережевывает HTML-код при отправке сообщения, вы можете проанализировать src = «cid: contentIdOfAttachment» и заменить его на правильную ссылку на вложение для отображения в браузере, но Exchange может сделать смешные вещи для HTML и CSS.

И для пояснения, «пользователь поддержки», вы имеете в виду сотрудника службы поддержки (т. Е. Техническую поддержку) или того, кто получает поддержку и проверяет статус своего билета? Если сообщение должно быть отображено и/или отправлено в Outlook, будет ли этот человек иметь доступ к одному почтовому ящику поддержки (возможно, к общей папке) или будет ли оно отправлено/скопировано в индивидуальный почтовый ящик?

Если я получу это право, вы будете копировать его в отдельный почтовый ящик, а оттуда он «выходит за пределы» системы, поэтому ответ направляется прямо к конечному пользователю и пропускает центральный почтовый ящик поддержки. Возможно, вы сможете обойти это, изменив сообщение, прежде чем оно будет отправлено/скачено, изменив «от» на центральный почтовый ящик поддержки. Когда пользователь поддержки отвечает, он возвращается к центральному почтовому ящику поддержки, где вы можете выполнить вторичное действие синхронизации (или даже тот, который получает входящую почту), изменить его в/из, чтобы отправить предполагаемому получателю из центральный почтовый ящик поддержки и отправьте его с помощью UpdateItems и сохраните его в папке «Отправленные». Это некрасиво, но это должно быть возможно. Это, однако, совсем не так, как я могу сказать, это может быть лучшим решением. И я работаю над несколькими предположениями о системе, в которой вы работаете, поэтому, возможно, у меня есть что-то не так.