前置き
前置きはいいよという方は、GoogleForm のデータをFileMakerに取り込む３つの方法からご覧ください。
社内SEの味方
中小規模の社内SEとして働いているのですが、慢性的にリソースが不足していることもあり
様々なサービスやソフトウェアに助けてもらいつつ日々課題に取り組んでいます。
この記事では日頃の感謝も兼ねて GoogleForm と Filemaker について、特にその連携について紹介します。
GoogleForm
説明なんて不要ですね。
ちょっとしたアンケートや申請受付を作るのに手軽で便利なGoogleForm。
私たちもよく助けてもらっています。
「こんなシステムが欲しいんだけど」という社内からの要望にも「それ、GoogleFormでよくない？」という場面は結構多いです。
弱小エンジニアだからこそ1、三大美徳の 「怠惰」 には全面的にしたがわねばなりません。
また、ピティナには「自分で作ってね」という 「怠惰」 もあります。
※ラリー・ウォールの「怠惰」からは外れますけどね
どちらの意味においても、GoogleForm は大変魅力的です。
FileMaker
「自分で作ってね」の点でいうと、FileMakerというソフトウェアも大変重要な存在です。
というか、FileMakerがあったから「自分で作ってね」という怠惰が許されています。
FileMakerについては少し説明します。
ViewとModelが一緒くたになったという感じなのですが・・・
- テーブルを定義すると、レイアウト画面でオブジェクトとして扱うことができる
- これにより、GUIで簡単にそれっぽい画面がめちゃめちゃ手軽に作れてしまう
というのがシンプルな説明でしょうか。
また、（ほぼ）日本語で記述できるスクリプトも搭載しているので、非プログラマーによるプログラミングが可能になっているのもポイントです。
イメージ
※FM17のサンプルファイルから拝借
右側に見えているのがテーブル定義用の画面で、左側がレイアウト（画面）設定画面です。
カラム（FMではフィールド）をGUIでラベルやテキストボックスとしてレイアウトすることできるので、
簡単に画面が出来てしまいます。
ピティナではFileMakerが基幹
私の働く ピティナ はこのFileMakerが基幹DBとなっており、社内システムの大半がFileMakerで構築・管理されています。
そのため、ピティナのシステム開発は「（なるべく）すべてのデータをFileMakerで見られるように」というのが暗黙の前提になっています。
GoogleFormとも仲良くしてほしい
なので、両者にはぜひ仲良くしてもらいたいのですが、GoogleForm と FileMaker はお互いのことを
気にしていませんので、デフォルトでは連携することができません。
GoogleForm のデータをFileMakerに取り込む３つの方法
前置きが長くなってしまいましたが、ここから本題です。
これまで連携させるために行ってきた方法と、いまいま「これがベスト」と思える方法について紹介します。
①CData を利用する
手動コピーをしていた時代もあったのですが（恥）、最初に行き着いたのがCDataでした。
概要
- CData
- ライセンスの購入
- ローカル端末
- ODBCドライバに設定する
- FileMaker スクリプトを作成する（当該端末でないと作成できない）
- 専用のスクリプトステップでインサートSQLを作成する
メリット
SQLが使える
SpreadSheetをテーブルとしてみなしSQLで任意のデータを取得できます！！
デメリット
設定が面倒
割とブラックボックスなUIなので、テーブル・カラムの指定方法が分かりにくいです。
一旦SQLを自動生成させて「ああ、こうやって書くのね」というのを掴んでから、
SQLを調整する感じになります。
こんな感じ
ライセンス料金
そこまで高価でもありませんが、後述の方法は特別な支払いがなく出来る方法なので、比較すると高く感じてしまいます。
＞ お値段表
端末が限定される
これもライセンス料金の影響なので、お金を払えば解決する問題ですが、
目先の料金を小さくしようと思うと端末１台にのみ適用することになります。
するとスクリプト修正・新規スクリプトの作成は、その端末で操作しなければならなくなり、
圧倒的に開発効率が悪くなります。
まぁ、、、お金を払って複数台に入れればいいんですよ。
②GAS＋FM「レコードのインポート」
概要
- GAS
- スプレッドシートでcsv出力マクロを作成する
- FileMaker
- WebViewerか何かでマクロ実行URLを叩く
- ローカルにcsvが落ちてくる
- スクリプトでcsvを「レコードのインポート」する
メリット
無料
自分で作れるので無料です。（開発コストはどれも大差ないので無視します）
GAS楽しい
プラットフォーム機能が改善されてプロジェクト管理できるようになりましたね。
やばいです。GAS開発がどんどん楽しくなってきてます。
デメリット
csvが邪魔
実ファイルを生成するので定期的に削除してあげる必要があります。
そこまで気にならない人もいるかと思いますが、やはりゴミになるものは作らないに限ります。
③GAS＋MySQL
現時点でのベストだと思っています。
もっと早く気づいてもよかったのに・・・。悔しい限りです。
GASの初期はMySQLへのインサートが出来なかったか、あるいは僕が情弱過ぎてリーチできなかったかで、
「できたらいいのにね」という話で終わっていました。
概要
- MySQL
- DBサーバをたてる or 既存のDBサーバに１つテーブルを作成する
- ユーザを作成する（当該フォーム専用のユーザ）
- GAS
- MySQLにインサートするマクロを書く
- FileMaker
- MySQLをESS透過する
メリット
MySQLにデータがある
FileMaker 大好きな組織で働いていますが、僕自身は実は苦手です。
（リレーションを貼るのにいちいちオカレンスなるものを作成しないといけないとか・・。）
なので、MySQLにデータがあるとすごく安心します。（SQL使えるし）
またFileMakerはデフォルトでMySQLとの連携があるため
- 透過してMySQLのデータを見ることができる（データはMySQLにのみ保持）
- FileMakerへの取込も標準対応（FileMakerのテーブルと同等に扱えます）
- ということは社内のスタッフも間接的にMySQLを扱うことができるのです。
データ量が多くなると、FileMaker越しにMySQlを見るのは辛くなってくるのですが、
GoogleForm で集める程度のレコード数なら問題にはなりません。
デメリット
サーバ代
DBサーバがあって相乗りするなら不要です。
GASに接続情報を書かないといけない
個人の感覚ですが、なんとなく気持ち悪いと思ってしまいます。
そもそも、当該ユーザは当該フォーム用のテーブルしかアクセスできないようにしますし、
公開されるわけでもないんですけどね。
古い人間の感覚かもしれません。
データの多重管理
スプレッドシート、MySQL、FileMakerと下手すると三重持ちになります。
なので、FileMakerにはデータを入れず、MySQLをESS透過するのが良いと思います。
ピティナでの使い方
- MySQL
- DBを１つ作成（GoogleFormの回答テーブルをまとめるDB）
- テーブルを１つ作成（GoogleForm１つにつき、１テーブル）
- ユーザを１つ作成（2のテーブルしか触れないユーザ）
- GAS
- 当該テーブルにインサートするGASを作成
- FileMaker
- 当該テーブルをESS透過
おしまいに
ピティナの場合は、
- エンジニアの都合（FM好きくない。MySQL好き）
- 事務スタッフの都合（MySQL好きくない。FM好き）
両方かなえようとしているので、③がベストですが、MySQLを必要としない組織であれば①か②が良いと思います。
①は多少SQLが出てきますが、おそらく一番単純なセレクト文しか使わないので、
SQLはじめての方でもQiitaの記事を参考にすれば対処できるでしょう。
※ちなみに、いずれの方法を取るにしてもフォーム毎に開発コストが掛かりますので、その点は留意なさってください。
-
わたし個人のことであって、ピティナ・エンジニア全体のことではないですよ！ ↩