Элемент управления ReportViewer и SQL SessionState в режиме удаленного сервера SSRS - PullRequest
1 голос
/ 06 июня 2011

У меня проблема с тем, как элемент управления ReportViewer использует SessionState.

Справочная информация. У нас есть приложение .NET 3.5 WebForms, которое использует ReportViewerControl в режиме RemoteServer

Поскольку наше приложение использует инфраструктуру, для которой требуется SessionState (с использованием SQL Persistence), похоже, элемент управления ReportViewer также подключается к SessionState.

Использование состояния сеанса RV проблематично:

  1. это немедленно требует дополнительных 9k сериализации (в dbo.ASPStateTempSessions)
  2. После отображения отчета все последующие страницы десериализуют состояние сеанса RV (т. Е. Каждую страницу, даже если на ней нет элемента управления ReportViewer). Это включает в себя сериализацию учетных данных, используемых для подключения к серверу SSRS.

В какой-то момент позже это неизбежно приведет к исключению rsExecutionNotFound, когда SSRS очистит выполнение на своей стороне. (Выполнение отчета xyz истекло или не может быть найдено)

Как другие решили это довольно грубое поведение SessionState с помощью RV?

В настоящее время предполагается, что RV вообще не может использовать SessionState, например, создав отдельное ASP-приложение для RV, а затем вставьте элемент управления RV в наше приложение.

В качестве альтернативы, есть ли способ перехватить проблему десериализации SessionState и затем удалить ключи RV?

Любой совет, который высоко ценится!

Edit:

Вероятно, проблема десериализации SessionState не возникает, если SessionState поддерживается в Process with IIS.

При использовании Fiddler во время десериализации SessionState наблюдается несколько подключений к SSRS, даже если страница не имеет элемента управления RV (предположительно, «сеттеры» на сериализованных объектах RV и учетные данные фактически повторно подключаются к SSRS)

Однако удаление ключей RV из SessionState в то время как на экране мешает работе функции управления Ajax RV, такой как подкачка страниц (т. Е. Мы не можем просто собирать ExecutionIds из RV и удалять их по мере их использования).

Единственное решение ATM состоит в том, чтобы реализовать «взлом», при котором ключи RV удаляются из SessionState на страницах, которые не имеют элемента управления RV (в надежде, что если пользователь уйдет со страниц отчета, мы сможем очистить его). ПЕРЕД тайм-аутом SSRS) и перехватывать AspNetSessionExpiredException и ReportServerException в global.asax Application_Error, отменять и очищать сеанс и перенаправлять пользователя на вход в систему (в случае, если пользователь оставляет экран RV открытым и время ожидания истекло). К сожалению, удаление данных непосредственно из dbo.ASPStateTempSessions убивает наш собственный SessionState (отмечая, что, как только SSRS истекает сеанс или удаляет выполнение, SessionState больше не может быть десериализован)

Такое поведение наблюдается как в RV2008, так и в RV2010 (с SSRS 2008R2)

...