※ SharePoint 2013 以降では、サンボボックス ソリューションは非推奨です。SharePoint アドイン (SharePoint Add-ins) による開発手法を使用してください。

環境 : SharePoint 2010, Visual Studio 2010

裏 10 行でズバリ ! サンドボックス ソリューション 

• SharePoint 2010 ワークフローアクションのサンドボックス配置
• SharePoint 2010 ワークフローの Visual Studio を使用したサンドボックス配置
• SharePoint 2010 コードを含む InfoPath 2010 Web フォームのサンドボックス配置
• SharePoint 2010 モジュールを使ったファイルのサンドボックス配置
• SharePoint 2010 における .aspx ページ (リストフォームなど) のサンドボックス配置
• Bing Maps を使って住所から地図を表示する (サンドボックス ソリューションの Networking)
• SharePoint Online 向けに機能 (フィーチャー) をまとめる

本シリーズは、「10 行でズバリ ! SharePoint 2010 開発」を理解された開発者向けに、さらに踏み込んだ内容を記載しています。(ちなみに、10 行にはおさまっていません。。。)

こんにちは。

次期 BPOS (Microsoft Online Services) への準備として、SharePoint 2010 のサンドボックス開発についてさらに記載していきます。今回は、ワークフローをサンドボックス ソリューションとして (Visual Studio を使って) 開発・配置する方法についてです。

まず、本題に入る前に、基本的な背景と仕組みを理解しておきましょう。

サンドボックスワークフローの前提知識

「10 行でズバリ!! SharePoint のサンドボックス ソリューションの作成」でも記載したように、サンドボックス ソリューション (sandboxed solution) で配置できるソリューションの種類は制限されています。ワークフロー (Workflow) 開発では、記載しているように、宣言型のワークフローはサンドボックス ソリューションとして配置できますが、Visual Studio で作成するコードを含んだワークフローはサンドボックス配置はできません。(これらは、後述するように、配置の内部的なメカニズムも異なっています。)

宣言型のワークフロー (Declarative Workflow) とは、SharePoint Designer で作成されるワークフローのことですが、このワークフローを毎回 SharePoint Designer を使用してユーザーに手動で作成してもらうのは大変です。そこで、今回は、Visual Studio を使用して、サンドボックス ソリューションとして配置可能なワークフローソリューションを作成していきます。この説明の前に、まずは、以下の手順で、SharePoint の標準画面を使用して、事前知識を学んでおきましょう。

まず、以下の手順で、サイトテンプレート (.wsp ファイル) としてサイトの情報を保存してみましょう。(基礎知識なので、画面イメージはなしで説明します。。。)

1. サイト上で、SharePoint Designer を使用し、あらかじめ、再利用可能なワークフローを作成しておきます。
2. 作成したワークフローの発行をおこないます。
3. [サイトの操作] – [サイトの設定] を選択し、[テンプレートとしてサイトを保存] リンクをクリックして、サイトテンプレート (.wsp ファイル) を保存します。この際、[コンテンツを含む] にチェックを付けておいてください。
   (注 : ただし、このリンクは、SharePoint Server 発行機能が有効になっているサイトでは表示されませんので注意してください。)
4. [サイトの操作] – [サイトの設定] を選択し、[ギャラリー] ヘッダーの [ソリューション] リンクをクリックして、ソリューションギャラリーを表示します。
5. ここに、上記で保存されたサイトテンプレート (.wsp ファイル) が存在するので、名前をクリックして、ローカルのディスクに .wsp ファイルを保存してください。

つぎに、上記の保存したサイトテンプレートをサンドボックス ソリューションとして、別のサイトコレクションに展開 (配置) してみます。

1. 今度は、サンドボックス ソリューションの配置先のサイトコレクションを SharePoint の画面で表示し、このサイトコレクションのソリューションギャラリー (上記参照) を表示します。
2. リボンの [ソリューション] タブの [ソリューションのアップロード] ボタンをクリックして、ローカルに保存した上記の .wsp ファイルをアップロードします。この際、表示されるダイアログで、[アクティブ化] ボタンをクリックして、このソリューションをアクティブ化します。

このサイトコレクション上でサイト (サブサイト) の新規作成をおこなう際に、上記でアップロードしたサイトがサイトテンプレートとして表示されるため、このサイトテンプレートを使用してサイトを新規作成します。すると、作成されたサイト上に、上記で構築したワークフローが登録されているのがわかります。(SharePoint Designer で確認してみてください。)

つまり、上記の .wsp ファイルには、サンドボックス ソリューションとして配置可能な宣言型のワークフローがフィーチャーとして登録されていて、これが内部で使用されています。

内部のメカニズムを理解する (簡単解説)

本題に入る前に、この内部的な仕組みについて軽く確認しておきましょう。なお、宣言型ワークフロー (SharePoint Designer のワークフロー) と、Visual Studio によるコードワークフローについては、書籍「VSTOとSharePoint Server 2007による開発技術」でも紹介していますので、こちらを読まれた方は、以下は読み飛ばして結構です。(SharePoint 2010 においても、アーキテクチャは同様です。)

まず、上記によって、どのような成果物がどこに配置されたか確認してみましょう。
SharePoint Designer でワークフローを作成 (および発行) した後、SharePoint のサイトをエクスプローラービューで表示すると、サイトのトップに「Workflows」というフォルダーがあるので、これを開いてみてください。ここには、ワークフローごとにサブフォルダーが作成されており、下図のように、ワークフロー関連のファイルがこのサブフォルダーに保存されているのがわかります。

このフォルダー (上図の Workflows フォルダー) は、実は普通のドキュメントライブラリではなく、ワークフロー向けの専用のコンテンツタイプを持ったリストです。(見た目は、ドキュメントライブラリと同じですね。。。) 宣言型ワークフロー作成時の成果物は、すべてこのリスト内に作成されます。

SharePoint Designer でワークフロー作成をおこなうと、内部では、以下のようなステップで動作をしています。(なお、SharePoint Designer では、WebDAV、Web サービスなどでこれらの処理を呼び出していますので、リモート環境からでも処理できます。)

1. 下記のファイル一式を作成し、Workflows フォルダー (専用のコンテンツタイプのフォルダー) にサブフォルダーを作成して、これらを保存します。
   • .xoml ファイル – ワークフローのステップを記述した XAML ファイルです (WF 3.5 ベースです)
   • .xoml.wfconfig.xml ファイル – 関連付け先のリスト、使用するタスクリストなど、SharePoint 関連の付帯情報を記述したファイルです
   • .xsn ファイルなど – ワークフローから使用する開始フォーム (.xsn, .aspx) など、その他の付随的なファイルです
2. 作成後、これらのファイルのコンパイルをおこないます (WF のコンパイルと、SharePoint 独自のその他の処理がおこなわれます)

余談ですが、この基本メカニズムを知っていると、以前紹介した「カスタムの SharePoint ワークフローエディター」のようなカスタムなアプリケーション (SharePoint Designer 以外のワークフロー構築ツールなど) も作成できます。

サンドボックス ソリューションの宣言型ワークフローを Visual Studio のプロジェクトとして作成する

では、本題に入ります。

上記のような配置方法ではなく、この宣言型のワークフローを、フィーチャーとして Visual Studio のプロジェクトに組み込んで、パッケージを作成してみましょう。(こうすることで、他のフィーチャーと組み合わせた統合的なパッケージ作成など、さまざまな拡張ができます。)
Visual Studio 上ですべて構築することもできますが、XAML 形式 (フォーマット) のファイル作成、.xoml.wfconfig.xml 形式 (フォーマット) のファイル作成など、全部実施すると結構大変ですので、いったん SharePoint Designer でワークフローを作成し、これを Visual Studio 上に取り込みます。

まず、以下の手順で、上記で作成した SharePoint Designer の宣言型ワークフローをサンドボックス ソリューションとして Visual Studio 上に抽出します。

SharePoint Designer で作成したワークフローを表示し、下図のボタンを押して、このワークフローだけをテンプレート (.wsp ファイル) として保存します。すると、そのサイト上の「サイトのリソース ファイル」というドキュメントライブラリに、この .wsp ファイルが保存されるので、これをクリックして、ローカルに保存しておきます。

注意 : なお、上記で作成した .wsp をそのまま使用しても良いですが、上記のパッケージ (.wsp) には多数のフィーチャーが登録されていて探すのが面倒ですので、この方法で、ワークフローだけをパッケージに取り出しておきます。

つぎに、Visual Studio で新しいプロジェクトを作成します。
プロジェクトテンプレートとして、[SharePoint ソリューションパッケージのインポート] のプロジェクトテンプレート (下図) を選択します。

注意 : 上図に、[再利用可能なワークフローのインポート] というプロジェクトテンプレートがありますが、セミナーなどでもご説明した通り、これは、SharePoint Designer で作成した宣言型のワークフローを (ファームソリューション用の) コードのワークフロープロジェクト (こちら を参照) に変換して取り出すためのものです。(今回は、使用しないでください。)

ウィザードが表示されるので、[サンドボックス ソリューションとして配置する] を選択 (チェック) して先に進めると、つぎに、どの .wsp ファイルをインポートするか選択するためのウィザードが出てきます。ここで、上記で保存したローカルファイル (.wsp) を選択します。
つぎに表示されるウィザードで、どのフィーチャーを取り込むか選択する画面が出てきます (下図)。ここには、上述したように (上記のエクスプローラービューの図を参照)、Workflows リスト (つまり、リストインスタンス) と、その中に入れる各種のファイル (つまり、モジュール) の 2 つのフィーチャーが表示されるので、この双方を選択します。
なお、上記で「コンパイル作業が必要」と記載しましたが、このための処理はフィーチャーのイベントレシーバーとして登録されています。(ですので、開発者は、これらのフィーチャーを取り込めば、何もしなくて OK です。)

これで、ひとまず、宣言型ワークフローの (Visual Studio の) サンドボックス ソリューションが作成できました。(使用されているイベントレシーバーなど、作成されたソリューションを確認して、いろいろと研究してみてください。)

つぎに、1 つ日本語環境での注意点があります。
リストインスタンスの名前がデフォルトで「ワークフロー」という日本語名になっているため (ASCII 文字でないため)、ソリューション作成時にファイル名が文字化けし、ソリューションの展開ができません。このため、Visual Studio 上でこの名前を「Workflow」などに変更しておいてください。(さらに、ワークフロー名に日本語を使用している場合も同様です。モジュールのファイル名に日本語が混ざるので、Visual Studio 上でモジュール名を英語に変更するか、ワークフロー作成時に、あらかじめ、英語名で作成しておいてください。)

さいごに、リスト定義、リストインスタンスでは、フィーチャーの既定のスコープが「Web」 (サイト) になっていますので、今回は、これを「Site」 (サイト コレクション) に変更してください (下図)。

注意 : スコープが 「Web」 (サイト) の場合、サンドボックス ソリューションのアップロード時にアクティブ化をおこなっても機能 (フィーチャー) のアクティブ化はおこなわれず、SharePoint の画面を使って、サイトごとに機能のアクティブ化をおこなう必要があります。このため、今回は、「Site」 (サイト コレクション) に変更しておきます。

あとは、リビルドと、パッケージ作成をおこなって、サンドボックス ソリューションとしてサイトコレクションに配置します。(この方法は、「10 行でズバリ!! SharePoint のサンドボックス ソリューションの作成」を参照してください。)
これにより、リストインスタンス、すなわち、ワークフロー用のリスト (上記で説明した「Workflows」) の作成がおこなわれ (同時に、リストアイテムも 1 件登録されます)、ここに、サブディレクトリと、.xoml ファイル、.xoml.wfconfig.xml ファイルなどの各モジュールが登録され、イベント レシーバーによってコンパイルがおこなわれます。(あらかじめワークフロー用のリストインスタンス (Workflows) が存在している場合は、リストインスタンスの作成はスキップされます。)

配置先のサイトで、SharePoint Designer を開いてみてください。すると、上記のワークフローが、ちゃんと登録されているのがわかります。

なお、サンドボックス ソリューションですので、ソリューションの非アクティブ化をおこなうとワークフローがアンインストールされると思われるかもしれませんが、実際は残ります。この理由は、「10 行でズバリ!! SharePoint のリスト定義の作成」の Note で記載しているように、リストインスタンスや、モジュールが配置したファイルは、フィーチャー/ソリューションの非アクティブ化をおこなっても削除されない仕様だからです。(こうした振る舞いも、ここで説明した前提知識を理解しておくと納得できると思います。)

あとは、10行シリーズでも説明しているように、Web パーツなど、さまざまな他のフィーチャーと組み合わせて、統一的なサンドボックス ソリューションの作成をおこなうことができます。私はまだ試してませんが、「SharePoint 2010 ワークフローアクションのサンドボックス配置」で説明したワークフローアクションと組み合わせれば、独自な処理 (コード) も含んだワークフローを展開・配置することも可能でしょう。

配置されたワークフローをリストに設定するには (2010/09/13 追記) 以下の手順で、ワークフローをアクティブ化する際、特定のリストに、このワークフローを設定することもできます。(以前、こちら で紹介した概念とまったく変わりません。)例えば、こちら で作成したリスト定義とリストインスタンス (「出張費一覧」リスト) のプロジェクトを使用してみましょう。(上述の通り、このプロジェクトのスコープも「Site」に変更しておきます。) 上記のワークフローのプロジェクトをこのソリューション (Visual Studio のソリューション) に追加して、パッケージ デザイナーを使って、パッケージにワークフロー関連のフィーチャー (上記のリストインスタンスとモジュール) を追加します。つぎに、フィーチャー イベント レシーバーを作成します。まず、Visual Studio のプロジェクトの [Features] を右クリックして [フィーチャーの追加] を選択してフィーチャーを追加します。(なお、このフィーチャーが確実に最後に実行されるように、パッケージ デザイナーを表示して、このフィーチャーの順番を確認しておきましょう。)つぎに、フィーチャー イベント レシーバーのコードを記述しますが、その準備のため、あらかじめ、ワークフローのテンプレート ID を取得します。ワークフローの .xoml.wfconfig.xml ファイルを開くと、以下太字の通りテンプレート ID が記述されていますので、この GUID をコピーします。<WorkflowConfig Version="14.0.0.4762">  <Template BaseID="{65C1D5D0-1F9E-4A07-9735-D48404F88F19}" . . ./>  <ContentTypes/>  . . .上記で作成されたフィーチャーを右クリックして、[イベント レシーバーの追加] を選択し、以下の通り、アクティブ化の際のコード (フィーチャー イベント レシーバーのコード) を記述します。ここでは、インストールされた「出張費一覧」のリストインスタンスに、上記のワークフローを設定しています。(なお、下記の太字部分は、上記でコピーした GUID の値を設定します。)public override void FeatureActivated(SPFeatureReceiverProperties properties){// サイトの SPWeb を取得SPWeb web;if (properties.Feature.Parent is SPWeb)web = (SPWeb)properties.Feature.Parent;elseweb = ((SPSite)properties.Feature.Parent).RootWeb;web.AllowUnsafeUpdates = true;// 「出張費一覧」のリストを取得SPList targetList = web.Lists["出張費一覧"];// ワークフローテンプレートの取得SPWorkflowTemplate wfTmpl = web.WorkflowTemplates.GetTemplateByBaseID(new Guid("65C1D5D0-1F9E-4A07-9735-D48404F88F19"));// タスクリストの取得 (通常、既定で作成済のため、取得のみおこないます)SPList taskList = web.Lists["タスク"];// ワークフロー履歴リストの取得 (なければ、新規作成)SPList histList = null;foreach (SPList list in web.Lists){if (list.BaseTemplate == SPListTemplateType.WorkflowHistory){histList = list;break;}}if (histList == null){string histListName = "ワークフロー履歴リスト";web.Lists.Add(histListName, "テスト用の履歴リストです", SPListTemplateType.WorkflowHistory);histList = web.Lists[histListName];}// リストにワークフローの関連付けをおこないますSPWorkflowAssociation wfAssoc = SPWorkflowAssociation.CreateListAssociation(wfTmpl, "AutoWorkflow", taskList, histList);wfAssoc.AllowAsyncManualStart = false;wfAssoc.AllowManual = true;wfAssoc.AutoStartCreate = true;wfAssoc.AutoStartChange = false;targetList.WorkflowAssociations.Add(wfAssoc);}

まとめ

上記で手順を紹介しましたが、実際、開発の最初の段階から、サンドボックス ソリューションを想定してこのように作っておくことは、現実にはむずかしいでしょう。(まずは、普通に、ファーム ソリューションのワークフローを作成することになるでしょう。)
しかし、作成したワークフローを、上記の SharePoint Designer を使用した手法と、「SharePoint 2010 ワークフローアクションのサンドボックス配置」の手法を組み合わせて再構成することで、比較的簡単にサンドボックス化が可能です。いったん SharePoint Designer でワークフローを作りなおす、という手間はありますが、そこさえクリアしてしまえば、上記のとおり、以降は Visual Studio に組み込むことができます。

Microsoft Online Services の日本国内の利用者は、2010 年 06 月時点で既に 20 万を超えています。開発当初から、こうした再構成も踏まえてアクションなどの設計 (フローとアクション、入出力パラメータなどの設計) をおこなっておくと、サンドボックス化 (すなわち、将来の SharePoint Online 対応) の際に、より迅速に再構成することができるでしょう。また、将来の WF 4 なども踏まえると、SharePoint 標準のタスクアクションなどを除き、ワークフロー上にコードを混ぜて記載するのではなく、コードはカスタム アクション (カスタム アクティビティ) にできるだけまとめておくと良いでしょう。