Набор средств интеграции утверждений, Azure и SharePoint (часть 4)

Набор средств интеграции утверждений, Azure и SharePoint (часть 4)

Это четвертая часть серии записей из пяти частей, посвященных набору средств CASI (Утверждения, Azure и интеграция с SharePoint) Kit. В Часть 1 представлен вводный обзор всей платформы и решения, а также описание всех компонентов, которые будут тестироваться и рассматриваться в этой серии. В Часть 2 представлено руководство по созданию приложений WCF, настройке для них поддержки утверждений и последующему их перемещению в Windows Azure. В Часть 3 рассматривается базовый класс, который используется для заполнения сайта SharePoint данными Azure путем добавления нового пользовательского элемента управления на страницу в каталоге "_layouts". В этой записи мы рассмотрим веб-часть, представленную в рамках этой платформы. Она разработана специально для использования с пользовательским элементом управления, созданным и добавленным на страницу макетов в третьей части.

Использование веб-части

Перед использованием веб-части необходимо: а) располагать работоспособной службой WCF, размещенной в Windows Azure и б) предварительно создать пользовательский элемент управления и добавить его на страницу макетов, как описано в третьей части этой серии записей. Предполагается также, что вы выполнили развертывание как сборки базового класса CASI Kit, так и сборки пользовательского элемента управления в глобальный кэш сборок на каждом сервере в ферме SharePoint. Также предполагается, что выполнено развертывание пользовательской страницы aspx, на которой размещен пользовательский элемент управления, в каталог макетов на каждом сервере веб-интерфейса в ферме. Чтобы познакомить вас со способами использования веб-части, я использую пример проекта AzureWcfPage, который я загрузил как приложение к третьей части записи блога. Теперь давайте рассмотрим способы создания связей между этими двумя элементами для отображения данных из Azure на сайте SharePoint.

ПРИМЕЧАНИЕ. Хотя это не обязательное требование, обычно намного проще использовать веб-часть в тех случаях, если вызываемые методы WCF возвращают HTML, благодаря чему отображение осуществляется непосредственно на странице без дальнейшей обработки.

Первым делом необходимо выполнить развертывание решения AzureRender.wsp в ферме; WSP-файл включен в ZIP-файл в приложении к этой записи блога. В нем содержится компонент, который выполняет развертывание веб-части Azure DataView и jQuery 1.4.2 в каталог макетов. После выполнения развертывания решения и активации компонента для семейства сайтов можно добавить веб-часть на страницу. На этом этапе все уже практически готово к началу визуализации данных из Azure, однако необходимо задать еще как минимум одно свойство. Поэтому далее мы рассмотрим, какое значение имеют это свойство и другие свойства для веб-части.

Свойства веб-части

Все свойства веб-части указаны в разделе "Свойства подключения". Необходимо задать как минимум одно свойство страницы данных для страницы макетов, создание и развертывание которой вы выполнили. Например, /_layouts/AzureData.aspx. Если серверным тегом для пользовательского элемента управления определены хотя бы свойства WcfUrl и MethodName, дополнительные действия от вас не требуются. Если вы больше ничего не делали, веб-часть вызовет страницу и использует конечную точку WCF и метод, настроенный на странице, после чего визуализирует в веб-части любые данные, возвращаемые методом (он специально возвращает их в формате HTML). Тем не менее в большинстве случаев рекомендуется использовать некоторые другие свойства веб-части для достижения большей гибкости. Рассмотрим каждое из этих свойств в отдельности:

· Имя метода* — имя метода приложения WCF, который требуется вызвать. Если необходимо вызвать страницу макетов с собственной функцией javascript, в качестве параметра строки запроса для этого свойства используется “methodname”.

· Список параметров* — список параметров для метода WCF, разделенных точкой с запятой. Как уже говорилось во второй и третьей частях этой серии, поддерживаются только базовые типы данных — строковый, логический, целое, " длинное целое" и "дата и время". Если требуется использовать более сложные типы данных, необходимо сначала выполнить их десериализацию, после чего вызвать метод и повторно выполнить сериализацию в сложный тип в конечной точке WCF. Если требуется вызвать страницу макетов с собственной функцией javascript, в качестве параметра строки запроса для этого свойства используется “methodparams”.

· Адрес обратного вызова при успешном выполнении — функция javascript, обратный вызов которой выполняется после успешного выполнения запроса jQuery для страницы макетов. По умолчанию это свойство использует функцию javascript, поставляемую в составе веб-части. При использовании собственной функции ее подпись будет выглядеть следующим образом: function yourFunctionName(resultData, resultCode, queryObject). Дополнительные сведения см. в документации jQuery AJAX по адресу: https://api.jquery.com/jQuery.ajax/.

· Адрес обратного вызова при возникновении ошибки — функция javascript, обратный вызов которой выполняется в случае возникновения ошибки при выполнении запроса страницы макетов jQuery. По умолчанию это свойство использует функцию javascript, поставляемую в составе веб-части. При использовании собственной функции ее подпись будет выглядеть следующим образом: function yourFunctionName(XMLHttpRequest, textStatus, errorThrown). Дополнительные сведения см. в документации jQuery AJAX по адресу: https://api.jquery.com/jQuery.ajax/.

· Стандартное сообщение об ошибке — сообщение, отображаемое в веб-части при возникновении ошибки во время обработки веб-части на стороне сервера. То есть, оно НЕ включает сценарии, в которых данные фактически извлекаются из Azure.

· Сообщение об отказе в доступе* — сообщение об ошибке "Отказано в доступе", отображаемое в случае отказа пользователю в доступе к конкретному методу. Например, как разъясняется в части 2 этой серии записей блога, поскольку маркер пользователя передается совместно с вызовом WCF, можно включить в любой метод запрос PrincipalPermission, например “этот пользователь должен принадлежать к группе "Менеджеры по продажам"”. Если пользователь не соответствует критериям запроса PrincipalPermission, происходит сбой вызова WCF и выводится сообщение об ошибке "Отказано в доступе". В этом случае веб-часть отобразит сообщение об отказе в доступе с соответствующим текстом. Обратите внимание, что в этом сообщении можно использовать расширенное форматирование, например использовать полужирный шрифт или выделить текст красным цветом, используя теги HTML (т.е. <font color='red'>Доступ запрещен. Обратитесь к администратору</font>). Если требуется вызвать страницу макетов с собственной функцией javascript, в качестве параметра строки запроса для этого свойства используется “accessdenied”.

· Сообщение о тайм-ауте* — сообщение, отображаемое в случае возникновения ошибки времени ожидания при попытке выполнения вызова метода WCF. В этом сообщении также доступны функции расширенного форматирования, например использование полужирного шрифта, выделение текста красным цветом и т. д. Если необходимо вызвать страницу макетов с собственной функцией javascript, в качестве параметра строки запроса для этого свойства используется “timeout”.

· Показать ссылку " Обновить" — установите этот флажок для отображения значка обновления над результатами для данных Azure. При щелчке этого значка будет повторно выполнен метод WCF для получения последних данных.

· Обновить стиль — позволяет добавлять дополнительные атрибуты стиля в главный атрибут Style тега IMG, который используется для отображения ссылки на обновление. Например, с помощью этого свойства можно добавить “float:right;”, чтобы выровнять обновленное изображение по правому краю.

· Кэшировать результаты — установите этот флажок, чтобы библиотека jQuery выполняла кэширование результатов запроса. Это означает, что при каждой загрузке страницы будет использоваться кэшированная версия результатов запроса. Это позволит избежать постоянного обращения к Azure, что обеспечит более высокое быстродействие для конечных пользователей. Если извлекаемые данные не обновляются часто, рекомендуется выбрать функцию кэширования результатов.

· Декодировать результаты* — установите этот флажок, если приложение WCF возвращает результаты, закодированные с использованием HtmlEncoded. Если для этого свойства установлено значение true, для этих результатов применяется HtmlDecoding. В большинстве случаев это делать не требуется. Если требуется вызвать страницу макетов с собственной функцией javascript, в качестве параметра строки запроса для этого свойства используется “encode”.

* — эти свойства игнорируются, если для свойства пользовательского элемента управления AllowQueryStringOverride установлено значение false.

Пример типичного использования

Предположим, метод WCF возвращает HTML. В большинстве случаев рекомендуется добавить веб-часть на страницу и задать два или три свойства: страницу данных, имя метода и, возможно, список параметров.

При наличии дополнительных требований к отображению или обработке данных, возвращаемых Azure, рекомендуется использовать для этого пользовательскую функцию javascript. В этом случае необходимо добавить функцию javascript на страницу и задать свойство Success Callback Address для имени функции javascript. Если для веб-части требуются дополнительные записи в приложение WCF, например, для добавления, обновления или удаления данных, необходимо добавить их в собственные функции javascript и выполнить вызов страницы пользовательских макетов с соответствующими значениями имени метода и списка параметров; имена переменных строк запроса, которые необходимо использовать, указаны выше. При вызове метода ajax в jQuery для вызова страницы макетов рекомендуется использовать подход, аналогичный используемому для веб-части. Используемое соглашение о вызовах основано на функции скрипта, приведенной ниже; обратите внимание, что вы скорее всего и дальше будете использовать приведенное здесь свойство dataFilter, поскольку оно извлекает все выходные данные страницы, которые получены НЕ из метода WCF:

$.ajax({

type: "GET",

       url: "/_layouts/SomePage.aspx",

dataType: "text",

data: "methodname=GetCustomerByEmail&methodparams=steve@contoso.local",

dataFilter: AZUREWCF_azureFilterResults,

success: yourSuccessCallback,

error: yourErrorCallback

});

 

Попробуйте!

Теперь у вас есть все детали головоломки, чтобы опробовать это комплексное решение. В приложении к этой записи блога вы найдете ZIP-файл, в котором содержится решение для веб-части. В следующей, последней записи блога в этой серии мы рассмотрим способы использования пользовательского элемента управления, который разрабатывался в части 2, для извлечения данных из Azure и их использовании в кэше ASP.NET с другими элементами управления; а также способы использования задач SharePoint (в этом примере рассматривается пользовательское задание таймера SharePoint).

Это локализованная запись блога. Исходная статья доступна по адресу The Claims, Azure and SharePoint Integration Toolkit Part 4