連携範囲が広いシステム
データ連携する手法
企業規模の大きな所になると、既に基幹システムが稼働しておりマスターデータはそこから引く、あるいは複数のシステムがお互いに必要な情報を補完しあうために、FileMakerで開発したシステムのデータとの連携が必要になってくることが多々あります。
FileMaker以外のシステムとデータを連携させる方法はいくつかありますが、代表的なものは次のとおりです。
- A： CSVやXMLデータなどのテキストデータファイルを介し、定期的にインポート/エクスポートする。
- B： 条件が合えば（適用できるドライバがあれば）、ODBCを経由したデータのインポート/エクスポート、あるいはスクリプト「SQLを実行」を使用して、INSERT/UPDATE/DELETEなどを行う。
- C： さらに条件が合えば（動作環境を満たせば）、外部SQLデータソース（ESS）機能を利用し直接データを参照する。
Aは、取り込み側でそのデータを取り込むための処理と、その処理をキックするトリガーが必要となります。その性質上、汎用性はありますが即時性に欠けます。
Bは、ODBCドライバの有無と、動作確認が条件となります。この場合は、データの送信と取得がFileMaker側のアクションで行えるので、例えば［更新］ボタンのスクリプトに「SQL実行」スクリプトをサブスクリプトで連ねておけば、一連の流れで連携がとれるので、リアルタイムに近い処理が行えます。
Cは、適用可能範囲が狭くなりますが、他システムのテーブルを直接参照していることになるので、連携の中では一番、即時性が高いでしょう。
データ連携する際の留意点
まず連携手段にかかわらず注意が必要なのは、「FileMakerにおけるテーブル定義では、桁数という考え方がない（に等しい）」という点です。FileMakerでは、各データタイプごとに保持できる最大データ量の仕様が存在するものの、テーブル定義の際に、各フィールドに桁数を指定することができません。
従って「テキスト」タイプのフィールドには、データサイズを特に意識しなくても良いくらいの文字数が入力できてしまいます。しかし、他システムとの連携を考えるときには、この「桁数」が大きく影響してきます。
そのため、それらの桁数を考慮した別の連携用フィールドを必要としたり、書き出したデータを成型し直したりする必要があります。
また、同様の理由からFileMakerは基本的に「可変長」です。よくホストデータから提供される形式に「固定長」のものがありますが、これらをFileMakerに取り込む時や他システムに提供する時も、この辺りを念頭に置いておく必要があります。
他システムとの連携を行う場合は、それぞれのシステムのデータの持ち方の特性について、相互理解を深める必要があります。データベースという同じ世界の中でも、それぞれで「常識」というものが存在し、それを外すと担当者同士の会話も通じません。ましてや、システム間の連携がさらに困難なことは言うまでもないでしょう。
以上のように、FileMakerはシステム開発のプロセスにおいて、「技術やデジタル」な部分よりも「対話やアナログ」な部分に関わる時間を多く取ることができる、大きな特長があります。
まとめ
冒頭で述べたようにソリューションがシステムの集合体であるとすると、すべてを一貫して同一環境で構築していく懐石やフレンチのフルコースのようなものより、洋食屋のアラカルト的な需要が増えてきていることが最近特に感じられます。
また得てして、そういう方が「ライス大盛り」にするような融通が効き、好まれたりするものです。また、出張シェフとして、フルコースの一品を供し得ることも忘れてはいけません。
これらを意識するために今回は、ちょっとだけ俯瞰したところから話を進めてきました。
まだまだ整理していきたい情報もありますが、また別の機会に場を移して皆さんと一緒に組み上げていきたいと思っています。
さて、次回よりまた少し新たな皿（展開）へと移っていきます。
最後になりましたが、この連載が終わる頃には「（お客様からの）注文の多い料理店」を志す人が少しでも増えていることを切に願って、次回にバトンを渡したいと思います。
