2013-01-17

IWP(インスタントWeb)導入の可否

 インスタントWeb(IWP、Instant Web Publishing)とは、FM社公式サイトによると「さまざまなフォームをワンクリックでWebに公開すること」。
 ワンクリックはさすがに言い過ぎと思うが、FileMakerで作成したデータベースのデータを非常に簡単にWeb公開できるのは事実だ。

 同時利用者が数十でデータの照会と検索だけでことたりるシステムであればIWPは有力な選択肢となりうるし、そのような用途であれば海外で多くの導入事例がある(後述)。
 にもかかわらず、FileMaker社(FM社)のIWPに対する立ち位置は微妙な感じ。

 試しにFMの導入事例が紹介されている日米のFM社のWebサイトの「FileMaker カスタマ・ヒストリー(FileMaker Customer Stories)」と銘打ったページを見てみると、iPadやiPhoneの導入事例は数多くあるのに対し、IWPに関する事例が非常に少なく、日本のサイトで1つ、米国のサイトで2つしか見つからなかった。
 これはFM社のIWPに対する立ち位置が微妙なるがため、と思われる。なぜか? 

 上述のように、同時アクセスユーザが数十、かつレコードの検索と照会だけであれば有用なIWPも、いったん、データの入力・更新が要求されると、多くの制約が発生してくる。

IWPの制約

「filemaker IWP」でググると、Top 10 Instant Web Publishing No-No’sなるページリンクが表示される。
 このページは「IWPの禁忌TOP10リスト」とも訳すべきページで、FileMakerではできるのにIWPでは互換性がないまたは実用に適さない機能のTOP10をリストしている。 

 以下意訳、つか編訳。
  1. 新規ウインドウは開けない
  2. 動的値一覧は使うな ― 動作しないことは無いが遅いので使わないが吉
  3. リストレイアウトは使うな ― 使えるが25行しか表示されない、なんでポータルを使おう
  4. 角が丸いオブジェクトは表示不可 - 角丸ボタンは四角で表示される
  5. 条件付書式は機能しない
  6. スクリプトトリガも機能しない
  7. ダイアログ表示のスクリプトも不可 - なんでグローバルフィールドにメッセージ表示するとか
  8. 自動保存オプションも不可
  9. Excel/Word/PDF等のファイルの挿入も不可(fx.phpを使って無理矢理サーバへファイルアップしたり
  10. レコードのインポート/エキスポートも不可
※IWPの制約については、以下のリンクも見てね
FileMaker Instant Web Publishing, Part I: Is IWP Right For You? (英語)


日本はともかく、外国はどうなん?


 上記の制約をみると、IWPの採用に二の足を踏む開発者やWeb担当者は多いと思う。
 減点法ベースの日本人は家電でもAV機器でも、機能がテンコ盛りのモノを好む。目的指向ではなく、減点指向。

 ただ、HTML、JavaScriptやPHPを1行も書かずにWebアプリを作成できる可能性を端から排除してしまうのは、開発コスト、FMクライアントライセンス費を考えるとあまりに惜しい、状況もある。
 では目的指向的、合理主義的な米国ではどうか。

 下図は「FileMaker インスタントWeb」(青)と「FileMaker Instant Web」(赤)の検索件数の比較である。
 青線が100%日本で実行されていてこれが1であるのに対して、赤線は100%米国で実行されていてこちらは23、つまり日本と米国ではIWPへの関心に極端に差があることになる。





 では実際の導入状況はどうか、ググって見た。
 URLに「"fmi/iwp"」を含むサイトを言語別/地域別で検索してみると以下のような結果となる(2013/1/22現在)。

言語別IWP導入状況
サイト言語 サイト数
日本語 220
英語 4,040
全言語 5,180
地域別IWP導入状況
地域 サイト数
日本 448
米国 2,190
全地域 5,180
注:図にはイントラネットや検索エンジン忌避対策を施しているサイトは含まれない。


 対英語比では約18倍、対米国比で約5倍(人口を考慮すると約2倍)、導入状況に差がある。

で、どういうときに使うん?

実際問題、IWPはどういうときに使えるのか。
 「アプリの性能よりも開発工数を抑え、コストを抑えることが第一」、「Webアプリを社内開発したいが、PHPやASPXの技術者を養成または雇用するのは厳しい」という方、以下を参考にしてみてはいかが。
  1. 高速なアプリを求めない
  2. IWPはFileMakerのスクリプト(実行可能スクリプトステップに上記の制限あり)でしか制御できないのため、実行速度を上げるたの作り込みができない。IWPに関する経験値が不足している場合、プロトタイプを作成して最低限の実行速度が出るかテストを行うことも必要。

  3. 高度な可用性を求めない
  4. 24時間/365日稼動みたいなシステムには使用しない。何かあったら、関連サービスを再起動できるような余裕がないと…

  5. 大規模なシステムにならない
  6. レコード数が数百万を超えるようなものは…、避けよう。

  7. Coolなユーザインタフェイスを求めない
  8. 上述のような制約があり、またJavaScriptをページに埋め込みブラウザを制御するようなこともできない(WebViewerを使うという抜け道がないこともないが…)。GoogleのようなCoolなインタフェイスを求めても無理。
 上記条件に合致し、IT責任者が今回はIWPの導入が適切と判断しても、「黙って俺について来い!」といえないような環境では、本開発の前にプロトタイプを作成して、関連部署のコンセンサスをとることも必要となるのだろう。


世界の大学や公共機関で使われるIWP

 ということで、目的合理性を解する大学、研究機関や政府・公共機関でIWPが使われていたりする。



以上

(土屋)



参考サイト:
全国90拠点、グループ社員5,000名が利用するWeb社内販売システム(日本のIWP導入事例)
Coach Source — A Fountain of Wisdom(米のIWP導入事例)
FileMaker Instant Web Publishing, Part I: Is IWP Right For You?
FileMaker Instant Web Publishing, Part II: Five Top Tips for Success



【IWP関連記事】

【弊社のIWP関連製品・サービス】

2013-01-16

FileMaker IWP (インスタントWeb公開) 上で JavaScript を使い、ページのリロードと印刷を行う方法

 FileMaker Pro/FileMaker Pro Advanced, FileMaker Server Advanced で インスタントWeb公開(Instant Web Publishing, 本記事では IWP で統一)を行うと、FileMaker Pro で開発したレイアウトをそのまま Web に公開してデータベースの更新や照会ができるようになります。

 現行で最新バージョンとなっている FileMaker 12 では、FileMaker Pro/FileMaker Pro Advanced の場合は、最大 5 ユーザまで Web での同時使用が可能となっており、これに対し、FileMaker Server Advanced の場合は最大 100 ユーザまで Web での同時使用が可能です。


 ただし、FileMaker Pro 本体に比べると、IWP には仕様上の制限があるため、開発時にそれらの制限を十分に考慮する必要があります。

 IWP でできないことは以下のとおりです。
  1. オブジェクトフィールドへのファイルのアップロード
  2. データのインポート/エクスポート
  3. FileMaker Pro のデータから PDF ファイルや Excel ファイルを作成
  4. FileMaker Pro のレポート閲覧
  5. レイアウト、レポート、スクリプト作成
  6. 警告音、メッセージポップアップ表示
  7. 印刷コマンド実行
 また、この他にもスクリプトトリガ、スクリプトステップ、条件付き書式などでも IWP に対応していない動作がありますので、FileMaker Pro 本体と IWP を併用する形でデータベースを運用する場合は、FileMaker Pro 側と Web 側での動作の違いに気を付けながら開発を進める必要があります。


 さて、今回は、上記に示した IWP の仕様制限のうち、1. オブジェクトフィールドへのファイルのアップロード、および 7. 印刷コマンド実行について対応方針を考えてみることにします。


【オブジェクトフィールドへのファイルのアップロード】

 オブジェクトフィールドそのものへファイルをアップロードする代わりに、php を使って Web サーバ上にファイルをアップロードし、そのファイルへのリンクを FX.php を使って FileMaker Pro データベースに書き込みます。

 FileMaker Pro 側の設定は、レイアウト上に以下のような Web ビューアを配置し、アップロード処理および FX.php 書込み操作を記述した php ファイルを指定します。



 php ファイルは Web サーバ上に配置してください。また、[Web ビューア内容とのインタラクションを許可] チェックボックスには必ずチェックを入れておきます。

 そのあと、IWP でデータベースを開くと、たとえば以下のようなページが表示されます。


 イメージとしては、ファイルアップロード後は、矢印が示すフィールド [FileURL] にそのファイルへのリンクを表示させるようにしたいわけですが、FX,php はバックグランドで操作されますので、ここは動的には変化しません。

 これを、JavaScript コマンドをページアップロード後に呼び出されるように組むことで、ページをリロードさせて反映させようというわけです。

 画面上に、「この部分が Parent」と表記しておりますが、Web ビューア(ピンク色)を自分自身とした場合、外のエリア(紫)が親 (parent) となりますので、JavaScript では parent に向けて処理をするようにします。



 parent.location.reload();


リロード後のイメージ



 FX.php を使った FileMaker Pro データベースへのデータ書込の話題は、以下の記事群をご覧ください。

【印刷コマンド実行】

 FileMaker Pro の印刷コマンドは、IWP では実行できません。
これでは、顧客一覧、見積書、請求書などの帳票を IWP で印刷したいときに不具合があります。

 この対策として、上記のファイルアップロード例と同じ要領で Web ビューアを配置し、印刷ボタンを配置したページを指定します。





 ファイルには、フォームの 印刷ボタンをクリックすると、JavaScript で以下のような関数を呼び出し、 parent ページを印刷するようにします。



function reportprint()
{
parent.focus();
parent.print();

}



 これにより、Web ブラウザの印刷ダイアログが表示されます。



 上図のように、印刷ボタンの部分もページとして印刷されてしまいますので、Web ビューアを配置する場所は 2 ページ目の先頭あたりにくるようにし、印刷時は 1 ページ目を選択するようにすると都合が良いでしょう。

以上

(亀澤)



【IWP関連記事】

【弊社のIWP関連製品・サービス】




2012-12-20

簡単? FileMakerで在庫管理(3) ―― 倉庫など場所別に在庫数を把握する

 弊社では在庫管理システムの講習を行っていますが、時折「うちは在庫の保管場所が複数あるので、保管場所毎に在庫を管理したいのだが、おたくの講習は対応できる?」との問い合わせを受けることがあります。 

 実のところ、複数の在庫場所に対応した在庫管理システムの構築は難度が上がってしまうのですが、なんとかコアの部分だけでも本記事でご説明させていただきます。

倉庫など場所別に在庫数を把握する


 ここでは、『FMEasy在庫 R1.0』で複数の在庫場所を管理できるように、仕様変更してみることにします。
 これまでに弊社の在庫管理講習を受講された方、または『FMEasy在庫R1.0(開発版)』ユーザ、倉庫別在庫管理の考え方を学びたい方の参考になれば幸いです。

  1. テーブル設計
    1. 在庫場所テーブル (新設、倉庫/保管場所等管理用マスタ)
      • ID(主キー)
      • 場所名(テキスト)
    2. 場所別在庫TB(新設)
      • ID(主キー)
      • 場所ID(外部キー)
      • 商品ID(外部キー)
      • 導入時在庫数(数値、導入時に元々あった商品在庫数を在庫場所別に記録)
      • 繰越在庫数(数値、繰越処理実行時に特定時点の商品在庫数を在庫場所別に記録)
      • c場所別在庫数(場所別在庫算出用計算フィールド)
      • g在庫基準日1/g在庫基準日2(入出庫の期間特定用グローバルフィールド)
    3. 入庫テーブル/出庫テーブル(変更)
      • 入庫場所ID/出庫場所ID(新設、入出庫場所を登録)
    4. 入出明細TB(変更)
      • 在庫場所ID(新設、入庫テーブル/出庫テーブルの入庫場所ID/出庫場所IDをコピーする)

  2. リレーションシップ設計

  3. レイアウト(LAY)/スクリプト設計
    1. 在庫場所LAY(新設、場所別の在庫数をポータルに表示)
    2. 入庫LAY/出庫LAY(変更)
      • 入庫場所ID/出庫場所IDを配置する
      • OnRecordCommitで入庫場所ID/出庫場所IDを入出明細テーブルの在庫場所IDフィールドにコピー
      • OnRecordCommit時、必要に応じて場所別在庫レコードを作成(4-a参照)

  4. 考慮すべき事項
    1. 場所別在庫レコードを作成するタイミング
    2. 複数倉庫がある等、場所別に在庫を管理しようとすると、FileMakerの場合、どうしても場所別に商品を登録しておく専用テーブル(場所在庫テーブル)が必要になる。そこで、場所別在庫レコードを登録するタイミングが問題となる。余分なレコードをテーブルに極力保持しないためには、入出庫レコード登録時(OnRecordCommit)に、未登録商品の場所別在庫レコードを登録するように制御する。 
    1. 倉庫間移動に対応
      • 出庫時、倉庫1の出庫伝票を、入庫時、倉庫2の入庫伝票を作成
      • 倉庫2の入庫伝票作成漏れを防ぐ
      • 倉庫2の入庫伝票作成後の関連伝票更新をどう考えるか?
    2. 出入庫同時作成機能(商品の近接場所間移動時)
    3. その他


リレーションシップ


 まず、テーブルでキモとなるのが場所別在庫テーブルですね。このテーブルにより、場所別に商品在庫数の算出が可能となります。
 ここで特に重要なフィールドは、在庫場所ID、商品ID、c場所別在庫数(計算フィールド)です。なお、下図で場所名と商品名は商品テーブルと在庫場所テーブルを参照しています。

【場所別在庫テーブルを表形式レイアウトに表示】



在庫算出部分のリレーション。

↓ 


 入出明細テーブルには商品ID/在庫場所ID(出庫元/入庫先の在庫場所ID)と入出庫数が登録されているわけだから、入出明細テーブルと場所別商品在庫テーブル上記のようにリレートして、以下のように計算式フィールをを作ればよいでしょう。 

元々ある在庫+特定期間のSum(入庫数)-特定期間のSum(出庫数)

注:
 「元々ある在庫」は繰越処理が未実行であれば[導入時在庫数]、実行済であれば[繰越在庫数]となり、「特定期間」はユーザが指定する[g在庫基準日1]と、[g在庫基準日1]のOnObjectValidate/Saveで起動するスクリプトにより制御された[g在庫基準日2]の値により決まります。
 [g在庫基準日2]の設定値については、「簡単? FileMakerで在庫管理(2)」の図が参考になると思います。

 他にもリレーションシップの追加はあるのですが、難しくないので省略します。


レイアウトとスクリプト


 入庫/出庫レイアウトには、それぞれのテーブルで新設した[入庫場所ID]と[出庫場所ID](入出庫した場所を示すID)を登録し、OnRecordCommit時に入出庫明細テーブルの[在庫場所ID]にコピーします。
 なお、Commit時に、入出明細テーブルに入力されている[商品ID]で場所別在庫テーブルに未登録の商品は登録するという、第2のキモともいうべきスクリプトについては、できれば機会を改めて書きたいと思います。

【出庫レイアウト】


 最後に在庫場所別に商品在庫数を表示するレイアウト。ユーザが[在庫基準日]に日付入力することにより、その日付時点の各商品の在庫数が表示されます。


【在庫場所レイアウト】

ポータル部分に在庫数(=場所別在庫::c場所別在庫数)と商品テーブルの情報が表示されます。
以上、『FMEasy在庫』というテンプレートをベースにカスタマイズしてみましたが、半日強の時間でとりあえず場所別在庫数は表示できるようになりました。
 上述の場所別在庫のレコード作成処理や、繰越処理は別途作成しなければなりませんが、意外と実装に時間はかかりませんでした。


 (土屋)