SQL Azure を SharePoint 2010 および Windows Azure と統合する
SQL Azure を SharePoint 2010 および Windows Azure と統合する
この投稿は、CASI (Claims, Azure and SharePoint Integration) キットについて 5 回シリーズで説明した記事の付属資料としてお役立てください。
· パート 1: CASI キットのフレームワークとソリューション全体の概要で、このシリーズで扱う内容について説明します。
· パート 2: CASI キットのガイドラインです。 最初に、WCF をすべてのデータ (データセット、XML、カスタム クラス、または HTML そのもの) のフロント エンドにします。 フェーズ 1 では、標準の WCF サービスを使用し、これをクレーム対応にします。これにより、SharePoint からユーザー トークンを受け取り、それを、アプリケーションの境界やデータ センターの境界を越えてカスタム WCF アプリケーションに送ることができます。 フェーズ 2 では、社内のこの一般的な WCF アプリケーションを Windows Azure でホストするのに必要なすべての操作の一覧を示します。 これが完了すると、統合認証を使用してマルチ アプリケーション、マルチ データ センターをサポートするバックエンドが実現します。
· パート 3: クレームに対応する WCF アプリケーションをクラウドおよび SharePoint ファームに接続する役目を果たすカスタム ツールキット アセンブリについて説明します。 ここでは、アセンブリの使用方法について、具体的には、作成する必要がある非常に簡単なカスタム コントロール (約 5 行のコード) について説明し、Web パーツ内でデータを取得および表示する手段として、これを _layouts ディレクトリ内のページでホストする方法について説明します。 サンプルのカスタム コントロールとレイアウト ページの完全なソース コードも投稿します。
· パート 4: CASI キットに含まれる Web パーツについて説明します。 この Web パーツは、コードが不要でそのまま使用できるソリューションに相当し、非同期のクライアント側クエリに接続して、クラウドでホストされるサービスからデータを取得し、そのデータを Web パーツに表示できます。 フックも組み込まれているため、自由にカスタマイズして、独自の JavaScript 関数を使用してデータを表示できます。
· パート 5: 2 つのサンプル アプリケーションを操作しながら、作成したカスタム コントロールを使用するシナリオについて簡単に説明します。カスタム コントロールの作成については、パート 3 で、別の一般的なシナリオを通じて既に説明しています。 一方のシナリオでは、コントロールを使用してある種のユーザー データまたは構成データを取得し、それを ASP.NET キャッシュに保存して、カスタム Web パーツで使用します。 もう一方のシナリオでは、カスタム コントロールを使用して Azure からデータを取得し、それをカスタム タスク (この例ではカスタムの SharePoint タイマー ジョブ) で使用します。 これらのサンプル アプリケーションの完全なソース コードも投稿します。
CASI キットを通じて、SharePoint 2010 から Windows Azure にすばやく容易に接続するためのガイダンスとツールをいくつか提供しました。また、一方で、現在のユーザーのトークンを送信して、セキュリティ上の決定を非常に高い粒度で行うこともできます。 CASI キットで利用するオリジナルの WCF アプリケーションでは、公開されているデータのハードコードされたコレクションのみを使用しました。 その後のビルド (CASI キットの投稿に記載していませんが) では、データ部分をアップグレードし、Windows Azure のテーブル記憶領域を使用してデータを格納および抽出できるようにしました。 データを SQL Azure に付け足して、そこから Windows Azure の WCF でデータを抽出するようにしたことで、ビルドは大幅に強化されました。 Windows Azure、SQL Azure、および (表面上) SharePoint Online は、まさに、マルチクラウド アプリケーション スイートです。 この投稿の要点は、SQL Azure を開発プロジェクトにより迅速に組み込めるように、SQL Azure の操作上のいくつかのヒントを共有することです。
統合のヒント
1. オープンな SQL Azure データベースを SQL Server Management Studio ツールで使用できるようにするために、SQL 2008 R2 にアップグレードする必要があります。 技術的には SQL Server 2008 でも可能ですが、その場合は、ハッカーからの攻撃に対して一連の対策を講じる必要があります。 SQL Server 2008 R2 にはそれらの対策が既に組み込まれているので、余分な手間を省いて、最初から必要な作業を適切に行えます。 どうしても SQL Server 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 ツールで 2 つの接続を作成します。1 つはローカル SQL インスタンスへの接続、もう 1 つは SQL Azure インスタンスへの接続です。テーブル、ストアド プロシージャなどをローカル SQL インスタンスに作成して、グラフィカル ツールを使用できるようにします。 次に、[スクリプト [任意の SQL オブジェクト] As…CREATE to… の新しい SQL クエリ] (Script [whatever Sql object] As…CREATE to…New Sql Query) ウィンドウを使用します。 これは、オブジェクトを作成する SQL スクリプトを生成します。この SQL スクリプトは、SQL Azure データベースに対して開いているクエリ ウィンドウに貼り付けることができます。
3. 重要ポイント: 既定のタイムアウトでは短すぎて SQL Azure に接続できないことがよくあります。 このタイムアウトは変更できます。.NET SqlClient クラスを接続文字列で使用する、つまり、"Connection Timeout=30;" を追加してください。 SQL Server Management Studio を使用している場合は、サーバー名と資格情報を入力するダイアログで [詳細設定] (Advanced) ボタンをクリックして、タイムアウトを 30 秒以上に変更します。 既定値は 15 秒です。通常これでは接続できませんが、30 秒に変更すると、問題なく接続できるでしょう。 ただし、外部コンテンツ タイプ (BDC アプリケーション定義など) が SQL Azure データ ソースに接続する際の接続タイムアウトは変更できません。
4. データベース管理者アカウント (データベース自体を作成するアカウント) を使用してデータベースに接続しないでください。 データ操作用のアカウントを別に作成します。 ただし、SQL Azure は SQL アカウントしかサポートしないため、要求元ユーザーの ID を直接使用して、データへのアクセスを決定することはできません。 これを回避するには、データのフロントエンドである WCF アプリケーションを SQL Azure で使用し、クレーム認証を Windows Azure で使用します (これはまさに CASI キットで使用するモデルです)。 また、特定のデータベースへの接続用ログインも 2 ～ 3 つの手順で作成できます。 次に例を示します。
-- 最初にデータベースを作成します。
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/ja-jp/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 などに使用できます。
以上、これらのヒントは、データを利用する際にきっと役立つでしょう。
データ アクセス
データにカスタム コード (Windows Azure WCF、Web パーツなど) からアクセスする方法は、設置型 SQL Server からデータを抽出する方法とまったく変わりません。 次に簡単なコード例を示します。このコードの一部について少し詳しく説明します。
//set a longer timeout because 15 seconds is often not
//enough; SQL Azure docs recommend 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);
//do something with the data
}
実際は、接続文字列を除けば、特に詳しい説明は必要ないでしょう。 接続文字列について説明が必要なポイントは、設置型 SQL Server への一般的な接続とは異なる場合があるということです。
· server: SQL Azure データベースの名前を "tcp:" に続けて指定します。
· Trusted_Connection: 統合セキュリティは使用しないので、False に設定してください。
· Encrypt: True に設定して、クラウドでホストされるデータベースへの任意の接続を許可してください。
· Connection Timeout: 前にも説明したように、既定のタイムアウトは 15 秒ですが、これで短いので 30 秒に設定します。
もう 1 つだけ、簡単に説明したいシナリオがあります。それは、データ移行を使用する場合についてです。 SQL Server に付属する BCP ツールを使用して、設置型 SQL Server から SQL Azure にデータを移行できます。 データを移行する基本的な処理は次のようになります。
1. フォーマット ファイルを作成します。このファイルは、ローカル データのエクスポートとクラウドへのインポートに使用します。 この例では、Test データベースの Region テーブル用のフォーマット ファイルを作成して、region.fmt という名前で保存します。
bcp Test.dbo.Region format nul -T -n -f region.fmt
2. ローカル SQL からデータをエクスポートします。この例では、Test データベースの Region テーブルから RegionData.dat というファイルにエクスポートします。 手順 1 で作成したフォーマット ファイル region.fmt を使用します。
bcp Test.dbo.Region OUT RegionData.dat -T -f region.fmt
3. データを SQL Azure にインポートします。 ここでは主に説明が必要な点があります。それは、データをクラウドにインポートするときは、必ず、ユーザー名パラメーターに “@serverName” を含めるということです。これがないとインポートは失敗します。 この例では、SQL Azure の Customers データベースの Region テーブルにデータをインポートします。 ローカル データをエクスポートした RegionData.dat ファイルからインポートします。 サーバー名 (-S パラメーター) は SQL Azure データベースの名前です。 ユーザー名 (-U パラメーター) には、前述の username@servername 形式を使用します。 手順 1 で作成したフォーマット ファイル region.fmt を使用するように設定し、1 回のバッチ処理で扱うサイズ (-b パラメーター) を 1,000 レコードに設定しました。
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 データベースの作成、SQL Azure データベースへの接続、および SharePoint サイトでの SQL Azure データベースの使用上の基本メカニズムを理解するうえで参考にしていただけると幸いです。 補足ですが、CASI キットによって、このデータを Windows Azure WCF フロント エンドを介して SQL Azure に抽出し、SharePoint サイトに表示しました。 SharePoint サイトの作成と、そこに以前公開していたすべての内容の検証は、CASI キットに関する筆者自身のブログに従いました。予想したとおり、作業は全体として順調に進みました。 パート 3 には、わずかですが、いくつかの訂正箇所があり、すぐにトラブルシューティングのセクションを追加しました。 ただし、全体的には、約 30 分で新しいカスタム コントロールを作成し、約 15 分で新しい視覚的 Web パーツを作成しました。 CASI キットの Web パーツを使用して WCF から SQL Azure データのセットを表示しました。また、視覚的 Web パーツ内で、カスタム コントロールのインスタンスをプログラムで作成してデータセットを抽出し、そのデータセットを ASP.NET グリッドにバインドしました。 これらを 1 つにまとめてサンプル ページに表示してみましたが、とてもいい感じですね。また、このサンプル ページを拡張して、データを別のいくつかの形式で表示するのも非常に簡単です。 サンプル ページは次のようになります。
これはローカライズされたブログ投稿です。原文の記事は、「Integrating SQL Azure with SharePoint 2010 and Windows Azure」をご覧ください。