Blog by msyk – Page 12 – Talk about computer, network and how we should work.

[IM] FileMaker Server 17とINTER-Mediator

FileMaker 17が発売されました。そして、FileMaker Server 17がリリースされました。ちょっとずつ変わりながら毎年アップデートするFileMakerですが、サーバーは結構変わっています。大きなところでは、管理コンソールがグッと今風なデザインになり、かっこよくなりましたが、その代わり、管理コンソールで設定変更できない項目が出てきました。その辺りがINTER-Mediatorの利用に大きく関連するので、INTER-Mediatorの利用に重点を置いて、変わった部分を説明しましょう。

PHPはインストール直後は未導入

FMS16までは、セットアップ時に選択すればPHPを設定できましたが、FMS17は初期状態ではPHPは使えない状態になっています。もし、PHPを別のサーバーで動かすなら、もうFMSのWebサイトにはPHPは不要ということになりますが、FMSのWeb機能を自分のマシンで動かして検証するなどの作業をしたい方も多いでしょう。その場合、以下のようにコマンドを入れます。$に続く部分が自分で入力するコマンドで、太字にしてあります。fmsadminコマンドで、管理コンソール上では見えなくなったいくつかの機能の設定を行うようになったのです。ユーザー名とパスワードを聞かれれば、FMSの管理者のユーザー名とパスワードを入力します。

$ fmsadmin set cwpconfig enablephp=true
username (msyk):admin
password:
EnablePHP = true
Restart the FileMaker Server background processes to apply the change.

macOSの場合は、「ターミナル」を使います。ログインしているユーザーが管理者の場合には、sudoをしなくても、fmsadminは利用できます。Windows 10の場合、最近まで、スタートメニューの右クリックででてくるメニューで管理者権限でコマンドプロンプトを起動できましたが、いつの間にかこの項目はでなくなっています。スタートメニューの右クリックで「Windows PowerShell(管理者)」を選択して、PowerShellを使いましょう。「コマンドが違うのでは？」と思われるかもしれませんが、上記のfmsadminも、以下のnetコマンドもPowerShellで使えるので安心してください。

このコマンドを入力すると、最後に再起動をするように出てきます。ここで、Webサーバーだけの再起動（HTTPServerフォルダにあるstop、startというファイルをsudo touchで更新）でやってもPHPは稼働しません。それから、CWP（Custom Web Publishing）の再起動も同様です。以下のコマンドで機能の再起動を行います（松尾さん、ありがとうございます）。もちろん、FileMaker Serverの管理者のユーザー名とパスワードを入力する必要があります。

fmsadmin restart httpserver -y

~~以下のように、FMS全体の停止と起動を行う必要があります。macOSの場合は次のように2つのコマンドを入れます。~~

sudo launchctl stop com.filemaker.fms
sudo launchctl start com.filemaker.fms

Windowsの場合は、以下の2つのコマンドを入力します。なお、Windows 10の場合は、他に考慮点が色々あるので、この記事の最後の方にそれを記載をします。

net stop "FileMaker Server"
net start "FileMaker Server"

これで、phpinfo()関数を動かすと、次のように、Ver.5.6.24が稼働していることがわかります。なお、info.phpファイルの中身は、phpinfo()関数だけでなく、タイムゾーン指定を入れないと警告が出て情報は表示されません。例えば、info.phpファイルは次のように作ります。

<?php date_default_timezone_set("Japan"); phpinfo(); ?>

PHP自身は古いビルドのままですし、Ver.7.2が主要リリースな今時にVer.5.6なので、アップデートする気はないというところが感じられます。

つまり、FMS17をインストールすると、PHPの実行環境はインストールされているものの、利用できる状態になっていなかったということです。ちなみに、macOSの場合は、Apache2の主要設定ファイルである/Library/FileMaker Server/HTTPServer/conf/httpd.confの最後に、

Include '/Library/FileMaker Server/Web Publishing/publishing-engine/php/sierra/httpd.fmi.conf.php'

という行が加わり、モジュールが読み込まれます。Windowsでも、FileMaker ServerフォルダはC:¥Program Files¥FileMakerにありますが、そこからのパスはほぼ同じような場所にPHPの実行環境が用意されていますが、IISにサイトを追加してWebサーバーとして稼働するようにしています。phpinfo()関数でphp.iniファイルを確認して、必要であれば設定を変更しましょう。

db-class=”FileMaker_FX”を指定する場合

FX.phpを使ってFileMaker Serverへ接続する場合を説明しましょう。INTER-Mediator 5.7/6現在、現実にはFX.phpの一部分だけを使っていますが、何れにしても、以前からあったXML共有を利用してデータベースアクセスしています。

XML共有を利用するには、まず、Web公開エンジンをオンにします。管理コンソールで、コネクタのページを開き、左側のリストで「Web公開」を選択し、右側の「Web公開エンジン」にあるボタン（右のほうにある左右に動くスイッチ）が全体的に青くなるようにしてオンにします。しかし、これだけではありません。

XML共有をオンにするには、さらに、以下のような$以降のコマンドを入力します。もちろん、FMSの管理者アカウントで認証が必要です。このコマンドに関しては、再起動は不要です。

$ fmsadmin set cwpconfig enablexml=true
username (msyk):admin
password:
EnableXML = true

このように、「Web公開エンジン」のオン、そしてXML共有をオンにすることの両方が必要になります。

db-class=”FileMaker_DataAPI”を指定する場合

FMS16でプレビュー扱いだったFileMaker Data APIも、FMS17では正式機能となり、ライセンス価格も「ダウンロードデータ量」に関連することに決まりました。ユーザー数で考えれば幅が広くなるWebサイトの事情を考慮したという点では評価できると考えます。1年間のライセンスの場合、24GX人数までが購入価格に含まれた分量ですが、ともかく、データ転送量を見積もらないと、かかるコストが分からないという状況になりました。

FileMaker Data APIの正式版は、ある意味で「バージョン1」と呼ぶのが適切でしょう。API呼び出しのURLがプレビュー版と大きく違っており、URLに「v1」という文字があることからも、API自体にバージョン管理を今後は行うということを示唆しているものと思われます。

FileMaker Data APIに応答するようにするには、管理コンソールで、コネクタのページを開き、左側のリストで「Web Data API」を選択し、右側の「Web Data API」にあるボタン（右のほうにある左右に動くスイッチ）が全体的に青くなるようにしてオンにします。これだけでよく、コマンドの入力は不要です。

なお、INTER-Mediatorは、FMDataAPIというライブラリを利用して、FileMaker Data APIを利用しています。FMDataAPIはVer.8で、プレビュー版からバージョン1へと対応APIを変更しました。FMS17リリース直後からVer.8は公開していますが、INTER-Mediatorで利用できるようになるためには、INTER-MediatorにあるFMDataAPIをアップデートしないといけません。アップデートするのは簡単ですが、FMS16のFileMaker Data APIは使えなくなります。もっとも、プレビュー版のAPIで真剣に構築していることはないだろうという見込みもあるので、単にどどーんとアップデートしてもいいのですが、その辺り、現在は検討中というところです。アップデート情報はFacebook等で公開します。

Windows 10でFileMaker Server 17

FileMaker Serverは、以前からWindows Serverが対応OSとなっており、Windows 10は対応OSではありません。また、FMS14に関するFileMaker社の文書では、「互換性はありません」となっています。ところが、Windows 10 Pro に FileMaker Server をインストールするによると、FileMaker Server 14/15のインストールができるようにする方法が書かれています。開発者としては手元のWindowsでFMSが動いて入れば便利だと思うところでもあるので、FileMaker Server 17がWindows 10で稼働するかどうかを試してみました。前述の記事のようにインストーラが動かないということはなく、インストーラは問題なく動き、インストールは可能です。ただし、インストーラが動くとは言え、様々なエラーメッセージをうまく捌かないといけない模様であり、「簡単ではないかもしれない」と言ったところです。そこで、PHPを動かすところまでを実現するためにどうすればいいかを確認しました。なお、FileMaker社は稼働するという保証をしていないので、Windows 10でのFMS利用はご自分のリスクで進めてください。

実際に確認したのは、Windows 10 Proに、バージョン1803のアップデートを当てたPCです。IISが稼働していない状態でインストールをすると、途中で次のようなメッセージが出てきて、インストールは途中で終わってしまいます。

そこで、IISをあらかじめ起動しておきます。スタートメニューを表示した時に左端に見えるギアのアイコンの「設定」を選択して、設定ウインドウを表示します。そして、「アプリ」を選択します。そして、右端にある「プログラムと機能」を選択し、懐かしいコントールパネルの「プログラムのアンインストールまたは変更」を表示し、左側にある「Windowsの機能の有効化または無効化」を選択して「Windowsの機能」ウインドウを表示します。ここで「インターネットインフォメーションサービス」のチェックを入れます。黒い四角になるのは下位の項目が全部チェックされているわけではないということを意味しています。ここで、World Wide Webサービス＞アプリケーション開発機能と階層を下り、「CGI」のチェックを入れておきます。このチェックを入れておくのがポイントです。他はそのままでいいのですが、必要に応じて他の機能を入れてもいいでしょう。OKをクリックします。もし、再起動を求められたら再起動をしてください。

この準備をした上で、FileMaker Server 17のセットアップを行えば、概ね問題なく稼働するもようです。インストール途中で以下のようなダイアログボックスが出てくれば、「Webサイトを無効にする」をクリックしてください。これはIISのデフォルトのサイトをオフにして、FileMakerでセットアップされるサイトだけを利用するためです。

こうしてセットアップが終われば、最初に説明したようにコマンドを入れればPHPが利用できるようになります。ただし、INTER-Mediatorを稼働させるという観点では、初期状態のPHPのモジュール読み込みは十分ではないので、php.ini等の設定を変更する必要があります。これについては、近日中にまとめたいと思います。

IISの設定を見るには、スタートメニューを右クリックして「コンピュータの管理」を選択します。「サービスとアプリケーション」の下位項目に、IISがあります。Default Web Siteは停止状態になり、FileMaker Serverのセットアップにより、FMWebSiteという設定が増えていることがわかります。

ここで、PHPを稼働させる設定は、「ハンドラマッピング」の中にあります。その項目の詳細設定ダイアログボックスは次のようになっています。パスは、C:¥Program Files¥FileMaker¥FileMaker Server¥Web Publishing¥publishing-engine¥php¥php-cgi.exeが指定されています。

ちなみに、WindowsでのPHPの稼働方法をチェックすることも含めて、fmsadmin set cwpconfig enablephp=trueを使わないで、IIS上でPHPを稼働できるかを試してみたのですが、その時には、以下の2つのパスのフォルダに、IIS_IUSRSグループに読み取りと実行の権限を与える必要がありました。要するにWeb公開するフォルダと、PHPの実行モジュールへのアクセス権を設定する必要があるということでしょう。

C:¥Program Files¥FileMaker¥FileMaker Server¥HTTPServer¥conf
C:¥Program Files¥FileMaker¥FileMaker Server¥Web Publishing¥publishing-engine¥php

他に、アプリケーションプールの詳細設定で、32ビットアプリケーションの有効化をtrueにしてやっと動いたということもあるのですが、FileMaker Serverに自動設定させた結果では、アプリケーションプールの設定はfalse（既定値）のままでした。

以上のように、Windows 10でもFileMaker Server 17は使えたのですが、なんども書きますが、対応OSではない点を理解した上で対処をしてください。

INTER-Mediatorのレコード数制限の実装

INTER-Mediatorのことをブログで書くのが久しぶりな気がしているが、以前のように、設計書代わりにブログを書いておく。INTER-Mediatorのコードにタッチしていない方はなんのことか分からないと思うので、最初にその点を指摘しておく。

INTER-Mediatorでは、ページネーションコントロールを自動的に生成して、例えば30レコードずつ表示するような仕組みを設定だけで実現している。しかしながら、その後に、ポップアップメニューからレコード数制限をできるようにしたり、Master/Detail形式のUIを実現したりと、１度に表示するレコード数に絡む機能を追加してきた。3年ほど前に、かなり混乱した感じになったのでリファクタリングをしたが、バグレポートをもらい、相変わらず怪しい部分があることに気づいた。ここで、根本的に直したいと思うのだが、今までの方法で欠けていたのは「ルールの明確化」だった。そこで、ルールを作って実装というか、リファクタリングをしたいと考える。

まず、現状（5.7+α）で、どんな要素が関連しているのかをまとめて見たい。レコード数に影響するUI要素は次のものである。

ページネーション
ポップアップメニュー（data-im=”_@limitnumber:コンテキスト名” の属性があるSELECT）
Master/DetailのDetail側（navi-control=”detail”、詳細側なので常に1レコードにしたい）

コンテキスト定義のキーで、関連するものは次のとおりである。

records
maxrecords
paging
relation
navi-control

さらに、関連するプロパティを挙げると次のとおりである。プロパティと言いつつ、オブジェクトは1つなので、事実上のグローバル変数である。なお、以下のプロパティの3, 4, 5は、getter/setter実装している。ローカルストレージ等を利用してページ移動してもパラメータの記憶をしたいためだ。

INTERMediator.pagedAllCount
INTERMediator.totalRecordCount
INTERMediator.startFrom
INTERMediator.pagedSize
INTERMediator.pagination

これれらの仕組みをどのように解釈するかという問題である。

まず、INTERMediatorオブジェクトのプロパティについては、paging=trueのコンテキストに対してページネーションを動作させるためのものであるので、ここでは「ページングを特定のコンテキストに対して実施する」という決定がなされた後のものである。したがって、UIとコンテキスト定義の内容について、どのように解釈をすべきなのかを、まずは決めなければならない。ここを曖昧にしていたのが、バグが常に治らない原因と考える。しかし、基準も何もない。よって、「UIが自然かどうか」という観点で推測しながら決め事をしなければならない。

前提条件1：
ページネーション処理は単一のコンテキストのみ

この点は、異論はあるかもしれないが、複数のコンテキストにページングを配置すると、画面に複数のページネーションコントロールが登場して、混乱をしかねないUIとなる。適切なUI設計では複数のページネーションは不要と考える。これを前提とする。また、1コンテキストに複数のページネーションコントロールを用意するということも同様にやらないことを前提とする。

前提条件2：
Master/Detail形式のUIでは、ページネーションはMaster側にだけ適用される

MasterにもDetailにもページネーションが欲しいという声が聞こえてきそうであるが、それぞれを同時に表示することも仕組みとしては持っているため、ページネーションはMasterだけに適用させたい。Detail側にレコード移動の機能を組み込めないようにしたいのである。なお、どうしてもそうしたいと思う場合には、Master/Detailの機能を使わないで、Detailと同一内容のページファイルを用意して、普通にページネーションを利用できる。適切な対応策があるので、この前提条件はデグレードには当たらないと考える。

優先順位1：
そのコンテキストで取り出されるレコード総数はmaxrecordsを上回ることは絶対にない

この仕様の優先順位が高いとしたら、サーバー側での検証とレコード数の修正は必要であるし、通信直前に処理するなど、UIから遠いところで処理をしないといけない。

優先順位2：
navi-control=detailのコンテキスト場合、レコード数は常に1以下とする

ある時点でこの設定を入れた。優先順位を高めにして、他の設定より優先される方が、矛盾するコンテキスト設定してもうまく動く模様であるが、一方、間違いに気づきにくいということにもなる。

優先順位3：
ポップアップメニューがあればそれに従う

ポップアップメニューは、ローカルコンテキストに記録するのであるが、ローカルコンテキストのバインド処理は、ページ合成処理の最後の方にやっている。少なくとも、limitnumber:＊の値の処理を、ページ合成前にもしなければならないし、本当に初めてページを開くときはローカルコンテキストがセッションに残されていないので、ノードを探る処理も結果的に入れておく必要がある。ここの改造は、コードの追加を伴う。

優先順位4：
recordsキーの値に従う

これは順当なルール。なお、relationがあるとレコード数の制限はなくすということを一瞬考えたが、関係レコードの上位3件だけ表示したいということもあると思う。結果的にrelationキーは考慮しなくてもいいのではないかと思う。

これらのルールで得られた「レコード数」を元にしてレコードを取得する。ページネーションを利用するコンテキストなら、ページネーションとの連動が必要になる。このページネーションとの連動部分が、コードとしてはうまく分離されていないのが現状である。上記のルールで決まれば、それに応じてページネーションを設定するという風に、レコード数とページネーションの処理順序を決めて、依存関係をシンプルにするようにリファクタリングを進める必要があると考えられる。すなわち、

方針：
レコード数決定プロセスとページネーション処理を分離し、レコード数の決定を先に行って結果を必要ならページネーション処理に渡す

ということになる。この方針で行ってみようと思う。

「Excelみたいに作ってくれ」という案件が失敗する理由

Excelは悪いソフトではないし、昔から使い込んできただけに、それなりに愛着がある。また、書籍もたくさん書かせてもらって一時はそれで食わせてもらっていたので感謝もしている。しかしながら、Excelの利用技術が結果的におかしな方向に行くのを目の当たりに見てきた。「ネ申エクセル問題」はその集約として非常に良いポイントを突いている。良し悪しを決めつけるのは簡単だが、問題はなぜそのようになり、なぜ是正できないかという分析だろう。「ネ申エクセル問題」としてまとめられた結果、ある領域についての理由と方向性がはっきりしたと言える。

業務システムの開発を請け負っていると、時々、「Excelみたいに作ってくれ」と言われる案件がある。要件がはっきりしていいのじゃないかと思うかもしれないが、これが大きな落とし穴になることもある。なるべく、そのような案件は断るようにしているが、作ってからメンテが大変だったりして、よくよく聞くと、Excelみたいに作ってもらいたかったと思っていたと言うこともあって、顕在化しない場合もある。

ある案件では、これまで、何十人レベルの人たちから毎月Excelのワークシートを提出していたものをWebアプリケーションにして欲しいと言われた。ちょっと複雑な経費精算である。Excelのテンプレートは、おそらく受け入れ側の都合を反映したもので、あまり分かりやすいとは言えないものと感じた。フィールドを全部埋めるのではなく、場合によっては埋まらないフィールドも多く、分類の違うフィールドがずらりと並び、状況によって入力したりしなかったりと言うことを入力者が決めるタイプだ。要するに、第一正規形を満たしていない。

それをそのままWebで作るとしたら、テキストフィールドがずらずら並ぶ。当然ながら、横幅は結構なものになる。状況に応じて必要なフィールドだけを出すようにすれば、スマホでも使えると考え、散々説得したが、「Excelみたいに作ってくれ」というところに常に落ち着く。仕方ないので、「Excelのように見えるだけで動作は違うけどいいでしょうか」と言って、それは納得してもらったはずなのである。

実際にExcelのように作ると言った時、その見かけを2次元セル的にやることと普通は思うかもしれないが、フタを開けると、「Excelのように」が指すポイントが人により異なることが判明した。つまり、これだけの文言では、要求定義にも、要件定義にもなっていない。単なる曖昧な表明にしかなっていないのである。

Webアプリでデータベースだから、レコードを作って入力すると言うのは、あまりに当たり前過ぎることなので、普通に実装したら、「画面を開いたら、最初からワークシートみたいになっているようにして欲しい」と来た。もちろん、そう言うライブラリもあるだろうし、レコードを複数作っておけば済むのだろうけど、ここで受け入れたら、本当にExcelそのものを作らされるのだろうと思って、それはできないと突っぱねた。最初からExcelと同一のものは作れないと言うことは明言し、データベースを利用して作ることも決まっていて、開発費用も決めたので、こちらの裁量がある。こちらとしても、要望が後から来たものは「費用の範囲に収まらない」と言う理由で断れる。そう言うわけで、当然ながら、「レコード追加ボタン」で対応した。

そこで引き下がっていたら、ドラッグしたらコピーするようにとか、式を入れられるようにみたいに要求が留まらないのではと危惧し、前記のような対応を取った。一応、システムは作成でき、想定外のことがあったもののメンテナンス開発でクリアし、今も使用しているようだ。しかしながら、「Excelみたいに〜は要件でもなければ要求でもない」というアンチパターンを実感したと言う意味で、悲喜交々な案件だった。それに、ワークシート的な見え方だと、多分、利用者は保存して添付する手間がないだけで、入力の手間はほとんど変わっていない。保存はないけど、ログインは必要になるので、面倒になったと思う人もいると思う。これは、つまりは今までワークシートを受け取っていた人だけが、集計が楽になるだけという非常に悪い設計の典型のようなシステムでもある。

「ネ申エクセル問題」での大きな教訓は、便利なソフトも使い方によって足かせになると言うことだ。よく、「紙での作業をそのままシステム化しても、効率が上がるわけではない」と言うことも言われる。まさに、ペーパーをExcelに置き換えても同じことが言えるし、それはExcelだけはないだろう。例えば、「LINEみたいなチャット機能もよろしく」みたいな要求は今だといろんな案件で出て来そうだ。しかし、そこで、思考を止めてはいけない。曖昧すぎて、本当に実現したいことが何なのかは、実はそれだけではコミュニケーションできないのである。馴染みのシステムを引き合いに出すのは、要求定義においてはきっかけに過ぎないことを常に意識すべきだろう。

開発の現場では「手法よりも問題解決」が現実

開発の現場で、「手法」を議論する機会が減ってきているように思う。もちろん、自分の身の回りのことが全てではないので、偶然かもしれないが、ブログ等での話題でも、あまり見られなくなっている気がする。以前だと、例えばMVCがどうとか言った話題が華やかだった記憶がある。そして、古くからのさまざまな手法のどれがいいのかと言った話題や、特定の手法をどのように理解すればいいのかといったことが議論された。サイエンス的に考えれば、原理原則があり、それに則った手法は、成功する確率が高くなるということから、以前は手法やアーキテクチャ中心的な考え方もあっただろうし、もちろん、今もそれはなくなってはいない。

現実はどうだろうか？色々な手法や原理原則は、１人１人がしっかり学習して現場適用するということも必要なことかもしれないが、「良い手法」はそのものが、すっかりパッケージ化されている。ソフトウェア開発で言えば、フレームワークやライブラリ、あるいは開発ツールで、そうした過去の蓄積が完全にパッケージされており、手法を深く理解しなくても開発を進める上ではあまり問題はない。ともかく、ある「やり方」を採用すれば、難しい原理原則はもちろん、手法の適用までができてしまうのである。Webのサーバーサイドフレームワークは典型的な例だろう。ほとんどのフレームワークはMVC（正確にはJavaEEでのMVC2パターン）であり、よほど変なことしない限りはMVCに基づく役割分担が自然に作り込まれるし、レイヤー化についても気がついたらそうなっているのが一般的だ。もちろん、実装の良し悪しはあるとしても、現場で働く側としては「○○フレームワークでよろしく」の一言で済んでしまう。

そうなると、現場でもっとも注目されるのは何だろうか？システム開発の現場と、サービスアプリケーションでは色々違うとしても、結果的に、「問題点は何か」ということに注目することが常に行われているのではないだろうか。開発の枠組みは使用フレームワークをはじめとして、結果的に決まってしまうことが多い。要求工学では手段は後から決めるというのが基本ではあるが、現実にはそうでもない。そして、そこではどんな手法を採用するかも概ね決まっている。スタッフが持つ経験をベースに、進行の可能性を検討し、誰かが問題なく進められる部分は、特にフォーカスされない結果となる。一方、誰も作ったことがない仕組み、誰も経験したことがフレームワーク、ある領域で実現できそうにない非機能要求など、「できるかどうか分からない」所に開発タスクとしては目を向けることになる。

では、できないことを、原理原則からボトムアップして、手法を求めるかと言うと、そう言う側面が問題解決に集中しているときはあるかもしれないが、その結果、あるライブラリを使うことで十分に解決されるなら、「ライブラリを使います」と言うことで集約され、問題がさらに絞られる。「チーム全員で手法をまずは勉強します」という結果はかなりハードルが高い。結果的に、問題から始めて、パッケージ化された解決手段で概ね解決し、さらに違う問題にたどり着き、それを繰り返す。問題がほぼなくなれば、一定時間後に完成に進めるということだ。

問題点の解決が現場での主要な話題になり、系統的な手法が議論される素地はほぼない。もちろん、結局のところアジャイルということなのかもしれないが、小さなプロセスでも、大きなプロセスでも同様に言えることではないだろうか。良い悪いはあるとしても、そのように進んでいる。その中で、基本や原理を叫んでも、誰も耳を傾けない。問題を解決する糸口は、まさに原理原則に立ち返ることで手にできるとも言えるのだが、「良い素材はないだろうか」が糸口になってしまうのである。

普段は小規模な開発に関わる機会が多いので、仕様書が渡されないような発注は普通にある。もちろん、大きな会社の発注では仕様書があるものの、非常に高い割合で「仕様書書いている」と言う証拠のためだけの紙の塊でしかないようなことも感じる。設計に役に立たないわけではないが、中身が実装作業に遠いのである。わかり切ったことは簡単に書き、問題点を記述して共有すれば、仕様書はより役に立つのではないだろうか？サイエンスなので、原理原則があって、それを踏まえた手法があるのは間違い無いのだが、いっそうのこと現実に合わせて「問題解決」にフォーカスした手法に目を向けるべきだと考える。とはいえ、そう言う「手法」を作っても意味はない。手法を否定する手法というのは存在に無理がある。その意味では、アジャイル宣言のように、どんなマインドで対峙すべきなのかをうまく表現しないといけないだろう。ということで、表題のように「手法よりも問題解決」と言ってみた次第だ。今やそういうやり方が一般的というスタンスで、メリットと注意点を検討すべきではないだろうか。

自動運転の実用化に違う方向性はないのだろうか？

次世代の自動運転技術に注目が集まっている。機械学習さらには人工知能の研究を強く牽引する期待が大きく、現実になればより安全な社会が実現するかもしれない。自動車業界は競争状態に入った自動運転技術を捨てるわけには行かないのかもしれないが、色々な業界がこぞって自動運転に目を向けている。一方で、新技術を危険視する向きもあり、自動運転で事故、あるいは死亡事故が発生すると、否定論が強まるなど、世論の関心も強く集めている。

技術そのものについて、「できない」と言ってしまうと、全く前に進めない。ところが「できる」とも言い切れないというのは、そこで「競争に負けた」と思われてしまうということもある。そして技術競争は熾烈になり、「あと何年で実用化」みたいな話はまことしやかに語られる。人工知能の世界でも、シンギュラリティという概念が既知のものであるのと同様、自動運転は近々実用化することになっているのが現在である。一方で、安全をどう確保するのかも大きな問題となっている。

自動運転の死亡事故をきっかけに一瞬、そうした議論が盛り上がったが、今回のアクシデントは偶発的なものと思いたい人たちと、ともかく「怖い」という漠然とした感覚から逃れられない人たちが大勢あることは改めて確認できたと思われる。事故が教訓になっていない漢字はちょっと怖いことでもある。どうすればいいという議論が進まないという点でもある意味怖い。この事故をきっかけに、何か安全性を高める方法はないだろうかと考えた。

自動運転の議論であまり出てこないと思うのが「社会インフラと連動した安全性の確保」だと以前より感じていた。現在、自動車をはじめとして色々な乗り物や人間が公道を安全に移動することができるには「信号」と言ったインフラがあるからだと考えられる。正確には、交通法規が根底にあるのだが、ともかく信号があるから安全でかつ、交通がスムーズに流れることは疑いの余地がない。自動運転にも、こうした社会インフラと連動したことができないだろうかと考えた結果、１つのアイデアが浮かんだ。それは、「舗装道路をスマート化」するということだ。

道路の舗装には、小石を含んだ砂利を利用していると思われるが、小石程度の大きさのIoTデバイスを開発し、一定の密度で舗装道路に含める。もちろん、様々なセンサーを持ち、結果は通行中のデバイスに送られる。熱に強いとか、すごく小さいとか、この『スマート砂利』には技術的な難しさは色々あるだろうが、自動運転よりはるかに容易だと想像できる。こうしたスマート砂利による舗装道路では、進路上に人間が歩いているなどのセンシングを、自動車の前の画像やセンサー等で見つける以上に正確にできることが期待できる。角を曲がった先の道路の状況が分かるかもしれない。

スマート砂利の道路は自動運転でより安全に走れるとしたら、自治体は極力スマート砂利を使った道路工事に切り替えるだろう。なんだか建築・土木系の利権を復活させるような雰囲気はちょっとげんなりするけども、自動運転について、自動車以外のことに目を向けてもいいのではないかとも思う。

JavaScriptの通信がPendingとなった理由は通信の問題ではなかった

JavaScriptとPHPで構築しているINTER-Mediatorで、分かりにくいバグに遭遇してしまったので、記録の意味も含めてここに書いておく。そもそも発端は、Ver.5.6-RC2を入れて動かしていたアプリケーションで、そろそろVer.5.7もリリース近いので、入れ替えるかと思って入れ替えたのが直接の原因なのだが、その瞬間にバグが顕在化したのならまだしも、ある程度時間が経過してから顕在化したので、根本的な原因を突き止めるのに非常に労力が消費されてしまった。

不具合が発生したのは、勤務先の業務システムで、スタッフ向けのページはかなり重たい動作のものある。全てのページで問題が出ないで、一部の「重たいと思われる」ページでのみで不具合が顕在化した。ここで、まず判断を狂わせることになる。システムは、サクラVPSで運用している。ここ数ヶ月、徐々にレスポンスが悪くなっている感じもあったので、プロバイダやネットワークをまずは疑ってしまった。不具合による結果は、ページを表示しようにもページ自体がフリーズしてしまうのである。ログインパネルはちゃんと出るが、正しいユーザ名とパスワードを入れると、フリーズする。これに気づいたのは2018年2月の上旬だ。

当然ながら、まずやることはデバッガでの確認だ。すると、以下のように、Statusが(Pending)となている。サーバーのログを追ったところ、Apache2はステータス200でデータを全部出し切っている。クライアント側で通信に入ったものの、一切のデータ受信ができない結果になっている。色々観察した結果、ページごとにPendingになるタイミングやこのページでの行番号は違うのもの、同一ページでは常に同じタイミングで発生した。ちなみに、Chromeだとこれが発生すると高い確率でそのタブを閉じることができず、他のタブは利用できる状態であるにも関わらず、Chromeの強制終了が必要になる。

今まで動いていたという気持ちがあると、当然ながら、アプリケーション側に問題はないとまずは考えてしまう。これも、後から考えれば間違いなのだが、エンジニアの皆さんはとりあえず人のせいにしてしまう気持ちはよく分かると思う。折しも、色々探すと、サクラのサポート情報で、「さくらのVPSで回線速度が遅くアクセスに時間がかかります。」というのがあった。ページのフリーズと、遅くなるのは違うのではあるが、こういう時には楽観的に物事を見てしまう。なんだ、原因分かっているんだと思いつつ、「さくらのVPSにおいて、不特定のVPS収容ホストとクライアント環境(プロバイダ等)の組み合わせにより、さくらのVPSからのダウンロード方向の通信に遅延が発生する場合があります。」という記述をみて、ネットワークの問題があるということに意識がかなり振られてしまった。

当然ながら、ここにある対処をしたのだが、結果は同じだった。むしろ、どのページも遅くなったので、仮にうまくいっても恒常的な対処にはならない。しかしながら、「ネットワークに問題がある」というところで判断がスタックしてしまった。もし、ネットワークに問題があるとしたら、プロバイダを変えるか、職場のネットワーク内にサーバーを立てるしかない。GMOクラウドのVPSは無料で試せるので、ともかく移動して動かして見た。結果は同じだ。同じページで、同じようにフリーズする。GMOではネットワークの問題は解決しないとしたら、一度、自宅のサーバーにセットアップして、自宅内でアクセスするとどうなるかをチェックして見た。なんと、同じようにフリーズする。また、別の軽いページを改良している時にも、フリーズが発生した。つまり、「ネットワーク」「重いページ」はどうも原因ではないという結論になった。

しかし、なんでPendingになるのか？色々検索すると、Ajaxがデッドロックしたみたいな書き込みがあった。しかし、それへの回答でも、JavaScriptはユーザープログラムは絶対に並列的に動作しないで、処理を1つずつしかしないのだから、他の言語等で発生する問題が同じように発生する可能性は低いと書かれている。もっともだ。しかも、INTER-Mediatorのこのバージョンは、Ajaxを非同期では利用せず、同期通信しているため、フレームワーク内で複数の通信が発生することはない。なお、次のバージョンでは完全に非同期通信を行うようになる。

前述のChromeのデバッガを見ると、CSSの通信がPendingになっている唯一、並列的に通信が発生するとしたら、CSSのサーバーからの取得と、INTER-Mediatorのデータベースアクセスの通信が並列にはなりうる。ちなみに、CSS自体もサーバーで生成しているので、URLは.phpになっている。そこで、フレームワークをいじってCSSアクセスのlinkタグを突っ込まないようにして見た。それでも同じところでフリーズする。やはりこれも原因ではない。

ここで、根本的な原因が全くわからない状態になった。ネットワークでも通信でもないということで、フレームワークに問題があることはほぼ明白になった。そして、2017年9月のVer.5.6.1に戻して見たところ、問題なく動いた。これで、INTER-Mediator側に問題があることが確実となった。INTER-MediatorはGitHubのレポジトリにコードが残っている。そこで、どのコミットでバグが発生したかを突き止めることにした。大雑把に2分割をしながら、2018年1月のあるコミットであるところまで突き止めた。コードを見ても、明らかに通信ではない。通信に問題があるが、原因は通信でないということはさらに明白になった。

しかし、見当がつかない状態と、ここまで絞りきれても原因の特定まではできない。このコミットでファイルは4つ変更されているが、1つはメタデータで処理には関係ないので、そのうちの3つのどれかである。そこで、ファイルを1つずつ、前のコミットに戻すことで、INTER-Mediator-Calc.jsに問題があることが分かった。diffの結果はあれこれあるが、setUndefinedToAllValuesにメソッドしか変更していないので、問題はここにある。何れにしても、計算式の処理部分に問題があることが分かったのである。

ここで腹を括って、地道にステップ動作をさせて見たところ、ついに問題の根本が分かった。325〜335行のdoループが、ある条件の場合だけ、無限ループしている。つまり、ここのループ処理にバグがあったのだが、ポップアップメニューのタグ要素に計算式の結果を適用する場合だけ、無限ループし、その他のタグ要素の場合には無限ループにならず、間違えたコードだが正しい結果が得られているという状況になっていたのである。直したところ、えらく時間がかかるようになったので、処理を効率化して高速化する必要もあったものの、ともかく修正ができて、Pendingは出なくなった。原因追及から修正完了まで、1日かかってしまった。

結論は明らかだ。ページがフリーズしたら無限ループを疑えということになる。だが、なんで、こんな処理が入っているのかという点もあって、モデルをさらに改良してここで問題になったコードは取り除く予定ではあるものの、「動いている」つもりになっていたので、後回しになってしまっているのである。テストでクリアできないかということもあると思うが、ページ展開していないとテストのしようがない部分であり、単体テストではカバーできていなかった。現在、Seleniumベースでの統合テストを組み込んでいるところであり、そこで、計算式のテストページに、ポップアップメニューに計算式を仕込んだものも作っておいた。やはり、見つけにくいバグは、テストから漏れている箇所に存在するということだ。

なんとも当たり前なことの確認に、ひどく時間がかかってしまったのではあるが、自戒の意味も含めてブログに記録する。

2018年頭の近況報告

気がついたら全然記事を書いていませんでした。最後に書いたのは昨年の5月、ちょうどFileMaker 16がリリースされたのですが、新機能であるREAST APIのためのクラスを作るなど、そこそこコミットしたので、いくつか記事はありましたが、すっかりご無沙汰になりました。仕事を一生懸命していたのと、INTER-Mediatorの開発をがっつりやっていたのが理由です。

開発プロセスの話も、2017年2月で以降に記載がありません。かなり詳細化したのですが、詳細化し過ぎかもしれません。INTER-Mediatorでアプリケーションを作る話に持ち込みたかったのですが、むしろフレームワークを作る上での分析の方向に行ってしまった感があります。とは言え、報告はしませんでいたが、色々な角度での検討は断続的に続けていました。古い書籍ですが Object Modeling and User Interface Design あたりで、オブジェクト指向的にユーザーインタフェースを設計する方法があり、モデリングの方法として参考になるものでした。加えて、データベースをどう設計するかということも問題点としてはあるわけですが、こちらもオブジェクト指向の世界での解決策は2000年前後に一定の成果を出しており、久しぶりにそのあたりの書籍を調べて、10月にINTER-Mediatorの勉強会でワークショップをやってみたりしました。さらに、最近はプロジェクトマネジメントの世界でも注目されてきたアジャイルということもあり、現在の開発における問題点を解決に向かわせる手法として注目されており、そうしたことを全てひっくるめての「開発手法」に行きつきたいということもあって、次の方針を模索中だったりします。

2017年度から、大学の非常勤の仕事を多めに入れたのですが、初年度はやっぱり教材の仕込みが大変でした。NIIの仕事が2017年から週に3日になったので、開発の仕事は大きなことができなくなることが予想されたので、細切れな仕事が中心になりましたが、それでも、断続的には開発の仕事も続けました。ということで、余裕のない忙しさがずっと続いていたので、研究を進めるのがかなり困難でした。もっとも、研究員としてNIIで雇用されているのですが、実際の仕事はトップエスイーのシステムや運営関連のことなのでNIIの業務時間内で研究をする時間は全くありません。今年、2018年は、もう少し余裕を持って色々なことに当たれるようになりたいなとは思っていますが、今年はまあそういう状況に持ち込めない感じです。とは言え、INTER-Mediatorの方は、最優先で進めているので、進行は色々あると思います。今年もよろしくお願いします。

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認証で利用する

一部に間違いがあり、修正しました。修正箇所は青字で記載してあります。（2017-06-17）

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」の３つの選択肢が増えている。利用する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ではこの同意画面を利用していないようで、「ユーザーに表示するサービス名」だけを設定して「保存」ボタンで保存すれば良い。

その後にアプリケーションの種類を選択するページが表示される。ここでは、「ウェブアプリケーション」を選択する。すると、名前などを入力する項目が表示される。ここで、名前は適当に設定するとして、もう１つは「承認済みのリダイレクト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対応はなされていない~~。~~これは先のバージョンを待つしかないだろう。~~WebDirectについては当初は対応していないと記載していたが、GOからのアクセスも含めて対応はしている。エミックの松尾さんに指摘をいただいたが、恐らく正しい証明書であればHTTPSであればOAuth認証ができ、自己署名の証明書であればできないということではないかと思われる。なお、http://…だと、Googleで登録ができなかった。この件、簡単に検証ができないのではあるが、手元で検証した時の違いとなると署名書の違いしか考えられない。

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に繋いで指定するのだが、これも１回読んで理解するのはほとんど無理かもしれない。

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を使いながら、得られるデータの活用方法などを解説しよう。