Набор средств интеграции утверждений, 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 (1)
  1. anton8090 says:

    Господа! Не могу найти RSS подписку на этот блог, или ее просто нет?

Comments are closed.

Skip to main content