クレームと Azure と SharePoint を統合するツールキット パート 5
クレームと Azure と SharePoint を統合するツールキット パート 5
これは、CASI (Claims, Azure and SharePoint Integration) キットに関する 5 回シリーズのパート 5 です。 パート 1 は CASI キットのフレームワークとソリューション全体の概要で、このシリーズで説明する内容を示しました。 パート 2 では、WCF アプリケーションを作成し、要求に対応するアプリケーションにして、Windows Azure に展開する方法を説明しました。 パート 3 では、_layouts ディレクトリ内のページに新しいカスタム コントロールを追加して SharePoint サイトと Azure データを接続する際に使用する基本クラスについて説明しました。 パート 4 は CASI キットに同梱される Web パーツについて記述したもので、その使用方法やさまざまなプロパティなどについて説明しました。 この最後の投稿では、CASI キットのそれ以外の重要なシナリオを 2 つ説明します。それは、パート 3 で作成したカスタム コントロールを使用して Azure データを取得し、他のコントロールで使用できるよう ASP.NET キャッシュに保存するというシナリオと、カスタム コントロールを SharePoint タスク (今回はカスタムの SharePoint タイマー ジョブ) で使用するというシナリオです。
他の Web パーツでコントロールを使用する
サポートする必要がある重要なシナリオの 1 つは、CASI キットのフレームワークを使用して、他の SharePoint Web パーツで使用するデータを取得するというものです。 しかし、設計目標がもう 1 つ残っています。それは、潜在的リモート WCF エンドポイントでサーバー側呼び出しを繰り返し実行しないようにするということです。 これら 2 つの異なるニーズを満たすため、データを取得して ASP.NET キャッシュに直接保存するためのサポートが基本クラスに実装されています。 これを利用して、他のカスタム Web パーツを作成し、次の非常に単純なパターンに従うことができます。
1. データが ASP.NET キャッシュにあるかどうかを確認する。
a. キャッシュにデータがある場合はそこからデータを取得する。
b. キャッシュにデータがない場合は次の手順を実行する。
i. カスタム コントロールのインスタンスを作成する。
ii. OutputType を ServerCache に設定し、ServerCacheName と ServerCacheTime を適切な値に設定する。
iii. ExecuteRequest メソッドを呼び出してデータを取得する。
まず、新しい Visual Studio プロジェクトを開始します。新しい SharePoint 2010 プロジェクトを作成できるよう、今回は Visual Studio 2010 を使用するものとします。 新しい Web パーツを作成するようプロジェクトを設定したら、2 つの参照を追加する必要があります。1 つは CASI キットの基本クラスへの参照で、もう 1 つはパート 3 で作成したカスタム コントロールへの参照です。 CASI キットの基本クラスへの参照を追加せずにコントロールのいずれかのプロパティを設定しようとすると、Visual Studio でそのプロパティの下に赤い波線が表示され、そのプロパティが見つからないことが示されます。 そのようなエラーが表示された場合は、CASI キットの基本クラスへの参照がまだ追加されていないということがわかります。
参照を設定したら、Web パーツに対して適切であればどのようなコードでも作成できます。 Azure からデータ (コンテンツや構成情報など) を取得する必要が生じた時点で、前述のパターンを実装する方法の例を以下に示します。
string CACHE_NAME = "AzureConfigConsumerCacheSample";
int CACHE_TIME = 10;
//create a var of the type of configuration data we want to retrieve
AzureWcfPage.CustomersWCF.Customer[] Customers = null;
//look for our item in cache
if (HttpContext.Current.Cache[CACHE_NAME] != null)
{
//if we find, it cast it to our type and pull it out of cache
Customers =
(AzureWcfPage.CustomersWCF.Customer[])
HttpContext.Current.Cache[CACHE_NAME];
}
else
{
//if it's not in cache, then retrieve it and put it into cache
//create an instance of the control
AzureWcfPage.WcfDataControl cfgCtrl = new AzureWcfPage.WcfDataControl();
//set the properties to retrieve data
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";
//execute the method
bool success = cfgCtrl.ExecuteRequest();
if (success)
{
//get the strongly typed version of our data
//the data type needs to come from the control we are creating
Customers =
(AzureWcfPage.CustomersWCF.Customer[])cfgCtrl.QueryResultsObject;
//if you wanted the Xml representation of the object you can get
//it from QueryResultsString
string stringCustomers = cfgCtrl.QueryResultsString;
}
else
{
//there was some problem; plug in your error handling here
}
}
コードの一部をもう少し詳しく見てみましょう。 まず、新しい Web パーツでは WCF エンドポイントへのサービス参照を追加する必要がないという点を理解することが重要です。 サービス参照はすべてカスタム コントロールにカプセル化されているので、カスタム コントロールによって公開される WCF アプリケーションの戻り型を使用できます。 それを説明しているのがコードのこの行です。
//create a var of the type of configuration data we want to retrieve
AzureWcfPage.CustomersWCF.Customer[] Customers = null;
この例では、AzureWcfPage がカスタム コントロール アセンブリです。 CustomersWCF は、私が WCF サービス参照に付けた名前です。 Customer は WCF メソッドが返すクラス型です。 参照をカスタム コントロール アセンブリに追加すると、これらすべてが新しい Web パーツに渡されます。
私が作成した最初のチェックでは、データがキャッシュにあるかどうかを確認しています。データがキャッシュにある場合は、以前キャッシュに保存した Customer インスタンスの配列にデータをキャストします。 キャッシュの中にデータがない場合は、カスタム コントロールのインスタンスを作成し、データを取得するのに必要な 7 行のコードを書きます。 次の処理を実行する必要があります。
a. コントロールの新しいインスタンスを作成する。
b. WcfUrl、MethodName、OutputType、ServerCacheName、および ServerCacheTime プロパティを設定する。
c. ExecuteRequest メソッドを呼び出す。
これだけです。 メソッドが正常終了すると、WCF アプリケーションからの戻り値が ASP.NET キャッシュに保存されるので、次にこのコードを実行するときはキャッシュ内にデータが見つかります。 同時に、ローカル変数 Customers をカスタム コントロールの QueryResultsObject プロパティにキャストできるので、Web パーツでデータを使用する処理は何でも実行できます。 全般的に見て、大部分の Web パーツ開発者にとって、このようなパターンを実装することは比較的単純で簡単なはずです。
タスクでコントロールを使用する
今度は、パート 3 で作成したカスタム コントロールを使用して、タスクで使用するコンテンツや構成データを Azure から取得する方法について説明します。 この例では、カスタムの SharePoint タイマー ジョブを作成し、その中で Azure からデータを取得しようとしています。 パターンは前述の Web パーツとかなり似ていますが、今回は多くのタスクと同様に HttpContext がないので、ASP.NET キャッシュは使用できません。 その場合、OutputType は None になります。ページ内に描画したり、キャッシュに保存する必要がないからです。代わりに、QueryResultsObject や QueryResultsString から直接値を取得します。 そのようなコードのサンプルを以下に示します。これは、カスタムのタイマー ジョブ クラスの Execute メソッドをオーバーライドするコードです。
SPWebApplication wa = (SPWebApplication)this.Parent;
//create an instance of the control
AzureWcfPage.WcfDataControl cfgCtrl = new AzureWcfPage.WcfDataControl();
//set the properties to retrieve data
cfgCtrl.WcfUrl = "https://azurewcf.vbtoys.com/Customers.svc";
cfgCtrl.OutputType = AzureConnect.WcfConfig.DataOutputType.None;
cfgCtrl.MethodName = "GetAllCustomers";
//since there's no Http context in a task like a timer job, you also need to
//provide the Url to a claims-enabled SharePoint site. That address will be used
//to connect to the STS endpoint for the SharePoint farm
cfgCtrl.SharePointClaimsSiteUrl = wa.Sites[0].RootWeb.Url;
//execute the method
bool success = cfgCtrl.ExecuteRequest();
//check for success
if (success)
{
//now retrieve the data and do whatever with it
AzureWcfPage.CustomersWCF.Customer[] Customers =
(AzureWcfPage.CustomersWCF.Customer[])cfgCtrl.QueryResultsObject;
string AzureResults = cfgCtrl.QueryResultsString;
//this is where you would then do your tasks based on the data you got from Azure
foreach(AzureWcfPage.CustomersWCF.Customer c in Customers)
{
Debug.WriteLine(c.Email);
}
Debug.WriteLine(AzureResults);
}
else
{
//do something to log the fact that data wasn't retrieved
}
このコードについてもう少し説明します。 タイマー ジョブは Web アプリケーションを対象範囲とするジョブなので、まず、Parent プロパティを参照することによって、このジョブの実行対象である SPWebApplication への参照を取得します。 次に、パート 3 で作成したカスタム コントロールを作成し、Azure からデータを取得するのに必要な、最小限のプロパティを設定します。 コードの次の行では、SharePointClaimsSiteUrl プロパティを設定する必要があります。 パート 3 で説明したように、CASI キットの基本クラスが ExecuteRequest メソッドを実行するとき、HttpContext を使用できるかどうかを確認します。 使用できる場合は HttpContext を使用して現在の SharePoint サイトの URL を見つけ出し、そのサイトを通じて SharePoint STS に接続します。 ただし、前述のようにコードがタスク内で実行されているとき、通常 HttpContext はありません。 そのような場合、基本クラスは SharePoint STS への接続に使用する URL を判断できないので、クレーム対応 Web アプリケーション内のサイトへの URL を基本クラスに渡す必要があります。 この実装のタイマー ジョブのコードは、クレーム対応 Web アプリケーションでのみ実行されることを前提としています。そのため、現在の Web アプリケーションへの参照を取得して、最初のサイト コレクションへの URL を渡しています。 クレーム対応 Web アプリケーション内にあるのであれば、どのサイト コレクションを使用しても構いません。
SharePointClaimsSiteUrl プロパティを設定したら、前に説明したように ExecuteRequest メソッドを呼び出すことができます。 メソッドが正常に実行されたら、QueryResultsObject プロパティや QueryResultsString プロパティを使用してコントロールから直接データを取得できます。
この投稿に添付した zip ファイルには、Web パーツのプロジェクトとタイマー ジョブのプロジェクトの両方が入っています。
終わりに
今回のシリーズはこの投稿で終わりです。CASI キットについて、そして CASI キットを使用してサイト上やクラウド内の WCF アプリケーションにホストされたデータに簡単に接続したり、アプリケーション境界やデータ センター境界をまたいでユーザーの ID トークンを使用する方法について、ご理解いただければ幸いです。 まとめると、パターンは次の手順で比較的簡単に実装できます。
1. コンテンツや構成データに対する WCF フロントエンドを作成します。 作成した WCF フロントエンドをクレーム対応にして、必要に応じてクラウドに展開します。 必要に応じて、呼び出し元のユーザーの ID と要求に基づくきめ細かい権限決定手法を実装します。
2. CASI キットの基本クラスから継承するカスタム コントロールを作成します。 1 つのメソッドをオーバーライドし、5 行のコードを書きます。 コントロールを簡単なレイアウト ページに追加して展開します。
3. Web パーツをページに追加し、1 つ以上のプロパティを設定して、WCF データの描画を開始します。 必要に応じて、コントロールを使用してカスタムの Web パーツ、またはカスタムのタイマー ジョブなどのタスクのコンテンツや構成データを取得します。
これでほぼすべて説明しました。 CASI キットを使用することによって、SharePoint ファームと世界中のあらゆる場所に保存されているデータの接続を非常に簡単かつ明快に行えるようになるでしょう。 SharePoint サイトに表示するコンテンツそのものだけでなく、構成データや個人用設定データの取得にも同様に有効です。 そして、実装したセキュリティをアプリケーション境界やデータ センター境界をまたがる組織で柔軟に使用できるようになります。 私は楽しみながら CASI キットを構想し、設計し、開発しました。CASI キットが皆さんのお役に立つことを願っています。 いつものとおり、これは v1 リリースであり、改良できる点が多数あると思いますので、これらの投稿に関するコメントを遠慮なく書き込んでください。次の大規模リリースのための検討材料として、定期的にコメントに目を通す予定です。
これはローカライズされたブログ投稿です。原文の記事は、「The Claims, Azure and SharePoint Integration Toolkit Part 5」をご覧ください。