Интеграция SQL Azure с SharePoint 2010 и Windows Azure
Интеграция SQL Azure с SharePoint 2010 и Windows Azure
Эта запись наиболее полезна при использовании вместе с моей серией из пяти частей о наборе средств CASI (интеграция утверждений, Azure и SharePoint).
· Часть 1: общее введение в платформу и решение в целом, а также описание назначения и содержания этой серии записей.
· Часть 2: руководство по набору средств CASI. Оно начинается с описания процедуры, позволяющей сделать WCF внешним программным интерфейсом для всех ваших данных — включая наборы данных, XML, пользовательские классы или просто HTML-код. На этапе 1 мы берем стандартную службу WCF и включаем в ней поддержку утверждений. Это позволит нам передавать маркер пользователя из SharePoint через границы приложений и центров обработки данных в наши пользовательские приложения WCF. На этапе 2 я рассматриваю список всего того, что необходимо для размещения этого обычного локального приложения WCF в Windows Azure. Результатом является готовый к работе внутренний компонент для поддержки среды с несколькими приложениями, центрами обработки данных и интегрированной проверкой подлинности.
· Часть 3: описывает настраиваемую сборку набора средств, обеспечивающую возможность подключения приложения WCF, поддерживающего утверждения, к облаку и ферме SharePoint. Я расскажу, как использовать эту сборку, какой настраиваемый элемент управления необходимо создать (совсем простой — примерно 5 строк кода) и как разместить его на странице в каталоге _layouts, чтобы иметь возможность загружать и отображать данные веб-части. Будет также представлен полный исходный код для образца настраиваемого элемента управления и страницы _layouts.
· Часть 4: веб-часть, добавленная мною к набору средств CASI. Она содержит готовое, не требующее программирования решение для установления подключения с помощью асинхронного клиентского запроса, позволяющего загрузить данные из службы, размещенной в облаке, и отобразить их в веб-части. В веб-часть также встроены обработчики, позволяющие после небольшой настройки использовать пользовательские функции JavaScript для визуализации данных.
· Часть 5: краткий пошаговый анализ пары примеров приложений, демонстрирующих несколько других сценариев использования созданного настраиваемого элемента управления, описанного в части 3, в паре других типовых сценариев. В одном сценарии с помощью этого элемента управления загружаются некоторые данные пользователя или данные конфигурации. Они сохраняются в кэше ASP.NET, а затем используются в настраиваемой веб-части. В другом сценарии настраиваемый элемент управления используется для загрузки данных из Azure и их использования в конкретной задаче, в данном случае — в настраиваемом задании таймера SharePoint. Здесь же приводится полный код для этих примеров приложений.
Используя набор средств CASI, я предоставил ряд указаний и средств, позволяющих достаточно быстро и легко подключиться к Windows Azure из SharePoint 2010, одновременно отправляя маркер для текущего пользователя, чтобы можно было принимать очень подробные решения, связанные с безопасностью. Исходное приложение WCF, используемое набором средств CASI, просто использовало жестко заданную коллекцию предоставляемых данных. В последующем построении (фактически без документирования в записях набора средств CASI) я обновил часть, относящуюся к данным, чтобы она сохраняла и загружала данные, используя хранилище таблицы Windows Azure. Теперь я еще немного улучшил ее за счет создания данных в SQL Azure и использования созданного приложения WCF в Windows Azure для загрузки этих данных. Теперь это действительно многооблачный набор приложений: Windows Azure, SQL Azure и (по-видимому) SharePoint Online. Цель этой записи блога — просто дать несколько советов по работе с SQL Azure, чтобы ускорить включение этого решения в разрабатываемые проекты.
Советы по интеграции
1. Чтобы открывать базы данных SQL Azure с помощью средства SQL Server Management Studio, фактически необходимо выполнить обновление до SQL 2008 R2. Технически можно использовать и SQL Server 2008, но для этого потребуется выполнить множество обходных действий. 2008 R2 предоставляет эти возможности в готовом виде, резко упрощая необходимые действия. Если действительно требуется воспользоваться обходным решением для 2008, воспользуйтесь следующей ссылкой: https://social.technet.microsoft.com/wiki/contents/articles/developing-and-deploying-with-sql-azure.aspx. Эта статья содержит ряд действительно хороших советов, поэтому ее стоит прочитать в любом случае.
2. Планируйте использование T-SQL для выполнения всех действий. Графические средства недоступны для работы с базами данных, таблицами, хранимыми процедурами и другими элементами SQL Azure. И снова, не будучи специалистом по T-SQL, я нашел удобное решение — просто создать сначала локальную базу данных SQL Server. Используя средство SQL Management, я создаю два подключения — одно к своему локальному экземпляру SQL, а другое к своему экземпляру SQL Azure. Я создаю таблицы, хранимые процедуры и т. д. в локальном экземпляре SQL, что позволяет мне использовать графические средства. Затем я использую окно создания скрипта SQL-запроса [для любого объекта SQL] As…CREATE to…New. При этом создается скрипт SQL для создания моих объектов, который затем я могу вставить в окно запроса, открываемого для моей базы данных SQL Azure.
3. Важный момент — время ожидания по умолчанию часто недостаточно для подключения к SQL Azure. Его можно изменить, используя классы .NET SqlClient в строке подключения, то есть добавляя "Connection Timeout=30;". При использовании SQL Server Management Studio щелкните кнопку "Дополнительно" в диалоговом окне ввода имени сервера и учетных данных и измените соответствующее значение, как минимум, на 30. Значение по умолчанию, 15 секунд, часто приводит к отказу, но 30 секунд, по-видимому, будет вполне достаточно. К сожалению, не существует способа изменить время ожидания для подключения к источнику данных SQL Azure при внешнем типе контента (т. е. определение приложения подключения к бизнес-данным).
4. Не используйте для подключения к своим базам данных учетную запись администратора базы данных (т. е. учетную запись, используемую для создания самой базы данных). Для работы с данными создайте отдельную учетную запись. К сожалению, SQL Azure поддерживает только учетные записи SQL, поэтому нельзя напрямую использовать удостоверение запрашивающего пользователя для принятия решений о доступе к данным. Это можно обойти, используя приложение WCF, служащее внешним программным интерфейсом для данных в SQL Azure, и используя проверку подлинности на основе удостоверений в Windows Azure, которая точно совпадает с моделью, используемой набором средств CASI. Кроме того, понадобится несколько шагов для создания входа в систему, который можно использовать для подключения к данным конкретной базы данных. Вот соответствующий пример:
--сначала создадим базу данных
CREATE DATABASE Customers
--теперь создадим учетную запись для входа в систему, а затем соответствующего пользователя в базе данных
CREATE LOGIN CustomerReader WITH PASSWORD = 'FooBarFoo'
CREATE USER CustomerReader FROM LOGIN CustomerReader
--теперь предоставим права пользователю
GRANT INSERT, UPDATE, SELECT ON dbo.StoreInformation TO CustomerReader
--предоставим права EXECUTE хранимой процедуре
GRANT EXECUTE ON myStoredProc TO CustomerReader
Дополнительные примеры и сведения, включая задание прав уровня сервера для учетных записей в SQL Azure, см. по адресу https://msdn.microsoft.com/en-us/library/ee336235.aspx.
5. Необходимо создать правила брандмауэра в SQL Azure для каждой имеющейся базы данных, чтобы разрешить взаимодействие с различными клиентами. Если нужно разрешить взаимодействие с другими службами Azure, необходимо сначала создать правило брандмауэра MicrosoftServices (предлагаемое SQL Azure при первом создании базы данных), начальным диапазоном для которого является от 0.0.0.0 до 0.0.0.0. Если это правило не создано, ни одно из приложений Windows Azure не сможет читать, добавлять или изменять данные в используемых базах данных SQL Azure! Также необходимо создать правило брандмауэра, разрешающее взаимодействие с сервером (серверами), используемыми для маршрутизации в Интернет. Например, при использовании кабельного или DSL-маршрутизатора либо RRAS-сервера нужно применить внешний адрес или адрес NAT (преобразование сетевых адресов) для чего-то, подобного RRAS.
Ниже приведено несколько полезных советов по получению данных и работы с ними.
Доступ к данным
Доступ непосредственно к данным из пользовательского кода — WCF в Windows Azure, веб-части и т. д. — к счастью, практически не отличается от загрузки данных с локального сервера SQL Server. Вот небольшой пример кода, и позже я рассмотрю некоторые из его частей немного подробнее:
//зададим более длинное время ожидания, так как 15 секунд часто
//недостаточно, в документации SQL Azure рекомендуется 30
private string conStr = "server=tcp:foodaddy.database.windows.net;Database=Customers;" +
"user ID=CustomerReader;Password=FooBarFoo;Trusted_Connection=False;Encrypt=True;" +
"Connection Timeout=30";
private string queryString = "select * from StoreInformation";
private DataSet ds = new DataSet();
using (SqlConnection cn = new SqlConnection(conStr))
{
SqlDataAdapter da = new SqlDataAdapter();
da.SelectCommand = new SqlCommand(queryString, cn);
da.Fill(ds);
//выполним что-нибудь с данными
}
Фактически, кроме строки подключения, здесь нет ничего, заслуживающего объяснения. Главное, на что стоит обратить внимание, — это возможные отличия от типичного подключения к локальному серверу SQL Server:
· server: предшествует имени базы данных SQL Azure с “tcp:”.
· Trusted_Connection: должно быть равно false, так как встроенные средства безопасности не используются
· Encrypt: должно быть равно true для всех подключений к размещенной в облаке базе данных
· Connection Timeout: как описано выше, время ожидания по умолчанию равно 15 секундам и часто является недостаточным, поэтому здесь оно устанавливается равным 30 секундам.
Другим сценарием, который я хочу коротко здесь упомянуть, является перенос данных. Для перемещения данных с локального сервера SQL Server в SQL Azure можно использовать средство BCP, поставляемое с SQL Server. Базовая процедура для переноса данных выглядит следующим образом:
1. Создайте файл форматирования — он используется как для экспорта локальных данных, так и для их импорта в облако. В этом примере я создаю файл форматирования для таблицы Region в базе данных Test и сохраняю его в файл region.fmt.
bcp Test.dbo.Region format nul -T -n -f region.fmt
2. Экспортируйте данные из локальной базы данных SQL — в этом примере я экспортирую таблицу Region базы данных Test в файл с именем RegionData.dat. Я использую файл форматирования region.fmt, созданный в шаге 1.
bcp Test.dbo.Region OUT RegionData.dat -T -f region.fmt
3. Импортируйте данные в SQL Azure. Основной момент, который здесь нужно отметить, состоит в том, что при импорте данных в облако НЕОБХОДИМО включить “@имяСервера” с параметром имени пользователя, без него импорт завершится с ошибкой. В этом примере я импортирую данные в таблицу Region базы данных Customers в SQL Azure. Для импорта я использую файл RegionData.dat, в который были экспортированы мои локальные данные. Имя моего сервера (параметр -S) — это имя базы данных SQL Azure. Для своего имени пользователя (параметр -U) я использую формат имя_пользователя@имя_сервера, как описано выше. Я предписываю использовать файл форматирования region.fmt, созданный в шаге 1, и задаю размер пакета (параметр -b) равным 1000 записей в одном пакете.
bcp Customers.dbo.Region IN RegionData.dat -S foodaddy.database.windows.net -U speschka@foodaddy.database.windows.net -P FooBarFoo -f region.fmt -b 1000
На этом данная запись заканчивается. Надеюсь, она дает хорошее представление об основных механизмах создания базы данных SQL Azure, подключения к ней и использования ее на веб-сайте SharePoint. Стоит заметить, что я использовал набор средств CASI, чтобы загрузить эти данные с помощью своего внешнего программного интерфейса WCF для Windows Azure из SQL Azure и отобразить их на своем веб-сайте SharePoint. При создании и проверке всего описанного я следовал рекомендациям, опубликованным в моем блоге о наборе средств CASI, и все вполне сошлось. В части 3 я внес пару незначительных исправлений, а также добавил краткий раздел по устранению неполадок. Но в общей сложности мне потребовалось около 30 минут на создание нового настраиваемого элемента управления и, возможно, 15 минут для создания новой визуальной веб-части. Я использовал веб-часть набора средств CASI для отображения одного набора данных SQL Azure из WCF, и в визуальной веб-части я программно создал экземпляр настраиваемого элемента управления для загрузки набора данных, а затем связал его с таблицей ASP.NET. Я собрал все вместе на одной странице, которая вполне прилично выглядит и может быть легко расширена для отображения данных множеством различных способов. Вот на что это похоже:
Это локализованная запись блога. Исходная статья находится по адресу Integrating SQL Azure with SharePoint 2010 and Windows Azure