アンインストール、修復、インストールのいずれも出来なくなりました。Ver2.3では、XML文書をSharePointにマップする機能が追加されました。これによって、DBXLを用いたアプリケーションでは、XML文書のデータ保管場所として以下の3つが可能になりました。経由して、マッピングで指定したSharePointに保管SharePointユーザーがDBXL2.3を導入すると、今までどおりSharePointを使いながらも、SQLのデータを使ってSQLレポーティングやその他便利なSQL機能を使うことができます。XML文書を扱う際のパフォーマンスの向上も、大きな魅力であります。本文書ではDMXLによるパフォーマンス向上に関しての実験結果を示します。文書をSharePointに送信して、所要時間(秒数)を計測。文書としては、InfoPath2007製品に付属の経費明細書を使用した。通常のSharePoint【青】:SharePointフォームライブラリを作成し、文書を送信する(自動送信用バッチを作成して使用)SharePoint+DBXL【赤】:DBXLで文書タイプを作成し、DAT(DBXL管理ツール)を用いてSharePointにマップするよう設定。1と同じ文書をDBXLに対して送信する。結果としては、DBXL経由でSharePointに送信されて、1と同様の文書がSharePoint上にできることになる。1624.64送信した文書数で所要時間を割り、1文書あたりの秒数をグラフにしたのが下記の図である文書数にかかわらず、所要時間はほぼ一定であることが分かる。DBXLを経由して送信した場合(1~3秒)には、直接SharePointに送信した場合(6~7秒)に比べて格段に速いことが示される。次に、よりクライエントの体感に近い測定を行ってみよう。文書一個を送信して各回の所要時間を測定した。20回測定した元データ、および平均と標準偏差のグラフを以下に示す。V2.3にはSharePointのリストを取得する機能もあります。webメソッドを使用した場合のパフォーマンスを比較してみます。【実験B-1】InfoPathフォームを作成し、このリストをon-loadでロードするときの所要時間を測定。クエリデータ接続を使用。webメソッドを使用。17.42秒、標準偏差3.1秒。DBXLのwebサービスを導入することにより、3000個強のリストを取得するのに、78秒から17秒と大幅に所要時間が短縮されましたが、さらにはQuerySharePointにはサーバー側でのフィルタリング機能もあります。フィルタリングすると約3000件すべてをロードしなくてもよいので、さらなるスピードアップが期待できます。次の段落では、フィルタリング機能を用いたときの実験結果を述べます。【実験B-2】InfoPath製品に付属の出張申告書で、目的地のフィールドを州と郡の2つのドロップダウンリストに変更する。州の欄は、先のSharePointリストから州名のクエリを行ってユニークな値を設定。On-loadの所要時間を測定すると、11.78±1.53秒(10回の計測による平均および標準偏差)となった。(このやり方では約3000件のダウンロードが発生しているために、10秒以上もかかっている。その後ユニークな値を抽出すると50に絞られるが、州名のように固定した値の場合には、別にリストを準備した方が良い実現方法といえよう)さて、ユーザーがドロップダウンから州名を選んだら、InfoPahフォームは、QuerySharePointでフィルタを指定して、SharePointのリストからその州の郡名を取得する。その際の平均所要時間は2.52±0.16秒となった。V2.3の新機能であるQuerySharePointのフィルタリング機能を活用することによって、リストをロードする際の体感速度がさらに向上することがご理解いただけるかと思います。