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の場合、イベントログ上でエラーが出る（そのポートを使うアプリケーションの通信ではないため）

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