Набор средств интеграции утверждений, Azure и SharePoint (часть 5)
Набор средств интеграции утверждений, Azure и SharePoint (часть 5)
Это последняя часть серии из пяти частей, посвященной набору средств CASI (Утверждения, Azure и интеграция с SharePoint) Kit. В Часть 1 представлен вводный обзор всей платформы и решения, а также описание всех компонентов, которые будут тестироваться и рассматриваться в этой серии. В Часть 2 представлено руководство по созданию приложений WCF, настройке для них поддержки утверждений и последующему их перемещению в Windows Azure. В Часть 3 рассматривается базовый класс, который используется для заполнения сайта SharePoint данными Azure путем добавления нового пользовательского элемента управления на страницу в каталоге "_layouts". В Часть 4 рассматривается веб-часть, в которую включен набор средств CASI Kit, способы ее использования, различные ее свойства и т. д. В этой последней записи блога подробно рассматриваются два других основных сценария для этого набора средств — использование пользовательского элемента управления, построение которого рассматривалось в части 3, для извлечения данных Azure, их сохранения в кэше ASP.NET и последующего использования с другими элементами управления; а также использование пользовательского элемента управления в задаче SharePoint — в этом случае рассматривается пользовательское задание таймера SharePoint.
Использование элемента управления в других веб-частях
Один из ключевых сценариев, для которого требуется поддержка — использование платформы CASI Kit для извлечения данных с последующим их использованием в других веб-частях SharePoint. При этом остается еще одна цель разработки, которая заключается в том, чтобы НЕ выполнять обычные серверные вызовы процедуры для потенциально скрытых удаленных конечных точек WCF. В целях соответствия этими двум противоположными критериям в базовом классе реализована поддержка извлечения и сохранения данных непосредственно в кэш ASP.NET. Это позволяет разрабатывать другие пользовательские веб-части по простому образцу:
1. Проверьте, присутствуют ли ваши данные в кэше ASP.NET.
a. Если да, выполните их извлечение
b. В противном случае:
I. Создайте экземпляр пользовательского элемента управления
II. Присвойте значение OutputType параметру ServerCache и установите соответствующие значения для параметров ServerCacheName и ServerCacheTime
III. Выполните вызов метода ExecuteRequest и получите соответствующие данные
Для начала выполните запуск нового проекта Visual Studio — в этом случае речь идет о Visual Studio 2010, чтобы можно было создать новый проект SharePoint 2010. Выполните настройку проекта для создания новой веб-части, после чего необходимо добавить две ссылки — ссылку на базовый класс CASI Kit и ссылку на один из пользовательских элементов управления, создание которых рассматривалось в части 3. Обратите внимание, что при отсутствии ссылки на базовый класс CASI Kit во время тестирования и установки любых свойств элемента управления в Visual Studio эти свойства будут подчеркнуты красной волнистой линией и отобразится сообщение о том, что не удалось найти соответствующее свойство. При возникновении такой ошибки сразу будет понятно, что вы еще не добавили ссылку на базовый класс CASI Kit.
После завершения настройки ссылок можно приступать к написанию любого кода, требуемого для веб-части. На том этапе, когда требуется извлечь данные из Azure (контент или сведения о конфигурации и т. д.), ознакомьтесь с приведенным ниже описанием реализации вышеописанного способа:
string CACHE_NAME = "AzureConfigConsumerCacheSample";
int CACHE_TIME = 10;
//создаем переменную данных конфигурации того типа, который требуется загрузить
AzureWcfPage.CustomersWCF.Customer[] Customers = null;
//ищем элемент в кэше
if (HttpContext.Current.Cache[CACHE_NAME] != null)
{
//если элемент найден, приводим его к нужному типу и выполняем извлечение из кэша
Customers =
(AzureWcfPage.CustomersWCF.Customer[])
HttpContext.Current.Cache[CACHE_NAME];
}
else
{
//если элемент отсутствует в кэше, извлеките его и поместите в кэш
//создание экземпляра элемента управления
AzureWcfPage.WcfDataControl cfgCtrl = new AzureWcfPage.WcfDataControl();
//задание свойств для извлечения данных
cfgCtrl.WcfUrl = "https://azurewcf.vbtoys.com/Customers.svc";
cfgCtrl.OutputType = AzureConnect.WcfConfig.DataOutputType.ServerCache;
cfgCtrl.ServerCacheName = CACHE_NAME;
cfgCtrl.ServerCacheTime = CACHE_TIME;
cfgCtrl.MethodName = "GetAllCustomers";
//выполнение метода
bool success = cfgCtrl.ExecuteRequest();
if (success)
{
//получение строго типизированной версии данных
//тип данных должен исходить из создаваемого элемента управления
Customers =
(AzureWcfPage.CustomersWCF.Customer[])cfgCtrl.QueryResultsObject;
//если требуется XML-репрезентация объекта, можно получить
//ее из объекта QueryResultsString
string stringCustomers = cfgCtrl.QueryResultsString;
}
else
{
//возникли какая-то проблема; необходимо подключить здесь обработчик ошибок
}
}
Давайте рассмотрим код более подробно. Для начала нужно понимать, что в новой веб-части НЕ требуется добавлять в конечной точке WCF ссылку на службу. Все это уже встроено в пользовательский элемент управления, поэтому можно использовать возвращаемые типы приложения WCF, предоставляемые посредством пользовательского элемента управления. Это показано в следующей строке кода:
//создаем переменную данных конфигурации того типа, который требуется загрузить
AzureWcfPage.CustomersWCF.Customer[] Customers = null;
В этом примере в качестве моей сборки пользовательского элемента управления выступает AzureWcfPage. CustomersWCF — имя, которое я присвоил для ссылки на службу WCF. Customer является типом класса, возвращаемым методом WCF. Все это включается в новую веб-часть при добавлении ссылки на сборку пользовательского элемента управления
Первым делом я проверил наличие своих данных в кэше; если они там, то я просто помещаю их в массив экземпляров Customer, сохраненных туда ранее. В противном случае следует просто написать семь строк кода, чтобы создать экземпляр пользовательского элемента управления и извлечь данные. Сделайте следующее:
a. Создайте новый экземпляр элемента управления
b. Задайте свойства WcfUrl, MethodName, OutputType, ServerCacheName и ServerCacheTime
c. Вызовите метод ExecuteRequest
Вот и все. Если метод выполняется успешно, значение, возвращаемое из приложения WCF, сохраняется в кэш ASP.NET, так что при следующем исполнении этого кода элемент будет найден в кэше. Тем временем я могу поместить локальную переменную Customers в свойство QueryResultsObject пользовательского элемента управления, после чего можно выполнять в отношении данных любые действия, которые требуются для веб-части. В целом выполнение этой процедура должно быть относительно простым для большинства разработчиков веб-частей.
Использование элемента управления в задаче
Теперь я расскажу о способах применения пользовательского элемента управления, разработкой которого мы занимались в третьей части, для извлечения контента или данных конфигурации из Azure для последующего использования в задаче. В этом примере я написал пользовательское задание таймера SharePoint и теперь в рамках этого задания собираюсь извлечь некоторые данные из Azure. Данный пример во многом сходен с вышеописанной веб-частью, но в этом случае, как и в случае с многими другими задачами, отсутствует HttpContext, что делает невозможным использование кэша ASP.NET. В таком случае для свойства OutputType используется значение None, поскольку отображение его на странице или сохранение в кэш не требуется; вместо этого мы просто извлекаем каталог значений из QueryResultsObject или QueryResultsString. Здесь представлен пример соответствующего кода — это код из переопределения метода Execute в классе моего пользовательского задания таймера:
SPWebApplication wa = (SPWebApplication)this.Parent;
//создание экземпляра элемента управления
AzureWcfPage.WcfDataControl cfgCtrl = new AzureWcfPage.WcfDataControl();
//задание свойств для извлечения данных
cfgCtrl.WcfUrl = "https://azurewcf.vbtoys.com/Customers.svc";
cfgCtrl.OutputType = AzureConnect.WcfConfig.DataOutputType.None;
cfgCtrl.MethodName = "GetAllCustomers";
//поскольку в такой задаче, как задание таймера, отсутствует контекст http, также необходимо
//указать URL-адрес для сайта SharePoint с поддержкой утверждений. Этот адрес также будет использоваться
//для подключения к конечной точке службы маркеров безопасности в ферме SharePoint
cfgCtrl.SharePointClaimsSiteUrl = wa.Sites[0].RootWeb.Url;
//выполнение метода
bool success = cfgCtrl.ExecuteRequest();
//проверка успешности выполнения
if (success)
{
//теперь извлекайте данные и делайте с ними, что угодно
AzureWcfPage.CustomersWCF.Customer[] Customers =
(AzureWcfPage.CustomersWCF.Customer[])cfgCtrl.QueryResultsObject;
string AzureResults = cfgCtrl.QueryResultsString;
//именно здесь вы впоследствии будете выполнять задачи на основе данных, полученных из Azure
foreach(AzureWcfPage.CustomersWCF.Customer c in Customers)
{
Debug.WriteLine(c.Email);
}
Debug.WriteLine(AzureResults);
}
else
{
//примите меры для занесения в журнал того факта, что извлечение данных не было выполнено
}
Далее представлено более подробное разъяснение по этому коду. Задание таймера относится к области веб-приложения, поэтому я начну с получения ссылки на SPWebApplication, для чего запускается это задание посредством ссылки на свойство Parent. После этого я создаю пользовательский элемент управления, который разработал в третьей части, и задаю минимальный набор свойств, которые необходимы для извлечения данных из Azure. В следующей строке кода мне нужно задать свойство SharePointClaimsSiteUrl. Как я уже объяснил ранее в третьей части, когда базовый класс CASI Kit выполняется в методе ExecuteRequest, он выполняет поиск доступного контекста HttpContext. При обнаружении такого контекста он используется для определения текущего URL-адреса сайта SharePoint и выполняет подключение к службе маркеров безопасности SharePoint через этот сайт. Как уже описано выше, при выполнении этого кода в задаче, как правило, не используется контекст HttpContext. В таком случае базовому классу не удается определить, какой URL-адрес должен использоваться для подключения к службе маркеров безопасности SharePoint, поэтому в данном случае необходимо указать URL-адрес сайта в веб-приложении с поддержкой утверждений. Предполагается, что в этой реализации код задания таймера будет исполняться ТОЛЬКО в веб-приложениях с поддержкой утверждений. Поэтому я получаю ссылку на текущее веб-приложение, после чего просто указываю для нее URL-адрес первого семейства сайтов. На самом деле неважно, какое именно семейство сайтов будет использовано. Достаточно, чтобы оно просто принадлежало веб-приложению с поддержкой утверждений.
После того задания свойства SharePointClaimsSiteUrl я могу выполнить вызов метода ExecuteRequest, как было показано ранее. В случае успешного выполнения вызова я могу извлечь данные из элемента управления непосредственно с помощью свойств QueryResultsObject или QueryResultsString.
В ZIP-файл, присоединенный к этой записи блога, включены оба проекта — веб-части и задания таймера.
Готово!
Это последняя запись блога в данной серии. Надеюсь, теперь вы хорошо разбираетесь в работе с CASI Kit и понимаете, как можно использовать этот набор средств для подключения к данным, размещенным в приложении WCF на сайте или в облаке, имея при этом возможность работать с маркерами удостоверения пользователя в масштабах приложения, и даже в пределах центра обработки данных. В целом этот пример достаточно прост для реализации:
1. Создайте интерфейсное приложение WCF для своего контента или данных конфигурации. Настройте для приложения поддержку утверждений и переместите его в облако (необязательно). Также можно (необязательно) применить детально настроенные разрешения в зависимости от удостоверения и утверждений пользователя, выполняющего вызов.
2. Создайте пользовательский элемент управления, наследующий от базового класса CASI Kit. Переопределите один метод и напишите пять строк кода. Добавьте элемент управления на страницу простых макетов и выполните развертывание.
3. Добавьте веб-часть на страницу, задайте одно или несколько свойств и запустите отображение данных WCF. Элемент управления можно также использовать для извлечения контента или данных конфигурации в пользовательской веб-части или задаче (например, пользовательском задании таймера).
Вот, собственно, и все по данному вопросу. Надеюсь, с помощью CASI Kit вам удастся избежать многих сложностей и проблем, связанных с подключением фермы SharePoint к данным, хранящимся в разных уголках мира. Этот набор средств полезен для извлечения как данных конфигурации или персонализации, так и собственно контента для отображения на сайтах SharePoint. Теперь вы сможете значительно более гибко использовать систему безопасности, реализованную в приложении и в пределах центра данных в корпоративной сети. Мне было очень интересно работать над этим продуктом, и я надеюсь, что он окажется вам полезен. Как всегда, это выпуск 1 продукта, и я уверен, что в дальнейшем мы сможем многое в нем улучшить, поэтому оставляйте свои пожелания в комментариях к этой записи — я буду периодически их просматривать, и они послужат пищей для размышлений в работе над следующим выпуском.
Это локализованная запись блога. Исходная статья доступна по адресу The Claims, Azure and SharePoint Integration Toolkit Part 5