フォーム主導型アプリケーションを計画する

  • [アーティクル]

 

適用先: SharePoint Server 2010

トピックの最終更新日: 2016-11-30

多くの SharePoint Server アプリケーションには InfoPath フォームが含まれています。これらのアプリケーションの大半は、フォームが事実上の動作の中心となっています。これらのフォーム主導型アプリケーションには、通常、以下の特徴が共通します。

  • 発注の手続き、従業員の業績評価方法など、ビジネス プロセスを自動化します。

  • 構造化されたコアな情報があり、そのインスタンスを複数の活動を通して受け渡していき、ビジネス プロセスを完了します。

フォーム主導型アプリケーションの働きはさまざまですが、多くの場合、そこに見られる構造には設計上の共通点があります。作成するアプリケーションにもこの設計上の共通点があれば、この記事で説明する設計を利用したうえで、特定の用途に合わせて手を加えることができます。

ここでは、フォームを使用する特定の種類の Microsoft SharePoint Server 2010 アプリケーションの設計について説明します。それ以外の種類の SharePoint Server アプリケーションの設計方法やフォーム自体の設計方法については、ここでは説明しません。Microsoft InfoPath 2010 フォームの設計方法については、「Forms (英語)」(https://go.microsoft.com/fwlink/?linkid=187550&clcid=0x411) (英語) を参照してください。

この記事の内容 :

  • フォーム主導型アプリケーションの構造

  • 一般的なフォーム主導型アプリケーションの計画について

  • コア情報を識別する

  • リストまたはフォーム ライブラリを使用する

  • ワークフロー

  • 追加のデータ ソース

  • ポータル

  • まとめ

フォーム主導型アプリケーションの構造

複雑なフォーム主導型 SharePoint Server アプリケーションは、以下のコンポーネントから構成されます。

  • アプリケーションをホストする SharePoint サイト。

  • コア情報を取得するフォーム テンプレート。フォーム テンプレートの表示形式は、ユーザーのグループによって、または情報のライフサイクルの段階によって異なる場合があります。

  • 完成したフォーム テンプレートのインスタンス (フォームと呼びます) を格納する SharePoint リストまたはライブラリ。

  • アイテムをビジネス プロセス内で受け渡していくワークフロー。ワークフローは、新しいフォームを作成すると開始されます。

  • フォーム テンプレート内のフィールドを設定するために使用される補助的な情報を格納する SharePoint リスト。フォームとワークフローをこれらのリストに関連付けて、リスト内の情報を管理できます。

  • フォーム テンプレートまたはワークフローにデータを提供する外部データベースまたは基幹業務 (LOB) アプリケーション。

  • フォーム テンプレート内の検証ルールとして、またはワークフローの一部として表されるビジネス ロジック。

  • ポータルとして機能し、ユーザーがフォーム テンプレートの新しいインスタンスを作成したり、フォームに関するその他の情報を表示したりできる場所となる Web ページ。対象ユーザーごとに複数の異なるポータルを用意することもできます。

作成するアプリケーションがこの構造と正確に同じである必要はありません。これらのコンポーネントが揃っていないフォーム主導型 SharePoint Server アプリケーションもあれば、ワークフローが複数あるなど、若干のバリエーションが加えられたフォーム主導型アプリケーションもあります。

一般的なフォーム主導型アプリケーションの計画について

一般的なフォーム主導型アプリケーションを設計するには、ビジネス プロセスを主導するコア情報を最初に特定する必要があります。その後で、コア情報を SharePoint リストとライブラリのどちらに格納するかを決定し、コア情報を処理するワークフローを定義します。次に、必要となる追加のデータ ソースを特定し、最後に、アプリケーションへのアクセスに使用されるポータルを設計します。

コア情報を識別する

フォーム主導型アプリケーションを計画する最初の手順では、アプリケーションの活動の中心となるコア情報を特定します。多くの場合に、このコア情報は明白です。たとえば、ヘルプデスクのアプリケーションであれば、コア情報はおそらくサービス要求です。従業員の業績評価プロセスであれば、コア情報はおそらく業績評価フォームです。購買システムであれば、コア情報はおそらく注文です。

プロセスを主導するコア情報を識別します。コア情報が明白ではない場合は、以下のヒントを参考に検討してください。

  • アプリケーションが既存のプロセスを自動化する場合、プロセスの過程で、ある個人から別の個人にドキュメントまたはファイルが受け渡されているか。このドキュメントまたはファイルがコア情報である可能性は濃厚です。

  • アイテムの作成時またはアイテムが特定の場所に現れたときにプロセスが開始されるか。このアイテムがコア情報である可能性があります。

  • おそらくコア情報には一定の構造があり、処理の過程で成長するか変更されることがあります。たとえば、注文には顧客の名前と住所、品目の一覧 (個数と単価を含む)、およびその他の詳細情報が含まれます。注文の処理が進むと、追跡番号などの情報がこれに追加されます。

  • おそらくコア情報に関連付けられた状態があり、この状態が時間の経過により変化します。

プロセスを主導するコア情報を識別できない場合は、この記事で説明する設計がアプリケーションに適していないと考えられます。

アプリケーションを実装するときに、このコア情報を扱うフォーム テンプレートを作成します。このフォーム テンプレートのことを、この記事では "コア フォーム" と呼びます。

リストまたはフォーム ライブラリを使用する

コア フォームのインスタンスを SharePoint リストと SharePoint Server フォーム ライブラリのどちらに格納するかを決定します。

可能な限り、リストを使用してください。リスト ベースのソリューションは単純であり、効率も優れています。ただし、リストが機能しない状況もあります。以下のいずれかの条件が成立する場合は、フォーム ライブラリを使用してください。

  • フォーム インスタンスの変更履歴を残す必要がある。

  • コア フォームに繰り返しセクション (従業員の評価フォーム内の任意の達成番号など) が含まれる。

  • コア フォームに入れ子のデータがある。たとえば、注文フォームにアイテムがあり、そこに製品コード、個数、サイズ、および単価を含めることができる場合など。

  • コア フォームにコードが含まれる。

    フォームにコードが含まれるとは、以下のような状況を意味します。

    • ユーザー設定アクションを実行するボタンがフォームに含まれる。

    • フォームの 1 つのフィールドの値が、フォーム内の他の値を複雑に組み合わせた結果に基づいている。

  • コア フォームのインスタンスがデジタル署名される。

  • コア フォームの各インスタンスに関するデータを XML 形式で保存する必要がある。

コア フォームのインスタンスをリストに格納すると、コア フォームの各フィールドがリスト内では列になり、コア フォームの各インスタンスがリスト アイテムとなります。コア フォームのインスタンスをフォーム ライブラリに格納すると、各インスタンスは XML ドキュメントに変換され、このドキュメントがライブラリに格納されます。

ワークフロー

ビジネス プロセスは、コア フォームのインスタンスになんらかの変化が起きると開始されます。多くの場合、コア フォームの新しいインストールを作成すると同時にビジネス プロセスが開始されますが、コア フォームのインスタンスを変更する、ユーザーに割り当てるなど、他のイベントによってプロセスが開始されることもあります。

ビジネス プロセスは、コア フォームのインスタンスを、アクションを実行する必要があるユーザーとシステムに受け渡していきます。たとえば、コア フォームがサービス要求である場合、新しいサービス要求を作成すると、サービス要求をサービス担当者に割り当て、サービスを要求したユーザーに連絡を取るというプロセスが開始されます。サービス担当者は、サービスを要求したユーザーとのやり取りに従ってさまざまなアクションを行います。たとえば、要求を上位の担当者に伝達したり、要求に解決済みのマークを付けたり、要求元のユーザーに交換品を送付する必要がある場合は注文部署に要求を転送したりします。

コア フォームのインスタンスを処理するプロセスに関連する手順と決定事項を識別します。この一連の手順を、SharePoint Server ではワークフローと呼びます。ワークフローの詳細については、「ワークフローを計画する (SharePoint Server 2010)」を参照してください。

追加のデータ ソース

フォーム テンプレートは、データベース、Web サービス、SharePoint など、外部ソースからデータを取得できます。外部データの一般的な使い方は、フォーム テンプレートのフィールドに有効な値のリスト (コスト センターのリストなど) を設定することです。また、外部データや他のフィールドの値を組み合わせてフィールドの値を計算するルールを使用することもできます。たとえば、"承認者" フィールドの値を取得するために、"送信者" フィールドに名前が入力された従業員の管理者を外部データ ソースから検索できます。

コア フォームからアクセスする外部データを識別します。外部データのソースごとに、データが取得される場所を特定します。たとえば、データの取得元としては、SharePoint リスト、SQL データベース、SAP などの LOB システム、またはその他のソースがあります。

注意

一部の LOB データには、外部コンテンツ タイプを作成して SharePoint Server リストから直接アクセスできます。詳細については、「Business Connectivity Services の概要 (SharePoint Server 2010)」を参照してください。

データをコア フォームに提供する SharePoint リストについては、リスト内のデータを管理する方法を検討してください。新しいデータをリストに入力するためにフォームを作成する場合や、リスト内のアイテムを管理するためにワークフローが必要な場合があります。たとえば、コア フォームでコスト センターのリストを使用する場合、承認ワークフローをリストに追加できます。

ポータル

アプリケーションの利用者はだれですか。複数のユーザー ロールがある場合、あるロールのメンバーが他のロールのユーザーとは異なるアクションを実行したり、異なる情報を見たりしますか。ユーザーのロールによってアプリケーションの使い方が異なるのであれば、ロール別にポータルを作成することを検討してください。各ポータルで使用可能なアクションと情報を、ポータルを使用するユーザーのロールに合わせて調整します。

たとえば、従業員の業績評価アプリケーションには、おそらく最小限でも以下の 3 つのロールがあります。

  • 従業員。業績評価フォームに入力します。

  • 管理者。業績評価フォームに情報を追加し、業績評価を承認します。

  • 人事担当者。業績評価からレポートを作成し、情報を集計します。

従業員は、従業員ポータルを使用して業績評価アプリケーションにアクセスし、新しい業績評価フォームを作成したり、各自の業績評価が管理者によって承認されたかどうかを確認したりできます。管理者は、管理者ポータルを使用して業績評価アプリケーションにアクセスし、管理下の従業員の一覧、各従業員から業績評価フォームが既に送信されたかどうかを示すマーク、および従業員の業績評価フォームを開くためのリンクを表示できます。人事担当者は、人事ポータルを使用してアプリケーションにアクセスし、すべての業績評価フォームに対して承認済みのフォーム、送信済みだが未承認のフォーム、または未送信のフォームが占める割合を示す統計の要約を表示できます。

作成可能な最も単純な種類のポータルは、コア フォームのインスタンスが格納されている SharePoint リストまたはライブラリの内容を単に表示するというものです。フィルターを使用するか条件付き書式を適用して、表示を特定のユーザー向けにカスタマイズできます。

また、ユーザー ロールごとに独自の Web ページを設計することもできます。各ユーザーには、そのロールに対応するアプリケーション アクセス用 URL を通知します。ポータル Web ページには、以下の要素を配置できます。

  • コア フォームの新しいインスタンスを作成する [新規] ボタン。

  • コア フォームのインスタンスの概要/詳細ビュー。概要ビューには、一定の条件によってフィルター処理されたフォーム インスタンスのリストを表示し、詳細ビューには、概要ビューで選択されたフォーム インスタンスの詳細な情報を表示します。概要ビューは、リスト ビュー Web パーツまたはコンテンツ クエリ Web パーツを使用して作成できます。詳細ビューを作成するには、InfoPath フォーム Web パーツでコア フォームをホストします。リスト ビュー Web パーツの詳細については、「the Microsoft SharePoint team blog (英語)」(https://go.microsoft.com/fwlink/?linkid=187653&clcid=0x411) (英語) を参照してください。コンテンツ クエリ Web パーツの詳細については、「How to: Customize the Content By Query Web Part by Using Custom Properties (英語)」(https://go.microsoft.com/fwlink/?linkid=187635&clcid=0x411) (英語) を参照してください。InfoPath フォーム Web パーツの詳細については、「How to: Host an InfoPath Form in the InfoPath Form Web Part (英語)」(https://go.microsoft.com/fwlink/?linkid=187637&clcid=0x411) (英語) を参照してください。ポータルでは、ロールごとに異なるフィルターを使用できます。たとえば、新しいフォーム インスタンスを作成するユーザー用のポータルでは、作成したユーザーを基準にインスタンスをフィルター処理できます。承認者用のポータルでは、ユーザーの評価と承認を待っているインスタンスをフィルターで抽出できます。

  • 1 日あたりのフォーム インスタンス処理数、アプリケーションの対象領域に関連する測定値など、プロセスに関する統計。

まとめ

作成するアプリケーションの特徴がここで説明した内容の大半に当てはまるのであれば、フォーム主導型アプリケーションのパラダイムに従ってアプリケーションを実装できると考えられます。アプリケーションをホストする SharePoint サイトを作成し、コア フォーム用のフォーム テンプレートを作成します。コア フォームのインスタンスを格納するリストまたはライブラリを作成し、フォーム テンプレートをリストまたはライブラリに関連付けます。新しいフォームをリストまたはライブラリに追加すると開始されるワークフローを追加します。フォーム テンプレートにデータを提供するために必要な追加のリストを作成し、値を設定します。ユーザーがアプリケーションを操作するために使用できる 1 つ以上のポータルを作成します。

See Also

Concepts

SharePoint Server 2010 のフォームについて
InfoPath フォームの管理 (SharePoint Server 2010)