InfoPath Forms Services フォーム設計における注意点

こんにちは SharePoint / InfoPath サポートの森 健吾 (kenmori) です。今回の投稿では、InfoPath Web ブラウザ フォームを作成するにあたり、初めに抑えておきたい点をご紹介します。

InfoPath フォームの利点として、プログラマーでないユーザーが、ビジネスにおけるデータ フローをもとに、自由に帳票のデザイン、動作規則・ルールを実装できる点にあります。また、標準機能で実現できない機能も Visual Studio Tools for Application (VSTA) を使用したプログラミングによりコードを埋めておくことで、デベロッパーとフォーム デザイナーのロールを住み分けたままソリューションの実現および運用保守が可能です。

小規模な業務システムを直感的にスピーディに構築するには、非常に有効な製品ではあります。ただし、業務フローは進化していきます。システムである以上、デザインやフローについては複雑化すると様々な問題が生じるリスクを伴います。プログラムで作成したソリューションとは異なりますので、細かな調整は効かないため、シンプルさを保って問題発生を防ぐよう設計時に色々考慮しなければなりません。

今回の投稿では、InfoPath Forms Services をベースとしたシステムを構築するにあたり、考慮すべき点をまとめます。

1. 一度に表示するフィールド数を制限する
2. フォーム テンプレートを分散する
3. 管理者発行テンプレートを再検討する

以下に、各項目の詳細を記載します。

 

1. 一度に表示するフィールド数を制限する

無計画に入力コントロールやコードなどを増やしていくと、ブラウザ側の消費メモリの増加、複雑に関連づけられた動作規則がレンダリング スピードを遅延、場合によってはページ、スクリプト ファイルのロード タイミングのずれ等から非同期実行される JavaScript のエラー発生などを招く結果となります。(IE9 以降の標準設定では、スクリプト エラーをステータス バーなどでユーザーに通知しない設定のため、誤動作が生じていることに気づきにくい傾向にあります。)

このような状況を防ぐためには、ビューを分割し、動作規則などで切り替えるなどを実施します。入力コントロールが多い場合は単純にビューを切り替えるだけでなく、意味的にグループ化された入力項目を 1 つのビューとして定義するなどし、パフォーマンスだけでなく業務効率の面でも配慮する必要があります。

 

ビューの分割・遷移方法

1)  新しいビューを作成します。


2)  ルールの管理をクリックしてボタンクリック時のルールを定義します。

3)  他のビューに遷移します。

 

2. フォーム テンプレートを分散する

フォーム テンプレートが複雑で大きいほど当然実行時パフォーマンスが低下しますが、同時に保守工数が増大してしまうことを考慮する必要があります。

これは特に、InfoPath フォームで実際に問題が発生した際に実感することになります。現象発生条件を切り分ける際には、最初に関係ないフィールドやデータ接続などを取り除いて、最小構成のフォーム テンプレートを確認していくことになります。例えばフィールド数が数百という単位になれば、切り分けだけでも多大な時間がかかります。

問題発生時の影響を防ぐため、ある程度巨大なソリューションに発展することが見込まれる場合は、当初の計画より InfoPath フォーム テンプレートの役割を定義した上で適切に分散し、設計することが重要となります。

フォーム テンプレート分散における成功の鍵は、中心となるデータの定義、それと連携する各フォームの役割を整理して分割できるかどうかにあります。そのためには、InfoPath の「データ接続」 を活用し、必要な処理やリソースをフォームテンプレートの外側へ配置し、適切に連携することとなります。大規模になればなるほど、当初の設計がその後の長期に渡る運用を左右することになります。

 

3. 管理者発行テンプレートを再検討する

VSTA を使用すると、InfoPath フォームの処理に .NET ベースのコーディングを含めることが可能となります。顧客からのご要件を満たす処理が標準機能では実現できない場合、最終手段として VSTA などを使用したコーディングに行く傾向があります。

タイトル : コードを含むフォーム テンプレートの開発作業を開始する
アドレス : https://msdn.microsoft.com/ja-jp/library/aa944896(v=office.14).aspx

タイトル : InfoPath Forms Services 用のフォーム テンプレートを開発および展開する
アドレス : https://msdn.microsoft.com/ja-jp/library/ms772110(v=office.14).aspx

しかしながら、管理者発行テンプレートでは、InfoPath フォームとフォーム ライブラリを 1:1 で関連付け発行するスタイルとは大きく異なり、以下 3-1. に記載するシステム変更を余儀なくされる点を事前に認識しておく必要があります。代替案として 3-2. に記載した内容もありますので、事前検討の必要があります。

 

補足

SharePoint 2007 および InfoPath 2007 までは、VSTA コードの追加はすなわち完全信頼、管理者発行を意味していました。
しかし、SharePoint 2010 および InfoPath 2010 の組み合わせでは、フォーム ライブラリやサイト コンテンツ発行されたフォームであっても、既定ではサンド ボックス上で VSTA コード ビハインドを動作させることができます。

簡単に説明すると、サンドボックス内では、・直接サービス参照を追加して呼び出す、・SQL Server に接続する、・AD に対してディレクトリ参照するといったコードを直接呼び出すことはできません。これらのメソッド定義側には、呼び出し元コードに対するアクセス許可を要求するような属性が追加されており、サンドボックスなど実行プロセス側が持つコード アクセス セキュリティ (CAS) ポリシーが低い信頼レベルの場合はエラー (SecurityException) になるよう実装されています。

CAS ポリシー違反にならない範囲のライトなカスタマイズである InfoPath フォームが保持する各種フィールド、データ接続オブジェクトに対するアクセス、文字列操作などのカスタマイズは、サンドボックス内で十分実装できます。
CAS について詳細に説明すると膨大になりますため、以下に参考情報を記載します。

タイトル : コード アクセス セキュリティ
アドレス : https://msdn.microsoft.com/ja-jp/library/vstudio/930b76w0(v=vs.90).aspx

 

3-1. 管理者発行テンプレートの問題点

管理者発行テンプレートはもちろん実績のある実装方法であり、この方法を使用すると正しく動作しないという話ではありません。
繰り返しとなりますが、フォーム ライブラリ発行などと比較すると、フォームの発行や管理方法、コンテンツとの連携等において大きく動作が異なるという点を事前に抑えておく必要があり、もしあらかじめ運用上問題があることが想定される場合は代替案を考慮する必要があります。

 

問題点 1)   InfoPath フォーム テンプレートのアップグレードで、アプリケーション プールがリサイクルされる。

InfoPath フォーム テンプレートを管理者発行して使用した場合、コードは通常の Web アクセス時と同じアプリケーション プール内で動作します。SharePoint に限らず .NET Framework 上のアプリケーションは一度ロードした dll ファイルをキャッシュして使用し続けるため、フォーム テンプレートのアップグレード等では、新しい dll ファイルの再ロードするためにプロセス (または AppDomain) の再起動が必要になります。この影響を想定せず、フォーム テンプレートを頻繁に発行して入れ替えていると、一般ユーザーによる SharePoint サイト閲覧に多大なパフォーマンス上の影響を与えることとなります。

管理者発行テンプレートは、一般的には Web パーツなどの開発と同じです。これらのソリューションを展開する際には、内部的にソリューション パッケージが使用されます。
アプリケーション プールのリサイクルを伴う点を考慮しても、運用の観点からフォーム テンプレートのアップグレードなどのメンテナンスを、通常業務時間外などに移して作業をしていく必要性が出てきます。

 

問題点 2)   InfoPath フォームと連携するサイト列等の内部名は自動的に "_{GUID}" に決定する。

InfoPath フォームは、ワークフロー (3rd パーティ製アドイン使用を含む) や SharePoint Designer などによるビューのカスタマイズと連携して使用される場合が多くあります。
これらのカスタマイズを展開する際に、列の内部名が予測できない場合、毎回ワークフロー デザイナーを使用して列との関連づけを行う必要があります。

上述の通り、内部列名を固定で定義することができないため、このようなソリューションを大量展開しようとした場合、毎回これらの手動作業が生じる結果となり、作業工数が発生することになります。

 

3-2. 管理者発行フォームに代わる効果的なフォーム設計の例

最初から完全信頼フォームに置き換えようとする前に、以下の 2 つの方法で代用できるかを確認し、上記運用要件に対する影響と比較を行う必要があると考えます。

 

代替案 1)   VSTA を使用して標準のデータ接続に対する動的な更新を実施した上で呼び出す方法で代用する。

InfoPath フォームを完全信頼にする理由の主な 1 要因として、VSTA フォーム コードから外部データに接続する要件があります。
このような方法を実施した場合、フォームコードは上述の通りサンドボックス ソリューションではポリシー上許可されていないメソッドを呼び出すことになるため、管理者発行する必要が生じる結果となります。

しかし盲点なのが、InfoPath フォームが公開しているデータ接続オブジェクト (DataConnection) を VSTA フォーム コード上でプロパティ参照、変更し、呼び出せば同じことが実現できるという点です。
このような方法を実施した場合、プロパティの変更がサンドボックス内で実施され、実際のデータ接続はサンドボックスではなく、SharePoint アプリケーション プール内 InfoPath Forms Services ランタイム上で実行されます。


VSTA フォーム コード内で、Web メソッドを直接呼び出すことがないため、完全信頼にする必要もありません。結果的に、サンドボックス ソリューションから Web サービスなどのデータ接続をある程度自由に呼び出すことが可能となります。

 

サンプル コード

public void DropDown_Changed(object sender, XmlEventArgs e)
{
// ここにコードを書き込んで、メイン データ ソースを変更してください。
FileQueryConnection conn = (FileQueryConnection)this.DataConnections["GetXML"];
conn.FileLocation = strMasterLibPath + ((XPathNavigator)(sender)).Value;
conn.Execute();
}

上記は XML ファイルに対するデータ接続 (GetXML) をカスタマイズしています。InfoPath の標準機能では、XMLファイルへの URL パスは固定ですが、上記のようなコードで動的に変更することで、例えばドロップダウン コントロールで選択したファイル名のデータを参照するなどの自由度が向上します。

InfoPath は他にも様々なデータ接続 (WebServiceConnection, AdoQueryConnection, EmailSubmitConnection, BdcQueryConnection) を保持しています。これらを活用し、コードで要求内容を変更した上で実行すれば、サンドボックス ソリューション内での実現可能な領域が大幅に広がり InfoPath アーキテクチャに親和性の高い設計でソリューションを実現できる可能性があります。

再度強調しますが、同じ目的を達成するために、実装方法を変更するだけで管理者発行する必要は一切ありません。
この方法のより詳細かつ多彩な活用方法については別の投稿にて記載を予定しています。

2014.07.04 補足 (上図も差し替えています)
完全信頼プロキシ プロセスである SPUCWorkerProcessProxy.exe を経由した場合、サービス呼び出しアカウントが完全信頼プロキシ プロセスの実行ユーザーになることを確認しております。
このため、呼び出しユーザーによって動作を変えるWeb サービス メソッドを実行する場合は、管理者承認フォーム テンプレートに変更したタイミングで正常に動作しない可能性がありますため、ご注意ください。

代替案 2)   VSTA 内の処理を Web サービス側に移植する。

InfoPath 内で複雑なコードを実装する代わりに、該当コードを外部の Web サービス側に移植し、動作規則などでデータ接続を呼び出すよう構成することも可能です。InfoPath フォームテンプレートからは標準機能の Web サービスに対するデータ接続を使用するだけで複雑な要件に対応する処理を実現可能となります。

Web サービスの実装方法について、参考情報を記載しますのでご確認ください。

タイトル : チュートリアル : ASP.NET を使用した基本的な XML Web サービスの構築
アドレス : https://msdn.microsoft.com/ja-jp/library/7hs6sw69(v=vs.80).aspx

タイトル : 方法 : IIS で WCF サービスをホストする
アドレス : https://msdn.microsoft.com/ja-jp/library/ms733766.aspx

 

もし、SPContext オブジェクトを使用するなどの事情により、SharePoint Web アプリケーション内部にサービスをホストする場合は、まずは独立したサービスを実装するところまで上記のサイトで確認しておけばスムーズに以下の手順で SharePoint 内にサービス エンドポイントをホストさせることが可能です。

タイトル : [ウォークスルー] カスタム ASP.NET Web サービスを作成する
アドレス : https://msdn.microsoft.com/ja-jp/library/ms464040(v=office.14).aspx

タイトル :カスタム WCF サービスを SharePoint Foundation で作成する
アドレス : https://msdn.microsoft.com/ja-jp/library/ff521581(v=office.14).aspx

その他、参考情報

以下に本投稿に関連する参考情報を記載いたします。

タイトル : InfoPath フォームのパフォーマンスの改善のためのガイドライン
アドレス : https://msdn.microsoft.com/ja-jp/library/office/ee526343(v=office.14).aspx

 

いかがでしたでしょうか。InfoPath フォームを使用したソリューションが大規模化することを想定する際は、是非ともご参考にしていただけますと幸いです。