More Related Content Similar to Data-driven Design: 4つの技法InfoPathを用いたスケーラブルSharePointソリューション
Similar to Data-driven Design: 4つの技法InfoPathを用いたスケーラブルSharePointソリューション (20) Data-driven Design: 4つの技法InfoPathを用いたスケーラブルSharePointソリューション1. R2-3:InfoPathウェブフォームで
SharePointの機能をアップ
Data-driven Design: 4つの技法
InfoPathを用いたスケーラブル
SharePointソリューション
2012年6月9日
Qdabra Software (キューダブラ)
ジェイムス リシュ
InfoPath MVP
2. 目次
• データ駆動型デザインとは?
• データ駆動型デザインの利点
• データ駆動型デザインの4つの例
• デモ
– 調査フォームの作成
– ローカリゼーション:UI言語の切り替え
を追加
– Web サービス: XMLデータを SQLのテーブ
ルにマッピング
– 繰り返しデータをテーブルにコピー
3. 「データ駆動型デザイン」と
は?
• データに基づいて動的な挙動を
行うソリューションの設計
• フォームの挙動をハードコード
しない
• ひたすら頑張るのではなく、賢
く省力化する
4. データ駆動型デザインの利
点
• 開発
– 仕様変更に際して、設計変更の労力が少なくてす
む。
– メインテナンスの簡略化
– ロジックの簡略化
– 基本設計は一回で、アップデートはいつでも簡単
– コードへの依存を減らす
• 統一性
– プロセスが複数ある場合にも、統一されたレポート
を作成しやすい。同一のフォーマットを使っている
から。
• 信頼性
– アップデート時にシステム停止なしで移行可能
5. InfoPath:データ駆動型デザイン
を
実現する便利なツール
• Office Professional Plusに含まれる
• フォームはSharePointに展開でき、
ブラウザで入力できる
• 電子フォーム作成のGUI:内部ロ
ジック、データ検証、XMLデータ表
現を含む
• XML webサービスやその他のXML
データ接続を幅広くサポートする
6. InfoPath バリュー・プロッ
プ
• ネイティブXMLサポート
• 使い慣れたOffice UI
• Webサービスにコードなしで接続
• クライアント側でのインストールは必須で
ない
• SharePointページを、InfoPath Webパーツで
デザイン可
7. データ駆動型デザインの例
電子フォーム
• データフィールド:色々な値を扱える
– 例:調査フォームの質問を変更する
• ラベル:ハードコードしない
– 例: フォームの変更なしてで、UI言語を追加す
る
• データクエリは動的に、データ送信は疎結合
で
– 本当に必要なデータのみを取ってくる
– XMLを送信し、 Webサービスでマッピングする
• コードを書かない、少なくともフォーム特有
のコードを書かない
– XPathに依存しない共通ライブラリを使用
– あるいは、ロジックをWebサービスの中に置く
“コードを避ける! 密結合を避ける!”
8. 例: データソース
• 「質問」フォームを使う?
– フィードバック、調査、チェックリスト、テスト、質問表など
• 質問が変わった場合には…?
– フォーム内で変更すると、昔のデータが失われる
– コンテントタイプによるサイド・バイ・サイドは、良さそうな技法だ
が…
– しかし!フォームが急増し、メンテナンスコストの増大を招く
• それぞれに新フォームを作らないこと!
– 一つのフォームですべての変化形を扱う。それがデータ駆動
• 技法
– データソースを汎用に。ファイル名などをハードコードしないように
– フォームロード時に、質問をIDをともに取り込む
– 質問セットの管理に別プロセスを作成
9. デモシナリオ: 調査
• たくさんの調査
– たくさんの質問事項
• たくさんの質問事項
– たくさんの答え
• 目標
– すべての調査を一つのフォームで実現
• なぜ調査ごとに別のフォームを作らな
いか
– メンテナンスが困難 (編集、発行の手間
が増える)
– それぞれを作るのに時間がかかる
– 結果の集計やマージができない
– 質問の統計が取れない
– 質問が変わった場合に、古い調査表を開
けなくなる
10. なぜデータをあらかじめ投
入するのか?
• フォームの記入が速い
• より統一的なデータ入力が期待できる
• 入力値のコントロールが可能
• ユーザへのヘルプとしてデータ例を見せる
• フォームテンプレート数を減らす
• フォームで収集したデータを報告可能なもの
にする
同一テンプレートで作成されたフォーム
データ (XMLファイル) は、スキーマ・レ
ポートを共有する。SQLでレポートを一つ
書けばすべてに適用可能!
11. データ自動投入の手法
• フォームのサンプルデータ
– 規定値データ : うまくデータソースを設計する要
あり
– XMLリソースファイル: データの追加削除が容易
• インターネット上のデータ
– XML config ファイル: 再発行せずにデータの変更
が可能
– SharePoint リスト / ライブラリ: データ更新の分散
化
• ビジネスデータ:SQL、または Webサービス
– SQLデータベース: 内部システムからデータ取得
– Webサービス: オンラインデータベースからデー
タ取得
12. 規定値データは
良いデザインに繋がる
• 理由: データソースをより良く構築すること
になる (ハードコードしない)
• 技法: データ ⇒ 規定値
13. 2つのフォームでの手法
= Data-Driven Design
質問を表示するフォーム Configファイルから読み込み
…
15. 例: ラベルを複数言語で
• 言語ごとに別のフォームをを作らない
– 二度手間、メンテナンスコストの増加
• 複数言語をサポートするフォームを作成
– 言語の追加、ラベルの変更 ⇒ 再発行なしで可能
• どうやってやるの? 意外に簡単!
– UI言語データをセコンダリconfigファイルに格納
• 言語ID
• ラベルID
• ローカリゼーション文字列
– 式ボックスの算出値を使用
– さらに、UI文字列編集のためのフォームを作成
• デモ: 複数UI言語による調査フォーム
18. 例: Web サービス
• フォームにあらかじめデータを設定す
る?SQLに送信する?
– もちろん!
• クエリをハードコードしないこと!
– でないとメンテナンスは悪夢と化す…
• 送信を密結合で行わないこと!
データ喪失が発生しやすい
– データ移行は悪夢と化す…
• こちらの技法を使え!
– UDCファイル
– RESTクエリと動的クエリ文字列
– フォーム全体をXMLの「塊」として送信す
ること。構成可能なマッピングファイルに
従って、リレーショナルテーブルに必要な
データを抽出
• デモ
– 経費報告書をSQLにマップする
21. 例: コード拡張
• ベストプラクティス(お勧めの手法): コード
をフォーム内に書かない!
– メンテナンスに、コード開発者が必要になる
– コード開発者は、XPathsをフォーム内に書きがち
である
• フォーム数が増えてくると…(100以上のフォー
ム?)
– 各フォームが少しずつ違ったコードを持つ
– 費用喰いの悪夢となる…
• 技法
– 共有ライブラリを作成 (あるいはQdabraのqRules使
用)
– データソースXPathsをルール経由でコマンドに渡
す
– あるいは、必要な機能を備えたWebサービスを使
う
(例: Excel RESTサービス)
• デモ
– qRulesコマンド: 繰り返しテーブルに複数項目を挿
24. 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: 会計機能: 支払い、レート、内部収益率等
25. まとめ: Data-Driven Design は
コスト削減に有効
• データソース
– 一つのテンプレートを多様に使用
• ビュー
– 複数UI言語では、ラベルを式ボックスの算出値で表示
• コード
– できるだけ、やめましょう
– どうしても必要ならば、xpathを限定しない共通ライブラリ
で
• Webサービス
– InfoPathでは疎結合のシステムが可能 (XSDを強制)
すなわち…そうしなくても良い!
– クエリフィルタを、Webサービスで解析されるパラメタと
して手渡し
– データを塊として送信し、Webサービス内でマッピング
26. 本日のサンプルパッケージ
?
当講演で用いたサンプルパッケージに興味がある方は…
• MicrosoftのPinPointサイトで
– http://pinpoint.microsoft.com/en-US/home
– Qdabraで検索して、レビューを書く
• または、Twitterでフェードバックをつぶやく
– @QdabraSoftware
• または、facebook.com/qdabraを「いいね!」する
本日のサンプルパッケージをお送りします
– 発表スライド
– Data-driven サンプル: 調査フォーム、複数UI言語による経費報告書
– qRulesとサンプルフォーム: 繰り返しデータをテーブルにコピー
– 3つの無料ラボ:データソース技法の紹介
– ボーナスラボ:InfoPathチェックリストフォーム
Editor's Notes Segue: making the data source data driven works for forms with questions that may change. Most forms, however, have a relatively fixed schema. For example, Expense Report. Next we’ll show how to make the view flexible, indeed data-driven using calculated values. add an optional question to the quiz form?