同期モデル
以前FileMakerとiPad、iPhoneの進化にて、古いiPadの延命として、同期モデルが必須というお話をさせていだたきました。
私は昨年くらいから、利用頻度の高く、規模もあるシステムでは同期モデルを取り入れるようにしています。
しかし、運用を始める直前にあることに気づきました。
FileMaker Proの利点はいつでも、ソリューションの修正ができる、という点です。
開発スピードも速いので、導入後に現場の意見を吸い上げ、それをすぐに実行できるというというところから、どんどん改良を加えていくわけです。
同期モデルでは、iPadやiPhoneのローカルに保存されるFileMakerデータベースからサーバでホストされている別のデータベースへアクセスし、データを取得したり、またはデータをサーバへアップロードします。
ということは、ホストされているデータベースに変更を加える場合、その影響がローカルのファイルにも影響することがあります。
また、ローカルのファイルに問題があったり、改良することもあるので、改良されていないローカルなデータベースがホストのファイルと同期をとると問題が生じするケースも出てきます。
そのため、ローカルなファイルに対して、バージョン管理をしっかりと行い、ホストファイルにアクセスできる最低のバージョンを満たしていない場合に、同期させないという処理が必要になってくるわけです。
私は昨年くらいから、利用頻度の高く、規模もあるシステムでは同期モデルを取り入れるようにしています。
しかし、運用を始める直前にあることに気づきました。
FileMaker Proの利点はいつでも、ソリューションの修正ができる、という点です。
開発スピードも速いので、導入後に現場の意見を吸い上げ、それをすぐに実行できるというというところから、どんどん改良を加えていくわけです。
同期モデルでは、iPadやiPhoneのローカルに保存されるFileMakerデータベースからサーバでホストされている別のデータベースへアクセスし、データを取得したり、またはデータをサーバへアップロードします。
ということは、ホストされているデータベースに変更を加える場合、その影響がローカルのファイルにも影響することがあります。
また、ローカルのファイルに問題があったり、改良することもあるので、改良されていないローカルなデータベースがホストのファイルと同期をとると問題が生じするケースも出てきます。
そのため、ローカルなファイルに対して、バージョン管理をしっかりと行い、ホストファイルにアクセスできる最低のバージョンを満たしていない場合に、同期させないという処理が必要になってくるわけです。
バージョン管理
最初は、そういう可能性に気づかず、危ないところでした。
もし、管理をせずに運用を始めると少し面倒なことになるところでした。
遠隔地で普段は顔を合わせない方も多いので、新しいバージョンにローカルファイルを更新したときにスムーズにファイルを入れ替えてくれるとは限らないからです。
ホストファイルに同期を許可する最低のバージョンの管理としていろいろな方法があると思いますが、ローカルのファイルにバージョン番号を持たせ、ホストファイルに接続できる最低のバージョン番号を保存し、同期処理前にその番号を比較し、最低バージョンを下回っている場合に同期させない。
ローカルファイルの作りや、業務上のルールにもよりますが、それだと問題が起きるケースも、考えられました。
ローカルファイルを開けたときに、ホストファイルと必ずしも接続する必要がない場合があります。
その時は、ローカルのファイルで入力などを行い、「さあ、同期しよう」となった場合、最低のバージョンを下回っていることを知り、同期できずにせっかくの入力が…となってしまうことが。
そういうことが起こりうるので、Webサーバにホストに接続できる最低のバージョン番号を記したファイルを置いておき、ローカルファイルを開くときに「URLから挿入」で、そのバージョン番号とローカルファイルのバージョン番号を比較する方法を取り入れています。
インターネットにさえつながっていれば、バージョン番号を取得できるので、けっこう便利です。
奥深い同期モデル
同期モデルに取り組む以前は、あまり想像もしていませんでしたが、けっこう奥深くて、いろいろと作っていくうえで勉強になりました。
また、いろいろと試してみていきたいと思います。
