2014年12月22日月曜日

FileMakerでデータの入力ログを記録してみる

ログを記録する


FileMakerには「誰が」「いつ」「どこを」「どのように」変更したという履歴を残す機能がデフォルトではありませんので、開発者自身がその機能を作ることになります。

ログを記録しておく理由にはいくつかありますが、主に、

・誤って入力してしまった場合に後で復活できるようにするため。

・誰がそれを入力したのかを知るため

・データベースの使われ方の統計を取るため

があるでしょうか。

またログはその後のソリューションの改善にも役立ちます。同じような入力ミスが多いようであれば、それを防ぐために、改良しなければいけませんので、そういったことにも役立ちます。

方法

方法はいくつもありますが、簡単な方法を一つご紹介します。

・ログを取りたいテーブルにそれを記録するためのフィールドを作成。

・オプションで、「入力値の自動化」「計算式」を設定します。

・「フィールドに既存の値が存在する場合は置き換えない」のチェックを外します。

・計算式は下記の図のようになります。







この計算式でLet関数を使用します。

最初の変数は、この計算式を起動するためのトリガーです。

変数に代入しているフィールドはログを取りたいフィールドを設定します。

次に、計算で、変更のあったフィールド名、内容、タイムスタンプ、アカウント名を取得して書き込みます。

また、繰り返し記録するため、改行区切りのリストで変更があるたびに追加されていきます。

実際に記録されるログはこんな感じになります。






注意点

この方法には注意点があり、基本的にユーザが手入力したものしか反映されません。フィールド設定のスクリプトステップでは前にフィールドへ移動のステップを使えば反映されますが、フィールドがアクティブにならないものでは、「いつ、誰が」という記録は残りますが、どのように変更されたかというところまでは残りません。

2014年12月19日金曜日

DevOpsとFileMaker

DevOpsって?

DevOps(デブオプス)とはDevelopment(開発者)とOperations(運用者)が連携して、システム開発を行っていくもので、今注目のキーワードです。

しかし、DevOpsとは具体的になんなのかということは、はっきりと決められていません。

一つ言えるのは、従来のウォーターフォールのような、初めに書類でシステムをどう作るかをやり取りし、GOが出たら、変更できないという問題点を何とかしようという動きであるということは分かります。

おおまかには通常、開発を委託する場合、委託側が提案依頼書を作成し、「こんなシステムを作ってほしいと考えているんだけど」と内容を明らかにします。

その提案依頼書やヒアリングなどをもとに、要件定義書を作成し、開発に取り掛かっていくことになります。また、大方はこの時点でかかる費用が見積もられます。

しかし、この段階では、委託側では実際に出来上がってくるのを見ることができません。

それゆえ、システムの全容が委託側で見られる頃には「イメージと違う」といったことが起きます。

また、運用後となって、「こうじゃなかった」と気づいても後の祭りということもあります。

その後の改修には追加の料金を取られることも多くあります。

大企業で、調達に慣れている専門の部署があれば、こういった問題になることは少ないかもしれませんが、中小企業には難しいところでしょう。

DevOpsとFileMaker

FileMakerでは、柔軟な開発を行うことが可能です。

ヒアリングによって情報をもとに、プロトタイプを作成し、見てもらう。

それをもとに、意見を交換し、次のバージョンを作成し、また修正。

運用開始後も、運用部門からの意見も聞きながら、直していく。

ニーズの変化があれば、すぐに直す。

といったフローが可能なのがFileMakerの特徴です。

これによって、開発者と運用者が連携し、運用者がイメージした、実際の業務を行う上で便利なソリューションを作成することが可能になるわけです。

運用しながら、直せる、DevOpsとFileMakerは親和性の高い組み合わせといえるのでしょう。

2014年12月17日水曜日

FileMaker Serverをインターネットに公開する

FileMaker Serverの公開ってなに?

FileMaker Serverの公開とは、インターネットからFileMaker Serverにアクセスし、ホストされているデータベースを開くことです。

ちなみにタイトルでは、「インターネットに公開」となっていて、誰でも見られるの?と誤解されるかもしれませんが、そういったことではなく、会社などの外からでもアクセスできるということです。

インターネットに公開されると、

・自宅PCからFileMaker Proで会社にあるFileMakerデータベースを開くことができる。

・外出先からFileMakerGOを使って、会社にあるFileMakerデータベースを開くことができる。

ということができるようになります。


FileMaker Serverを公開する方法

まず、FileMaker Server上では何か設定する必要がありません。しいて言うならば、AdminConsoleで「SSLの接続を有効」にするチェックを入れて、サーバを再起動させるだけです。

設定が必要なのは、FileMaker Serverが置いてあるネットワークと、WAN(インターネット)の境界にあるルータやファイアウォールなどのネットワーク機器の設定だけです。

この設定はルータなどによって名称が異なりますが、NAT、ポート解放、DMZ、IPマスカレードといった名称の機能です。

公開するための設定に必要な情報など

まずルータに設定するに当たり、必要な情報は、

・FileMaker ServerのIPアドレス(固定されていない場合は固定しましょう)

・ルータの外側(WAN・インターネット側)のIPアドレス
 これは、http://www.cman.jp/network/support/go_access.cgiで教えてくれます。
 ちなみに、プロバイダから固定IPアドレスをもらっていない場合は、もらったほうがいいと思います。

ルータに設定をしよう

ルータによって違いますが、ルータの管理画面を開き、NAT、ポート解放、DMZ、IPマスカレードなどの機能を開きます。

・インターネット側のアドレス=ルータの外側(WAN・インターネット側)のIPアドレス
・プロトコル、ポート番号=TCP 5003
・LAN側IPアドレス=FileMaker ServerのIPアドレス
・LAN側ポート=TCP 5003

というような設定をします。この設定はルータによって入力するところが違いますので、注意しましょう。

次にパケットフィルターの設定です。
ルータによってはこのパケットフィルターの設定が自動で施されるものもあります。

通常はこのパケットフィルターの設定によって、ルータが外からの接続を許可する、しないという行動をとります。

先ほど設定した、TCP 5003ポートの通信を許可するような設定をしなければなりません。


※ルータのポート解放は設定を誤るとセキュリティ上の問題がある場合がありますので、不安な方は専門家へ相談した方がいでしょう。


基本的にはこれで、外からアクセスできるようになります。
これはFileMakerPro、FileMakerGOを使用してのアクセスに限られます。

WebDirectやAdminConsoleなどを使う場合は80、443、16000のポートを開ける必要もあります。

また、FileMakerデータベースの設定で「[共有ファイルを開く]ダイアログに表示をしない」というオプションがあります。

設定したいFileMakerデータベースを自分のPCに移動し、データベースを開きます。
「ファイル」→「共有設定」→「FileMakerクライアントと共有」を開き、「[共有ファイルを開く]ダイアログに表示をしない」にチェックを入れます。

このファイルをFileMaker Serverにアップロードします。

これをしておくと、FileMaker Serverにホストされているデータベースの一覧が表示できないので、セキュリティ的にいいでしょう。

2014年12月15日月曜日

FileMaker(ファイルメーカー)の同期モデルについて考えてみる

同期モデル

以前FileMakerとiPad、iPhoneの進化にて、古いiPadの延命として、同期モデルが必須というお話をさせていだたきました。

私は昨年くらいから、利用頻度の高く、規模もあるシステムでは同期モデルを取り入れるようにしています。

しかし、運用を始める直前にあることに気づきました。

FileMaker Proの利点はいつでも、ソリューションの修正ができる、という点です。

開発スピードも速いので、導入後に現場の意見を吸い上げ、それをすぐに実行できるというというところから、どんどん改良を加えていくわけです。

同期モデルでは、iPadやiPhoneのローカルに保存されるFileMakerデータベースからサーバでホストされている別のデータベースへアクセスし、データを取得したり、またはデータをサーバへアップロードします。

ということは、ホストされているデータベースに変更を加える場合、その影響がローカルのファイルにも影響することがあります。

また、ローカルのファイルに問題があったり、改良することもあるので、改良されていないローカルなデータベースがホストのファイルと同期をとると問題が生じするケースも出てきます。

そのため、ローカルなファイルに対して、バージョン管理をしっかりと行い、ホストファイルにアクセスできる最低のバージョンを満たしていない場合に、同期させないという処理が必要になってくるわけです。

バージョン管理

最初は、そういう可能性に気づかず、危ないところでした。

もし、管理をせずに運用を始めると少し面倒なことになるところでした。

遠隔地で普段は顔を合わせない方も多いので、新しいバージョンにローカルファイルを更新したときにスムーズにファイルを入れ替えてくれるとは限らないからです。

ホストファイルに同期を許可する最低のバージョンの管理としていろいろな方法があると思いますが、ローカルのファイルにバージョン番号を持たせ、ホストファイルに接続できる最低のバージョン番号を保存し、同期処理前にその番号を比較し、最低バージョンを下回っている場合に同期させない。

ローカルファイルの作りや、業務上のルールにもよりますが、それだと問題が起きるケースも、考えられました。

ローカルファイルを開けたときに、ホストファイルと必ずしも接続する必要がない場合があります。

その時は、ローカルのファイルで入力などを行い、「さあ、同期しよう」となった場合、最低のバージョンを下回っていることを知り、同期できずにせっかくの入力が…となってしまうことが。

そういうことが起こりうるので、Webサーバにホストに接続できる最低のバージョン番号を記したファイルを置いておき、ローカルファイルを開くときに「URLから挿入」で、そのバージョン番号とローカルファイルのバージョン番号を比較する方法を取り入れています。

インターネットにさえつながっていれば、バージョン番号を取得できるので、けっこう便利です。

奥深い同期モデル

同期モデルに取り組む以前は、あまり想像もしていませんでしたが、けっこう奥深くて、いろいろと作っていくうえで勉強になりました。

また、いろいろと試してみていきたいと思います。

2014年12月10日水曜日

FileMaker Serverにホストされている一覧が表示されない問題(備忘録的)

FileMaker Server11→13にソフトを更新した時にごく一部のユーザで、
ホストされたデータベースの一覧が表示されない問題が起きました。

これは一覧が表示されないだけではなく、直接パスを入力しても
ファイル自体が開けないというものでした。

最初原因が全くつかめなったのですが、テスト環境で使用している
ローカルなサーバには接続でき、ファイルの一覧も取得できることが判明。

このサーバと本番運用のサーバとの違いを考えました。

このサーバはローカルに置かれているテスト用で、SSLの設定を無効にしていることが
分かり、ためしにこのサーバのSSLを有効にしてみると同じ問題が。

SSLの接続に問題が、あると推測。

問題なく接続できているユーザにインストールされている
「C:\Users\(ユーザ名)\AppData\Local\FileMaker\FileMaker Pro Advanced\13.0
にある、××.pemという証明書を置き換えてみたりしてもダメでした。

しかしその過程で、問題なく接続できるユーザと、そうでないユーザの相違点を発見。
ユーザ名が日本語か、アルファベットという違いが…

接続できないユーザのPCのユーザ名を変えてみると接続できました。


これって、日本の環境であれば結構おこることだと思うんですが、FileMaker社のHPには
記載がない。

Windowsだけで起こることなんでしょうか。。。

2014年12月9日火曜日

FileMaker Serverで使うサーバのサイジングについて考えてみました。

難しいサーバのサイジング


今日はFileMaker Serverで使うサーバのサイジングについて考えてみました。

サーバサイジングは非常に難しいと思います。
FileMaker Serverだけではなく、これまで数台のサーバを購入してきましたが、
正解が見えません。

スペックが高すぎでも、コスト的に無駄が出てしまう。
スペックが低すぎたら、非難ごうごう。

今のサーバのスペックが足りているか足りていないかは、
AdminConsoleやログを見ることである程度判断することはできますが、
クライアントの環境にも大きく左右されますので、判断は難しいところです。

また、PCやサーバもへたってきますし、3年後に環境などを想定して、
サイジングを行わなくてはいけません。

参考までに、実例からちょっと考えてみたいと思います。
インターネット越しのアクセスがある二つのサーバのスペックを下記に
記しました。

・条件

初代
FileMaker Server:11
CPU:Xeon X3430 2.4GHz(4コア)
HDD:SATA500GB×2
RAID:RAID1
RAM:4GB
OS:Windows Server 2008(32Bit)

二代目
FileMaker Server:11→13
CPU:Xeon E5-2430 2.2GHz(6コア)
HDD:SATA500GB×2
RAID:RAID1
RAM:16GB
OS:Windows Server 2008 R2(64bit)

初代はインスタントWeb公開を使用し、
二代目は最初は初代の環境をそのまま移行、その後、FileMaker Server13へ移行。
WebDirectも使用。ともに、Web公開エンジンと、データベースエンジンは同じサーバで動かしています。

メインはFileMaker ProとFileMakerGOからのアクセス。

初代から二代目への買い替えは、利用頻度が多くなったこと、FileMaker13が発売され、移行を決定したこと、ログ上は処理速度が遅くなっていたことがあり、買い換えることに。

買い換えるにあたって、FileMaker Server13でWebDirectを使うことを想定し、
それなりのスペックを用意しました。

価格的にもほぼ2倍くらいになりました。

最高の同時接続数としては、
WebDirect:5程度
FileMaker Pro:5程度
FileMaker GO:25程度 くらいあります。

買い換えた当初、ログ上は明らかに軽くなっている数値が出ていましたが、
使っている方にはよくわからないようでした。

私自身は毎日そういったことを気にしているので、「ああ、早くなったな」とわかりましたが、
分からないという人がほとんどでした。。。

2014年12月8日月曜日

FileMaker ProとMicrosoft ACCESSの比較 Part2

検索とソートの比較

前回、「FileMaker ProとMicrosoft ACCESSの比較」にて比較はあまり意味がないということを書かせていただきましたが、
実際にパフォーマンスとしての比較を細かくしたことがなかったので、ちょっとしてみたくなり、してみました。

※あらかじめお断りさせていただきますが、下記のような限られた条件下でのテストですし、テスト自体も数回しか行っていないので、精度的に信頼できるものではない可能性があります。
実際、業務などで使うものは、テキスト、日付などのデータも扱いますし、検索やクエリも複雑なこともありますので、あくまでも興味本位という視点でご覧ください。

条件

・FileMaker Pro、ACCESSとも同じデータを使用
・データはランダムな1~5ケタの数字が入力されているものだけ
・レコードの件数約24万件
・インデックスは双方に設定
・測定は、FileMaker Proはスクリプトで、検索・ソートを始める前に時間を取得し、最後にその差を出す。ACCESSはVBAでFileMakerと同じように時間を取得
・スタンドアローン

使用したマシンのスペック

CPU:core i7
メモリ:16GB
OS:Windows7 Pro
FileMaker:13
ACCESS:2007
ハードドライブ:SSD

条件FileMakerACCESS
ある数字(一字)が含まれるものを検索0.112秒0.070秒
ある数字(二字)が含まれるものを検索0.113秒0.070秒
ある特定の数字を検索0.095秒0.063秒
昇順でソート(約24万件の並び替え)3.25秒0.063秒

上記のようになりました。テストは2回行った平均値です。2回目はPCを再起動して、行いました。
ちなみに、「ある数字」とはワイルドカードを使った検索です。

正直な感想を言うと、検索(クエリ実行)に関しては数字上では違いがありますが、人間の目には違いが分かりませんでした。

ソートに関しては明らかな違いがありました。ただ、24万件のレコードを丸ごとソートするなんて普通はしませんから、パフォーマンスとしての参考になるのかどうかは疑問はあります。

もっとレコードを増やしたり、テキストを検索したりしたら違いが出るのかなぁなんて、思ってしまいました。

また、機会があれば別の条件で試してみたいと思います。

2014年12月4日木曜日

恐ろしく簡単になったFileMaker Serverのインストール

FileMaker Serverの進化


FileMaker Serverはバージョンが13になって恐ろしいほど進化しました。

私はテスト環境を作ったり、昨年から今年にかけてサーバ機の更新を行ったこともあり、
FileMaker Serverのインストール作業はかなり行いました。

本当にインストールが楽になったし、トラブルもあまりありません。

FileMaker Server11の頃

まず、インストーラを起動する前に、Webサーバのインストールが必要でした。

私はWindows Serverがメインなので、IISを使うわけですが、このインストールに
なんだかんだで10分くらいはかかります。

その後インストーラを起動して行うわけですが、そこまでは特に何もありません。

問題はAdmin Consoleです。

まず、JAVAのバージョンやPCの環境によって起動しないことがある。

特に、他のPCから遠隔で起動する際にトラブルが起こることがあり、
本当に大変な思いをしたこともあります。

また、FileMaker Serverの台数分、PCにはAdminConsoleをインストールが必要という点。

FileMaker Server13の今

今となっては、サーバ起動→インストーラダブルクリック→ちょっと入力→終了です。

事前にIISのインストールもいりません。勝手にやってくれます。

AdminConsoleもブラウザから起動なので、遠隔で操作する場合もトラブルなくできます。

一番初めは、IEでうまく動かないことがありましたが。今では、特にそういったこともなく。

Bonjourのインストール時に、ウィンドウが出ていることにしばらく気づかずインストールが中断されていたり…ということくらいでしょうか。

本当に楽になりました、うんうん。

2014年12月3日水曜日

FileMaker ProとMicrosoft ACCESSの比較


FileMaker Proをこれから使おうという人が陥る罠

おそらく、FileMaker Pro(ファイルメーカープロ)をこれから使うかどうか迷っている人の多くは、Microsoft ACCESS(アクセス)とFileMakerとを比較して、どちらが有用かを判断することと思います。

こういった視点での比較は、はっきり言って意味がないと私は思っています。

こういった比較をされる方はおそらく、ACCESSを共有ストレージなどに置き、複数人で使用されているのではないかと思います。

ACCESSは本来、スタンドアローンとして使うソフトです。
FileMaker Proは複数がアクセスすることを標準としたソフトです。

そもそもの土壌が違うわけですが、比較したくなるのも理解できます。

ACCESSは会社で使う事務用のPCであれば、すでにインストールされている可能性が高い。

FileMaker Proは専門家ではなくてもソリューションを作成することが可能。

この二つの点は双方のソフトの入り口が広く、敷居が低いという共通点があり、
よく比較されるわけです。

とはいうもののちょっと比較を表にしてみましょう。

FileMaker ProとACCESSの比較図


項目FileMakerACCESS
複数での接続可能できるが、想定されていない
権限管理可能できるが、プログラミングの知識が必要
見た目・レイアウト自由度が高い、比較的簡単古いインターフェイスになりがち
開発スピード早い比較的遅い
最大のファイルサイズ8TB2GB
プログラミング知識なくてもいいあったほうがいい
インターネットからアクセス可能標準で可能(Server使用時)できない

また、よくデータベースのパフォーマンスについてどちらが早いのかを知りたいということを耳にしますが、これもあまり比較の使用がありません。

私の経験からいうのであれば、インターネットから接続するFileMakerデータベースで、約600万件のレコードから検索を行っても、結果を返すのに、1秒もかかりません。

確かに、ソートはFileMakerはちょっと苦手だといわれています。
正確に比べたことはありませんが、ACCESSのほうが早いような印象もあります。

技術的な知識のあまりないACCESSを使っていた方がFileMakerを使うと、ACCESSでは簡単にできなかったことが、簡単にできるようになります。そして「FileMakerは遅い」といいます。それは、「非保存の計算フィールドを多用したりといった」本来と違った使い方をしているからです。

特に、複雑な処理などを必要としない、「Excelでは、データの再利用が難しいけれど、ACCESSなら検索も簡単だし」という理由でACCESSを使っているのであれば、無理にFileMaker Proを購入する必要はないでしょう。

逆に、インターネットから会社の情報にアクセスしたい、複数でデータベースを使いたい、処理を自動化したい、ソリューションを内製したいという企業の方はFileMaker Proを使ったほうがいいでしょう。

用途が違うソフトなので、完全な比較は難しいわけです。

2014年12月1日月曜日

なぜあなたのFileMakerデータベースは遅いのか?

FileMakerは遅い?

「FileMakerは遅い」と言われることがあります。

それはなぜでしょうか。

ツールやソフトには大きく分けて二つあります。

専門的な知識を必要とするプロ用のもの
特に専門的な知識を必要としないパーソナル用のもの

仕事で使用するものなのにパーソナルというのもなんですが、
特別な知識を必要としないということということです。

「FileMakerは遅い」といわれる原因の一つは、
FileMakerというソフトが、そのどちらにもあてはなまらない、
そのどちらにも当てはまるソフトだからなのではないかと思います。

実際、FileMaker Proを使用し始めるのに専門的な知識は必要ありません。

しかし、ソリューションやシステム開発に使用するツールとしては、
専門的な知識を必要とします。

専門的な知識がある人とそうでない人が同じことができるソリューションを作れるのが、
FileMakerの魅力ですが、

その中身は大きく変わってきます。

どんなツールにでも、そのソフトを重くする方法はいくらでもあります。

同じものを作っても、遅いものとそうではないものが存在するということは、
作り手の力量次第というということになるでしょう。

FileMakerで一番大変なのはパフォーマンスとテスト

だと私は思います。

少し前に書きましたが、新しいOSの動くiPadで新しいFileMakerのソリューションを動かさなくてはいけない。というようなことを書きました。

パフォーマンスは永遠のテーマのような気もします。

例え業務改善するソリューションを作っても、パフォーマンスが悪くては仕方がありません。

しかしパフォーマンスは経験によるところも多いので、経験の多い方に見てもらうのも手かもしれません。

インターネットを超えるデータベースは注意が必要

FileMakerでは非保存のフィールドを多用するなという不文律があります。

インターネットを超えないLAN内での運用しかないものであれば、
非保存のフィールドはそれほど、ストレスにはなりませんが、

インターネット(WAN)越しにアクセスがあるものに関しては、格段に遅くなります。
また、FileMaker GO向けのものも注意が必要です。

ちなみにVPNもWAN越しと同様です。回線などにもよりますが、一般的にVPNはWANよりも低速です。

リレーションを多用しない。

同じ計算式内で同じ計算を何度もする場合はLet関数を使う。

テーマを正しく使う。

など、いろいろあります。

ハードや回線よりもまず内部を見直す

ハードや回線を変えても劇的にソリューションのパフォーマンスが上がることはあまりないでしょう。

私の経験上でも、サーバ機のスペックを上げてもベンチマークでは明らかによくなって、私の目にも早くなっていることは分かりましたが、それが、ユーザの方まで認識できるようなレベルかどうかは難しいところです。

回線も低速なADSL→光などの差があり、1M→40Mといったぐらいにスピードが上がれば、別ですが、なかなか難しいでしょう。

それよりもデータベース内部を見直した方が確実といえるかもしれません。

メンテナンスとの戦い

メンテナンスの正体

よく、Webサイトや、インターネット上のさまざまなサービスで、「メンテナンス」という言葉を聞きます。

いったい何をするんだろうと思われる方も少なくないかと思ます。

私も、今の仕事をするまではそう思っていました。

メンテナンスにもいろいろな種類があります。

緊急メンテナンス

いわゆる、サーバーが止まってしまうとか、データベースが壊れたとか、突然不具合などのトラブルが発生して、再起動させたり。
データベースであれば、バックアップから復旧したりといったことを行います。

もう、ちびまる子ちゃんのように、顔に線が出てしまう心境。

臨時メンテナンス

緊急性は高くはないけれど、定期メンテナンスを待っていると少し遅いと感じられるときに行います。
主に、ソフトウェアのアップデートや、システム上で何か変更を加えたい、ルータなどのネットワーク機器を交換したり、設定を変更したりといったことになるでしょう。

定期メンテナンス

あらかじめ決められているスパン(1か月ごとなど)で実施する、ルーティーンワーク。
OSの更新プログラムの適用、ソフトウェアのアップデート、ログなどのバックアップを取ったり、
臨時メンテナンスの部分に書いてあることでも、定期メンテナンスまで待てるようなものは、
ここで行います。


主にこういったことを行うのがメンテナンスです。

IT化とブラック化


会社のIT化が進むにつれて、サーバが増え、ネットワーク機器が増え、メンテナンスする対象が少しずつ増えてきました。

そうすると、今まで、「ちょっとこれからサーバ止めますね」とそのサーバを使用している数人に声をかければよかったものが、
前もって計画を立て、決められた時間内に処理をする必要が出てくるようになります。

さらに、ファイアウォールのような、止めるとインターネットに接続できなくなるような機器のメンテナンスを行う必要が出てきて、土日にしかできないようなことも発生。

さらにさらに、止めると業務に支障が出る基幹的なシステムも管理するようになり、
深夜か早朝しかできないようなことも発生。

IT業界はこういった運用だけではなく、開発も労働環境が厳しいところもあり、
人が集まらないということを耳にしたことがあります。

なかなかITに詳しくない人に、この苦労をわかってもらえないというのが、
非常に難しい部分でもあります。