InfoPath Dev

お世話になっております。

作成しているフォームをMOSS2007 のフォームライブラリに発行しています。

実は、そのフォームのLoading と、アクションにかなりの時間がかかっています。
「New」ボタンをおして、Loading に30秒くらい
チェックボックスを、クリックする際にも、砂時計が表示され、30秒くらいかかって、仕込まれた非表示エリアが表示されます。

非表示・表示の展開が、軽い小さなものであればそれほどではないのですが、
セクションの中に、複数の表 や、チェックボックス、更に、動作規則を設定してある場合、ほんとに実用レベルで無いくらいに時間がかかります。

サーバー管理者に確認したところ、確かに、移行の最中でありますが業務時間内には停止しているとのこと。

Infopathは、機能として、FormService がWebで実装できるように用意されているわけですが
何か、障害や、パフォーマンスに問題になるような事例ってあるのでしょうか？

MOSS側では、
Display as a Web page
を選択しています。

ご教授お願いいたします。。

すでに参照済みかもしれませんが、以下などを参考にしてはいかがでしょうか。

InfoPath 2007 フォームのパフォーマンスの改善 (Microsoft MSDN サイト)
http://www.microsoft.com/japan/msdn/office/2007/bb380251.aspx

パフォーマンスについては本当にさまざまな要因があるので、この MSDN の
情報を元にひとつひとつチェックしていくことになるでしょうね。 

システムにおいては使い勝手（もしくは開発の容易さ）とパフォーマンスは裏と表の
ような関係になっている場合があります。InfoPath の Forms Services はまるで
Web アプリケーションを Visual Studio を使わずに作成できるような感覚を持ち
ますが、その分、注意しなくてはならない点や、できないことが結構あります。
言い換えると、Visual Studio で行っていた Web アプリケーション開発の代替と
して想定しているソリューションではありません。

ですので、機能制限やパフォーマンスについては当初から検討して、ASP.NET に
よる開発がよいのか、InfoPath によるソリューションがよいのかの見極めが重要
になるようです。

サイト情報を参照されて解決されればよいのですが。

クリエ・イルミネート
沼口

沼口様

こんにちは！お世話になっております。
はい、InfoPath 2007 フォームのパフォーマンスの改善 (Microsoft MSDN サイト)は、先日投稿の後みつけて
出来るだけの検証をしていたところで、投稿しようとおもってたところです。

ですが、なかなか改善にいたらなくて

テスト1
規定に空白のビューを追加
→ 気持ち程度、Loadingが早くなったような気がするのみ

テスト2
ローカルに保存
→ 動作は許容範囲で問題なし

テスト3
SPSから、Webページではなく、Infopathで開くように設定
→ 動作は許容範囲で問題なし

ここまでくると、
やはり、ビューや、動作規則の問題でしょうか・・・

Microsoftのさいとにレイアウトテーブルやセクションの入れ子も読み込みに時間がかかるとありますが
レイアウトをそろえる関係で、確かに複数使用してますが、これくらいで影響出てしまうのかという感じです。
作成したフォームには、今までの経緯でお話したように、

・チェックボックスによる表示非表示セクションが多数ある状況 → 20セクションくらい
・テンプレートパーツが → 4つ
・繰り返しセクションはない
・レイアウトテーブルは表としても使用しているものを含め → 30くらい
・チェックボックスによる動作規則は → 約100 くらい
・データソースを利用するドロップダウンリスト → 3つ
・ボタン → 4個　（1つは送信ボタン、　3つは、表示非表示）

ざっとお知らせするとこのような使い方です。

沼口様が以前に、「クライアントにInfopathが全てにはいってるので、Webで開くようにはしていない」とのことでしたが
「フォームオプション」 → 「互換性」 → 「ブラウザまたはInfopathで開くことができるフォームテンプレートをデザインする」をオフにして設計してるということでしょうか、、
それとも発行先で、WebページではなくクライアントPCにインストール済みのInfopathを Viewerのようなイメージで使っているとくことでしょうか。

機能的なことだと、前者のブラウザ互換では作成してないってことだと思うのですが、、、
この場合、パフォーマンスの改善のために、クライアントに、Infopathを導入させるということも、
手段として正しいのでしょうか・・

アドバイスをいただけますでしょうか。
よろしくお願いいたします。

あくまで局所的な話なので、これがすべてではないでしょう、というのを前提にすると、
弊社の講師陣が受けた相談の中でパフォーマンストラブルの原因でよくあるのは
「一つのフォームにコントロールを張り付けすぎている」と聞いております。

解決策は「ビューでフォームをわける」ということであり、上記のテスト１で行われて
いる「（初期ロードのための）空白のビューを追加する」ではないんです。

ブラウザは HTML で送られたテキストを解釈してレンダリングするわけです。レンダ
リングする量が多ければその分そのフォームを表示するまで時間がかかります。

電子フォームソリューションとしての InfoPath + SharePoint は、本当にお手元に
あるだろう「経費精算書」とか「備品購入申請書」など、紙ベースの申請書を、
InfoPath に置き換えて、フォーム ライブラリに蓄積します。フォーム ライブラリその
ものは、上司の机の上にある「受け箱」のイメージです。

そう考えた時に、現実に1つの申請書にそれだけのコントロールが張り付いたもの
が存在しているかどうかを確認してもらうそうです。

弊社の社内システムでの使い方は、たとえば、トレーニングコースの受講申し込み、
見積書、請求書といった、一度入力したデータを再利用するようなものは、1つの
InfoPath フォームにすべてのデータ ソースをメイン データ ソースにいれていますが、
ビューを複数にわけています。基本情報入力ビュー、見積書ビュー、請求書ビュー、
といった形です。印刷用のページがほしければ、条件付き書式でビューの中に
「表示・非表示」といったコントロールを配置せずに、必要なコントロールのみが
ある「印刷用ビュー」を追加してしまいます。1つのビューの中のコントロールを無駄に
多くしない、、、これがポイントのように思えます。

この例の場合、メイン データ ソースには 40 以上のフィールドが存在しますが、
それぞれのビューで使われているフィールド（コントロール）は 20 前後です。

このような現存している紙のフォームを電子化するのは Visual Studio で Web
によるアプリケーションをつくるよりもはるかに生産性は高く、変更も容易で、かつ、
SharePoint のライブラリの「ビュー」を使って、集計、グループ化ができるので、
使い勝手がいいわけです。

また、ブラウザでのフォーム参照を使わないので、上記でおっしゃっているように
「ブラウザまたは InfoPath で、、、、、をデザインする」をオフにして、フォームの
作成、変更を行っています。フォーム ライブラリの新規ボタンをおすと、
テンプレートとして登録した InfoPath フォームが InfoPath を使って表示され、
新しくデータを入力したり、保存された InfoPath フォームの変更を InfoPath から
行っています。

最後の、パフォーマンスの改善のため、クライアントに InfoPath を導入する、、
についてですが、それもあるかもしれませんが、いま取りかかっているものは
本当に InfoPath ですべきものかどうか、、、に依存すると思います。前にも
書いたように、Visual Studio で行っていた Web アプリケーション開発の
すべてを代替するソリューションではないので、本来、InfoPath が苦手な部分を
やろうとしていれば、クライアントに InfoPath が入っても、別の問題が発生する
かもしれません。なので、、、手段として正しいかどうかは、、、なんともいえない
のが正直なところです。

クリエ・イルミネート
沼口

フォームの作成だけに絞った話になっていますが、フォームのデザインだけでなく
以下のようなこともありますので、ご参考までに。

http://technet.microsoft.com/ja-jp/library/cc261832.aspx

ただ、1PCのクライアントからのテストの段階なので、まずはフォームのデザイン
のような気がしますが、Forms Services/IIS が利用できるメモリなどもパフォーマンス
に大きな影響を与えます。言い換えれば、1PC で解決してもサーバーの構成次第では
複数 PC の利用でパフォーマンスの問題が発生する可能性がある、ということです。

あと、フォームのデザインですが、ビューの中のフィールド（＝コントロール）の数だけ
ではなく、MSDN の記事にもあるように HTML の量という観点からの調整も必要に
なりますね。

たとえばレイアウト用の表などは実行時には見えないものですが、表作成最大の
64 63列 x 100行のレイアウト用の表を作り、いくつかのコントロールを配置し、発行、
実行してみると、あきらかにパフォーマンスが落ちます。これは以前のレイアウト用の
表の挿入、、、のおはなしのなかで、レイアウト用の表は HTML のテーブルに
なる、に関係しています。各セルごとに <tr><td><div></div></td></tr> が HTML
として作成されています。これが 1つのビューに 6400 セットあるわけですから、、、。
HTML の量が多くなりますよね。

[追記] ちょっと確認してみました。直接「ソースを表示」でみても HTML は変わりませんが、
画面上で左クリックしながらドラッグすると、たしかに何もない部分に Table が作られて
いることがわかりました。
JavaScript によって生成されているんですよね。ローカルに保存されている xsn を
zip に変えて以前紹介した方法で view1.xsl を確認すれば、大量の <tr><td>... が
あります。

クリエ・イルミネート
沼口 

沼口様

こんにちは、、お世話になっております。
連休明け、、あいかわらず、休みの頭を戻しつつinfopathに取り組んでます。汗
休みといっても、フォームが夢にでてきてしまいました！爆！！

 パフォーマンスについて、いくつか改善しました。

1. 多少ではありますが、可能なレイアウト枠のカット
   ビューの一部を別ビューに移動
2. データソースの3つのうち、一つをリストボックスの中に埋め込み
3. データソースの1つがかなり大きなもので、アイテムベースで約2000件を参照してました。
   これを、コントロールボタンで、必要箇所に更新ボタンとしてセットし、最初に読み込まないようにしてみました。

これだけで、パフォーマンスかなりあがりました。
順をおって、検証したのですが、一番大きかったのは、３のデータソースでした。
先日紹介してくださった、WSSを検討してもらえるまで、苦肉の策でしたが、今回の件もかなりのお勉強です。

また、前述のベストプラクティス内にある「Windows SharePoint Services ドキュメント ライブラリの 2,000 のドキュメント制限」も
今後の運用に認識しなくてはならないところですね。

パフォーマンス、、なんとか許容範囲に持っていけそうです。引き続きワークフローの格闘もしようとおもいます。
検証できるうちが、いいわけですよね。
ありがとうございました！

aiminさん、numaguchiさん　はじめましてsuzukiでございます。

InfoPathフォームをIPFS上で利用する際のパフォーマンス問題にはずいぶん悩みました。
IPFS君も文書管理システム＋αとしての使い方であれば耐えきれるのですが、
業務システムとしての位置づけで利用するのはなかなか難しいですね。

注意すべき点は、簡単に言えば「シンプルに作る」ことにつきます。

・ビジネスロジックはIPFSにのせないこと
・ドロップダウンリストへの動作規則セットはLoadの際、イベントヘルに陥るので禁忌であること
・ドロップダウン以外でも動作規則はPostbackが走ってしまうのでなるべく使わないこと
　（どうしてもクライアントサイドで使いたいのであれば直接JavaScriptをソースに書く）
・numaguchiさん御指摘の通り、viewX.xslはソースで開いて、ゴミ掃除すること

といったところでしょうか。私の場合、悩んだ挙句、これは、作ることはできても、
実データ、ユーザー数を想定して実用を想定した際、ユーザーに満足して使ってもらえる
プロダクトにはならないと判断し、ASP.NETでスクラッチから作りました。。。
WEBサービスが使いまわせたのでだいぶ良かったですが、悲しかった経験ですね。

少しでもaiminさんの開発、プロジェクトのお役にたてれば幸いです。

ストローハット
鈴木

鈴木さん

 初めまして！アドバイスありがとうございます。

技術的なことは、専門職でもなくわからないのですが、IPFSは「NAT と状態テーブルのための情報を保存/復旧する 」？のことでしょうか。
確かに、シンプルということよりも、あれもこれもと周囲の要件が多くなりつつあります。
できないこと、シンプルがよりよい結果になることをディスカッションしていくしかないところではあります。。
作りとし手としては、、、、、

もちろんアドバイスはよ～くわかりますので、ASP.NETが使えたらいいのですができないわけですし、
スクリプトで作成したとすると、今後のメンテナンスの維持者を考えると、環境的にはむずかしいのかもしれません。
やはり、できうることで、最高のパフォーマンスが出せたらいいなと、奮闘はしてるのですが、、
せめてWEBサービスいれてほしいわけです。

知識不足の私ですがこれからもご教授の程よろしくお願いいたします。

aiminさん

IPFSは、スミマセン、InfoPath Form Servicesの略です。
WEBサービスの導入、役割分担をうまくやることにより、
随分とUI側の負荷は減らすことができるかと思います。
WEBサービスの導入によりプロジェクトが促進すると
いいですね。ではまた！がんばっていきましょー。

ストローハット
鈴木

沼口様

こんにちは。。お世話になっております。

「view1.xsl 」ですが、2007での「ファイル」 → 「ソースファイルとして保存」をすると、フォルダ内に「view1.xsl 」が見ることができますが
この方法でも同じでよろしいでしょうか。
例えば、ソースファイルとして、xsl 内の不要な<tr><td>... を削除したとして、「Xsn」のテンプレートファイルとして成形しなおすには
どのようにすればいいのでしょうか。

またテンプレートを変更すると、「upgrade.xsl」が肥大化していきますか？
技術情報の

InfoPath 2007 フォームのパフォーマンスの改善 (Microsoft MSDN サイト)
http://www.microsoft.com/japan/msdn/office/2007/bb380251.aspx

 では、変更時の読み込みも関係するようですが、変更を初期化して最新を0とするわけにはいかないのでしょうか？
変更ファイル、「upgrade.xsl」？　を常に読み込まないと更新されないのでしょうか。

変更後、名前をつけて別ファイルとして保存した場合には、それが、初版のテンプレートとして登録されるのでしょうか。

同じファイル名で更新を続ければ、「upgrade.xsl」が重くなっていくのではと不安になってますが、、、
ご教授よろしくお願いいたします。

なんとか先がみえてきたようでなによりです。 

まずは view1.xsl は参考として参照されたほうがいいと思います。実際に不要な <tr><td>...を
削除するには、InfoPath の[このフォームのデザイン]でレイアウト表が見えるわけですから、
そこで隣り合っている不要な複数のセル（＝テーブル）をドラッグして選択し、ツールバーの
[セルの結合] をクリックして 1 つのテーブルにするだけで、かなりの数の不要なセル(テーブル)を
削除することができます。

その上で、再発行をかけるわけです。

なので、まずは標準の機能を使いこなすことを考えたほうがよろしいかと思います。