Набор средств интеграции утверждений, 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

Comments

  • Anonymous
    January 18, 2011
    Господа! Не могу найти RSS подписку на этот блог, или ее просто нет?
  • Last updated on