Data-driven Design: 4つの技法InfoPathを用いたスケーラブルSharePointソリューション

R2-3：InfoPathウェブフォームで
SharePointの機能をアップ
Data-driven Design: 4つの技法
InfoPathを用いたスケーラブル
SharePointソリューション
2012年6月9日

Qdabra Software (キューダブラ)

ジェイムスリシュ
InfoPath MVP

目次
• データ駆動型デザインとは?
• データ駆動型デザインの利点
• データ駆動型デザインの4つの例
• デモ
– 調査フォームの作成
– ローカリゼーション：UI言語の切り替え
を追加
– Web サービス: XMLデータを SQLのテーブ
ルにマッピング
– 繰り返しデータをテーブルにコピー

「データ駆動型デザイン」と
は?
• データに基づいて動的な挙動を
行うソリューションの設計
• フォームの挙動をハードコード
しない
• ひたすら頑張るのではなく、賢
く省力化する

データ駆動型デザインの利
点
• 開発
– 仕様変更に際して、設計変更の労力が少なくてす
む。
– メインテナンスの簡略化
– ロジックの簡略化
– 基本設計は一回で、アップデートはいつでも簡単
– コードへの依存を減らす
• 統一性
– プロセスが複数ある場合にも、統一されたレポート
を作成しやすい。同一のフォーマットを使っている
から。
• 信頼性
– アップデート時にシステム停止なしで移行可能

InfoPath:データ駆動型デザイン
を
実現する便利なツール
• Office Professional Plusに含まれる
• フォームはSharePointに展開でき、
ブラウザで入力できる
• 電子フォーム作成のGUI：内部ロ
ジック、データ検証、XMLデータ表
現を含む
• XML webサービスやその他のXML
データ接続を幅広くサポートする

InfoPath バリュー･プロッ
プ
• ネイティブXMLサポート
• 使い慣れたOffice UI
• Webサービスにコードなしで接続
• クライアント側でのインストールは必須で
ない
• SharePointページを、InfoPath Webパーツで
デザイン可

データ駆動型デザインの例
電子フォーム
• データフィールド：色々な値を扱える
– 例：調査フォームの質問を変更する
• ラベル：ハードコードしない
– 例：フォームの変更なしてで、UI言語を追加す
る
• データクエリは動的に、データ送信は疎結合
で
– 本当に必要なデータのみを取ってくる
– XMLを送信し、 Webサービスでマッピングする
• コードを書かない、少なくともフォーム特有
のコードを書かない
– XPathに依存しない共通ライブラリを使用
– あるいは、ロジックをWebサービスの中に置く

“コードを避ける! 密結合を避ける!”

例: データソース
• 「質問」フォームを使う?
– フィードバック、調査、チェックリスト、テスト、質問表など
• 質問が変わった場合には…?
– フォーム内で変更すると、昔のデータが失われる
– コンテントタイプによるサイド・バイ・サイドは、良さそうな技法だ
が…
– しかし！フォームが急増し、メンテナンスコストの増大を招く
• それぞれに新フォームを作らないこと！
– 一つのフォームですべての変化形を扱う。それがデータ駆動
• 技法
– データソースを汎用に。ファイル名などをハードコードしないように
– フォームロード時に、質問をIDをともに取り込む
– 質問セットの管理に別プロセスを作成

デモシナリオ：調査
• たくさんの調査
– たくさんの質問事項
• たくさんの質問事項
– たくさんの答え
• 目標
– すべての調査を一つのフォームで実現
• なぜ調査ごとに別のフォームを作らな
いか
– メンテナンスが困難 (編集、発行の手間
が増える)
– それぞれを作るのに時間がかかる
– 結果の集計やマージができない
– 質問の統計が取れない
– 質問が変わった場合に、古い調査表を開
けなくなる

なぜデータをあらかじめ投
入するのか?
• フォームの記入が速い
• より統一的なデータ入力が期待できる
• 入力値のコントロールが可能
• ユーザへのヘルプとしてデータ例を見せる
• フォームテンプレート数を減らす
• フォームで収集したデータを報告可能なもの
にする
同一テンプレートで作成されたフォーム
データ (XMLファイル) は、スキーマ・レ
ポートを共有する。SQLでレポートを一つ
書けばすべてに適用可能！ 

データ自動投入の手法
• フォームのサンプルデータ
– 規定値データ : うまくデータソースを設計する要
あり
– XMLリソースファイル: データの追加削除が容易
• インターネット上のデータ
– XML config ファイル: 再発行せずにデータの変更
が可能
– SharePoint リスト / ライブラリ: データ更新の分散
化
• ビジネスデータ：SQL、または Webサービス
– SQLデータベース: 内部システムからデータ取得
– Webサービス: オンラインデータベースからデー
タ取得

規定値データは
良いデザインに繋がる
• 理由: データソースをより良く構築すること
になる (ハードコードしない)
• 技法: データ ⇒ 規定値

２つのフォームでの手法
= Data-Driven Design

質問を表示するフォーム Configファイルから読み込み
…

デモ
• データ駆動型データソースの作成
– ラボ 1: データ駆動型の調査フォームを作成
– ラボ 2: 質問事項をフォームの外で設定
– ラボ 3: 別フォームで質問事項を編集

例: ラベルを複数言語で
• 言語ごとに別のフォームをを作らない
– 二度手間、メンテナンスコストの増加
• 複数言語をサポートするフォームを作成
– 言語の追加、ラベルの変更 ⇒ 再発行なしで可能
• どうやってやるの? 意外に簡単!
– UI言語データをセコンダリconfigファイルに格納
• 言語ID
• ラベルID
• ローカリゼーション文字列
– 式ボックスの算出値を使用
– さらに、UI文字列編集のためのフォームを作成
• デモ: 複数UI言語による調査フォーム

経費報告書テンプレート
複数UI言語用

デモ
• 複数UI言語に対応した経費報告書
– 経費報告のローカリゼーション
– 言語文字列編集用のフォーム

例: Web サービス
• フォームにあらかじめデータを設定す
る？SQLに送信する?
– もちろん!
• クエリをハードコードしないこと！
– でないとメンテナンスは悪夢と化す…
• 送信を密結合で行わないこと！
データ喪失が発生しやすい
– データ移行は悪夢と化す…
• こちらの技法を使え！
– UDCファイル
– RESTクエリと動的クエリ文字列
– フォーム全体をXMLの「塊」として送信す
ること。構成可能なマッピングファイルに
従って、リレーショナルテーブルに必要な
データを抽出
• デモ
– 経費報告書をSQLにマップする

良いWebサービスとは?
XMLクライエントとSQLデータベー
スを、緩やかに結合するデータブ
リッジ

デモ
• 経費報告書をSQLにマップ
• データをSQLからクエリ

例: コード拡張
• ベストプラクティス（お勧めの手法）: コード
をフォーム内に書かない！
– メンテナンスに、コード開発者が必要になる
– コード開発者は、XPathsをフォーム内に書きがち
である
• フォーム数が増えてくると…(100以上のフォー
ム?）
– 各フォームが少しずつ違ったコードを持つ
– 費用喰いの悪夢となる…
• 技法
– 共有ライブラリを作成 (あるいはQdabraのqRules使
用)
– データソースXPathsをルール経由でコマンドに渡
す
– あるいは、必要な機能を備えたWebサービスを使
う
(例: Excel RESTサービス)
• デモ
– qRulesコマンド: 繰り返しテーブルに複数項目を挿

カスタムコードの場合

デモ
• 繰り返しデータのコピー
– 規定値データとセット
– qRules挿入

Qdabra製品紹介: qRules v4.2、 6月発売予
定複数リストへのマッピング： SharePointリストをデータベースと
して使用
• SubmitToSharePointListの改善：より簡単に複数リストへのマッピングを可能に
SharePointへの保存: ビデオや巨大ファイルをアップロード
• SaveToSharePointの改善：バックグラウンドでのアップロード
• バックグラウンドでアップロード中にもフォームの編集が可能
• 『処理中』インディケータが、完了％を表示
文字列コマンド：文字列操作のための新しいコマンド群
• CompareStrings: 文字列比較。規定値では大文字小文字の違いを無視
• PadString: 文字列の右あるいは左に指定文字を埋め込み
• GetIndex: 検索文字列の位置を返す
• RemoveFromString: 指定文字列を削除
• ReplaceString : 指定文字列で置換。正規表現による複雑なパターンマッチングも可能!
• SetCase: 大文字に、あるいは小文字に変換
• TrimString: 指定文字を文字列頭あるいは文字列末より削除
算術コマンド: 計算のための新しいコマンド群
• 三角関数コマンド: Acos, Asin, Asin, Cos, Cosh, Tan, Tanh 等
• 切り捨て、切り上げ、丸め：フィールド値を整数に変換
• Pow, Exp, Sqrt
• TBD: 会計機能：支払い、レート、内部収益率等

まとめ: Data-Driven Design は
コスト削減に有効
• データソース
– 一つのテンプレートを多様に使用
• ビュー
– 複数UI言語では、ラベルを式ボックスの算出値で表示
• コード
– できるだけ、やめましょう
– どうしても必要ならば、xpathを限定しない共通ライブラリ
で
• Webサービス
– InfoPathでは疎結合のシステムが可能 (XSDを強制)
すなわち…そうしなくても良い! 
– クエリフィルタを、Webサービスで解析されるパラメタと
して手渡し
– データを塊として送信し、Webサービス内でマッピング

本日のサンプルパッケージ
?
当講演で用いたサンプルパッケージに興味がある方は…
• MicrosoftのPinPointサイトで
– http://pinpoint.microsoft.com/en-US/home
– Qdabraで検索して、レビューを書く
• または、Twitterでフェードバックをつぶやく
– @QdabraSoftware

• または、facebook.com/qdabraを「いいね!」する

本日のサンプルパッケージをお送りします
– 発表スライド
– Data-driven サンプル: 調査フォーム、複数UI言語による経費報告書
– qRulesとサンプルフォーム：繰り返しデータをテーブルにコピー
– 3つの無料ラボ:データソース技法の紹介
– ボーナスラボ：InfoPathチェックリストフォーム

 InfoPathソリューション開発の実績No１
 最も多くのInfoPathMVPs
 最大のリソース：ブログ、ツール、フォー
ム等
 最先端のトレーニングクラス
 毎週の無償webinars

 InfoPathDevフォーラム 2003年創立
• 50k ユニークビジター / 月
• かならずお答えします

どうも有難う
ございました

Data-driven Design: 4つの技法InfoPathを用いたスケーラブルSharePointソリューション

More Related Content

Viewers also liked (15)

Similar to Data-driven Design: 4つの技法InfoPathを用いたスケーラブルSharePointソリューション (20)