2014-07-27

受注・受注残管理モジュールを作る(2)テーブル、リレーション、レイアウトの設計 ― FMEasy在庫のカスタマイズ

 受注残は面倒なので脇に置いておき、まず受注モジュールを作ります。
 作業にあたり、カスタマイズする『FMEasy在庫 R1.0/R1.5』は分離モデル(注)を採用しているため、作業するファイルが2つ ― EasyApp15.fmp12とEasyData15.fmp12 ― あることに注意してください。

 EasyData15.fmp12 は業務データ用のファイルで、原則として業務用テーブルに加え、業務用テーブルの計算フィールドに使用する最小限のリレーションを含みます。
 EasyApp15.fmp12 はアプリケーション/システム用のファイルで業務用テーブルは含まず、アプリ用のテーブルとリレーション、レイアウト(画面や帳票)、さらに業務ロジックを組み込んだスクリプトを含んでいます。

 作業に際しては、このことを念頭に混乱のないよう作業を進めてください。

注:『FMEasy在庫 R1.0/R1.5』は テンプレートですので、データファイルとアプリファイルの分離度は高くなっていません。
 分離度を高めるためには、データファイル(EasyData.fmp12)では計算フィールドやフィールド制御は極力行わないように設計します。

受注モジュールのテーブル、リレーション、レイアウト、スクリプトを作る

 受注モジュールは出庫モジュールと類似していますので、出庫関連のテーブル、リレーション、レイアウト、 スクリプトをある時はコピー・変更し、あるときは直接変更し、またあるときは変更することなく共用します。

 『FMEasy在庫 R1.0/R1.5』は、最小限の労力で他の類似モジュールを追加できるよう設計しています。

EasyData15でテーブル/フィールドを作成・定義する

 まずはテーブルから作成します。EasyData12.fmp12の出庫/入出明細テーブルを下図のように選択し、コピペし、それぞれの名称を「受注」と「受発注明細」に変更します。

 入出明細テーブルは、出庫明細と入庫明細の共用テーブルであるため、今後発注モジュールに対応することを想定して「受発注明細」という名称にしておきます。

※本稿では原則として発注には触れませんが、発注関連モジュールも開発する場合、発注関連のテーブル/リレーション/スクリプトも作成しておく方が効率的です。

図1.出庫、および入出明細テーブルをコピー&ペーストして、受注、および受注明細テーブルを作る

 2テーブルの名称を変更したら、その中のフィールド名を変更(図3/4)。

注:
  • フィールド名は後述の図3と図4に準じること(変に変更すると、スクリプトの変更が大変になる)
  • フィールドの変更・削除は極力しない→動作しなくなる
  • 入庫関係のフィールド名は、発注モジュールを作成する場合に備えそれらしく変更しておく(入庫No→発注No)
なお、受注用のリレーションが無いと設定できない計算フィールドは、下記のリレーションシップを設定後に定義します。

EasyData15でリレーションシップを作成する

 EasyData15.fmp12 のリレーションシップは出庫TOG(Table Occurence Group)をコピペし、出庫TOGに準じて下図のオレンジのTOG のように設定します。
なお、、リレーションシップも複数選択してペーストができます。

図2.出庫レイアウトTOG をコピー&ペーストして受注レイアウトTOGをつくる

 リレーションシップを正しく設定すると、<不明>あるいは<フィールドが見つかりません>と表示されていた計算フィールドを定義できるようになりますので、これも出庫/入出明細の計算フィールドに準じて定義していきます。

図3.リレーションシップを設定後、受発注明細テーブルのフィールドを再定義

図4.リレーションシップを設定後、受注テーブルのフィールドを再定義

EasyApp15でリレーションシップを作成する

 EasyApp15.fmp12 のリレーションシップも出庫TOG(Table Occurence Group)をコピペし、出庫TOGに準じて下図のように受注レイアウトTOGを設定します。

 赤枠の部分の「得意先List」と「出庫商品List」はUIテーブルとのリレーションシップであるため各レイアウトから共用できるので、受注側での作成は不要となります。
 また、濃い青の3つのTO(Table Occurence)はIWP(インスタント)専用であるため今回は作成しませんが、受注モジュールをIWPに対応させる方は作成する必要があります。

 なお、TOの名称は下図に準じるようにしてください(変な名称を付けると、スクリプトの変更が大変になってしまいます)。


レイアウト/値一覧を作成する

 受注用レイアウトは EasyApp15 側でのみ作成します。出庫レイアウトをレイアウトモードで表示し、[レイアウト]―[レイアウト複製]を選択します(一種のコピペ)。
図の赤枠内のように、レイアウト名を「出庫のコピー」から「受注」に、レイアウトテーブルを「出庫」から「受注」に変更します。


 この段階ではフィールド/ポータルは出庫または入出明細のものが貼られているので、フィールドをダブルクリックしながら、受注/受注明細関連のものになるように変更していきます。
 また、出庫No/出庫日、出庫などのレーベル名も適当なものに変更しましょう。また、変更漏れがないように注意するようにしてください。

 値一覧は、伝票区分、担当ID、得意先ID、商品ID、請求部署ID、数量、単位の各フィールドで使用されているが、変更する必要があるのは、伝票区分と請求部署IDに割り当てられているもののみ。

 ここまで、慣れている人であれば1~2時間でできると思われますが、次のスクリプトからがかなり作業が複雑になってきます。

注:
 受注一覧、受注伝票の各レイアウトも実務では必要になると思われるので、前者については出庫一覧レイアウトを、後者については入庫伝票レイアウトを上記の要領でコピーして作成してください。

スクリプトを変更する

 さて、出庫レイアウトをコピーして作った受注レイアウトは以下のようになります。
 ボタンに割り振られたスクリプトだけではなく、フィールド/レイアウト等に割り振られたスクリプト(赤枠部)もひとひとつ変更が必要かどうか吟味し、必要があれば変更を加えていきます。

 スクリプト変更はかなり骨が折れる作業で、下手に変更を加えると他のモジュールに障害を与えることがあるので慎重に作業してください。 変更後のテストも十分に行う必要があります。



 下表はスクリプトが割り振られたオブジェクトの一覧です。
 チェックマークが付いてるものは変更が必要になります。
*1 『FMEasy在庫 IWP/WD R1.5』でのみ利用可。変更難度高し。“選”ボタンを受注対応させない場合、レイアウトから削除すること。


以上

 
(土屋)

2014-07-18

受注・受注残管理モジュールを作る(1)概要と開発方針― FMEasy在庫のカスタマイズ

 弊社に寄せられる各種問い合わせで多いのがモジュールの追加 ― 「売上入金残管理モジュールを作りたい」、「受注残管理をしたい」といったものです。
 これらの質問はあまりにカバーする範囲が広く、また漠然としているので、回答も漠然としたものになります。

 そこで今回から数回にわたり、『FMEasy在庫 R1.0/R1.5』をカスタマイズし、受注・受注残管理モジュールを付加する方法の概要ご説明したいと思います。 

機能概要

  • 受注管理
  • 入力支援機能(FMEasy在庫 IWP/WD R1.5 のみ)
  • 受注伝票毎及び得意先毎の受注残管理 
  • 受注明細レベルで分納に対応する


用語

  • 在庫 ― 商品の入庫数計-出庫数計
  • 受注残 ― 商品の受注数計-出庫数計
  • 可用在庫 ― 在庫-受注残


注:
 弊社では商品の[在庫]から[受注残]を差し引いた値を[可用在庫]と呼んでいます。意味としては、倉庫に物理的に存在するだけではなく、買い手が決まっておらず(受注残となっていない)、得意先から注文があればすぐに出庫できる状態にある在庫です。
 逆に、倉庫に物理的に存在していても、買い手が決まっていて何らかの事情により倉庫に留め置かれている在庫は、出庫不能な在庫(非可用在庫)となります。


画面イメージと移植する機能

 弊社が2004年6月にリリースした「FlexManager R1.5」という製品の受注・受注残モジュールの一部を『FMEasy在庫』に移植します。下図はそのオールド製品の画面です。


【受注】

受注画面
 受注情報を入れる画面。この画面から必要最低限の機能を『FMEasy在庫』に移植します。


【受注残管理】
受注残管理画面

 受注残管理画面。受注残管理だけではなく、受注情報を利用した発注処理、その発注に対する入荷情報の表示(画面の[発注数(内入荷)])にも対応していますが、今回は発注・発注残管理機能には触れません。この画面から、受注残管理の必要最低限の機能を『FMEasy在庫』に移植していきます。


【分納管理】

分納管理画面

 受注商品データを売上に移行するための画面。新規に売上伝票を作成して(“新”ボタンを使用)そこへ受注データを移行することも、既存の売上伝票([売上No]をプルダウンメニューから指定)の売上明細に受注データを付加することもできます。なお、『FMEasy在庫』では売上モジュールはなく、代わりに出庫モジュールへ移行することになります。

開発方針

 「FlexManager 1.5」は結構機能がテンコ盛なので、複雑になりすぎないよう、受注残管理に焦点をあてて、必要最低限の機能を移植したいと思います。 (次回へ続く)



(土屋)

2014-06-30

インスタント Web/WebDirect対応在庫管理テンプレート『FMEasy在庫 IWP/WD R1.5』を本日リリース

 本日、『FMEasy在庫 IWP/WD R1.5』(フリー版)のダウンロードと販売を開始。


 ホントは昨年末にインスタントWeb(IWP)に対応の「FMEasy在庫 IWP R1.5」としてリリースする予定が、同時期に IWP の後継WebDirect(WD)を含む FileMaker Pro 13 がリリースされ、「タイミング、悪!ヽ(`Д´)ノ」、 と思いつつ、「WDにも対応させよう」と思い直し、艱難辛苦の末、今日を迎えることができました\( ̄▽ ̄;)/。


 以下、 本製品についての若干のご説明。


製品概要


  『FMEasy在庫 R1.0』 に検索・入力支援機能を付加し、インスタントWebとWebDirectに対応させたのが本製品です。


製品種類

  • フリー版(無料) ― データ入力無制限
  • 開発版(価格:¥54,000、税込) ― FileMaker Pro 12/13 Advancedにより開発可

 本製品リリース後も、在庫管理テンプレート『FMEasy在庫 R1.0』(フリー版/開発版 ¥26,250)は引き続きダウンロード/購入可。

開発方針


こんな感じで開発してみました。

  1. インスタントWeb(IWP)/WebDirect(WD)の両方に対応させる
  2. 入出庫・在庫の基本機能は『FMEasy在庫 R1.0』をそのまま踏襲
  3. FileMaker/IWP/WD間で、できるだけレイアウトを共有する(下記※参照)
  4. 検索・入力支援機能 ― 取引先または商品のレコードが千~1万件を超す場合、FileMaker標準の 関連フィールドによる値一覧は実用に耐えない(特にWeb環境下) ― ので、検索・入力支援機能を搭載する(後述)
  5. 検索・入力支援機能の流用性 ― 本製品をカスタマイズして売上/入金/仕入/支払/受注/発注等々の機能を付加する場合、取引先、得意先、仕入先、商品の入力が必要となるが、その時に検索・入力支援機能を簡単に流用できるように設計する
  6. 検索・入力支援機能は FileMaker/IWP/WD の3プラットフォームで利用できること
  7. WDの実行速度を落とさないように、レイアウトテーマは前版「FMEasy在庫 R1.0」の「レトロ」から「クラッシック」に変更 ― この為、本製品R1.5と前版R1.0の画面がかなり異なっている

※レイアウト共有で工数減?

 レイアウトを共有するとレイアウトだけでなくスクリプトも共有できる可能性が高まり、工数削減につながりそうだが、レイアウトを弄る度にFileMaker/IWP/WD、3つのプラットフォームでレイアウトのズレを気にしなければならなくなり、実際の工数減に繋がるかは微妙です。
 おおざっぱな方 ― 多少、オブジェクトが被ったりズレたりしても気にしない人はレイアウト共有し、細かいことが気になる人はレイアウトを分けた方が幸せかもしれないです。

 それともかく、本製品はIWPの入力更新系画面を除き、できるかぎり3プラットフォーム間でレイアウトを共有しています。

検索・入力支援機能


本製品のキモはなんと言っても検索・入力支援機能。
下図はWebDirect環境のChromeの画面。

[取引先の検索・入力支援機能]

※取引先画面で検索支援機能を使う
“検索支援”クリック検索支援画面が開く→取引先名を入力して“表示”表示された一覧から目的とする取引先を選択クリック元の取引先画面に戻り選択した取引先が表示される。

※出庫/入力画面で入力支援機能を使う
“選”クリック入力支援画面が開く得意先または仕入先名を入力して“表示”表示された一覧から目的とする得意先/仕入先を選択クリック元の出庫/入庫画面に戻り選択した得意先/仕入先が入力される

注:実行元の画面により、検索・入力支援画面に表示されるボタン、表記、機能が若干異なります。



[商品の検索・入力支援機能]

※商品画面で検索支援機能を使う
“検索支援”クリック検索支援画面が開く商品名を入力して“表示”表示された一覧から目的とする商品を選択クリック元の商品画面に戻り選択した商品が表示される

※出庫/入力画面で入力支援機能を使う
明細の“選”クリック入力支援画面が開く商品名を入力して“表示”表示された一覧から目的とする商品を選択クリック元の出庫/入庫画面に戻り選択した商品が入力される
  • 実行元の画面により、検索・入力支援画面に表示されるボタン、表記、機能が若干異なります。
  • 入力支援画面で[伝票単価][数量]を入力すると、その値が入出庫明細の単価と数量に入力されます。



Blog連動


 いくつかの問題もあります。 例えば、インスタントWeb(IWP)/WebDirect(WD)では満足な印刷ができない。これは FileMaker Serverの問題ですが、回避策がないこともないです。
 それは、ネットワーク上に印刷専用の FileMaker クライアント(FileMaker Robot)を常に起動しておき、IWP/WDクライアント(ブラウザ)から印刷リクエストがないか常に監視し、リクエストがあればFileMaker Robotから印刷を行うようにスクリプトを作成し、そのスクリプトを常に実行した状態にしておきます。

 別の問題として、IWPではダイアログボックス表示のスクリプトステップが使用できないため、レコード削除実行時に確認のダイアログが表示されずに即刻レコードが削除されてしまう、ということがある。

 また、 WDは各種ブラウザとの互換性が低いがFileMaker クライアントの再現性が高いのでインストラネットで、IWPは各種ブラウザとの互換性が高いので不特定多数対象のインターネットで使用したいが、WD/IWPの同時使用は可能か…等。 こうした問題・課題について、できるだけ本Blogで取り上げていきたいです。


サポート

前版インシデント2→今版5インシデント(365日間有効)に!

 ご質問については、Blog 記事として回答させて頂くこともあります →例1とか例2とか。


講習とか


 本製品をベースに在庫管理を学んでみたいという方はこんなのとか、IWPをやってみたいという方はこんなのとか、WDとはなんぞやという方はこれとか、あります。

 それでは足りない!、開発支援とかコンサルティングを!という方はこちら

 その他の在庫関連記事を読む
 その他の WebDirect 関連記事を読む

(土屋)

2014-06-24

『FMEasy在庫 IWP/WD R1.5』 のクライアント強制フィールドの使用


『FMEasy在庫 IWP/WD R1.5』のユーザの方へ

 『FMEasy在庫 IWP/WD R1.5』はFileMakerクライアント、インスタントWeb(IWP)、WebDirect(WD)の3つのプラットフォームで動作する在庫管理テンプレートですが、本製品のMain Menu画面には[クライアント強制]というフィールドがあり、クリックすると「0:FM、1:IWP、2:WebDirect」のいずれかの値を選択することができます。 


本製品は「0:FM」が選択されていればPC上のFileMakerクライアントとして、「1:IWP」ならインスタントWeb環境に接続されているブラウザとして、「2:WebDirect」であればWebDirect環境に接続されているブラウザとして、実際のプラットフォームとは関係なく、動作します。 

 たとえば、PC上の FileMaker Pro 13 を使用し、『FMEasy在庫 IWP/WD R1.5』にアクセスする場合、デフォルトでは上記フィールドの値は「0:FM」が選択されています。 この時、“取引先へ”をクリックすれば、FileMakerクラインアント用に用意された以下の画面が表示され、これが本来の正しい動作です。

では、 上記のMain Menu画面の[クライアント強制]を「1:IWP」に変更して“取引先へ”をクリックするとどうなるでしょうか? その場合、インスタントWeb(IWP)用に用意された下記の画面が表示されます。


つまり、実行環境はFileMaker Pro 13であるにも関わらず、インスタントWebにアクセスしているブラウザの動作をシミュレートできます。 これは、主としてIWPアプリの開発時、デバッグ環境が存在しないため、FileMaker Pro Advanced にブラウザを動作をシミュレートさせ、デバッガに利用するための仕組みです。 よって、開発時以外は、[クライアント強制]の値は変更しないようにしてください。

注:
  • 本機能は他のプラットフォームをある程度はシミュレートしますが、プラットフォーム間でサポートするスクリプトステップや機能が異なる為、完全にシミュレートするものではありません。
  • 開発時のFileMakerクライアント上での「1:IWP」指定(IWPブラウザのシミュレート)と「2:WebDirect」指定(WebDirectシミュレート)を前提としています。その他の指定はお勧めできません。
以上


【関連リンク】
FMEasy在庫のカスタマイズ関連記事リスト

2014-05-19

FileMaker IWP と SQL-Server 2000 によるソフトハウス用ライセンス販売管理システム

 ユーザに特定のブラウザを強制できない状況、不特定多数のユーザがアクセスする環境では WebDirect を使用できないため、IWP(インスタントWeb)が有用ですが、現状として WebDirect が限られたブラウザのみしかサポートしない状況で、IWP(またはその機能)の提供を打ち切っちゃう FileMaker ってなんなの……。

  さて、小社では自社ソフトウェアのユーザ管理用に Microsoft SQL-Server 2000(以下、Ms-sql)とASPをしたシステムを開発し長らく運用してきておりますが、1 年半ほど前にフロントエンド部を Active Server Page から FileMakerに 置き換えた、ということは以前、本Blogでご紹介いたしました。

 この前システムは10年以上ユーザ情報と製品サポートの記録用に運用してきましたが、昨年 5 月『売上猫くん Standard R5』をリリースしたのを機に一念発起し、ソフトウェアライセンスのWeb販売機能追加を含め、大幅に機能を拡張することにしました。


開発環境

MS SQL-Server 2000 (同左)
MS SQL-Server Management Studio Ver 9 (同左)
FileMaker Pro Server 12 Advanced (FileMaker Pro Server 11 Advanced)
FileMaker Pro 12 Advaned(FileMaker Pro 11 Advanced)
注:( )内は、前回開発時の環境

※なぜいまさらMs-sql 2000なのか?

な ぜ前世紀の遺物の Ms-sql 2000 を使い続けるのか?というと、FM が公式にはサポートしていないSQLデータソースを操作できるのか試してみたい、という好奇心からです。
 ちなみに、FM12 が公式にサポートしている Ms-sql は2005と2008のみ。 前回、Ms-sql 2000→2008 へのアップグレードは簡単にできることを確認していますので、問題が発生時したらアップグレードするつもりでしたが、現在まで問題なく運用できております。

注:FM13 が公式にサポートしている SQL データソースはこちらになりますが、例によって旧版 SQL データソースはいとも簡単にリストから外されているのであった……
 

FileMaker 13 でもはやサポートされなくなった IWP をいまさら使う理由は次のとおり。

  1. PHPに比べ非常に短期間で開発が可能
  2. 必要最低限の機能で満足できる(JavaScriptなどを使用したゴージャスなインタフェイスは要らない)
  3. ヘビーなトラフィックが発生しない
  4. 何かあればサーバを再起動できる程度の余裕がある
上記 1. が IWP 採用の最大のメリットで、今回の開発では30人日程でカットオーバーできました。

※なぜWebDirect(WD)ではないのか?

  1. ブラウザの互換性が低い(不特定多数がWebアクセスする環境では使えない)
  2. ハードウェア/ソフトウェアのコスト
WDは¥100万~数百万の投資が普通にできる企業がイントラネットで利用するってことで。


ライセンス販売管理システムの仕様

仕様は以下のとおり。

No AP 機能名 内容/仕様
1 FM カスタマ管理 カスタマ(顧客)管理、Webログイン用アカウント管理
2 FM ライセンス管理 ・複数ライセンス管理(同一カスタマが複数の製品を所有することを想定、メール/葉書等の重複送信を防ぐ)
・入金確認後、Webでカスタマが登録した情報を元に、ユーザ(ライセンス)情報の登録/更新を行う。同時に、製品情報(製品用パスワード)等を登録完了通知メールとして送信
3 FM メール送信 ユーザを検索し、対象ユーザにアップグレード等の情報を一括送信。
4 FM 送信文章管理 メールで送信する文章を作成。ここで登録した内容をEvaluateし、ユーザ/商品毎の変数を評価(例:本文中に表示する宛名やアカウント情報をユーザ毎に変更する)
5 FM 送信履歴管理 ユーザ毎にメール/葉書などの送信履歴を保存
6 FM 葉書 アドレスが無効または不明でメールが送信されなかったユーザに対し、葉書(表裏面)を印刷する
7 FM サポート管理 ・サポート期間、インシデント消費状況を管理
・サポート内容を記録
8 FM 商品管理 ・複数商品対応
・同一商品の複数種類対応(例えば、『売上猫くん Standard R5』には、シングルユーザ版、マルチユーザ版、開発版の3種類がある)
・シリアルNo(ライセンスNo)生成
9 Iwp ログイン カスタマ毎に登録してあるアカウント情報をもとに認証
10 Iwp ユーザ情報更新 ユーザ情報の登録/更新/チェック
11 Iwp アカウント情報更新 アカウント/パスワードの登録/更新/チェック
12 Iwp 商品選択・購入 ・新規購入とアップグレード購入の両方に対応
・アップグレードというソフトウェア特有の販売形態に関連した各種制御(所有ライセンス数に基づくアップグレード)
13 Iwp 確認メール 注文確定後、カスタマに対して確認メールを送信
注:AP列の「FM」はFileMaker Pro 12/13で、「Iwp」はWebブラウザ がIWPにアクセスして利用するの意。


主な画面

FM で本アプリを起動時に表示される初期メニュー。
 [ClientMode]で「1:IWP」を選択すると、それ以降はブラウザの動作をシミュレート、デバッグはFMで行う。
図1 FileMakerクライアントで表示されるMenu画面


 カスタマが Web で入力した情報を基に、カスタマ画面上の情報が更新・作成される。
 ライセンスの購入・アップグレード履歴は、「購入履歴」タブに表示される。
 住所/電話等の情報は変更されうるので、カスタマ側で最新の情報を、購入履歴では購入時点の情報(ピンク部分)を保持する。

図2 FileMaker クライアントで表示されるカスタマ画面 ― 購入履歴タブ


 「サポート履歴」タブでは行ったサポート内容を入力・記録する。尚、このタブを開くと、ライセンス付属のサポートの有効期限を表示したサポート状況ウインドウが表示される。


図3 FileMaker クライアントで表示されるカスタマ画面 ― サポート履歴タブ


 メールの送信文章を入力。[送信内容]はEvaluate()されるので、フィールド名や変数を指定可。

図4 FileMaker クライアントで表示される送信文入力画面


 今回の開発の肝はソフトウェアライセンスのショッピング機能。
 下図はそのまた肝の購入申込画面(FireFox使用時)。

 登録ユーザがブラウザを使用しログインすると本画面が表示され、カスタマ情報とともに所有する[現有ライセンス]が画面左下に、その右側にアップグレード可 能な商品情報が表示される。
 “カゴへ”をクリックすると、その商品が買い物カゴに入り、「買い物カゴ」タブが表示される。
 「新規購入」タブでは(アッ プグレードではない)購入可能な商品が表示される。必要に応じてアカウント情報を含む「お客様情報」欄の情報を更新し、商品を買い物カゴに入れて“確認 画面へ”をクリックすると、FMServerは入力情報をチェックしエラーがなければ確認画面を表示する。
 確認画面で“注文を確定する”をクリックする と、FMServerはカスタマ情報を更新するとともに、購入確認メールをユーザに対して送信する。
 なお、既存カスタマの場合、アカウント名/パスワードを 変更して“注文を確定する”と即座にデータベースに反映される。
 
図5 ブラウザに表示されるアップグレード・新規申込画面

 IWP と侮るなかれ。
 結構なモノが構築可能なのです。

以上

(土屋)

追記:
ショッピングモジュールに加え、 CRM(Customers Relationship Management)モジュールのユーザサポート機能を公開。詳しくはこちら


【IWP関連記事】

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

2014-05-15

FileMaker Server のプログレッシブバックアップ機能の考え方と使い方

通常バックアップとプログレッシブバックアップの違い


 FileMaker Server の通常バックアップ機能のしくみは、以下のとおりです。



 この場合は 8 時間おき、つまり一日 3 回、データベース全体がバックアップされます。
 この全体のバックアップを取ることをフルバックアップと呼びます。

 上記のように定期的にフルバックアップを取っておけば、たとえばバックアップ 1 を取り終えたあとに重大なデータベース障害が発生したとしても、データベースをバックアップ 1 の状態に戻せば業務を再開できます。

 ただし、この場合、バックアップは最長約 8 時間前の状態に戻ってしまいます。
 このうな場合はその約 8 時間分のデータベース作業を丸ごとやり直さなければならないことになります。

 一日の更新データ量が膨大になる業務の場合、この復旧作業は大変な労力と時間を費やすことになりますし、そもそもデータがもと通りになる保証はありません。
 かと言って、フルバックアップを1時間とか数分に1度実行するように設定すれば、パフォーマンスが低下することは明らかです。

 このような欠陥を補うため、FileMaker Server 12/13 にはプログレッシブバックアップ(Progressive Backup)という機能が搭載されています。

 プログレッシブバックアップを図解すると、次のようになります。



  プログレッシブバックアップでは、データベース全体ではなく更新分のみをバックアップします。これにより、短い時間でバックアップを終了するので、システムのパフォーマンス低下を短い時間に抑えます。上図の例では通常バックアップとは別に60 分おきにプログレッシブバックアップを行っています。


 データベースが損傷しデータベースがダウンした場合、プログレッシブバックアップにより最大 60 分前の状態に戻ってデータベース業務を再開できるようになります。

 ちなみに、プログレッシブバックアップの間隔は 1 分~99分の間で設定できます。


 それでは、プログレッシブバックアップの設定方法と動作確認、データベースの復旧方法について見ていくことにします。


 通常バックアップのスケジュールの考え方と設定方法については、以下の記事をご覧ください。
 前回の記事: データベースのバックアップ方法


本記事の内容は、当方の動作検証結果にもとづくものになっております。
プログレッシブバックアップ機能を検討されている場合は、事前に動作テストを十分に行い、お客様の自己責任で導入していただけますよう、お願いいたします。

プログレッシブ・バックアップの設定方法


 今回は、FileMaker Server 13 を使ったプログレッシブバックアップ機能をご紹介します。
 FileMaker Server 12 でも基本機能は同じですので、設定画面の情報を読み替えてご利用いただけると思います。

 FileMaker 社で公開されているプログレッシブバックアップの日本語ヘルプには誤訳が含まれているため、英語ヘルプをもとに解説していきます。

1.  FileMaker Server Admin Console にログインし、左ペインの「データベースサーバー」をクリックして「フォルダ」タブを選択します。

 そして、画面下部の「プログレッシブバックアップを有効にする」チェックボックスにチェックを付けると、次のようなメッセージが表示されます。



2. 「保存間隔」と、バックアップフォルダへの「パス」を指定します。

 社内の業務方針に応じて妥当な保存間隔を決定する必要がありますが、とりあえず今回は 60 分を設定しておきます。

 プログレッシブバックアップフォルダは、ここでは G: ドライブのバックアップ用フォルダへのパスを設定してみることにします。

 以下が、これらの条件を設定しおわったところです。



データベース運用中のディスクドライブと、プログレッシブバックアップ用のディスクドライブを分散させることにより、FileMaker Server のパフォーマンスが向上します。


3. “保存”ボタンをクリックした直後は、プログレッシブバックアップ用のフォルダには、以下の 3 つのフォルダが自動生成されます。


  • Changes_FMS ― 変更点が記述された .flx 形式のファイル
  • Copies_FMS ― 前回のプログレッシブバックアップ実行時点のデータベースのコピー
  • InProgress_FMS ― 蓄積された更新点が反映されるまで使用される暫定的なデータベースのコピー
重要:これらの 3 つのフォルダは、ユーザには直接無関係のフォルダとなりますので、中身を変更したり、消去したりしないようにしてください。

 設定後しばらくの間は、公開中のすべてのデータベースがこのプログレッシブバックアップ用フォルダの中にバックアップされますので、公開データベースの数や容量によっては、準備が整うまで時間がかかることがあります。


 InProgress_FMS フォルダは、初回のプログレッシブバックアップに成功すると消去され、その代わりに、タイムスタンプ付きの二種類のフォルダが生成されます。



FileMaker Server のプログレッシブバックアップでは、これらの二種類のバックアップコピーが生成されますので、必要に応じてどちらかの状態に復旧させることができます。


 上記では、スクリーンショットを撮る目的でバックアップの間隔を 1分に変更してフォルダを作成したために、05-15-14-37 と 05-15-14-38 という 1 分間の開きがあるフォルダが作成されていますが、間隔を 60 分にすれば、一時間の開きのあるフォルダが作成されることになります。


プログレッシブ・バックアップからのデータベース復旧方法

1. FileMaker Server Admin Console を使って、復旧させたいデータべ―スを閉じます。
 データベースの閉じ方は、以下の画像をご覧ください。



2. 1. で閉じたデータベースを消去します。



3. 前述の「プログレッシブバックアップの設定方法」の手順 3. で作成された、タイムスタンプ付きのフォルダのうち、復旧させたい時点のフォルダを開き、その中から対象となるデータベースファイルを特定して、FileMaker Server の公開データベースフォルダにコピーします。



 上記は、タイムスタンプが 2014-05-15-1511 のフォルダから、FMServer_Sample.fmp12 ファイルを特定したところです。


このフォルダは、定期的に FileMaker Server からアクセスされる性質のものですので、ファイルを特定したら、そのファイルをすぐにデータベースサーバの方にコピーしてください。

IncrementalBackup フォルダの中では、絶対に直接ファイルを開かないようにしてください。

4. 3. でデータベース公開用フォルダに配置したファイルを開きます。



 復旧操作は以上です。
 これによって、データベースファイルの状態が、2014-05-15-1511 時点でのプログレッシブバックアップ状態に戻りました。


【参照データのみ保存しているオブジェクトフィールドのデータはどうなるのか】

 英語版のヘルプによると、オブジェクトフィールドのデータ格納オプションより、「ファイルの参照データのみ保存」で参照先のみを保存している場合は、その実データは、タイムスタンプ付のフォルダの中に生成される RC_Data_FMS というサブフォルダの中にバックアップされるそうですが、当方の実験ではバックアップされていないようです。

 この点については、日を改めて検証したいと思います。


以上

(亀)



関連記事:
データベースのバックアップ方法


参考記事:
プログレッシブバックアップの設定とバックアップからの復元
Setting up, and restoring from, progressive backup (英語)



【関連する土屋企画の講習】
FileMaker Server とバックアップ(対象者:中級、5時間×1日)

2014-05-13

データベースのバックアップ方法


バックアップの重要性


 FileMakerにかぎらず、データベースを運用するうえで日々のバックアップ作業はとてもとても重要です。理由はデータベースが以下のような状況で破損するからです。

 データベースはいつかは必ず破損する!壊れる!ものと思ってバックアップ道に精進しましょう。

  • ユーザによる強制シャットダウン、システム稼働中の電源コード抜き
  • ハードディスクの寿命・故障
  • 電源障害、停電
  • 落雷、地震
  • 怪奇現象(なんの前触れもなく突然壊れる)

 戦略的、かつ定期的にバックアップを行うことにより、データベース破壊時にも最小限のコストで業務を再開できます。

※本稿で使用しているバックアップソフトウェアは FileMaker Server です。 


バックアップスケジュールの考え方


 データベースが破損すると、そのデータベースが関連するすべての社内業務はストップしてしまいます。
 このため、バックアップは最低毎日1回はお取り下さい。バックアップはデータベース管理に関わる者の責務です。

 バックアップがあれば、たとえば火曜日にデータベースが破損しても、月曜日のバックアップを使用し、月曜~火曜の間に更新したデータを再入力することにより業務を再開できるようになります。
 データの一部は再入力できないかもしれませんが、全データを失うよりは遥かにマシです。

 それでは以下の順に作業を進めていきます。


1. バックアップ用のディスクを用意します。

 FileMakerのデータベースファイルが保存されているディスクとは別の物理ディスクを用意してください。
 同一のディスクを使用すると、ディスクが物理的に破損したときにバックアップも一緒に破損してしまうからです。

 バックアップディスクには、外付のハードディスクを使用するのが良いと思いますが、 iSCSIドライブを使用するのも手です。iSCSIドライブであればサーバが起動できなくなっても、他のサーバでiSCSIディスクをマウントできます。 iSCSIドライブとスタンバイサーバがあれば、サーバがデータセンターにあるような場合、管理者はサーバ所在地に行かなくても復旧を行うことができます。

注:
  • FileMaker Serverスケジュールでは、NAS などのネットワークドライブにはバックアップを取れません。 
  • ネットワークドライブにバックアップを取るには、FileMaker Server でローカルディスクに一旦バックアップを行い、その後タスクスケジューラ等で NAS にバックアップを行うバッチを実行させると良いです。

 ここでは、外付けハードディスクにドライブレター F: を割り当てたものを想定します。


2. 日々のバックアップ戦略を考えます。

 バックアップを考えるにあたり、まず以下の2点を考えます。
  1. 頻度
  2. 上書 or 追記

 データ復旧性のことだけ考えるのであれば、1分に1回、常に追記する(以前のバックアップを上書きしない)のが最良でしょうが、頻繁なフルバックアップは実行速度の低下や停止を招きますし、また毎回追記していてはディスク等のバックアップメディアの費用もかかさみます。

 データ復旧性、システムパフォーマンスへの影響、金銭的コストなど、バックアップに関わる様々な事項を検討して、その企業における最適解を得るのがバックアップ戦略です。

 以下、バックアップ戦略の一例です。

  • バックアップは月曜日~日曜日まで毎日個別のバックアップ用ディレクトリに取る
  • 月曜~土曜は前週同曜日分を上書きバックアップする
  • 日曜日は永久保存用に 追記バックアップする(上書しない)


 これを1カ月の表にすると、次のようになります。

上書上書上書上書上書上書永久
上書上書上書上書上書上書永久
上書上書上書上書上書上書永久
上書上書上書上書上書上書永久



【日次バックアップのスケジュール】

 上記のバックアップ戦略に基づき、外付ディスク(F:)に月~土曜用のバックアップフォルダを作成します。



A. 手動による日次バックアップ


 FileMaker Server をお持ちでない方は、毎日の業務終了後に FileMaker データベースを完全に終了させてから、FileMaker データベースの入っているフォルダをそれぞれの正しいバックアップフォルダに正確にコピーしてください。


B. FileMaker Server を使った日次バックアップ

以下では、FileMaker Server 12 を使用し、これらフォルダに対して月~土曜用の上書きバックアップを設定していきます。

 スケジュールアシスタントの、1. タスクの選択~ 3. データベース選択までの操作はここでは省略しますが、業務に合った内容のものを選択してください。


1. たとえば、月曜日のバックアップフォルダ設定は次のとおりとなります。

FileMaker Server の仕様上、ネットワークドライブをバックアップ先に指定することはできません。

 一週間に一度上書きバックアップさせるため、フォルダに保持させるバックアップ数を 1 つに設定しているところに注目してください。



2. バックアップスケジュールを設定します。
 
 月曜日のフォルダに毎週バックアップさせるために、頻度を毎週にします。
 スケジュールは月曜日ですね。

 この例では、一日一回バックアップを取るようにしています。
 バックアップの開始時刻は業務条件によりますが、毎日の終業時間後に取るようにすると、翌日トラブルに見舞われてデータベースが使えなくなったときにも作業を再開しやすいかもしれません。


【応用編】

 日々大量のデータを扱う業務の場合は、朝、昼、晩と 3 回バックアップを取った方が、万が一のデータロスが少なくてすみますので、頻度を決めてバックアップを取るようにするとよいでしょう。
 たとえば以下のように設定すると、7 時間おきにバックアップを取るようにするため、一日で 3 回バックアップが実行されます。



 このような場合は、前の画面に戻り、バックアップの保持数を 3 に変更しておけば、朝、昼、晩と 3 種類のバックアップが 3 種類のフォルダに作成されます。


#ユーザから文句を言われたくなければ、システムがフル稼働する時間帯にバックアップを実行するのは止めましょう。 早朝、昼休、深夜、おやつの時間など、システムの稼働率が低い時間帯を見計らって、こっそりバックアップしましょう。


3. この要領で、月曜日~土曜日までの 6 日分のバックアップ設定をすると、以下のようなリストになります。




 これでバックアップスケジュールを有効にすれば、月~土曜の毎日、バックアップが定時に実行されるようになります。


【永久バックアップのスケジュール】

 日曜日のデータを永久バックアップする方法をご紹介します。

1. 永久バックアップ用には、月~土曜のバックアップディスク(F:)とは別に外部ハードディスクドライブ(または iSCISI)ディスクを用意し、ドライブレターに G: を割り当てました。

 月~土曜と日曜日のバックアップで、2つの外部ディスクを用意するのは、ディスク障害のリスクを分散するためです。


2. G: ドライブの中に日曜日永久バックアップ用のフォルダを一つ作成します。
 たとえば、以下のようになります。



A. 手動による永久バックアップ


 FileMaker Server をお持ちでない方は、日曜日の業務終了後に FileMaker データベースを完全に終了させてから、FileMaker データベースの入っているフォルダを永久バックアップ用のドライブ(例: G: ドライブ)の正しい永久バックアップフォルダに正確にコピーし、フォルダ名に日付を追加してください(例:俺のバックアップ150706、俺のバックアップ150713、俺のバックアップ150720.…)。

 このようにすることにより、日曜日の日付のついたバックアップフォルダを、ディスク容量が一杯になるまで永続的に蓄積していきます。

B. FileMaker Server を使った永久バックアップ


 次に、Windows 版の FileMaker Server 12 を使ってバックアップスケジュールを設定する方法をご紹介します。

スケジュールアシスタントの、1. タスクの選択~ 3. データベース選択までの操作はここでは省略しますが、業務に合った内容のものを選択してください。


1. 日曜日の永久バックアップフォルダ設定は、たとえば次のとおりとなります。

FileMaker Server の仕様上、ネットワークドライブをバックアップ先に指定することはできません。


 バックアップフォルダが G: ドライブの 7日(永久)になっていますね。
 また、永久バックアップは追記型で増やしていきますので、「保持するバックアップの最大値」を最大の 99 に設定します。




 これにより、99 個のバックアップまでは追記型でバックアップフォルダが自動生成されます。

追記できるのが 99 回までなら、その後はどうすんの?

 100回目以降は古いバックアップフォルダから順次上書きされてしまいますから、99 週≒約 2 年を一区切りとして、その後はどうするのか検討しておく必要があります。

 99週を過ぎると、古いバックアップフォルダから順に上書きされていきますから、当然上書きされた分は使用できなくなります。
 そのときは、バックアップディレクトリを変更するか、ハードディスクを交換します。

 ハードディスクは2年壊れず使えればラッキー!と考え、99回を区切りに新しいものに交換するのは、とても良いと思います。


ディスク容量とデータ増も考慮せよ

 データベースの容量は把握していますか?
 1月にデータがどのくらい増えるか把握していますか?
 そのハードディスクで2年間、週1回の追記バックアップ99回分を保持できますか?



2. バックアップスケジュールを設定します。

 スケジュールの指定方法は、日次バックアップと同様ですが、バックアップの頻度は 1 回にします。
 これにより、日曜日(永久)のバックアップは、一週間に一度追記作成されるようになります。


C. FileMaker Server と外部プログラムを併用した永久バックアップ


 FileMaker Server によって毎週作成される日曜日のバックアップフォルダを、外部メディアやネットワークディレクトリに自動コピーするには、以下の方法があります。

  •  指定フォルダをバックアップできるソフトウェアを使い、毎週日曜日の深夜に外部メディアに追記型で世代管理できるようにスケジュールを組む。
  •  コマンドバッチファイル、vbs などのスクリプトを使って永久バックアップフォルダの外部メディアへのコピー条件を指定し、タスクスケジューラに登録して毎週日曜日の深夜に実行されるように設定する。


最後に… 上記で管理者のバックアップは作業は終わりでしょうか? とんでもありません。 管理者は1日1回、設定したバックアップスケジュールが正しく実行されているかどうか、FileMaker Server のコンソール画面等で確認してください。 また、週に一度位は、作成されたバックアップが実際に起動できるか試してみてください。 この確認作業は、バックアップ戦略策定や設定作業以上に重要です。 なぜって、バックアップが実際にできていなければ、立派なバックアップ戦略も無意味ですから。


(亀)


<おまけ> 地震、雷、火事、オヤジ、太陽フレアは?

 建物が被雷した場合、電源の入っているすべてのハードディスクやストレージデバイスが破壊される可能性があります。
 地震、火事、テロではオフィス内のすべてのディスク、オフラインのメディアも焼失/消失する可能性があります。

 定期的にクラウドなどの遠隔地のストレージへのバックアップや、支店支社・銀行貸金庫へのデータの保管を検討してください。

 少し前になりますが、大規模な太陽フレアが起こる、との風説があり(NASAも言っていたので風説ではないかも)、筆者も結構マジメに悩んだことがあります。
 調べてみると、他にも悩んでる人はいました。
 太陽フレア対策として、週に1度、ディスクやメディアにバックアップして、それを電磁波シールド袋で包み金庫に保管とか、本気で考えてる人もいます。

 まぁ、そいつの出番が来る時は、業務継続以前に、現代文明全体が危機に陥っていると思いますが……


関連記事:
FileMaker Server のプログレッシブバックアップ機能の考え方と使い方


【関連する土屋企画の講習】
FileMaker Server とバックアップ(対象者:中級、5時間×1日)


2014-01-27

WebDirect の Web ブラウザ互換性

 いくつかの Web ブラウザを用いて、FileMaker Sever 13 WebDirect へのアクセス実験を行いました。

 FileMaker 社が公式にサポートしていない Web ブラウザでの実験も行っております。

(2014/01/30 更新)
 *1 上表で (サポート) はFileMaker社が公式にサポートするブラウザ、(非サポート) は公式にはサポートを表明していないブラウザ。
 当方の実験では、サポート対象のはずの Internet Explorer 9 でアクセスすると、遅すぎてとても実用向きではないという結果になりましたが、この辺はもしかするとレイアウトを軽量化することで速度を改善できるのかもしれません。


 これから WebDirect の導入をお考えの方は、参考にしていただければと思います。

2014-01-24

WebDirect 開発の勘どころ

 インスタント Web (IWP) の後継版として、WebDirect が FileMaker Server 13 に搭載されましたが、今回は WebDirect の機能概要をご紹介したあとに、WebDirect 向けの開発の勘どころをご紹介します。

 なお、今回の記事の作成にあたっては、Richard Carlton Consulting Inc. で提供されている WebDirect の概要と最適化のプレゼンテーションビデオをベースに、当社の知見も交えて開発のヒントをまとめてみました。


※本記事は FileMaker Server 13 の WebDirect 機能(2014/01/24 時点)を中心に書かれたものです。

※2017年5月10日に FileMaker  Server 16 が発売されました。
FileMaker 16 WebDirect に関する記事も併せてご覧ください。
WebDirect は 16 で実用段階に近づくか? ― JMeter による WebDirect 14/15/16 比較

【WebDirect の特長】

  1. WebDirectを使用するにはFileMaker Server 13 と同時接続(ライセンス)が必須
  2. IWP の後継版? 但し、WebDirectがサポートするブラウザ数は減っている
  3. Web プログラミングの知識がなくても、基礎的な FileMaker Pro 開発経験があれば OK
  4. FileMaker Pro クライアントと(ほぼ)同内容をブラウザ上に展開
  5. FileMaker Pro 13  の機能の多くを Web ブラウザ上で実行、特にIWPに比し、実行可能なスクリプトステップが増えている
 

【WebDirect vs IWP】

以下の 旧版FileMaker の IWP (Instant Web Publishing) との相違表をご覧いただくと、さらに機能の概要がつかめると思います。

WebDirect と IWP の機能相違表


参考記事:Comparing FileMaker WebDirect to Instant Web Publishing


【WebDirect導入時の問題】

WebDirect 導入にあたっては以下の問題に特に留意する必要があります。

1. WebDirect の同時接続可能数はデフォルトでは 1。WebDirectの利用者数に応じて同時接続(ライセンス)の買い増しが必要(後述)。

2. 不特定多数を対象とした中大規模なサイトには向かない。WebDirect互換ブラウザが限られている(後述)。

3. 現時点で WebDirect のモバイル機器(タブレット/スマホ)に対するサポートが限定的(公式には非サポート)

4. 最大同時接続数が50、また同時接続が増えるとサーバのスペックも増す

5. WebDirect ではまともな印刷/PDF出力ができない。


【WebDirect対応システム開発のヒント】


 WebDirect のプロジェクトに着手するまえに、上述の WebDirect できること/できないことをまず認識し、プロジェクトを実施するかどうか決定します。
 状況によっては、プロトタイプを作成し、実際に近い運用環境でテストを行うことも検討してください。
 開発に際しては WebDirect の特性を意識した開発を行う必要があります。

 以下の FileMaker 13 WebDirect Overview and Optimization Presentation では開発ステップを提示しています。



FileMaker 13 WebDirect Overview and Optimization Presentation
Richard Carlton Consulting Inc.
このサイト、さすがプロ、素晴らしい  \(^o^)/

 以下、上記の動画を参考に WebDirect 導入・開発のポイントをまとめてみました。


ステップ1: 必要なライセンス種類/同時接続数の分析



 WebDirect を使用するユーザ候補を選定し、それらのユーザがWebDirectのサポートするブラウザを使用し、さらにWebDirectがサポートする機能のみで十分業務を行えるか検討し、最終的なWebDirectのユーザ数を決めます。

 たとえば、請求書などの帳票を印刷はWebDirect では扱えないため、FileMaker Pro や iPad を使用する必要が出てきます。
 WebDirect(及びGo) のを使う場合は、使用ユーザ数に応じた同時接続ライセンスを購入する必要があります。


 2014年1月24日現在、FileMaker Server 13 本体(99,000円)に 5 接続ユーザライセンスを付ける場合、別途104,400 円分のライセンス料を支払う必要があります。

 また最大ユーザ数≠同時接続数ではないことも少し考慮にいれましょう。
 例えば、WebDirectを使用する営業担当が10 人いたとしても、それほど頻繁にアプリを使わない場合、同時接続ライセンスは 5 で済む可能性もあります。


ステップ2: ブラウザ互換性の検討



 公式サイトによると、DirectWeb でサポートされている Web ブラウザはつぎのとおりです。 
なお、「FMEasy在庫 IWP/WD R1.5」という当社の製品でテストしたとろでは、IE11やChrome の上位バージョンでも動作しました。

〇Windows
Internet Explorer 9.x
Internet Explorer 10.x
Google Chrome 27.x

〇Mac OS X
Safari 6.x
Safari 7.x
Google Chrome 27.x

 WebDirect非互換のブラウザを使用している場合、互換ブラウザをインストールする必要があります。

 また、当方で上記に挙げたブラウザで動作や実行速度の検証を行っていますが、ブラウザによって動作にバラつきがあるので、使用を予定する各ブラウザによるテストも重要です。

 弊社での Web ブラウザ別パフォーマンス検証結果は、こちらの記事をご覧ください。
 WebDirect の Web ブラウザ互換性


 WebDirect で公開したデータベースを Web ブラウザで開く時、FileMaker Server はレイアウト上のオブジェクトをCSS、HTML5、Web互換の画像データとして生成・転送するため、レイアウトに配置するオブジェクトは少なければ少ないほどページ読み込み速度は速くなります。

 したがって必要に応じて、WebDirect 用と FileMaker Pro 用のレイアウトに分け、プラットフォーム別に動作するようにシステム構築するのが良いのでしょうが、そうすると開発工数が増えてしまうので、悩ましいところではあります。

 ちなみに、弊社で開発中の『FMEasy在庫 IWP/WD R1.5』はWebDirectに対応する予定ですが、FileMakerとWebDirectで原則、同じレイアウトを使用するようにし開発工数を減らしています。また、レイアウトはできるだけシンプルにし、できるだけ適用するテーマのママ、手を加えないようにしています。


ステップ3: インスペクタのスタイルを使用し表示速度をUp


 Web ブラウザの画面表示速度は、CSS、HTML5、画像データの転送量に依存し、レイアウトの作成方法によりこれらの転送量も大きく増減します。
 表示速度を向上させるには、WebDirect に最適化されたレイアウトを作成することが重要で、そのためにはレイアウトモードで利用する「インスペクタ」の「スタイル」を使用します。この「スタイル」にはレイアウトレベルのスタイルとテーマレベルのスタイルがあり、この2つを使用することによりアプリケーション内でCSSが共有されるため、表示速度が向上します。この「スタイル」の使用方法については、機会があれば改めてご紹介したいと思います。

 前述のビデオのプレゼンターによると、スタイルを使用していない旧レイアウトで生成されるデータ量と、スタイルを使用したレイアウトで生成されるデータ量を比較したところ、 850KB から425KB に減ったとのことでした。
 これは、ブラウザでのレイアウトの読み込み速度が 2 倍速くなる可能性があることを意味しています。

※WebDirect では書式コピーツールを使わない


右図のレイアウトの書式コピーツールを使うと、オブジェクトごとに個別のスタイルとして CSS および XML に書式が登録されてしまうため、余分なデータ転送が発生してしまいます。
 代わりに、スタイルを使いましょう。

【FileMaker Pro 12/FileMaker Pro 13/WebDirect のハイブリッド環境で FileMaker Pro データベースを公開するには】

 FileMaker Pro 13 のファイル拡張子は .fmp12 のため、FileMaker Pro 12 と互換性があります。

 このため、FileMaker Server 13 でデータベースを公開すれば、FileMaker Pro 13 および WebDirect のみならず、FileMaker Pro 12 クライアントからも同データベースを利用できることになります。
 このような複数のアプリケーションバージョンに対応したシステム環境を「ハイブリッド環境」と呼びます。

 ハイブリッド環境において、それぞれの FileMaker Pro クライアントの動作条件を満たすようにする場合は、最もスペックの低いユーザに合わせて開発する必要があります。

 つまり、ハイブリッド環境では FileMaker Pro 12 でレイアウトが適正に表示されることを前提にしたうえで、FileMaker Pro 13 および WebDirect でもアクセスできるように調整していくことになります。

 ハイブリッド環境向けに開発を行う場合は、以下のような点に留意する必要があります。

案1) FileMaker Pro 12/13/Webdirect で共用されるレイアウトを作成するなら、FileMaker Pro 13 のテーマ、およびカスタムスタイルの使用は避ける。

 FileMaker Pro 13 で導入されているテーマおよびカスタムスタイルは、FileMaker Pro 12 では十分に表示できないものが含まれています。

 このため、レイアウトの調整は基本的に FileMaker Pro 12 で行い、表示チェックを FileMaker Pro 13 で行うようにするのが無難といえます。

案2) WebDirect 専用レイアウトを作る

 先にご紹介したとおり、WebDirect のパフォーマンスは Web ブラウザに依存します。
 Web ブラウザの読み込み時間を考慮すると、レイアウトのデータサイズは小さければ小さいほど良いということになります。

 しかし、FileMaker Pro 12 のレイアウトは、「インスペクタ」の「スタイル」で最適化されていないため、WebDirect クライアントで表示すると、Web ページの読み込みに時間がかかってしまいます。

 Web ページ読み込み速度を優先するなら、FileMaker Pro 13 で WebDirect 専用のレイアウトを作成し、カスタムスタイル設定で軽量化させたものを使うようにすると、WebDirect クライアントもデータベースに快適にアクセスできるようになるでしょう。


※本項の記述は上記ビデオを参考にしています。
 FileMaker Pro 13でレイアウトを保存すると FileMaker Pro 12 での表示が若干異なったり、FileMaker Pro 12で行ったレイアウト設定(特にフィールド内のインデント設定)が消失してしまったりすることがあります。

 しかしながら、常に FileMaker Pro 12 を使用してレイアウト開発を行っていると、FileMaker Pro 13 の資産を十分に活かせませんし、後続の FileMaker データベース製品のことを考えると仕様に無理が出てくる可能性が高くなるでしょう。

 したがって、クライアント別のレイアウトの切り分けを十分に行ったうえで、レイアウトを含む開発はすべて FileMaker Pro 13 で行い、FileMaker Pro 12 で表示チェックのみを行うというのがより現実的といえるかもしれません。

【その他の開発ヒント】


 WebDirect が FileMaker Server 13 に搭載されているといっても、従前のデータベースを配置して公開しただけでは十分なパフォーマンスを得られない可能性が高いため、WebDirect による同時接続ユーザ数、およびレイアウトデータの転送量を意識した設計と最適化が必要になります。

 こちらも併せてご参照いただければ幸いです。
 パフォーマンスの最適化(PDF 『FileMaker 14 WebDirect ガイド』より)


 最後に、上記で書ききれなかった WebDirect の開発ヒントをいくつかご紹介します。

  1. レイアウトに配置する画像やオブジェクトは必要最低限に  ボタン、アイコン等にグラフィックを使うと、Web ブラウザでのロードに時間がかかります。

  2. WebDirect で使うテーマはシステム全体でできるだけ統一する
     たとえば、顧客マスタで「クール」というテーマを使い、売上画面で「エレクトリック」というテーマを採用すると、Web ブラウザで画面切替するたびにキャッシュ読み込みが発生するため、表示速度が遅くなります。
  3. FileMaker Pro のような新規ウィンドウを開くことはできない
     新規ウィンドウを仮想ウィンドウとして開くことはできますが、複数ウィンドウ上または複数タブ上に異なるレコードまたは異なるレイアウトを表示することはできません。

  4. タブはできるだけ使わない
     レイアウトに配置できるタブは入力フィールドの整理に役立ちます。
     しかし、WebDirect では初回ロード時に最上位のタブが読み込まれた後、ユーザがタブ切替を行うたびに ブラウザ→ WebDirect FileMaker Server 13 → WebDirect へのリクエストが発生するため、これがパフォーマンス低下につながることになります。

  5. ソートは FileMaker Server 13 側で実行されるので高速になる
     WebDirect 自身にはデータベースエンジンが搭載されていないため、データベースエンジンが行うべき操作はすべて FileMaker Server 13 側で実行されることになります。
     
     このため、FileMaker Pro 13 クライアントでレコードソートをしたときよりも、WebDirect でソートしたときの方が処理速度が速かったという結果も出ています。

     上記のビデオによると、35万件のレコードをソート実験した結果、WebDirect で 35 秒、FileMaker Pro クライアントで 227 秒と、実に 400% 近くのソート速度の差が出ています。

 以上、WebDirect を使ったデータベース開発の参考にしていただければ幸いです。


参考記事(英語):
FileMaker 13's WebDirect: I want to like it. I really do.
What is FileMaker WebDirect?
Comparing FileMaker WebDirect to Instant Web Publishing

その他の WebDirect 関連記事を読む

亀澤

2013-12-26

海外のFileMaker Pro 13 対応ホスティング会社比較

 2013年12月4日に FileMaker 13プラットフォームがリリースされ、従来のインスタントウェブ(IWP)の後継版として、WebDirect が搭載されました。

 FileMaker Server 12以前のIWP では、最大 100ユーザまでの同時接続に対応(理論値)していました。

 これに対し、FileMaker Server 13 のWebDirect では、初期状態では 1 接続のみの対応となっており、必要に応じて 5 接続単位でライセンスを買い増す必要があり、50の同時接続を行うには約115万円のライセンス料が必要となります。さらに、同時接続ユーザ数に応じて、8GB~16GB の RAM、4コア~12コアの CPU が推奨されています。

 ということで、FileMaker Server 13 の WebDirect を導入するには、ライセンスとハードウェアの費用が相当かさむことになりそうです。 で、代替策として安価なホスティングサービスはないものかと探してみたところ、2013年12月末現在、日本ではFileMaker Server 13対応のホスティングサービスは見あたらず、では海外のサイトはと探してみたところ、いくつか提供会社が見つかりましたので、下表にまとめてみました。


海外のFileMaker Pro 13 対応ホスティング会社比較
会社名
(国外対応)
月額プラン基本料金WebDirect
追加料金
DB数DB容量アップロードFM接続数
初期費用転送量制限バックアップphp/xDBC最低期間
FileMaker Hosting Pros
(不明)
試用期間15日
Starter$19.95不明11GBコンパネ無制限
無料無制限自動/手動利用可1ヶ月
Standard$39.9535GBコンパネ無制限
無料無制限自動/手動利用可1ヶ月
Premium$59.95610GBコンパネ無制限
無料無制限自動/手動利用可1ヶ月
http://www.filemakerhostingpros.com/FileMaker-Pro-Database-Cloud-Hosting.html
mac USA Hosting
(不明)
1$16.95$18/5ユーザ1無制限管理ツール100
無料無制限自動不明1ヶ月
2~4$13.95/1ファイル2~4無制限管理ツール100
無料無制限自動不明1ヶ月
5~9$11.95/1ファイル5~9無制限管理ツール100
無料無制限自動不明1ヶ月
10以上$9.95/1ファイル10以上無制限管理ツール100
無料無制限自動不明1ヶ月
http://www.macusa.net/fmserverhosting13.cfm
TRIPLE 8 NETWORK
(有)
試用期間30日
Personal$19.95$10/ユーザ22GB不明4
不明無制限自動/ftp不明1ヶ月
Standard$29.9555GB不明10
不明無制限自動/ftp不明1ヶ月
Business$39.9588GB不明16
不明無制限自動/ftp不明1ヶ月
Enterprise$49.951212GB不明24
不明無制限自動/ftp不明1ヶ月
http://www.triple8.net/filemaker/filemaker-hosting.cfm#fmpricing
Austin Michael Internet Solution
(不明)
試用期間15日
Starter$19.95不明11GBコンパネ無制限
無料無制限自動不明1ヶ月
Standard$39.9535GBコンパネ無制限
無料無制限自動不明1ヶ月
Advanced$59.95610GBコンパネ無制限
無料無制限自動不明1ヶ月
http://www.austinmichael.com/hosting/filemaker-server-hosting.htm
l








 FileMaker Pro クライアントからの同時接続 100 に対応しているところがある一方で、WebDirect の接続数は、5ユーザ単位で追加料金が発生したり、1ユーザごとに追加料金が発生しているところを見ると、WebDirect 利用ユーザ数が増えれば、それだけ利用料金も高くなるようです。

 個人的には、mac USA Hosting が提供しているプランがお得感がある印象ですが、細かいサービス内容については、それぞれのホスティング会社のサイトを確認したうえで、不明点は直接問い合わせてくださいね。


(亀澤)