Monthly Archives: May 2017

FileMaker Server 16のREST APIをmacOS上で試用する場合

FileMaker Server 16をまずは手元のMacにインストールして使ってみようという方も多いだろう。ここで、FileMaker Data API(REST API)を使用する場合にPHPのcurlライブラリを使うと、「SSL: CA certificate set, but certificate verification is disabled」というエラーメッセージが返ってくる。httpsでの通信が推奨され、証明書が検証できないと通信をしないということが当然となって来ているが、とはいえ、試用なので自己署名証明書で運用できないかとPHPの様々なパラメータを触ってみたところで、上記のエラーないしは別のエラーが出る。ということで、色々調べてみると、macOSに入っているopensslのバグで、サーバー検証をしないという設定ができないということらしい。homebrewから入れ直す方法など、色々紹介されているが、何をとっても大事になってしまう。

というところで、早速、FileMakerホスティングで有名なエミックの松尾さんが、ルータとなるスクリプトを公開された(一部、修正したい箇所があったので、筆者がフォークしたものもある)。FileMaker ServerのREST APIは、httpで接続してもhttpsにリダイレクトされるが、その背後のNode.jsが開いている3000ポートを目指して接続することで、httpでも処理が進められる。ただ、ヘッダをうまく使って同じホストからの接続しかできないような仕掛けがあるため、「直接3000番ポートに接続する」よりも、ルータスクリプトを使う方が楽である。

ルータは、WebアプリケーションとFileMaker Serverの中間に位置しており、WebアプリケーションがFileMaker ServerへのRESTコールを行う代わりに、ルーターに対して呼び出しを行う。ルーターはhttpsを使わずにFileMaker Serverを呼び出し結果を得て、それをWebアプリケーションに返す。動作としては「プロキシ」であるが、名前がrouterなので、ルーターと呼ぶことにする。

ルーターを利用できるようにするには、ダウンロードしたファイルrouter.phpを、以下のようなコマンドで起動する。ファイルがある場所をカレントディレクトリにして、コマンドを入力する。

php -S 127.0.0.1:8090 router.php

ここで、127.0.0.1は自分自身に接続するIPアドレスであり、コロンに続いてサーバーが利用するポート番号を指定する。他のプロセスが使っていない番号を使う必要がある。なお、使用を止めたい場合は、Terminalの画面でcontrol+Cキーを押す。

筆者が作ったAPIを利用するためのクラスFMDataAPIでルーターを利用したい場合、利用方法のサンプルを示したFMDataAPI_Sample.phpであれば、最初の方にあるインスタンス化している部分を記載のように修正する。パラメータを2つ追加して、8090ポートを使うことと、httpプロトコルを使うように設定すれば良い。他は変更が必要ない。もちろん、8090はルーターを起動する時に指定したポート番号を使う。IPアドレスも、基本的に起動時に設定したものを指定する。

修正前:
$fmdb = new FMDataAPI("TestDB", "web", "password", "127.0.0.1");

修正後:
$fmdb = new FMDataAPI("TestDB", "web", "password", "127.0.0.1", 8090, "http");

一方、FMDataAPITrialにあるスクリプトは、まず、lib.phpファイルにある以下の関数の返り値に、ルータ側のポート番号を指定する。

function targetHost()
{
    return "127.0.0.1:8090";
}

そして、Test2.php以降、プログラムの中のhttpsの記述をhttpに切り替える。callAPI関数の最初の引数が全てhttpsになっているので、httpに書き換える。

$host = targetHost();
$result = callAPI(
    "http://{$host}/fmi/rest/api/auth/TestDB",
    null,
    json_encode(array(
        "user" => "web",
        "password" => "password",
        "layout" => "person_layout",
    )),
    "POST");
resultOutput($result);

なお、phpコマンドで、router.phpを起動する時、127.0.0.1ではなく、localhostで指定した場合、上記の修正箇所のIPアドレスは、全てlocalhostで記述する。127.0.0.1では稼働しないので注意する必要がある。phpコマンドで起動する時に127.0.0.1を指定すると、Webアプリケーション側の設定は、127.0.0.1でもlocalhostでもどちらでも良いようだ。FileMaker Serverはかなり以前からIPv6ベースで動いているのだが、localhostとした場合、どこかで127.0.0.1ではないIPv6のアドレスとして識別しているのではないかと想像できるのだが、詳細は分からない。

ちなみに、FMDataAPIを使ったシステムを運用する時、原則としては正しい証明書でhttpsで運用することが原則だ。もちろん、盗聴されないためというのが大きな理由であるが、ホストを偽ってデータを収集されたり嘘の情報を流されることも防ぐ必要がある。httpsでの運用は、Let’s Encryptで無償で利用できるなど、年々手軽になってきているので、面倒がらずに対応すべきだというのが1つの結論である。

では、PHPを稼働させるWebサーバーとFileMaker Serverが同一のホストであれば、盗聴の心配はないのではないかと言うことになる。Firewallでポートを塞げば、それでいいのではないかと言う話もなくはない。ただ、FileMaker Data APIだけにWebサーバーを使うと言うことはあまりないと思われるので、Firewallの設定はちょっと面倒ではないだろうか。絶対に外部からFileMaker Data APIは利用しないで、サーバー内部に限るのであれば、httpでの運用でも問題はないかもしれないが、必ずサーバーの内部からの利用しかしないと言うことを管理者が人手で保証しないといけなくなる。通常、httpsで運用する手順を踏む方が楽なのではないだろうか。

自己署名証明書の問題も同様だ。サーバー内部に限るのなら、詐称のしようもないと考えることができる。これも、「絶対にサーバーの内部からの利用しかしないと言うことを管理者が人手で保証する」と言うモデルであり、むしろ、そういった人的な縛りよりもhttpsでの運用をする方が問題が発生しにく状況であると言えなくないだろうか?

そう言うことで、httpや自己署名証明書での運用は自己責任が大きいので、FileMaker Data APIでアプリケーションを開発したら、本番はhttpsでの運用を目指すようにすべきである。

なお、筆者の作ったFMDataAPIクラスは、デフォルトは証明書の検証をしない状態で稼働するので、そちらは開発中での利用を想定している。実際に正しい証明書が用意できれば、以下のメソッドを呼び出す。そうすれば、証明書の検証を行うようになる。自己署名でないこと、期限、アクセスしているサーバ名と同一なのかが検証される。

$fm->setCertValidating(true);

すなわち、FMDataAPIクラスは、証明書の検証もメソッドでコントロールできるようになっている。

FileMakerデータベースをOAuth認証で利用する

FileMaker 16の大きな機能アップの1つは、OAuth対応だ。GoogleのアカウントでFieMakerデータベースへのログイン認証ができるようになったのである。OAuthの大きな特徴は、1度パスワードを入れれば、その後に認証されたことが異なるサービスに対しても継続されることである。これは「パスワードを覚えていて、その都度送り出す」のではなく、認証した事実を別のサーバーにうまく伝達を行うことで、サービスをまたいだ認証の継続を実現している。パスワードのやりとりは最初のログイン時だけになるので、概してより安全な認証方法と言うべきだろう。FileMakerがOAuthにどのように対応したのかを、データベースログインをGoogleアカウントでログインできるようにするための設定を通じて説明する。

FileMakerデータベースへのログイン

FileMakerデータベースをFileMaker Serverで公開したとする。以下はINTER-MediatorのサンプルデータベースをプライベートネットワークにあるFileMaker Server 16で公開した結果を示す。上記のサンプルで改変した点は本文途中で示す。

公開したデータベースをFileMaker Pro/Advancedで開こうとすると、次のようなダイアログボックスが表示され、そして、アカウント名とパスワードを入力して、「サインイン」ボタンをクリックする。

ここで、FileMaker Server 16で、Googleを認証サーバーとして利用するような設定を行い、加えてデータベース側にそのGoogleのアカウントを追加設定すると、サインインのダイアログボックスがでは以下のように、「Google」のボタンが下部に追加される。このダイアログボックスが表示された時には、「Google」ボタンをクリックするだけでOKである。アカウント名やパスワードのテキストフィールドに、Googleのユーザー名やパスワードを入力することは不要である。

そうすると、デフォルトのブラウザが開き、Googleアカウントのログインの「アカウントの選択」の画面になる。ちなみに筆者が複数のGoogleアカウントでログインをしているのでアカウントの選択になるのだが、アカウントが単独の場合には何も出ないかもしれない。あるいはまだログインをしていないのなら、さらにパスワードの入力や場合によってはアカウントの入力も必要だろう。何れにしても、サインインのダイアログボックスで「Google」ボタンをクリックすると、Webブラウザを利用してGoogleでの認証結果を確認する。その時に、Googleのアカウントでログインしていなければログインをするが、ログインして入ればそのまま処理が継続される。

ログインが成功するか、ログインされて入れば、次の図のようなダイアログボックスが表示される。これは認証が成功したことを示しており、データベースを利用するには「FileMaker Pro Advancedを開く」(もちろん、Proの場合もある)ボタンをクリックする。なお、「開かない」にしたら、何もしないので、ここでは必ず「〜を開く」ボタンをクリックする必要がある。

そうすれば、データベースが開かれる。この時、Get(アカウント名)等の取得関数の結果もデータビューアで示したが、ログインしているGoogleアカウントのアカウント名がそのまま見えている。

以上のように全てがうまく設定された状態だと、ログインパネルで、Googleボタンをクリックすることで、パスワードをその場では入力することなく、自動的にデータベースを開き、データベースではGoogleアカウントで誰が使っているのかを識別できる状態になる。あらかじめGoogleアカウントでログインしていれば、何も追加作業は必要ないか、あるいはアカウントの選択の作業が必要になる。 ログインしていなければ、Webブラウザでログイン作業を行う。

OAuthで利用するためのデータベース

FileMakerのデータベースは、ProないしはAdvancedで管理者でログインをして、「ファイル」メニューの「管理」にある「セキュリティ」を選択する。認証を行なったのちに、アカウントの追加をまずは行う。「アカウントの認証方法」の部分には、「Amazon」「Google」「Microsoft Asure AD」の3つの選択肢が増えている。利用するOAuthサービスを選択した上で、ユーザー名は、そのサービスのユーザー名をそのまま指定する。このように、Googleであれば、Googleのユーザー名を指定したアカウントを作っておかなければならない。もし、作っていない場合は、たとえGoogle側のログインが成功していてもデータベースの利用はできなくなっている。一見すると、他のこの種のサービスのように自由にログインできないのは不便と思われるかもしれないが、登録しないと利用できないようにするのがセキュリティ確保の基本である。誰でもログインできる状態というのは、多くのFileMakerデータベースには望まれていない。

アカウントが実際に利用できるようになるには、「アクセス権セット」を選択する必要がある。ここでは既定の「データ入力のみ」を選択しているが、もちろん、このアクセス権セットに、fmappつまり「FileMakerネットワークによるデータベースアクセス」の拡張アクセス権が設定されている必要がある。これは従来からと同様で、FileMaker Serverで公開するデータベースでは必須の設定である。なお、INTER-Mediatorのサンプルデータベースでは、「データ入力のみ」のアクセス権セットには、fmappはチェックが入っていないので、サンプルをそのまま使う場合には注意していただきたい。

アカウントの一覧には、Googleがタイプの項目が増えており、アカウントの列ではGoogleのユーザー名がそのまま見えている。

FileMaker Serverでの設定

FileMakerのAdmin Consoleで作業をする。ログイン後、左側で「データベースサーバー」を選択し、右側で「セキュリティ」のタブを選択する。そこにあるポップアップメニューで「FileMakerと外部サーバーアカウント」を選択する。すると、Amazon、Google、Microsoftの3つの項目が表示されるので、右側のギアのアイコンをクリックして、作業を進める。ここでは、Googleを例にとって説明する。

Googleのギアアイコンをクリックすると、次のようなパネルが表示される。結果的には、ここでGoogle側で得られた2つのコードを入力することになるが、それは、この後に説明する。簡単なようで難しい問題もあるので、それも併せてこの後に説明する。ともかく、2つのコードが得られたら、「保存」ボタンをクリックする。

ちなみに、Microsoftを選択すると、少し違うダイアログボックスが表示される。これらはサービスごとに得られるデータが少しずつ違うと言うことだ。なお、これら3つ以外のサービスはプラグインとして追加は可能となっているが、基本的にはメジャーなサービスの場合はFileMaker社による機能追加を待つことになるだろう。自社でOAuthサーバーを立てているなら、プラグインの開発をしたくなるところだろうが、こちらはFileMaker社による情報待ちの状態だ。

設定終了後、次のようなメッセージがでかでかと表示される。つまり、FileMaker Serverのサービスを再起動すると言うことだ。もちろん、コンピューター自体を再起動してもいいが、macOS、Windowsでの作業方法が、こちらのページに記載されている。

Googleのコードの取得

Admin Consoleで設定をするには、Google側から与えられるコードを取得しなければならない。そのコードは、Google APIのところで取得を行う。以下の手順で「利用規約の更新」が出てくる場合には、もちろん、そこで対応をして進める。

Googleの場合、Admin Consoleの「データベース」のセキュリティ設定のところで出てきた「Google API Console」をクリックすると、以下のような英語のOAuth 2.0のページが出てくる。実際作業は、このページの本文の2パラグラフ目にある「Google API Console」をクリックして進める。

Google API Consoleをクリックすると、以下のページに移動する。こちらを直接開くには、Google Developer Consoleのページにジャンプすれば良い。なお、このページ内容は、それまでにこの機能を使ったかどうかによって大きく違っている。全く初めて使う場合の作業手順も併せて説明しよう。ポイントは、上部に「Google APIs」というバーが出ている点である。

Google APIsと書かれた右側の部分では、初めて使う場合には「プロジェクトを選択」と表示されるので、それをクリックする。すでに何かで利用してプロジェクトが存在する場合には、とにかくプロジェクト名が見えているのでそれをクリックする。すると、以下のように、プロジェクトの一覧パネルが表示される。パネル右上の「+」をクリックすると、プロジェクトが新たに作成される。ここで、FileMaker Server向けにプロジェクトを1つ作っておく。

プロジェクトの作成時に必要なことは、プロジェクトの名前を設定することである。名前は適当に設定する。なお、プロジェクトIDはこの後は特には使用しない。

プロジェクトを作成すると、そのプロジェクト名がGoogle APIsの右に見えていることを確認して、左側で「認証情報」を選択する。すると、「認証情報を作成」というボタンが見える。ここで、ボタンをクリックして「OAuthクライアントID」という項目を選択する。

なお、ここで以下のようにメッセージが見えているGoogleアカウントでは、必要なコードを生成する権限が与えられていない。例えば、組織で作成されたアカウントではコード生成が許可されていない場合があるので、その場合は個人でアカウントをするなどして、コード発行を行う必要がある。組織のアカウントの場合は、その組織の管理者が、クライアントIDの発行を制限していることが一般的な原因だろう。

 「OAuthクライアントID」を選択した後、同意画面の作成を促す表示が出てくれば、それに従って以下のページで必要な情報を入力する。本来はこの「同意画面」がユーザーに示されて、そしてサービスを利用できるようにするという流れをOAuthでは採用している。しかしながら、FileMakerではこの同意画面を利用していないようで、「ユーザーに表示するサービス名」だけを設定して「保存」ボタンで保存すれば良い。

その後にアプリケーションの種類を選択するページが表示される。ここでは、「ウェブアプリケーション」を選択する。すると、名前などを入力する項目が表示される。ここで、名前は適当に設定するとして、もう1つは「承認済みのリダイレクトURI」を入力しなければならない。このURLは、例えば、FileMaker Serverに接続するためのホスト名が「fmstest.msyk.net」ならば、「https://fmstest.msyk.net/oauth/redirect」を指定する。ホスト名の部分だけがサーバーによって違い、他の部分はどのサーバーでも同様だ。なお、:443はあってもなくても良い。ちなみに、ここにmacOSの共有名(Macintosh.local)や、IPアドレスではうまく動作しない。ドメインを含む利用可能なホスト名をきちんと設定し、そのホスト名でサーバーに接続できる環境になっていなければならない。

「作成」ボタンをクリックすると、生成されたコードがパネルに表示される。こちらからコピーして、Admin Consoleの該当するフィールドにペーストすれば良い。なお、コードは後からでも参照は可能である。

うまくいかない場合の対処

手順は以上の通りだが、FileMakerのドキュメントにも書いてある通り、FileMaker Serverを、きちんとしたドメイン名のURLのホストで公開する必要がある。macOSの共有名の場合、ブラウザからのアクセスが正しくできない場合もある。IPアドレスだけではhttpsでアクセスしているはずはないので、Googleの側で登録が進まない。自分でドメインを持っている方は、何らかのテスト項目を作るなどしてともかくドメイン名を含むホスト名を用意する。

例えば、サインインのダイアログボックスで、Googleボタンをクリックした場合に次のようなページが出たとする。ここで詳細を表示すると、redirect_uriに見えるように、https://MacBookPro.localというホストにアクセスしようとしている。もちろん、この名前は共有名である。ブラウザでは共有名でもOKのはずなのにと思うかもしれないが、単にそのURLにブラウザからアクセスするのではなく、裏ではもっと色々複雑なことを行なっている。筆者の場合には、msyk.netというドメインを所有しているので、fmstest.msyk.netが利用できるようして、検証を行なった。IPアドレスは、実は10.0.1.102というプライベートアドレスだが、自宅環境ではそれで運用可能なので問題はない。

ここで、上記のrequest_uriのURIがどのように自動生成されるのか分からず、対処がなかなかできなかった。実際には、FileMaker Pro/Advancedがrequest_uriを「サーバーへ接続した時に使うホスト名」から生成しているようだ。macOSの場合、自動的にBonjour名が左側に出てきてアクセスをしがちであるが、それだと、上記のrequest_uriには共有名が含まれてしまう。サーバーのドメイン名(つまりFQDN)で接続するサーバーを選択できるように、例えば、お気に入りのホストにドメイン名を登録して、そこからデータベースを選択して開くようにすれば良い。以下の図のように、fmstest.msyk.netでデータベース選択ができるように、お気に入りのホストの登録を行なった。もちろん、自動的に識別される名前がホスト名であれば、それを選択すればOKである。

OAuth対応をどう考えるか

以上のように、Google側の使いこなしが必要になるものの、OAuth対応は確かに便利だろう。アカウントそのものの管理を外部に任せることができるのである。ただし、社員全員がGoogle Appsなどでアカウントを持っていれば便利は便利なのだが、データベース個別にそれぞれのアカウントを登録しなければならない。これは、テキストファイルで読み込みはできないため、自動化のスクリプトなどを使用することになると思われる。ともかく、Googleにアカウントを作ればデータベース側を変更しなくても新しいアカウントから使えるようになる…と言う状況は作れない。機能としては素晴らしいが、運用を考えた時に、手間になる部分も見えてくる。ログインしたアカウントのドメイン名がある名前であれば、自動的に登録されて定義されたアクセス権セットを利用するような仕組みがあることで、管理負荷を軽減できると考えられる。

FileMaker Data APIもOAuth対応している。その意味ではWeb対応しているのだが、WebDirect経由ではOAuth対応はなされていない。これは先のバージョンを待つしかないだろう。

FileMaker Data APIを使えるようにする

FileMaker Server 16に搭載されたFileMaker Data APIについて、実際に利用できるようになるまでの手順を紹介しよう。FileMakerでのWeb開発やFileMaker Data APIの意義については、「FileMaker 16より搭載のFileMaker Data APIとは」を参照していただきたい。

FileMaker ServerのインストールとAdmin Console

FileMaker Data APIの有無に関わらず、FileMaker Serverをインストーラを使って通常通りインストールを行う。展開アシスタントの「Web公開」のところで「FileMaker Data API」のチェックを入れる必要がある。このチェックに相当する機能は、アシスタント利用後でも設定できるが、使用することが分かっているのなら、インストール時にセットするのが手軽だろう。

FileMaker Serverのセットアップ後、「ステータス」のページでは、「FileMaker Data API」の状態を表示する領域が見えており、機能が動作しているかどうや接続数が参照できるようになっている。ここでは詳細な設定はない。

細かい設定は左側で「Web公開」を選択し、上部のタブで「FileMaker Data API」を選択することで表示できる。こちらでは、機能の有効/無効とログについての設定が可能である。

左側で「ログビューア」を選択してログを見るとき、「ログ」ボタンをクリックしてログの選択する箇所で「FileMaker Data API」についてのチェックボックスが表示される。こちらをオンにするとログを参照でき、アクセスするごとに1項目ずつ追加され、日時やURLのパス、クライアントIP、エラーの様子などが記録されていることが確認できる。

FileMaker Data APIに応答するデータベース

データベース自体にも、FileMaker Data APIの利用の可否を指定する部分がある。XML共有やFileMaker Serverへの接続等でも指定した「拡張アクセス権」の設定が必要である。FileMaker 16では、「fmrest」というキーワードのFileMaker Data APIを利用する拡張アクセス権が存在している。データベースを開いて、「ファイル」メニューの「管理」から「セキュリティ」を選択して表示されるダイアログボックスで「拡張アクセス権」のタブをクリックして確認できる。

データベースに設定されたアカウント、あるいは外部のアカウントは、「アクセス権セット」のいずれかの項目に結びつけられる。そのアクセス権セットの設定で、fmrestにチェックが入っている必要がある。このアクセス権セットを選択しているアカウントが、FileMaker Data APIを利用できる。

FileMaker Data APIのマニュアル

FileMaker Serverをインストールしたホストの16001番ポートを開くと、「FileMaker Server 16 開始ページ」が開く。そのページの「Web公開リソース」にある「FileMaker Data API マニュアル」をクリックすると、マニュアルが参照できる。このマニュアルはまだ日本語版は存在していない。日本語のマニュアルは同じ開始ページの「FileMaker 16 Data API ガイド」を辿れば参照できる。

例えば、FileMaker Data API マニュアルにあるREST APIの記述を見てみよう。

REST APIは、簡単に言えば、Webブラウザのアドレスバーに入れるようなURLをサーバーに遅れば結果が返ってくる仕組みだ。ならばSafariやChromeでちょっと試そうかと思うかもしれないが、原則、返って難しい。ちなみに、こうしたREST APIを試す開発ツールとして「PAW」などがすでにあり、APIの利用が成熟していることの現れであるとも言える。

このGet RecordはrecordIdを与えてデータベースの1レコードを得るものである。/fmi/rest…という部分はURLのパスとして与えるものである。その中の「:solution」はデータベース名に置き換えるが、:は含めない。ちなみに、このコロンはNode.jsでのプログラミング経験者にとっては見覚えがある表記だろう。例えば、TestDB.fmp12のpostalcodeレイアウトにあるrecordIdが25のレコードを得るには、FileMaker Serverと同じホスト上でAPIにアクセスするとしたら、

https://localhost/fmi/rest/api/record/TestDB/layout/25

というURLにアクセスする。ここで、パスの上に緑のボックスで「GET」と書いてあり、通常のWebブラウザでのアドレス手入力と同じくGETメソッドでアクセスすれば良いということになる。他にPOSTだけでなく、PUTやDELETEメソッドも使うAPIもある。POSTやPUTではURL以外にリクエストのボディ部にどんなJSONデータを指定するのかが記載されている。

Headerの項目を見て欲しいが、ここの記述は、リクエストのヘッダに、

FM-Data-token: XXXXXXXXXXXXXXX

といった形式のデータを追加しないといけない。従って、WebブラウザでURLを入れれば済むと言う話ではなくなるわけだ。このヘッダの値は、事前に呼び出したLogin APIの結果を入れる。こうした点は詳細には書かれてはいないが、APIドキュメント全体を読むとそうした事実もわかる。

ページの下の方には、どんなデータが返されるのかが記載されているが、「Success-Response:」をクリックすると、ある程度具体的なデータ例が記述されている。「Success 200」はHTTPのステータスコードが200、つまり通信が成功した時のJSONの応答に含まれているデータのキーと値についての説明となっている。なお、ちらっとOptional query parameterに書かれてあることは、解釈は決して簡単ではないが、レイアウトに含まれるポータル内にあるデータを制限する方法が記述されている。具体的には「Example query with portal」のところに書かれている「?porta=」の部分をURLに繋いで指定するのだが、これも1回読んで理解するのはほとんど無理かもしれない。

FileMaker Data APIを実際に使ってみる

ちなみに上記URLはhttpsとしたが、httpとしたらどうなるだろうか? サーバーはhttpsのURLへリダイレクトする応答を返す。つまり、httpでは処理をしないのである。リダイレクトにどう対処するかよりも、httpsと最初から指定すれば良い。

httpsで運用することになると、サーバ証明書の問題が発生する。通常は、既定値で自己署名の証明書がインストールされているが、最近は通信時に自己署名ではエラーになる場合もあり、適切なパラメータを指定しないといけなくなることもある。もちろん、本番の運用は、自己署名ではなく、正しい証明書を利用することが前提である。

/fmi/restの処理をFileMaker ServerのApacheの設定で追ったところ、Node.jsのサーバーにたどり着いた。つまり、デフォルトの3000番ポートが全てのネットワークポートに対して開かれていることから、別途、Node.jsのプログラムを動かす場合には注意が必要になる。FileMaker 16 Data API ガイドによると、8989ポートも開かれているようだが、こちらはlocalhostに対してのみ開かれている。ちなみに、Node.js内でどのようにしてFileMakerデータベースへアクセスしているかと言えば、Javaのプログラムをリモートコールするようなクラスを利用している。つまり、Node.jsの先は公開されていないJavaのAPIを利用している模様だ。この辺りも解析すると何かわかるかもしれないが、ざっと見た範囲では、FileMaker Data APIの範囲を超える仕組みを組み込むことは期待できない感じであった。

これらのAPIを解説してもいいのだが、アプリケーションの利用を考えた時、毎度URLを組み立ててリクエストとレスポンスするのはちょっと効率が悪い。すでに別の記事で紹介したように、PHPで使えるクラス「FMDataAPI」を開発しておりPHPでFileMaker Data APIを使用したいなら、このクラスを使うことが早道である。なお、他の言語でも同様により容易に利用できるライブラリの登場が待望される。引続く記事では、FMDataAPIを使いながら、得られるデータの活用方法などを解説しよう。

FileMaker Server 16より搭載のFileMaker Data APIとは?

FileMaker Data APIは、データベースへの読み書きの処理を、Web APIあるいはREST形式のAPIで利用できるものである。FileMakerデータベースを他のシステムと統合したり、Webアプリケーションのバックエンドとして使う場合には様々なフレームワークや言語と組み合わせ利用しやすい形態がREST APIと言える。FileMakerのREST APIについては、すでにアナウンスされていたとは言うものの、FileMaker Data APIがFileMaker Server 16で初めて製品としてリリースされ、利用できるようになった。本来はFileMaker Cloudに搭載されるものと思われていたが、Ver.16が先になったので、次のCloudのリリースには確実に搭載されるのだろう。REST APIはすでにサードパーティ製品はあるものの、FileMaker本体に搭載されたことは今後の製品を予測する上でも大きな出来事と考える。

FileMakerデータベースのWeb利用

FileMaker Pro/GOをクライアントとして利用するソリューションのバックエンドとして、FileMaker Serverを利用し、データの共有をスムーズにできるようにすると言うのがFileMakerのもっともメジャーな利用形態だ。一方、Webの発展が著しいのは言うまでもないが、FileMaker Serverに蓄積したデータをWebつまりWebブラウザーをクライアントとして利用できるようにするニーズもある。

FileMakerは20年近く前からWeb利用に取り組んでいる。初期のHTML拡張によるCDMLによるデータベース連動ページ作成はVer.4で搭載され、当初はかなり期待されたものの、簡単なソリューションで更新処理が複雑でない程度のものでないとかえって開発が難しく、Ver.7の時点で廃止された。Ver.7からしばらくはXSLTをベースにしたWebページ開発ができたが、こちらもVer.11までの搭載となり廃止された。標準技術をベースにしているとは言うものの、他のWeb開発とあまりに手法が違いすぎた。一方、Ver.5より搭載された初期のXML共有は現在ではCustom Web Publishing(CWP)として若干の機能更新はあるものの、現在のFileMaker Serverまで継続している。その後、PHPのクラスライブラリとして提供されたFileMaker PHP APIやそのバックエンドとしてのXML共有の拡張を経て、これらの機能は現在も利用できる。これに加えて、FileMaker Data APIが登場したのである。データの蓄積や取り出しだけを担うサーバー機能としては以上のような経緯があるものの、FileMaker Server 16では、CWPとFileMaker Data APIと言う過去からの全ての仕組みが搭載されていることになる。CloudではCWPは搭載されず、FileMaker Data APIのみとなっている。

FileMaker Pro/Advancedで作ったレイアウトをそのままWebブラウザーで表示するといった仕組みのWeb対応もなされてきた。Instant Web Publishing(IWP)は若干の改良はされてきたもののVer.12で終了となり、Ver.13以降はWebDirectとして、完成度を高めてきており、Ver.15では動きもスムーズになり、システム開発の1つの手法として実運用可能な状況になっている。ただし、Ver.13でGOからの接続がコネクション数に応じたライセンス体系を取るようになると同時に、WebDirectもライセンスが必要となった。従来のIWPは任意の接続は可能であったが、パフォーマンスの問題で数十程度のクライアントの同時接続までとなっていた。

Webアプリケーションに繋がる手法としては、Ver.15では接続数に応じたライセンスが必要となるWebDirectと、サーバーのパフォーマンス次第で接続ライセンスの不要なCWPの両方が組み込まれている。FileMakerのレイアウトがそのままWebブラウザで見えて利用できるのがメリットかデメリットかは簡単には結論は出せない。ソリューションの設計と運用によるものである。HTMLでWebクライアントを構築したい向きにはCWPが必要になるが、一方でライセンス費用を気にしなくてもいいといったコストに偏った見方をされている場合もある。

ライセンス体系は今後どうなるのか?

FileMakerはVer.13以降、接続クライアントに応じたライセンスということを重視した製品系列へとシフトしてきており、FLTというライセンス体系の追加や、IWPの廃止やGOの接続ライセンス必須化を含めて、CWPのような自由な接続という仕組みを排除してきている。加えて、年間ライセンスへとユーザーをシフトさせようとしている。

そうなると、1つの重要な命題は「CWPがいつまで使えるのか」ということに集約できる。現行のライセンスモデルにマッチしない手法だけに、いつ、機能としてなくなっても不思議ではないのである。しかしながら、それに替わる仕組みがなくなることで、システム構築の自由度がそがれることは明白である。CWPに替わるものが、Ver.16で搭載されたFileMaker Data APIとなるが、「トライアル」ということで、今後の展開を見てライセンス形態を決めようとしている意図が見えてくる。正式にリリースされたことで、まだアナウンスはないもののCWPの継続が中止される可能性はゼロではなく、結果的にどのバージョンまで使えるかという問題に帰着する。そして、FileMaker Data APIに関して、どういったライセンス体系への統合を、どのバージョンで行うかということに注目することになる。Ver.16現在、FileMaker Data APIは自由にアクセスできる状態であるが、FileMakerの製品ライセンス体系を考えれば、「いつかはお金を取る」という姿勢は容易に感じとれるのである。

モダンなデータベース利用が可能なFileMaker Data API

ちなみに、なぜ、CWPがFileMaker Data API置き換わると予想されるのかについてだが、総じてFileMaker Data APIの方がモダンであると言えるからである。サーバーにリクエストを送って結果を得るのは昔からあるXML共有でも現在のFileMaker Data APIでも同じであるが、XML共有はURLに対してXMLで結果が返るのに対して、FileMaker Data APIではHTTPのメソッドを伴うきちんと定義されたAPI動作に対してJSONで結果を返す。データの内容的には、ポータルか、別のTOのフィールドなのかを判別するという点では、XML共有は確実にできなかったこともあった。その後の改良でできるようにもなったが、パフォーマンスが悪くなった。

HTTPのメソッドとURLの組み合わせで動作を記述し、JSONで得られるFileMaker Data APIの方が、様々な用途に展開しやすいことも事実だ。機能的には、レイアウト情報まで取得できるCWPの方が勝るものの、FileMaker Data APIは必要最小限の機能になっており、むしろデータ処理に特化されてシンプルに使えることも、学習しやすい点もあり、実運用に即した進化であると言える。

筆者が現在、開発を進めているWebアプリケションフレームワークのINTER-Mediatorも、もちろん、FileMaker Data APIへの対応を行う予定である。CWPがなくなることを見越しての対応である。そこで基礎部分の足固めとして、PHPで使えるクラス「FMDataAPI」を開発し、こちらは単独でMITライセンスのオープンソースソフトウェアとしてGitHubで公開した。こちらの開発で得られた知見を元に、しばらくはFileMaker Data APIについての情報を本ブログで提供することにする。