ファイルメーカー（FileMaker）を同期で使おう Part4

このシリーズの他の記事はこちら
ファイルメーカー（FileMaker）を同期で使おう Part1
ファイルメーカー（FileMaker）を同期で使おう Part2
ファイルメーカー（FileMaker）を同期で使おう Part3

ファイルメーカーを同期で使おうの第4弾です。

 今回は、中間ファイルから共有ファイルにデータを取り込むというテーマです。

レイアウトの作成

まず、中間ファイルで、共有ファイルのテーブルをコンテキストにしたものを作成します。

このようなレイアウト設定です。sampleというのが共有ファイルの名前です。

ブラウズモードにすると、このようにデータが１件あります。

「数量」というフィールドまでが、共有ファイルのフィールドで、「同期タイムスタンプ」というフィールドが、この中間ファイルにあるテーブルのフィールドです。

この「同期タイムスタンプ」のフィールドにデータを入力すると、前回行ったリレーションの設定により、中間ファイルのテーブルにレコードを作成し、ルックアップの設定で、データを取り込むことになります。

このように「同期タイムスタンプ」にデータを入力します。

このレイアウトは、中間ファイルのテーブルです。

ルックアップの設定によって、このようにデータが入力されました。

また、レコード自体はリレーションの設定で、自動的に作成されます。

これで、共有ファイルから中間ファイルへのデータのコピーはできます。

また、中間ファイルから共有ファイルへのデータの書き込みも可能です。

上の「受注マスター_sample」のレイアウトにて、データを書き込めば、共有ファイルに書き込むことになります。

この例では、営業担当者が受注を確認すると、フィールド設定で「営業確認タイムスタンプ」に確認したときのタイムスタンプを入力します。

これを共有ファイルのフィールドにコピーするという流れになってきます。

「受注マスター_sample」のレイアウトにて、「営業確認タイムスタンプ」に中間ファイルから書き込むということになります。

これが、この例での中間ファイルと共有ファイルのデータのやり取りの流れです。

FileMaker Serverの同時接続ライセンスを気にする必要がないけれど、

外出時で、ネットワーク環境のよくないところで共有ファイルのデータを見たいというときには、

これまでのやり方で、基本的にはいけるでしょうか。

ちなみに、データを共有ファイルから「もらう」だけであれば、中間ファイルの「受注マスター」というテーブルはなくてもいけます。

問題は共有ファイルに「戻す」という同期の時に中間ファイルのデータと共有ファイルのデータを比較する必要がある場合は中間ファイルの「受注マスター」が必要になってくるでしょう。

この例では、実際なくてもいけます。

次回は「入力用ファイル」と中間ファイルとのやり取りについてです。

ファイルメーカー（FileMaker）を同期で使おう Part3

このシリーズの他の記事はこちら
ファイルメーカー（FileMaker）を同期で使おう Part1
ファイルメーカー（FileMaker）を同期で使おう Part2
ファイルメーカー（FileMaker）を同期で使おう Part4

こんにちは同期シリーズ第3弾です。

今回から実際の作り方を見ていきます。

少しだけ、復習+α

同期モデルを選択する場合、いろいろな課題があり選択していくと思います。

1）　インターネットに接続でいない場所（電波が悪い等も）でデータを見たい

2）　同時接続ライセンスを節約したい

などがあります。1）にはモバイル通信（3Gや4G）の場合も含まれます。モバイル通信だと、ソリューションの規模やサーバーのスペックなどにもよりますが、あまり本格的に閲覧したり、データ入力をするには厳しい場合もあり、同期モデルで作った方がいい場合もあります。

FileMaker GoからFileMaker Serverの共有ファイル開くポイント

FileMaker Goにあるファイル（iPad、iPhone上のローカルファイル）からFileMaker Serverの共有ファイルをリレーションするとFileMaker Serverの共有ファイルを開いた状態（接続ライセンスを消費）になる。

ということです。リレーションをしないで取り込むには、エクセルファイルか何かにエクスポートして、インポートするという手もありますが、個人的な見解としてあまりインポートをさせたくないという考えがあります。たまに、トラブルがあり、インポートが止まらなくなったりなどがあり、そういったことが少なく、確実性が高いを個人的に思っている方法を紹介します。

構成

まず図のようなイメージで

・入力用のファイル（client.fmp12)

・中間ファイル（container.fmp12)

・FileMaker Server上の共有ファイル(sample.fmp12)

という３つのファイルがあり、2つのファイルが同じデバイス上にあるとします。

このソリューションの前提

1）　営業社員が自身の担当顧客から注文が本社に入り、アシスタントがsampleに入力

2）　未確認の注文情報をダウンロード

3）　clientファイル上で確認して、確認ボタンをタップ

4）　確認情報をsampleに戻す（入力・同期）する

という流れのソリューションであると思っていただければと思います。

1）FileMaker Server上の共有ファイルsampleの構成

FileMaker Serverの共有ファイルsampleの構成はこのようになっています。実際には、もっと項目が多くなると思いますが、分かりやすいように絞ってあります。

2）　中間ファイル(container.fmp12)の構成

中間ファイル(container.fmp12)にも同じ項目のテーブルを作成します。

一番下にあるフィールドは同期したタイムスタンプを保存しておきますが、共有ファイル上のファイルとのリレーションで、このファイルにレコードを作成するために主に使用します。

リレーションシップの編集

このファイルは共有ファイルとリレーションをして、そのリレーションを使ってこのファイルにレコードを作成したりします。

リレーションシップの管理で、このボタンをクリックします。

「FileMakerデータソースの追加」で共有ファイルを選択します。

このようにリレーションを作成します。「このリレーションシップによるレコードの作成を許可する」を忘れないようにします。

そして、先ほどのフィールドの設定にあったようにルックアップの設定をします。

次回は、中間ファイルに共有ファイルからデータを取得する流れについてみていく予定です。

ファイルメーカー（FileMaker）を同期で使おう Part2

このシリーズの他の記事はこちら
ファイルメーカー（FileMaker）を同期で使おう Part1
ファイルメーカー（FileMaker）を同期で使おう Part3
ファイルメーカー（FileMaker）を同期で使おう Part4

こんにちは！

前回の続きです。

前回は、同期モデルのメリットや簡単な概念を紹介しました。

今回は、完全同期モデルでという名前で紹介した、３つのファイルでデータをやり取りするモデルを作成するにあたって、知っておきたいことを少し掘り下げます。

なぜ３つ必要か

前回紹介した画像です。すこし分かりやすく同じデバイス上にあるファイルを区切りました。

FileMaker Server上のファイルにあるテーブルオカレンスを中間ファイルのリレーションマップに配置して中間ファイルのテーブルオカレンスとリレーションを組み、データをやり取りすることになります。

この時点で、FileMaker Serverのファイルのデータを表示しようとしまいと、中間ファイルを開いている間は、FileMaker Serverに接続し続けます（iPhone、iPad等では同時接続としてカウントされます）。

ちなみに、中間ファイル上でスクリプトステップの「ファイルを閉じる」を実行して、FileMaker Serverのファイルを閉じようとしても閉じられません。

ただし、FileMaker Server上のファイルにてアカウントが設定されていて、アカウント情報を入力して必ず開くようになっている場合は中間ファイルを開くときに、FileMaker Server上のファイルのアカウント情報を入力するように求められますが、キャンセルしてしまえば、接続されずに中間ファイルを開くことはできます。

しかし、FileMaker Server上のファイルのデータを取得するのにはアカウントの入力が必要になり、一度ログインすると、中間ファイルを閉じるまでは基本的に接続し続けます。

こういったことから、データを取得（同期）したらFileMaker Serverの接続を解除したい場合は、３つのファイルが必要となります。

まず、入力用のファイルに中間ファイルのデータを表示しません。

入力用のファイルのリレーショングラフには中間ファイルのテーブルを表示しないということです。

２つのファイル（入力用のファイルとFileMaker Server上のファイル）で、同じように行うこともできます。

ただ3つにすることによって、FileMaker Server上のファイルにできるだけ変更を加えなくて済むというメリットがあります。

方法

基本的なやり方としては、中間ファイルにスクリプトを設定し、入力用ファイルからそのスクリプトを実行して、データのやり取りをします。

データのやり取りには、スクリプト引数をセットしたり、スクリプトの結果を利用して送ったりします。

データのやり取りが多い場合にはエクスポート、インポートでのやり取りが必要になりますが、個人的な感想として、エクスポートはともかくインポートがらみにでトラブルに見舞われることがあるので、あまり好きではないという理由で、今回はこの方法は紹介しません。

なお、同期モデルのやり方にはいろいろあり、その一つであるという前提でお読みいただけると助かります。

次回は実際の手順を紹介していきたいと思います。

ファイルメーカー（FileMaker）を同期で使おう Part1

このシリーズの他の記事はこちら
ファイルメーカー（FileMaker）を同期で使おう Part2
ファイルメーカー（FileMaker）を同期で使おう Part3
ファイルメーカー（FileMaker）を同期で使おう Part4

こんにちは、いつもご覧いただきありがとございます。

FileMaker Server（ファイルメーカーサーバー）13より、無料のクライアントの同時接続ライセンスが導入されました。

これは、iPad、iPhoneのアプリFileMaker Go、WebDirectからFileMaker Serverでホストするファイルにアクセスする場合、FileMaker Serverに同時接続ライセンスを購入しないと接続できないというものです。

FileMaker Server14では、Proのクライアントソフトの値段と同じくらいの価格になり、地味に辛くなってきました。

できるだけ同時接続を節約したいと思う方は多いのではないでしょうか。

これから数回にわたって、そんな悩みの解決になればということで、同時接続を節約する同期モデルという方法について解説をしていきます。

今回ここで紹介するのは、FileMaker Goでの同期モデルの方法です。WebDirectではPHPを使ってアクセスすれば節約できますが、コーディングが必要になってきます。

同期モデルってなに？

FileMakerGoからFileMaker Serverホストされている共有ファイルを開くと、そのファイルを直接ファイルを開くことになり、同時接続ライセンスを1つ消費します。

また、そのファイルを開いている間はFileMaker Serverと繋ぎっぱなしの状態になり、同時接続ライセンスを繋ぎ続けることになります。

この繋ぎっぱなしをなくし、データのやり取り時だけ、サーバに接続するというのが同期モデルと言われるものです。

同期モデルのもう一つの効果

同期モデルには接続ライセンスを節約するということを目的にする場合と、Wi-Fiなどの電波が届かなく、インターネットに接続できない環境下でもデータを入力したい場合などに使われます。

また、接続できたとしてもクライアント側の電波状況が悪い場合で、FileMaker Serverとうまくつながらない状況下でも効果的です。

同期モデルの二つの方法

①まず、データをFileMaker Serverに送ったり、受け取ったりするとき（同期時）だけFileMaker Serverに接続する方法と、

②インターネットに繋がっている状況であれば、常にFileMaker Serverに繋がっている方法の二つがあります。

②は接続ライセンスの節約というよりは、クライアントにいろいろな状況があり、インターネットに繋がりにくい環境下で作業することがある場合です。

①は②に加えて接続ライセンスの節約もできるという方法です。

ここでは、①の方法を扱っていきます。

また、二つの方法がどう違うかを見ていきます。

①完全同期モデル

先ほどの①モデルでは、FileMaker Server上の共有ファイル、同じiPad、iPhone（以下デバイス）上の2つのファイルが必要になります。

入力用のファイルと、中間ファイルは同じデバイスにあります。

役割としては、入力用のファイルは入力（や閲覧）だけをするためにあります。

中間ファイル（コンテナ）は入力用のファイルのデータをFileMaker Serverのファイルを開いて更新したり、または受け取ったりします。

なぜ、このような複雑な方法と取るかというと、入力用のファイルに直接FileMaker Serverのファイルのデータを取得しようとすると、その入力用のファイルを開いている間、FileMaker Serverに接続している状態になるからです。

②簡易同期モデル

このモデルでは、入力用ファイルからFileMaker Serverのファイルに直接接続します。直接、データをサーバのファイルから移動します。

このモデルでも、インターネットに繋がっていなくても、入力用のファイルが開けますので、Wi-FiモデルのiPadなどで事務所でデータを同期（ダウンロード）して、Wi-Fiのつながらない場所に移動しても入力などができます。

次回は、①完全同期モデルでの開発と解説を行っていきます。

FileMaker（ファイルメーカー）で複数のキーワードで検索してみよう

Google（グーグル）などのWebサイトの検索ではおなじみですが、

「ラーメン　秋葉原」や「本屋　神保町」という風に複数のキーワードを組み合わせて検索するというのはよくあります。

Web検索では無意識に行っていますが、FileMakerでもやりたいと思ったことはないでしょうか？

今回は複数のキーワードを検索する方法を紹介します。

ちなみに「ラーメン or　秋葉原」ではなく「ラーメン and　秋葉原」の検索になります。

あるフィールドから「ラーメン」も「秋葉原」も両方が含まれるレコードを検索するということになります。

概要

・まず対象となるフィールドのどこかのフィールドに「ラーメン」が含まれるレコードを検索します。

・次にその対象レコードから、どこかのフィールドに「秋葉原」が含まれるレコードを絞り込みます。

・例ではキーワードが二つでしたが、それ以上にもフレキシブルに対応します。

・３つ以上のキーワードはLoopでさらに絞り込んでいきます。

設定

・フィールド「商品名」「メーカー」「コメント」の3つ（この3つのフィールドのどれかにキーワードが含まれていることものを検索する）

・「g_検索ワード」というグローバル格納のフィールドにキーワードを入力するとスクリプトが起動し、検索を行う。

スクリプト

スクリプトはこの図のようになります。

・（2行目）スペース区切りで入力された検索ワードを改行区切りにします。半角でも全角でも大丈夫なようにします。

・（3行目）ワード数を調べます。

・（4行目）最初のワードを取得します。

・（5～11行目）最初のワードが対象のフィールドのどこかに含まれているレコードを検索します。

・（12～14行目）ワードが１つだけだった場合（ない場合も）は、スクリプトを終了させます。

・（15行目）2つ目のワードであることを変数に格納します。

・（17行目）2つ目のワードを取得します。

・（18～24行目）1つ目と同じようにどこかに含まれているかを設定し、対象レコードの絞り込みを行います。

・（25行目）現在の絞り込み回数がワード数実行されたら、ループ（Loop）を抜けます。

・これをワード数分繰り返します。

実行例

このような４つのレコードが場合です。

上部にある窓が検索ワードを入力する部分です。キーワードをスペース区切りで入力し、「Enter」や「確定」させるとスクリプトが実行されます。

「usbメモリ」「東芝」「16」と入力されています。

実行すると、このように「usbメモリ」「東芝」「16」がすべて含まれる１レコードだけが結果に表示されました。

サンプルダウンロード

今回紹介した内容のサンプルファイルを用意しましたこちらからダウンロードできます。

え？ クライアントOS（Windows）でFileMaker Serverが使えない？

FileMaker 14シリーズになり、もしかしたら気づかれた方も多くいらっしゃることと思います。

FileMaker Server14では、WindowsのクライアントOSがサポートされなくなりました。

「クライアントOSで動くことがFileMaker Serverの魅力の一つだったのに…」などと少し残念な気持ちにもなりました。

しかし、初めにFileMaker Serverに触れたとき、クライアントOSでも動くのか！　と少し驚いたことを考えるとなるべくしてなったことなのかなと思うこともあります。

ただし、サポートされなくなっただけで現状はインストール可能なようです。FileMaker Server14ｖ1ですが、Windows7で動いているので、実際にはまだ大丈夫なようです。

Windows10でどうか？

結論から言いますと、現状は難しそうです。

先日ためしにインストールを試みましたが、Application Request Routing（ARR）のインストール中に止まってしまいます。

もしくはエラーが出て「インターネットに繋がっていない」旨のメッセージが出てインストールできませんでした。

手動でインストールする手順がFileMaker社のサイトに載っていますが、Windows10のIIS（インターネットインフォメーションサービス）のバージョンが違うのでできません。

IIS10というバージョンになるので、それ用のものを探そうとしたところで断念。

Windows10にしなければ大丈夫だ…ということで。

FileMaker Serverが新しいWindows Serverに対応するころにいけるようになるのではと推測しています。

WindowsのクライアントOSのテスト機として用意しやすいので、インストールできないようにしないでください…ね？（期待を込めて）。

その繰り返しフィールド、本当に「繰り返しフィールドでいいですか？」

繰り返しフィールドのデメリット

もう、FileMakerの扱いにも慣れ、多数のソリューションを作り、繰り返しフィールドのメリット、デメリットをご存じであれば、特にこの記事を読んでいただく必要もないでしょう。

FileMaker Proには特殊な機能である「繰り返しフィールド」というものがあります。

1レコード、1フィールドに複数のデータを保持できるものです。

本来は別のテーブルに保存して管理するべきデータを繰り返しフィールドに保存してしまうといったことが起きます。

例えば、請求書をFileMaker Proで作成するとします。

請求書には請求先の名前や、請求金額及び、明細が必要となります。

名前や請求金額などは1つの請求に対して、1つだけが必要なので、特に問題はありません。

明細は1つの請求書に対して、複数必要になってきます。

FileMaker Proを触る以前にAccessなどでリレーションを少しでも学び、使ったことのある方であれば、テーブルを二つ作ることを思いつくでしょう。

しかし、Excelから直接FileMaker Proに来た方などはどうしても繰り返しフィールドに手が出てしまいます。

私はこれがFileMaker Proの初めての罠だと思っています。

先ほど出ました明細行に繰り返しを使うと、Excelなどに出力する場合に、その後加工するのが面倒ですし、スクリプトや計算式で複雑になってきます。

あとで、このデータを別のテーブルに移動して使いたいなど、データの再利用が難しいなどのデメリットありますし、将来的にデータベースに加える際などに大変になってきます。

メリット

もちろんメリットもあります。

一時的にデータを格納したり、再利用するつもりもない、メモのようなものを保存する場合には繰り返しフィールドは効果的な場合も多くあります。

正規化

データベースには正規化というものがあります。

FileMakerの場合はそこまで厳密にする必要がないということも言われていますが、上記の例のように請求書の明細行などはテーブルを分けます。

正規化の詳しい内容について検索をしていただければいくらでも出てきます。

第一正規化くらいでいいので検索してみましょう。

まず、FileMaker Proを始められる方は、繰り返しフィールドを使わない方がいいでしょう。

いくつもソリューションを作成し、リレーションにも慣れてきたら、少しずつ使うようにした方がいいかもしれません。

FileMaker Pro＋Goで行う在庫管理システムを作ってみる Part6

FileMaker　Pro＋Goで行う在庫管理システムを作ってみるの第6弾です。

以前の記事はこちら↓

FileMaker　Pro＋Goで行う在庫管理システムを作ってみる Part1

FileMaker　Pro＋Goで行う在庫管理システムを作ってみる Part2

FileMaker　Pro＋Goで行う在庫管理システムを作ってみる Part3

FileMaker　Pro＋Goで行う在庫管理システムを作ってみる Part4

FileMaker　Pro＋Goで行う在庫管理システムを作ってみる Part5

バーコードスキャンをするスクリプト

part4で作成しましたレイアウトの「Scan」ボタンに設定するスクリプトはいたってシンプルです。

上の図のように1行だけなので、ボタン自体にスクリプトステップを割り当ててもいいのですが、今後その前後に何かの処理をさせたいということがあるかもしれないので、とりあえず１行のスクリプトを作成し、設定します。

このスクリプトを実行すると、カメラが立ち上がり、バーコードをとらえると自動で読み取り、設定したフィールド（ここでは「棚卸記録::kf_商品コード」）に入力されます。

スキャンすると上の図の「商品コード」のフィールドにバーコードの内容が挿入されます。

次に、日付と、在庫数を入力すればOKという流れです。

日付に関しては、先ほどのスクリプトにフィールド設定で「Get(日付)」を設定してもいいでしょうし、レコードが作成されたときに自動で、入力するようにオプションで計算値の入力を設定してもいいでしょう。

実在庫とデータベース上の在庫の差異調整スクリプト

棚卸が終わると、そのデータと商品マスター上のデータの差異を調べて、実在庫に合わせるように調整を行います。

下記がそのスクリプトです。

スクリプト内にある変数を設定「$現在庫数」の計算式は下記のようになっています。

また、「$実在庫数」は下記です。

スクリプトの流れとしては、棚卸の記録レイアウトで本日行った棚卸の記録を表示し、Loopで上から商品マスター上の在庫数を比較します。異なれば、「入出庫管理マスター」に移動して、差異を調整し、これを一番下のレコードまで繰り返します。

$実在庫数では、倉庫内に同じアイテムが別々の場所にある場合を想定していますので、複数の場所にあっても（棚卸記録テーブルに商品コードの重複したレコードがあっても）問題ありません。

非常に簡単ではありましたが、在庫を管理するだけという観点のソリューションになります。

FileMaker Pro＋Goで行う在庫管理システムを作ってみる Part5

FileMaker　Pro＋Goで行う在庫管理システムを作ってみるの第5弾です。

以前の記事はこちら↓

FileMaker　Pro＋Goで行う在庫管理システムを作ってみる Part1

FileMaker　Pro＋Goで行う在庫管理システムを作ってみる Part2

FileMaker　Pro＋Goで行う在庫管理システムを作ってみる Part3

FileMaker　Pro＋Goで行う在庫管理システムを作ってみる Part4

バーコード

このソリューションでは、商品や棚にバーコードを貼り付け、それをスキャンすることで商品を識別し、実在庫数を入力し棚卸をします。

というわけで、どこかでバーコードを印刷したりするようにしなくてはいけません。

バーコードフォントというのがあり、入力した数値などをバーコードとして表示してくれるフォントがあります。

https://www.technical.jp/barcode/font/で無償配布されていますので、そちらを使わせていただきます。（Windowsのみのようです）

ここではCODE39という簡単なものを使用します。

インストールはいたって簡単で、ダウンロードしたファイルをダブルクリックで開いて、「インストール」を選択するだけです。

バーコードにはスタートコードと、ストップコードというのがあります。CODE39の場合は「*」です。これを商品コードの前後につけます。これを読み取ると商品コードを読み込んでくれます。

商品マスターをちょっと改造

バーコードを印刷できるようにするために、商品マスターに商品コードをバーコードで読めるようにするためのフィールドを作成します。

このフィールドには自動計算値入力で、

"*" & 商品コード & "*"

としました。このフィールドをCODE39のフォントでレイアウト上に表示するとバーコードになります。

レイアウトはこんな感じになります。

ブラウズモードで見るとこんな感じ

これを印刷して、貼っておけば、これをスキャンするだけで入力ができるようになります。

次回はいよいよスキャンするスクリプトを配置したり、レイアウトを調整していきたいと思います。

FileMaker Pro＋Goで行う在庫管理システムを作ってみる Part4

FileMaker　Pro＋Goで行う在庫管理システムを作ってみるの第4弾です。

以前の記事はこちら↓

FileMaker　Pro＋Goで行う在庫管理システムを作ってみる Part1

FileMaker　Pro＋Goで行う在庫管理システムを作ってみる Part2

FileMaker　Pro＋Goで行う在庫管理システムを作ってみる Part3

レイアウトの作成

今回はレイアウトの作成を主に扱っていきたいと思います。

今回のテーマとして「FileMaker Pro＋Go」ということがテーマとなっています。

PCとモバイルのハイブリットということですが、こういったケースの場合、それぞれのデバイスで行うことの役割というのは比較的明確になってくるでしょうか。

今回はPCは在庫数のチェックやマスターの登録。

モバイルは棚卸での利用を想定していますので、商品マスター等の閲覧はしません。

イメージとしては、iPhoneやiPodTouchを使って、バーコードを読み取り、在庫数を入力していくという作業に使います。ハンディターミナルや、バーコードリーダーの代わりということになります。

商品マスター

商品マスターのレイアウトは今回はリスト形式を採用します。

この例ではフィールド数が少ないので、リスト形式だけでいけますが、実際に業務で使っていくとなると、商品には様々な情報（画像や、商品の仕様など）あると思いますので、フォーム形式との併用ということになろうかと思います。

一覧表示（リスト形式）にボタンを配置し詳細画面（フォーム形式）に移動したり、一覧表示にポップオーバーボタンを配置し、そのポップオーバーにリスト形式では表示しきれないデータなどを配置するという手もあるでしょう。

棚卸用レイアウト（Go）

続いて、棚卸レイアウトです。

iPhoneやiPodTouch用のレイアウトを作成していきます。

レイアウト管理画面から「新規」をクリックすると、ウィザードが出ます。そこでタッチデバイス→iPhoneを選択すると、自動的にiPhone用の画面の大きさになります。

ただし、現在はiPhoneでもさまざまな画面サイズがありますので、基本的にはアンカーを使って、いろいろなサイズに対応していく必要があります。

上の図の赤枠部分がアンカーです。右側のアンカーを各フィールドに設定します。こうすることで、横画面や縦画面でその画面サイズに応じて、フィールド枠が広がります。

ズームの設定

iPadやiPhoneのモバイルデバイスでは、指先で画面の拡大や縮小が可能です。しかし、多くの場合、これをそのままにしておくと、画面がぶれる様な動きをすることがあり、扱いづらくなります。

スクリプトで、「ズームの設定[ロック；100％]」を作成し、OnLayoutEnterに設定しておくことで、これを防ぐことができます。

レイアウトはこのような感じにしました。

ボタンを配置し、「Scan」ボタンは、バーコードを読み取り、その内容を「商品コード」に入力、「New」で新規レコードを作成するという形になります。

FileMaker Pro＋Goで行う在庫管理システムを作ってみる Part3

FileMaker　Pro＋Goで行う在庫管理システムを作ってみるの第3弾です。

以前の記事はこちら↓

FileMaker　Pro＋Goで行う在庫管理システムを作ってみる Part1

FileMaker　Pro＋Goで行う在庫管理システムを作ってみる Part2


※FileMaker14が登場しましたので、FileMaker Pro 14での操作画面になりますが、基本は12でも13でも変わりありませんので、よろしくお願いします。

これまで＋これから

前回までは、テーブルを作成し、フィールドを定義してきました。今回はリレーションを定義していきたいと思います。

リレーションシップの基本

リレーションシップの基本はこちらを参照していただくか、書籍などにも記載がありますので、詳しくは取り上げません。

しかし、一つ気を付けておいた方がいいことがあります。

通常のソリューションの作成として、「テーブル・フィールド作成」→「リレーション作成」→「レイアウト作成」→「スクリプト作成」という大きな流れがあると思います。

しかし、ガッツリこの流れで行うとリレーションマップが複雑（増えすぎ）てしまうということがあります。

「テーブル・フィールド作成」→「リレーション・レイアウト作成」→「スクリプト作成」というように、リレーションを作りこまずに進める方が、うまくいくケースが多く、リレーションが割とシンプルになってきます。

とはいっても、今回はそれほど複雑なものでもないので、リレーションを定義していきたいと思います。

一つだけリレーションを作成しました。とりあえずこれだけです。このリレーションは、在庫数を計算するためのものです。

また、フィールド定義を変更しました。

「現在庫数」として、図のように計算式を入れました。

Sum ( 入出庫管理マスター::入庫数 )　-　Sum ( 入出庫管理マスター::出庫数 )

※「商品名」というフィールドを追加しました。

ちなみに、この「現在庫数」は非保存のフィールドになるので、レコード数が増えてくると重くなってくる可能性があるので、その時は考えなくてはいけないかもしれません。

次回はレイアウトを作成してきます。

FileMaker 14がやってきた！

こんにちは！
FileMaker14がやってきました！

FileMaker14ではおもに開発者が開発しやすいような機能の拡張や改善などが
多く見られました。

主な変更点などを取り上げていきたいと思います。

・メニューなどのデザインが変わった。
iOSに準拠したようなデザインになりました。

・スクリプトウィンドウのインターフェイスの大幅な改善
今までは必ずスクリプトステップをリストから選んでダブルクリックで選ぶ必要がありましたが、手で入力することができるようになりました。また、入力された文字から予測する機能もあるので、非常にスクリプトを素早く記述できるようになりました。

なんだか、プログラミングっぽくなった！

また、お気に入りが登場！　このブログを読んでいただいたんでしょうか？
もしそうだとしたら感激です。

・スクリプト編集画面からスクリプトデバッガが起動できる
スクリプト編集画面にデバッガを起動できるボタンができました。


・スクリプト編集画面で色が変わる
If分やLoop分などで色が分かるようになりました。また、フィールドが使用されている部分も色が変わって表示されるようになりました。

・計算式設定ウィンドウのインターフェイス大幅改善
スクリプト同様に、入力を予測し、候補を表示し入力できるようになりました。これがほしかった！

・スクリプトデバッガでエラーの説明も
今まではデバッガでエラーが発生したときにはリンク付きの番号が表示されていただけでしたが、説明も一緒に表示されるようになりました。

・ボタンバー
レイアウトツールの一つに、複数のボタンを連結したボタンバーが登場しました。
レイアウトでボタンをくっつけて、メニューリストのように使うことはよくあるので、便利です！
今までは、ボタンのサイズや位置を調整するのが少し面倒だったので、楽になりました。

しかも、普通のボタンとポップオーバーを混在させることもできる！

・新しいフィールドラベル
フィールドが空で、非アクティブ時にフィールド内部にフィールド名が表示されるラベル（プレースホルダ―テキスト）が登場
配置するフィールドが多いレイアウトには重宝しそうです。

・新しいパートが追加
上部ナビゲーションパート、下部ナビゲーションパートという新しいパートが加わりました。

・チェックボックスなどのスタイルが変えられる。
今までは違うテーマからコピペなどで何とかしのいでいたチェックボックスなどのスタイルが変更できるようになった！　すごい。
レイアウトを作成するときに、けっこう大変だった……

・アカウントの新しいウィンドウ
アカウントの管理で新しいインターフェイスになりました。
文字は大きくて使いやすいけど…と思ったいたら前のも使えてよかったです。

・デバイスにパスワードが保存できるように
FileMakerソリューションのパスワードがデバイスに保存できるようになりました。また、各ソリューションごとにさせてもいいか、させたくないかを選択できます。

新しい関数や、スクリプト

・許可される向きの設定
このレイアウトは横表示だけにしたいといったときに使うようです。

・ディレクトリを取得
簡単に言うとフォルダが作成できるようになりました。

・タッチキーボード
iOSやWindows8でタッチキーボードを切り替えることができるようになりました。出したくないときなどに重宝しそうです。

・OnExternalCommandReceived
ユーザがロックボタンなどを押したときに動作するスクリプトを設定できるようになりました。

細かい変更点はまだまだありますが、主な変更点はこんなところでしょうか。

イメージとしては、開発機能とモバイルデバイス用の機能が強化された印象です。
ユーザの方にはあまりバージョンアップしたことが実感的ないかもしれませんが、
開発者としては便利になったなといった印象を受けたFileMaker14です。

FileMaker Pro＋Goで行う在庫管理システムを作ってみる Part2

前回に引き続きFileMaker Pro（ファイルメーカー）とFileMaker Goで使える在庫管理システムを作ってみるをお届けします。

FileMaker Pro＋Goで行う在庫管理システムを作ってみる Part1

前回は基本的な構造（テーブル）作成を行ってみました。

今回は、フィールドを定義していきたいと思います。

フィールドの定義

FileMakerで、ソリューションを作成する場合、初めから詳細な設計図や要件定義書を作成したりしてから取り掛かるという場合は多くはないと思います。それが、FileMakerのよさであります。

少しずつ、付け足していけるということができるのがこのFileMakerなので、この段階でも完璧を求める必要はありません。思いついたものを定義していくという感覚で進めていきたいと思います。

商品マスター

上記の図のように、３つのフィールドを作成しました。

実際に使用する場合は、単価や、備考など管理のためにフィールドを追加する必要があるでしょう。

入出庫管理マスター

入出庫マスターは、仕入れがあったり、販売して出荷する際の記録をするためのテーブルです。図のようにフィールドを作成します。商品コードのフィールドは、リレーションで商品マスターの商品コードのフィールドと繋ぐことになります。

また、このテーブルは、棚卸で、このシステム上の在庫数と差異があった場合に調整のためのレコードが記録されるテーブルでもあります。

棚卸記録

このテーブルは、棚卸の記録をするためのものです。棚卸では、iPadやiPhoneを持ち、倉庫で実在庫を記録することを想定しています。ここで記録された在庫数と、商品マスターでの在庫数を比較し、調整を行います。

次回は、リレーションを作成しながら、フィールドの定義について見直していきたいと思います。

FileMaker Pro＋Goで行う在庫管理システムを作ってみる Part1

はじめに

今日から数回に渡り、在庫管理をFileMaker Proで行う方法の一つを紹介していきたいと思います。

方法は他にもいろいろありますが、比較的単純な方法で行ってみたいと思います。

まず、何で在庫管理かというと、業務で使用するソリューションで会計管理、販売管理というのは双璧で、市販のソフトも充実しています。

その次として顧客管理や在庫管理も多く使われているかと思います。顧客管理はパッケージが多くあります。
在庫管理は販売管理とセットになって組み込まれている場合もありますが、別で管理することもあるでしょう。ということで、FileMaker Proを導入される方で作成されることも多そうなものをチョイスしてみました。

前提として、先ほども触れましたが比較的単純な方法で行います。

企業ごとに業務ルールなども違うと思いますので。

構造

・商品マスター
在庫のもととなる商品のテーブルです。このテーブルを大元として、データベースを作成します。

在庫数が変動する要素として、下記のようなことがあります。

・入庫
・出庫
・棚卸による差異の調整

よって、この３つの動きが個別にわかるようなテーブルを作成します。

「棚卸による差異の調整」に関してのテーブルは棚卸時の在庫数を入力できるようにし、このテーブルとマスター上の在庫を照合し、差異があるものと別のテーブルに記録し、調整します。

以上から作成する基本のテーブルは3つになります。

次回は、フィールドの作成とリレーションを見ていきます。

ヘルプは最高の教材

FileMaker Proとヘルプ

皆さんは、FileMakerに限らずヘルプを見ますか？

おそらく、そんなに見ないかと思います。

私の会社では、PCでソフトやOSのヘルプを見ている方というのにお目にかかったことがありません。

しかし、ヘルプは使い慣れれば非常にいいツールであることが分かります。

Windowsのヘルプ

Windowsのヘルプはスタートなどから開くことができ、検索などで目的のページにたどり着き、内容を参照する、ということになります。

これが使えるようになるとけっこう便利です。

目的の処理や動作、設定などのウィンドウを開くためのリンクが用意していあるからです。

「あれ、どこにあったかなあ」と唸るのであれば、素早くキーボードの「ウィンドウズ」マーク＋「F1」でヘルプが開きます。

基本的にどのソフトでも、「F1」を押すと、ヘルプが立ち上がります。

ただし、目的のページを探せるかは、難しい部分もあります。インターネットで検索した方が早く出てくる可能性は高いかもしれません。

FileMakerのヘルプ

FileMaker社では、いろいろなドキュメントや、公式の教材があり多くの方が読まれているかと思います。

しかし、ヘルプにしか書いてないことも多くありますし、関数の使い方や、スクリプトステップなどはヘルプで探した方が早い場合もあります。

ただ、どのソフトのヘルプでも同じですが、英語からの翻訳だったりする場合もあるので、意味が理解できないものもありますので、使いかけだと思いますが、

私が開発中に見るのはヘルプでFileMakerの仕様を確認することが多いですね。

FileMaker Serverでのトラブル（備忘録的）

FileMaker Serverの最近のトラブル

ここ半年間で起きたFileMaker Serverがらみのトラブルをちょっと書かせていただきます。

・Admin Serverのダウン

・ホストしているファイルが閉じられなくなる

・クライアントが入力した値がサーバ上で書き込まれない

主にこういったことがありましたので、個別に書いていきたいと思います。

Admin Serverのダウン

ここ半年で3回あったトラブルです。

その前の半年間では一度もなかったように記憶しているので、ソフト上で不安定になっているのか、サーバ機自体に何かあったのかは不明ですが、2か月程度に一回くらいあるイメージです。

Admin Server（管理サーバ）の役割はFileMaker社が発行しているヘルプによると、

他の FileMaker Server コンポーネントの展開を管理し、FileMaker Server 設定のために、クライアントコンピュータに Admin Console を表示する FileMaker Server ソフトウェアコンポーネント。

となっています。

簡単に言うと、AdminConsole用の管理プロセス、もしくはインターフェイスを管理しているということになるでしょうか。

最初は、スケジュールも動かなくなるのか、とヒヤッとしましたが、スクリプトエンジンがあたりがやっているのでしょう。このAdmin Serverがダウンしても問題はないようです。

このダウンを放っておいても、AdminConsoleが使えなくなるだけで、ホストされているデータベースも普通に動くし、スクリプトも動くということになるでしょう。

ホストしているファイルが閉じられなくなる

あるファイルですが、クライアントがスクリプト実行中にソフトを強制終了が引き金に起こりました。通常、スクリプトステップ「ユーザによる強制終了」をオフにしておけば、スクリプト自体は止めることができないのですが、FileMaker Pro自体を強制終了させてしまえば、ソフトが終了します。

しかも今回の場合は、AdminConsole上はそのアカウントがログインしたままの状態になっていました。

さらに、それがAdminConsoleでも、コマンドラインでも接続解除できないという事態。

ファイルも閉じられず、AdminConsole上でデータベースサーバを停止してみるも、停止しない。

結局はコマンドラインで、全ファイルを一括で閉じてみると閉じられました。

クライアントが入力した値がサーバ上で書き込まれない

同じファイルを開いているAさんとBさんがいたとします。

Aさんが入力をし、確定すると通常はサーバ上のファイルに書き込まれ、Bさんにも即座に表示されます。

しかし、書き込まれませんでした。さらに、排他制御も働かなかったようで、同じレコードに同時に書き込むこともできてしまったようでした。

AdminConsole上のログを見ても何も警告など出ていなかったので、念のためサーバ機自体再起動をして直りました。

これは後にも先にも１回だけの出来事でした。

同じような出来事があった方の参考になればと思います。

FileMakerでデータの入力ログを記録してみるPart2～決まったフィールドだけ監視～

データの入力ログ（履歴）を記録してみる

FileMakerでデータの入力ログを記録してみるでは、テーブルの全フィールドに対して変更がされた場合のログを記録しましたが、この方法では、スクリプトなどで書き込まれた値は反映されません。

しかし、テーブルに内に20や30のフィールドがあってもログとしての変更履歴を残したいのはそれほど多くない場合もあるかもしれません。そんな場合の方法の一つです。

この場合は、スクリプトや全置換によって変更されたデータ内容も記録されます。

基本的には方法はFileMakerでデータの入力ログを記録してみると変わりありません。

方法

履歴を記録したいフィールド1つに対して、1つ記録用のフィールドを用意します。

記録用のフィールドに対して下記の計算式を設定します。

※logA　はfieldAの履歴保存用のフィールドです。

logA & Get ( タイムスタンプ ) & " | "  & fieldA  & "¶"

無駄な改行が気になる場合

上記の方法では最初に改行が必ず入ります。入らないようにしたい場合はこのようにすると入らずにできます。

Let([

$count = Case (ValueCount(logA)=0 ; 1 ; 0)];

Replace ( logA & "¶" & Get ( タイムスタンプ ) & " | "  & fieldA    ; 1 ; $count ; "" )

)

ちなみに、履歴は末尾に足されていきます。

最新の履歴を上にする場合

最新の履歴を履歴の上に（降順）にする場合は下記のようにします。

Get ( タイムスタンプ ) & " | "  & fieldA  & "¶" &  logA

また、この場合終わりの改行が入りますので、気になる場合は消す必要があります。

下記のようにすればきれいになります。

Let([

 $log = Get ( タイムスタンプ ) & " | "  & fieldA  & "¶" &  logA コピー ;

 $length = Length($log);

 $m = Case ( ValueCount($log) = 1 ; 1 ; 0)

];

 Left ( $log ; $length - $m)

)

Webサイトから情報を取得して、一部（価格など）をFileMaker Pro（ファイルメーカー）に取り込む（価格.com）

価格.comからある商品の最安価格を取得

ネットショップなどを運営されていたり、そうではなくてもただ、ネットショップの最安価格を頻繁に知りたいときってありますよね。

FileMaker Proを使って価格比較サイト「価格.com」から最安価格の情報を取得して、フィールドに表示してみる方法です。

最低限必要なフィールド

・価格を格納する

・URLを格納する

・HTMLソースを格納する

この３つのフィールドが必要となるでしょうか。

流れ

URLから挿入スクリプトステップで「ソース」フィールドにソースを挿入

↓

ソースから最安価格の入っている部分の文字位置を取得（Position関数）

↓

価格部分を抜き出す（Middle関数）

※基本的な手順はFileMaker Proでメールを受信してみるで扱ったのとあまり変わりありません。

どこに最安価格が書いてるか？

上の画像が商品のページで、このページから情報を取得します。人間が見ればすぐに最安価格が目に入ってきますが、ソース上でどれがそれにあたるかを見なければなりません。

トラブル？

URLから挿入で、ソースを取得すると日本語が文字化け・・・文字コードの関係なのでしょうか。

文字化けがなければ、ヘッダ部分に情報があるのでそれを取得できたのですが・・・

先頭文字位置

最安価格はソースのいろいろなところにありましたが、「kakakuItemviewPrice」という部分が分かりやすいので、この部分から取得できます。これの文字位置を取得し、さらにkakakuItemviewPriceの文字数分を足すと、純粋な数字で価格の先頭文字位置になります。

※実際には「kakakuItemviewPrice = '」が検索文字になります。

文字数を取得

文字数（価格の桁数）を調べるには先ほど調べた先頭文字位置をスタートとして次に「'」が出てくるところまでになります。

これは　「Position ( ソース ; "'" ; 先ほどの先頭文字位置 ; 1 )」で分かります。

計算式

Let([

 $start = Position ( ソース ; "var kakakuItemviewPrice = '" ; 1 ; 1 ) + 27;

 $end = Position ( ソース ; "'" ; $start ; 1 )

];

Middle ( ソース ; $start ; $end - $start )

)

これを価格のフィールドに設定すると最安価格を取得することができます。

FileMaker（ファイルメーカー）とデータモデリング～FileMakerの使い方を覚えるくらい重要なこと～

FileMakerはシステム開発

「なんだこれ！　だれが作ったんだ」

私が初心者の時に作ったソリューションは今でも動いているものもありますが、
FileMaker11のものだったので、いっそのこと作り変えてしまおうと思い、構造を分析し始めたときに思わずPCのモニターに向かって叫んだ言葉です。

見るに堪えないし、ほかの人には見せられない。

同じような経験は他の方にもあるのではないかと思います。

FileMaker Proの使い方以前に、何でこういう構造にしたのか理解できないということが多くありました。

「ファイルメーカーの使い方だけを覚えても、業務に役立つシステムは作れない」ということを身に染み、データモデリングについて勉強が必要だということを感じました。

FileMakerトレーニングシリーズ（training series）では「データモデリング」というセクションがあり、
データベースの設計について書かれています。

わざわざひとつのセクション丸ごと扱うということは、重要だということでしょう。

私もそうでしたが、とにかくExcelや紙はやめたいという思いが強く、そんな小難しいことを勉強する余裕があるはずもありませんでした。

長く、業務に役立つものを作り、社内からも支持されるには、小手先のソフトの使い方ではなく、表には見えにくい基礎的なことを充実させることが、いいソリューションを作成することではないかとFileMakerを使い始めてからしばらくして気づきました。

とはいえ、こういった分野のことは本当に奥が深く、インハウスの開発者であれば、あまり意義を見出せないかもしれません。私もそう思ったことがあります。

しかし、何年間前に作ったものを見返すたびに「基礎を見直そう」と思うわけです。

私もまだそんなことを言っても勉強の途上にいるので偉そうなことはとても言えません。

重要だと思ったこと

・シンプルに行く（＝他の人が見て分かりやすいように）

・システムを業務に100％合わせようと失敗する

たぶんシステム開発に関して書かれた本か何かに書いてあったことだったと思います。特に「システムを業務に100％合わせようと失敗する」は本当にそう思います。

「システムを業務に100％合わせようと失敗する」とは、紙やExcelの帳票をそのままFileMakerに載せ替えるだけでは、業務の改善・効率化という意味ではあまり意味をなさない。というようなことです。

システムを作るとき、作り変えるときは業務フロー自体も見直す。と書いてありました。

無理に合わせようとすると、滅茶苦茶なソリューションを作り出すことになり、どこかで行き詰ってしまいます。

また、作ったソリューションはいつか自分の手を離れる。ということも意識しなくてはなりません。

自分の手から離れたものは他人がメンテナンスします。後任に分かりやすいように作ることを意識できれば理想的ではないでしょうか。

そういったことを実現していくには、やはり作る前にソリューションの要点を整理することではないかと思います。

メモでもいいと思いますし、cacoo.comのようなツールを使って図を作ってもいいでしょう。

できれば図式化しておき、頭の中を整理するといいのではないかと思います。

FileMaker Serverはオンプレミスかクラウド 結局どっちがいいのか？

オンプレミスとクラウド

今回は「FileMaker Serverにとっての最適なクラウドサーバ」とはで取り上げましたクラウド上の仮想マシンを使う場合と、オンプレミスのどちらを選択するべきかを考えてみたいと思います。

ちなみにオンプレミスは直訳すると「敷地内」となるでしょうか。

つまり、企業であれば自社のオフィス内にサーバを設置して、管理も自分たちで行うことを言います。

対してクラウドは、サービス提供者のデータセンターにサーバがあり、サービス提供者が管理をする方式です。

最近ではAmazonやマイクロソフトなどの事業者が比較的簡単かつ自動的にWindowsの仮想マシンを作成できるクラウドサービスを提供していることによって、FileMaker Serverをクラウドに置くことを検討したり、実際に運用したりすることが多くなりました。

基本的にAmazonやマイクロソフト（Azure）のサービスマシンをシャットダウン（停止）しておくと課金されないので、私なんかはテスト環境として開発中だけ起動して使ったりしています。

テスト環境用に自分でサーバを持とうとすると、結構なコストになりますので、クラウドサービスを使うとコスト削減に直接的につながるでしょう。

では、FileMaker Serverの運用サーバとして使う場合はどうなんでしょうか。

ちょっと考えてみたいと思います。

比較を行う条件

・Amazon EC2の仮想マシン（m3.large）

・オンプレミスは同程度のマシンを用意

※同程度のマシンといっても仮想マシンと実マシンなので一緒とは言えないかもしれません。

費用面について

まず、オンプレミスのサーバですが、Amazonと同程度といっても、まったく同じ構成の実サーバを探すのはちょっと難しいので、ざっくりで計算しています。

オンプレミスの場合はサーバ機以外にもUPSやインターネットから接続させることも考えるのであればルータなども必要になってくるでしょうし、細かいところを言うと固定IPアドレス取得代、プロバイダの接続代金などネットワーク関連の費用も必要になってきます。この辺はすでに持ってい場合もあるでしょうが、月に7千円ということにしておきます。

ざっくり計算ですが、サーバ機および周辺機器に約30万円、それと月に7千円のコストがかかるという感じにしておきます。

一方のEC2は月に2.6万円です。

この費用をグラフで比べたものが下の図です。

オンプレミスの場合はサーバ機の購入費用などを１か月目にすべて計上しています。

19か月目にオンプレミスとクラウド（Amazon）が累計費用が逆転します。

簡単にいうと19か月以上サーバ機を使うとオンプレミスの方がコスト的には安くなります。

しかし、コスト面だけで比較してはいけない面もあります。

直接コストに現れにくい面

例えば、故障を最初から考えて費用として見積もっておくのは難しいことだと思います。しっかりしたベンダーから購入したサーバ機が3年程度で壊れるかといったことは今の時代あまり考えにくいですが、壊れれば部品代、外に直すのを頼めば修理代もかかります。

オンプレミスの場合は社内の人間が面倒を見るので、人件費もかかります。

クラウドの場合は基本的に含まれているわけです。

また仮にOSが壊れたとしましょう。

クラウドの場合は、別の仮想マシンを立ち上げて、壊れたものは消してしまうこともできます。

オンプレミスの場合はそういうわけにはいきません。

そういった面も考慮するとなかなか結論を出しにくい問題ではあります。

私見

あくまでもこれは私見ですが、クラウドを選んだ方がいい場合とオンプレミスの場合を書かせていただきます。

クラウドがいい場合

・ネットワークやサーバの知識に自信がない

・とにかく早くサーバを導入したい

・社内にサーバを置く場所がない

・管理にできるだけ人を使いたくない

・費用として計上できる（サーバ機の償却が必要ない）

オンプレミスがいい場合

・長期的、継続的に使用する場合コスト的に安くなる

・LAN内だけの運用

・ネットワークやサーバの知識に自信がある、または頼れる人がいる

という感じになるでしょうか。

関連する記事：

FileMaker Serverにとっての最適なクラウドサーバとは　Part2

FileMaker Serverにとっての最適なクラウドサーバとは　Part1

FileMaker（ファイルメーカー）の変数について

データのテーブル間の移動

FileMaker Proであるテーブルから、別のテーブルへデータを移動する場合、どのような方法で移動されていますか？

おそらく、Excelなどにエクスポートして、レイアウトを移動して、インポートというのが一般的でしょうか？

リレーションを使って、ID同士か何かでテーブル同士を紐づけして、ルックアップで移動。

ExecuteSQL関数で、データを引っ張ってくる。

など、いろいろあるかと思います。

変数に格納

私はよく変数に格納し、複数行のデータがあれば改行区切りのリストとして格納して、別のテーブルのレイアウトへ移動して、一行一行展開なんてことをやったります。

スクリプトの行数としてはフィールドが増えると増えてしまいますが、エクスポート→インポートよりもトラブルが少なかったりするので、使っています。

Let関数を使えば、その行数も減らすことは可能でしょう。

しかし、よく考えてみると「変数って、メモリに保存されるはず」と思い立ち、ちょっと変数を使うことでどのくらいメモリ消費量が増えるかを調べてみました。

状況としては、7ケタの数字のデータを改行区切りにして、約12万件分をグローバル変数に格納。

すると下記のようにメモリ使用量が増えました。

格納前↓

格納後↓

4MB程度増えている感じです。

今の時代、4MBなんて大したことないですが、これがテキストデータだったりするともっと増えるのでしょう。

PCであれば問題になることはないでしょうが、もしかしたら、iPad、iPhoneであれば、データ量が大きければ問題が起きるかもしれません。

iPad、iPhoneでそんなに大量なデータを扱ったりすることはたぶんないのでしょうが。

FileMaker13からはFileMaker Goからでもサーバ上でスクリプトを動かせるので、それをうまく活用すれば特に問題はないでしょう。

FileMaker Serverにとっての最適なクラウドサーバとは Part2

前回FileMaker Serverにとっての最適なクラウドサーバとは　Part1の続きです。

今回は実用的なマシンスペックに変更して、前回と同じテストをしてみました。

2回目の比較

仮想マシンのスペックは下記の通りになります。

	名称	CPU	RAM
Amazon EC2	m3.large	2Core	7.5GB
Microsoft Azure	D2	2Core	7GB

※ディスクは両方ともSSDです。

結果

マシン	1回	2回	3回	4回	平均
Amazon EC2	1.051	1.044	1.055	1.035	1.046
Microsoft Azure	1.435	1.408	1.393	1.439	1.419

単位は秒です。

以上の結果になりました。

4つのマシンで行った結果の平均値だけをまとめてみます。

マシン	サイズ	平均
Amazon EC2	m3.large	1.046
Microsoft Azure	D2	1.419
Amazon EC2	t2.small	1.516
Microsoft Azure	A1	2.548

単純な数値判断ですと、Amazon EC2の方が早いという結果になりました。いちおうRAMがAmazonのほうが若干スペックが上ですが、仮に同じだったとしても、1回目と2回目の比較ではAzureのほうがいいということはないかと思います。

これは個人的な感覚ですが、リモートデスクトップでの動作（フォルダを開いたり、何かをコントロールパネルを開いたり）はAmazonのほうが早く感じました。

また、AzureのD2とAmazonのt2.smallとの差があまりありません。

あくまでも単純な比較ですが、Amazonに軍配が上がるでしょうか？

価格的なところ

価格を比較してみます。

マシン	サイズ	1か月の価格
Amazon EC2	m3.large	26,515円
Microsoft Azure	D2	24,132円
Amazon EC2	t2.small	4,390円
Microsoft Azure	A1	5,615円

※この価格は、各サイト上に掲載されている数字を24時間×31日で1/15現在のデータで計算したものです。これとは別にデータの出入り等で金額が変わる場合もあるでしょう。

数字には出ない面

ここまでは数値面を比較してきましたが、数字には出ない面はどうでしょうか。

使いやすさという点ではMicrosoft Azureの方が使いやすいと思いました。

基本的に仮想マシンの作成やダッシュボード（マシンの設定などの画面）が日本語対応なので、設定もしやすく、分かりやすくなっています。

Amazonは英語のダッシュボードですので、英語が苦手な方（私を含めて）は戸惑うかもしれません。

あとは、何を優先するかところだけだと思います。

コストだけだったら、Amazonのような気がします。しかしトータル面ではAzureかもと思われる方も多くおられるでしょう。

また、Amazonは料金表がドル建てで表記されているのでおそらく支払い時のレートで換算されて請求されるのでしょうか。Azureは円で書かれているので、円で請求されます。ただ、Azureもレートによって料金が変更されるということもあるでしょうから、何とも分かりませんが、短期的に円安に振れるようなことがあると、Amazonの方は思ったよりコストが高くなるということはあるかもしれません。

FileMaker Serverにとっての最適なクラウドサーバとは Part1

近年はFileMaker Serverを扱えるクラウドサーバ（仮想マシン）が増えてきました。

やはり素早く登録して、使用開始できるサービスとしてAmazon EC2とMicrosoft Azureはやはり２大サービスといっていいのではないでしょうか。

今回と次回の２回に分けて、FileMaker Serverを使った場合の比較をしてみたいと思います。

前提条件

同じFileMakerデータベースをFileMaker Server13でホスト

サーバOSはWindows Server 2012

サーバの場所はamazonは東京、MSは東日本

WAN経由でアクセス

データベースの内容は、郵便番号のデータベース（約12万件のレコード）

下記のスクリプトを実行して検索にかかった時間を測定（4回連続で測定）

１回目の比較

1回目は下記の２つのサイズの仮想マシンで比較しています。

	名称	CPU	RAM
Amazon EC2	t2.small	1Core	2GB
Microsoft Azure	A1	1Core	1.75GB

このスペックを選んだのは、FileMaker Serverを使える最低のスペックだと思うからです。

Amazon EC2にもMicrosoft Azureにもそれより小さいスペックはありますが、なかなか難しいでしょう。

ちなみに、FileMaker社の公表しているハードウェアの最低要件を満たしていませんがFileMaker Serverをインストールすることができます。テスト環境としては使えます。

結果

マシン	1回	2回	3回	4回	平均
Amazon EC2	1.773	1.341	1.108	1.840	1.516
Microsoft Azure	2.451	2.640	2.490	2.610	2.548

単位は秒です。

こんな結果が出ました。次回はスペックを上げて比較をしてみます。

次の記事：FileMaker Serverにとっての最適なクラウドサーバとは　Part2

FileMaker Proでメールを受信してみる

FileMaker Proでメールを受信してみる

FileMaker Proではメールを送ることができます。

しかし、メールを受信することができません。

受信するには何かしら外部の手助けが必要です。例えば、プラグインを使ったりします。

結構いろいろな方が、メールを受信できたらいいなという話をよく聞きます。

PHP+FileMaker Proで行う方法を紹介してみたいと思います。

しかし、自分でもまだ試行錯誤中なので、完ぺきではありません。

FileMaker Serverがあれば、PHP APIで、FileMakerデータベースに直接書き込めますが、ここではFileMaker Serverを使わずにやってみたいと思います。

準備

冒頭でも書きましたが、FileMaker  Proだけではできませんので他の手助けが必要になります。

方法としては、FileMakerからURLから挿入で、メールを受信するPHPスクリプトを起動して、送られてきたデータをフィールドに挿入し、分解していきます。

PHPスクリプトを起動するには、Webサーバが必要になります。

XAMPPというPHPやWebサーバのApacheなどが一度に開発用の環境がインストールされる、PHPとWebサーバを使用します。

このXAMPPでインストールされたApacheは初期設定では外からアクセスることができないようになっていて、自分からのアクセスだけが行えるようになっています。

このWebサーバにメールを受信するPHPスクリプトを置き、FileMaker Proから起動し、メールを受信してみます。

PHPのコード

<?php

header('Content-Type: text/html; charset=UTF-8');

mb_internal_encoding("EUC-JP");

$stream = imap_open("{メールサーバーとポート番号}INBOX","ユーザ名","パスワード");

if($stream == false){

die("false");

}

//メッセージの件数を取得

$count = imap_num_msg($stream);

for ($value = 1;$value <= $count;$value++){

$head = imap_fetch_overview($stream,$value);

$mg = '[start]'.mb_convert_encoding(imap_fetchbody($stream,$value,1),'UTF-8','JIS').'[end]';

echo $mg;

}

//メールストリームを閉じる

imap_close($stream);

?>

※メールサーバーとポートの部分の例は　{pop.exsample.com/pop3:110}INBOX　のような感じです。またユーザ名とパスワードもそれぞれ必要です。

FileMakerデータベース

数件のメールがまとまった形で一時保存されるフィールド「g_mail」※グローバル格納

それを１通ごとに分解したものを保存する「text」とフィールドを用意しました。

上記のコードで取得されたものはメールの本文だけで、受信者や件名などのヘッダは行っていません（いろいろと面倒がったので、またの機会に…）

また、複数のメールが一つのまとまってPHPでは取得されますので、出力するときに、メールの始まりに[start]、一通のメールの終わりに[end]を付けて出力されるようにしています。

これをFileMakerのスクリプトで探して、分解して、１レコード、１件のメールとなるようにしています。そのスクリプトが下記になります。

注意点

ただのプレーンのメールの場合はあまり問題がありませんが、HTML形式のメールだったりすると文字化けしたりします。本当であれば、ヘッダを取得して分析し、文字コードをフレキシブルに変えたりということができればいいんでしょうが…

ぜんぜん完ぺきではないので、もし試される方がいらっしゃいましたら、自己責任でお願いいたします。

FileMakerとWeb公開

多彩なWeb公開

FileMaker Serverには標準で多彩なWeb公開機能が搭載されています。

WebDirect

PHP

XML

とあり、幅広く方法でWebにFileMakerデータベースを公開することができます。

WebDirect

FileMaker Proで作成したデータベースをFileMaker Serverにホストさせ、Internet Explorer（インターネットエクスプローラー）やChrome（グーグルクローム）から特にデータベースに変更を加えずにアクセスすることができます。

頻度は多くないが、FileMaker Proを購入してまでは必要のない方にとって最適な機能でしょう。

専門的な知識はあまり必要なくデータベースをブラウザから見ることができ、デザインなどもFileMaker Proと同じように表現されるのが魅力的です。

FileMaker12まではインスタントWeb公開という機能でした。

インスタントWeb公開ではできなかったことがWebDirectではできるようになりました。

一つ問題があるとすれば、サーバのリソースを大量に使用する点でしょうか。

常時10や20アクセスのある場合はFileMaker Server2台体制（Web公開エンジンと、データベースエンジンを分離）させることは必須といえるかもしれません。

PHP

動的なWebページを表現するためのスクリプト言語であるPHPからもFileMakerデータベースにアクセスすることが可能です。

使い方としては大きく分けて２つあるでしょうか。

①すでにあるデータベースからデータを閲覧する場合

特定のデータをPHPを使ってデータベースから引っ張り出し、Webブラウザ上に表示させたり、またデータを書き込めますので、利用場面が限られる場合などにWebDirectの代わりに使ったりできます。

また、データベースの内容を自社のホームページなどに掲載したいときにも使えます。

②MySQLなどの代わりに

PHPでは、MySQLなどのデータベースにデータを書き込み、また読み込んでWebブラウザに表示させたりするのが一般的です。ネットショップや掲示板など幅広いWebサービスにPHP+MySQLという組み合わせが使われています。

このMySQLの代わりのデータベースとしてFileMakerデータベースを使えます。

メリットとしてはデータベースの定義が簡単なこと、メンテナンスが簡単、PHPコードの記述が少なくて済む場合がある、スクリプトが使えるなどのメリットがあります。

※PHPコードの記述が少なく＝PHP+MySQLでは管理機能もPHPで書く必要がありますが、FileMaker+PHPの場合は、管理機能をFileMaker Proで操作できます。

PHPを使うデメリットとしては、PHPの知識が必要ということでしょうか。PHPは比較的習得しやすい言語だといわれていますが、全くの初心者が独学で使うのは難しいかもしれません。

自分的には、PHP+FileMakerで結構いろいろなことができるんじゃないかと思ったりしています。

FileMaker+PHPでサーバの死活監視をしてみる

安定運用を支える死活監視

安定運用は、サーバやシステムが止まってしまう前に予防策（メンテナンス）を講じ、止まらないように努めることですが、いくら万全を期しても止まってしまうことはあります。

そこで、予防策と一緒に必要なのが、いかに早く障害や停止に気づくかということではないでしょうか。

それを知るには死活監視が必要です。特に、停止時にそれを教えてくれ、なおかつデータベースに記録していて後にいろいろなことを調べることも可能でしょう。

FileMaker Serverを使われている方には、FileMakerのWeb公開機能の一つPHPを使って、死活監視を行うこともできます。

といっても、特定のポートが通信できるかどうかを確かめるだけの非常に簡易的なものです。

方法

・FileMakerデータベースを用意

　監視状況を記録できるテーブルとフィールドを用意

・PHPのコードを用意

PHPのコード

$ip = {監視対象マシンのIPアドレス}
$port = {監視するポート番号} //例えばFileMaker Serverの場合は5003

$socket = @fsockopen($ip, $port, $errno, $errstr, 5);

if ($socket !== FALSE) {
echo 'OK'
 
        }else{
echo 'NG'
        }

このPHPコードをURLから挿入のスクリプトステップを使て、GETかPOSTでマシンのIPアドレスとポート番号を投げてあげれば、URLから挿入のターゲットになっているフィールドに結果が書き込まれます。

また、FileMaker API for PHPと連携して、PHPからFileMakerデータベースから監視対象のマシンのデータを参照して、結果を書き込む方法もあります。

欠点

・Windows Serverの場合、イベントログ上でエラーが出る（そのポートを使うアプリケーションの通信ではないため）

・死活監視をしているサーバの死活監視も必要（笑）