連載
アプリケーション・アーキテクチャ・ガイド2.0解説

第6回 典型的なアプリケーションのパターン(後編)

日本ユニシス 猪股 健太郎
2009/12/15
Page1 Page2 Page3 Page4

SharePoint業務アプリケーション

 SharePoint業務アプリケーションは、MOSSやWSSを利用して構築する、ロールベースのWebアプリケーション・ポータルである。

 アプリケーションの論理階層構造は、先ほど説明したOBAと同様、プレゼンテーション層、生産性向上支援層、アプリケーション・サービス層の3つからなる。このアプリケーション・パターンでは、プレゼンテーション層がSharePointポータルとなっている。

 SharePointポータルは、IISをWebサーバとして使ったWebアプリケーションとして動作する。ポータルには複数のサイトを作成することができる。

 サイトは複数のページを含み、各ページは複数のWebパーツを含むことができる。最初から用意されているWebパーツを使うだけでなく、アプリケーション独自の機能を提供するカスタムWebパーツを開発してページに組み込むこともできる。

 なお、プレゼンテーション層と生産性向上支援層の機能はMOSSとWSSのどちらでも提供できるが、アプリケーション・サービス層の機能はMOSSだけに含まれている。

SharePoint業務アプリケーションの構造

 SharePoint業務アプリケーションのアーキテクチャ・フレームとして、AAGでは下記のものを取り上げ、検討すべきガイドラインを提示している。ここでは、その中から「ドキュメントとコンテンツのストレージ」「Webパーツ」「ワークフロー」「SharePointオブジェクト・モデル」の4つを説明しよう。

SharePoint業務アプリケーションの アーキテクチャ・フレーム
ドキュメントとコンテンツのストレージ
Webパーツ
ワークフロー
ビジネス・データ・カタログ
SharePointオブジェクト・モデル
InfoPathフォーム・サービス
Excelサービス
配置

ドキュメントとコンテンツのストレージ

 Office文書はSharePointのドキュメント・ライブラリに格納できる。また、Officeアプリケーションを使うと、複数のストレージに格納されているコンテンツを連結して扱うこともできる。

注意点:

  • ドキュメント・ライブラリに文書を格納する場合は、コンテンツ・タイプとして適切なメタデータを設定しておく
  • コンテンツ・タイプをどのように管理するかの方針を定めておく。サイト全体で共有することもできるし、特定のリストだけで利用することもできる
  • コンテンツ・タイプの継承を活用する。ポータルのルートで定義したコンテンツ・タイプは、子のサイトでも利用できる。また、既存のコンテンツ・タイプを拡張した新しいコンテンツ・タイプを定義することもできる
  • ドキュメント情報パネルをカスタマイズし、文書を追跡できるようにしておく
  • ユーザーが構成可能な情報や、一時的でない情報は、リストに保存する
  • あるリストを何度も表示する場合は、検索結果をDataTable(データテーブル)などにキャッシュしておく
  • データベースには、一時的な情報や、トランザクション処理を行う情報を保存する
  • SharePointのドキュメント・ライブラリを乱用しない。ドキュメント・ライブラリには、共同作業や適切な管理が必要な文書だけを登録する
  • SharePointのドキュメント・ライブラリでソース・コードを管理しない
  • リストには2000項目までしか含めることができない。それ以上の項目を扱う場合は独自のUIを作成する
  • フィルタを適用したビューではなく、別のフォルダにドキュメントを格納した方が、高速に取得できる

Webパーツ

 Webパーツを組み合わせることで、プレゼンテーション層を自由に変更できる。アプリケーション独自の機能を実装したカスタムWebパーツを作ることもできるし、SharePointやASP.NETが提供するWebパーツを使うこともできる。

 Webパーツを開発する際は以下の点に注意する。

注意点:

  • Webパーツとして実装するのにふさわしい機能を選択する
  • Webパーツが利用するデータソースを特定する
  • 保守性を高めるため、Webパーツをプレゼンテーション層、ビジネス層、データ・アクセス層の3つの論理階層に分割して設計する
  • 再利用性を高めるため、Webパーツは単機能とする
  • Webパーツはユーザーが構成したりカスタマイズしたりできるように設計する
  • マスター・ページをカスタマイズする時は、マスター・ページにWebパーツ・マネージャを追加しておく
  • Webパーツを組み込むページにはWebパーツ・ゾーンを追加しておく
  • ユーザーがWebパーツを個別に操作できるように、Webパーツ動詞を利用する
  • Webパーツに含まれるコントロールに直接スタイルを設定しない
  • Webパーツに共通のプロパティとカスタムWebパーツ独自のプロパティとを区別するために、プロパティをカテゴリ分けしておく
  • Webパーツ内で作成したSharePointオブジェクトやアンマネージ・リソースは適切に破棄する

ワークフロー

 SharePointには、ドキュメント・ライブラリと組み合わせられるシンプルなワークフローが付属している。SharePointデザイナやVisual Studioを使うことで、カスタム・ワークフローを作成することもできる。

注意点:

  • どのビジネス・プロセスが自動化されているのかを確認しておく
  • 既存のワークフローを電子化する前に、そのワークフローが正しく、かつ適切に文書化されていることを確認しておく
  • 業務要件を満たす適切なワークフロー技術を選択する
  • 業務要件が単純であれば、組み込みのワークフローを選択する
  • 組み込みのワークフローで業務要件を満たせないのであれば、SharePointデザイナを使用する
  • 業務要件が非常に複雑だったり、既存業務システムとの連携が必要だったりする場合は、Visual Studioでカスタム・ワークフローを開発する
  • Visual Studioでカスタム・ワークフローを開発する場合は、開発者でなくても使えるように、SharePointデザイナに登録できるようにする
  • カスタム・ワークフローのデバッグ時には、ログ出力レベルを「Verbose」にする
  • カスタム・ワークフローのデバッグを容易にするため、実行状況を外部から計測できるようにしておく
  • ワークフロー・アセンブリのバージョンを適切に管理し、アセンブリのバージョンを上げる場合はGUIDも変更する
  • ワークフローを入れ替える前に、既存ワークフローへの影響を確認しておく
  • 利用者が作成したワークフローの履歴やタスク・リストは独立して管理する
  • 保守性を高めるため、ワークフローはコンテンツ・タイプと対応付ける
  • リストのアイテムに対して、同じワークフローは1つしか動作させられないことに注意する
  • ワークフローはリストに対して開始させるものではなく、リストのアイテムに対して開始させるものであることに注意する

関連するパターン:

SharePointオブジェクト・モデル

 SharePointは、プロセスの自動化に対応したオブジェクト・モデルを公開している。それを使うことで、文書のバージョン管理をカスタマイズしたり、チェックイン・ポリシーをカスタマイズしたりすることもできる。

注意点:

  • アンマネージ・リソースを解放するため、SharePointオブジェクトを使い終わったらDisposeメソッドを呼び出して正しく破棄する
  • 例外ハンドラで適切にSharePointオブジェクトを破棄する
  • SharePointオブジェクトをキャッシュする場合は、スレッドの同期およびスレッドセーフを心がける
  • SharePointオブジェクトのデータをキャッシュする場合は、DataTable(データテーブル)を利用する
  • 権限を昇格させるときには、権限昇格後に生成されたSharePointオブジェクトだけが、昇格した権限を利用するように注意する

 最後に、SharePoint業務アプリケーションの構築に利用できる実装テクノロジを表にまとめる。

テクノロジ 利用シナリオ
Windows Workflow(WF) カスタム・ワークフローを取り入れたアプリケーションを構築する場合
Microsoft BizTalk Server ワークフローにおいて、複雑なシステム連携や、信頼性の高いメッセージングが必要となる場合
マイクロソフトESBガイダンス マイクロソフト以外の製品で構築されたシステムと連携してEDIを実現したい場合や、エンタープライズ・サービス・バス(ESB)パターンを実現したい場合
Microsoft Office SharePoint Server(MOSS) アプリケーションのビジネス層が単一のSharePointサイトにからしか利用されず、ほかのサイトの情報にアクセスする必要がない場合
System.Web.UI.WebControls.WebParts.WebPartクラス カスタムWebパーツを開発する場合で、SharePoint 2003との互換性が不要な場合
Microsoft.SharePoint.WebPartPages.WebPartクラス カスタムWebパーツを開発する場合で、SharePoint 2003との互換性が必要な場合
SharePoint業務アプリケーションの構築に利用できる実装テクノロジ

 以上で、本連載が開始した2009年3月時点におけるAAGの内容を一通り紹介し終わった。

 しかし、前回の連載の冒頭でお伝えしたように、AAGは3月時点の内容からさらに加筆され、2009年10月にMSDNに正式公開された。よって次回は、正式公開されたAAGの概要や、本連載記事からの変更点、そして新規に追加されたクラウド・サービスの設計について紹介することで、連載の最終回とさせていただきたい。End of Article


 INDEX
  連載:アプリケーション・アーキテクチャ・ガイド2.0解説
  第6回 典型的なアプリケーションのパターン(後編)
    1.サービス
    2.モバイル・アプリケーション
    3.OBA
  4.SharePoint業務アプリケーション

インデックス・ページヘ  「アプリケーション・アーキテクチャ・ガイド2.0解説」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

注目のテーマ

Insider.NET 記事ランキング

本日 月間
ソリューションFLASH