Category: データベース

[IM]バリデーションの実装を再考する

INTER-Mediatorではかなり以前にバリデーションの実装はしたものの、完全ではない状態だったのですが、このところ、手を入れるに従って、いろいろ不具合…というか、「考慮が薄い」ポイントが目立ち始めましたので、改めて、議論を進めたいと考えています。

まず、バリデーションは、「入力チェック」とも言われます。いちばん、根本的なことは何かというと、「正しくない値をデータベースに保持しないようにしたい」という要求があると考えています。「正しくない」の基準は、アプリケーションによって変わりますが、「NULLである」ということかもしれませんし、「正しいメールアドレスのフォーマットではない」ということかもしれません。その場合に、データベースに記録しないようにするということがあります。データベース絡みとなると、いろいろ複雑な問題が出てきますので、これを後回しにして、まずは、アプリケーション利用者レベルからの見方を考えてみます。

開発者や管理者がバリデーションを必要とし、実装しますが、Webアプリケーションフレームワークは、バリデーションに関連したユーザーインタフェースを構築し、ユーザーを惑わせない仕組みの提供が望まれます。そもそも、アプリケーションで、どようにバリデーションが絡み合うのか、5W1H的にまず考えます。

  • When：正しくない値が入力されたとき
  • What：開発者や管理者が望ましくないと考えるデータを検知する仕組み
  • Where：入力可能なコンポーネント
  • Who：ユーザーが生成すると考える
  • Why：単純なミス、さまざまな誤認、テストあるいはインスペクション
  • How：キータイプ、あるいはコピー&ペーストなどのユーザの操作

以上の分析からは、バリデーションの検知と通知が大きな目的であることが出てきます。しかし、一部に例外があって、フィールドの初期値がバリデーション違反という場合もあります。そのとき、上記のWhoは「システム」ということになってしまいます。この初期値が違反している問題は、厳密にはデータベースの定義が正しくないで終わってしまいますが、非常に複雑な事情が絡むので、後ほど議論します。

バリデーションの検知は、INTER-Mediatorではすでに実装しています。onchangeイベントが発生したときに、フィールド単位でのチェックを行います。フィールドをまたがった判定用にも、コールバックされるメソッドの定義があります。最近になって、初期値が違反しているときでもバリデーションが働くように、onblurイベントでも判定をするようにしました。これら、さまざまなニーズはあると思われますが、タイミングと仕様が確定していれば、対処できる範囲かと思います。

一方、バリデーション違反の通知は、さまざまなバリエーションが考えられます。そういうニーズも状況も多様な状況では、プログラムを組んで対処というのはもちろん柔軟な対応ができていい部分ですが、一定の範囲を宣言的な記述でまかなうことで、プログラムを書くことを減らす意図のあるINTER-Mediatorではなんとかしたかったところです。そこで、フィールド単位のバリデーションが違反したら、「ダイアログボックスを表示して促す」「近辺に赤字等でメッセージを出す」という仕組みを定義ファイルの設定だけで実現しました。そして、イベント発生時に違反が検知されれば、雇用な動作をして、フィールドからフォーカスがはずれないようにしました。

しかし、ここまででも、すでに議論のポイントはいくつもあります。

  • バリデーションはいつ行うのか？
    • キータイプごと？
    • カット&ペーストするごと？
    • データベース更新前？
    • 複数のフィールドに対して「書き込み」ボタンがあれば、それを押したとき？
    • ポストOnlyモードとデータベース更新時は動作を違う必要があるのか？
    • 現状は、定義ファイルで指定可能なのはデータベース更新前のみ。
  • 違反通知をどのように行うのか？
    • 現在は、ダイアログボックスとページ上への文字の追加
    • 新しいページを表示したい？
    • 何が間違えたのかをもっと詳しく表示したい？
  • バリデーションに違反したら、その後にどのような操作を期待するのか？あるいは期待されるのか？
    • そのままでいいのか？
    • どこまでロールバックするのか？
    • どこまで既定値的な値を設定するのか？
    • 違反したレコードは削除しなくていいのか？
    • 違反してもレコードは作るのがいいのか？
    • 現在は、そのままにしつつ、正しい値を入力しないとそのページの他の作業をできなくしている。

あらゆるバリエーションに対する答えを用意するのか、それとも、主要な手法以外はプログラミングをしてもらうのか、その辺りが議論のポイントになると思います。いずれにしても、問題を書き出すことは必要でしょう。

データベースエンジンには通常バリデーションの仕組みは含まているので、本来はそちらを使うべきという議論があるでしょう。SQL言語での定義時に記述するため、「難しいから敬遠している」という向きもあるかもしれません。一方、なぜ、フレームワークがバリデーションをサポートするかというと、データベース側でのバリデーション処理は、違反時の状況の取得や、そこからの適切なユーザーインタフェースの構築、さらにやり直しなどの処理の組み立てなど、単純ではないプログラミングを要求されます。また、その対処方法も、データベースごとに違う可能性もあるので、むしろ、フレームワークの内部でバリデーションをサポートした方が、動作上作りやすいということもあるわけです。データベース側のエラー検知は、レイヤーを上下するワークフローをうまく組み立てるようなプログラミングを必要としますし、その結果、アプリケーションサーバーとデータベースということなるソフトウエア間の連携ということも必要になります。結果として、データベースに頼らない方が、フレームワーク内部で完結するため複雑さの一部を回避でき、加えてデータベースごとの事情に左右されないというメリットを生みます。

その結果、データベースのスキーマ定義にバリデーションルールが入らないことになり、それによる大きな問題は、初期値がバリデーション違反という状況で、ユーザーの操作に入ることがあります。これをどこの段階で、不正とみなし、どのような方法で排除するか、これが定まらないと、実装が揺らぎます。

ということで、とりあえず、頭にあることを書き出しておいて、議論を進める手掛かりにしたいと思います。

実は深刻な“カミFileMaker問題”

（2015/2/12 0:28更新：Facebookでの杉原さんの意見も反映させました。2015/2/13 17:00更新：Facebookでの日高さんの意見も反映させました。ありがとうございます。）

ネ申ExcelはExcelだけの問題か？

Excel方眼紙や罫線優先のワークシートなどなど、Excelで作った文書のうち、見栄えを整えることを主眼として作ってしまったことにより後からデータの活用ができなくなってしまった文書などを「ネ申Excel」と総称されています。三重大学の奥村先生の論文にまとめられています。良し悪しの問題は難しいのですが、例えばネ申Excelな記入用紙はWebフォームにすれば、即座に一覧が作られるなど、より利便性が高い代替え手法が明らかに存在するような場合があります。そのようにExcelにこだわる余り、自身の効率化を損なうのはもちろん、入力をするなどの利用者の利便性を著しく損なう状態になるのは避けるべきだと言えるかと思います。

同じような問題は他のソフトウエアにも、サービスにも存在します。ここで、データベースソフトの話をしたいのですが、そうなると、AccessかFileMakerかということになります。自分自身の問題でもあるので、馴染みの深いFileMakerを取り上げ、「カミFileMaker問題」として扱います。あえて、カタカナの「カミ」にしたのは、大昔「ファイルメーカー」と呼んでいたFileMakerへのトリビュートです。FileMakerのレイアウト機能は、帳票を高い自由度で作成できることから、従来の紙ベースで行われてきた業務をそのままデータベース化できる強い動機付けになっています。同じような仕様がAccessにもあることはありますが、プロの開発者からデータベース利用者までがみんなしてテーブルを定義してレイアウトをいじるというのはFileMaker市場の大きな特徴だけに、「カミFileMaker問題」が浮き彫りになると考えられます。

「カミFileMaker問題」とは？

ここで問題の定義として、紙の帳票類をそのままデータベース化してしまうことで発生する問題とします。もちろん、帳票をそのままデータベース化するだけでも、例えば、共有ができることや、印刷を省きパソコンやタブレットで閲覧することでの即時性などのメリットは発生します。最初の帳票ができたとき、「これはいい！」と誰もが思います。だけど、いくつも帳票を作るに従って問題が顕在化します。

紙が画面に変わっただけ？

帳票をデータベース化すると、どうしても従来のワークフローが結果的に踏襲されることになります。むしろ、ワークフローは出来上がっているのだから、それを電子化すればよりスムーズという、あまり根拠のない理屈を信じて突き進みます。その結果、まず、電子化されているのに「転記」という作業や、帳票の生成や破棄、あるいはステータス更新という動作に「手作業」が入ってしまいます。今までは紙だったので、それはやって当たり前でした。しかしながら、電子化するときに、そこでの自動化を深く考えなかったとしたら、同じことを端末を操作してやらないといけません。パソコンを扱うのが弱いとか、ストレスが高い人は、そこでまずはつまずくことになります。

紙にはなかったリンク情報はどうなった？

それでも仕事をみんなでがんばってこなしたとします。そして、さまざまな帳票レコードが、1つのエンティティに対して複数積み重なることにより、新たな問題が発生します。ある帳票と別の帳票が結びついている場合はよくあります。1対1や1対多ということもあるでしょうし、多対多もあります。紙で作業していると、その結びつきを人間がやっていることがあります。業務上の常識から、誰もが自動的に異なる2枚の帳票に関係がある、関係ないということを判定できるのです。この作業をパソコンの画面上で人間が行うのは非常に面倒です。紙のファイルを何冊か机に並べて対応するものを開けて突き合せるような手軽さは、今のパソコンやタブレットではまだまだ無理です。

もちろん、相手の文書IDを記録するなどすればいいのは当然ですが、気付いた時には遅かったということもあります。また、そのような「リンク」の重要性が、問題が発生しても気付かない、あるいは気付かないふりをするということあるでしょう。かくして、対応する文書の手がかりをかなり強引に引っ張り出すことになります。「同一顧客で、この帳票より前のもののうち、最新のもの」などといったリレーションシップを組むなどします。それでも、運用は可能かもしれませんが、対応が取れなくなる可能性が0ではなく、小さいながらも0%よりも大きくなります。また、業務で発生するイレギュラーなケースを忘れていると、ミスにつながります。ビジネスロジックでほぼ解決できるものでも、より単純な解決法があるのなら、単純な方が安定しているのは言うまでもありません。

矛盾する2つのフィールドの関係

さらにこんな例もあります。紙の帳票から、別の帳票に転記するとき、人間が転記するといいように解釈していたのですが、それを電子化すると、機械的に転記できないような場合が発生します。つまり、それぞれの帳票のスキーマに、論理的な不一致が発生してしまうのです。もっとも身近な例では、入力帳票が「氏名」で、それに対応する別の帳票が、姓名別々のフィールドのような場合です。こうしたスキーマの不一致は、紙の帳票をそのままデータベース化すると、気が付いたら行っていたということになります。また、転記なのか参照なのか、ここの考え所を全部転記することにしてしまったことで、かえって手作業が増えることもあります。

この問題は、突き詰めると、データベースのスキーマを検討するときに必ず必要となるその業務ドメインのモデル化が不正確なのです。フィールドとテーブルを定義すれば良いというのはFileMakerの機能のことで、設計者は他に考えないといけないことはたくさんあります。データ間の連携はもちろんだし、これについてはリレーションシップで定義することになります。しかしながら、FileMakerの機能に見えないこととして、あるデータは転記して見えるようにするのか、参照して見えるようにするのかということを考える必要があります。これは、FileMakerのテーブル設計のダイアログボックスでは明示化されていないものの、極めて重要な設計上の決まりごとになります。

データベースには、データベースに合った設計を

こうした問題は、昔からありますが、FileMakerは手軽だからこそ、陥る罠でもあるといえます。あえて、「カミFileMaker問題」として、問題を浮き彫りにすることで、より多くの方が意識できるようになればと考えました。もちろん、プロの方々もこうした失敗を重ねてきていて、いろいろなノウハウをお持ちでしょうし、長年使ってきた人も同様です。例えば、受託開発のとき、導入経験がないお客さんの要望をそのまま構築すると、「カミFileMaker問題」の宝庫です。プロや熟練者は、そこでしっかりとお客さんの要望を受け入れつつ、問題の発生を抑える手立てを考えないといけません。言われた通りにやればいいというのは間違いで、そのようなやり方を続けてきた結果使われないシステムを納品することになり、信用を落とすことになるのです。この問題を認識し、きちんと説明して方向付けをする必要があるのは、プロや熟練者の皆さんなのです。決して、素人を茶化すための問題定義ではないことは最後に強調したいと思います。

以下にまとめておきます。もちろん、みなさんの意見や表現の向上も大歓迎です。

「カミFileMaker問題」の発生

  • 帳票類をそのままFileMakerのデータベースで再現する電子化

「カミFileMaker問題」による起こりがちな結果

  • 一見すると効率化されたように見えるが、帳票作業とは異なる事務作業等が増えているなど、実は効率化されていない
  • 機械的に行えるデータの連携や解釈などが、データベースの仕様に含まれず、そうした作業も人間が行う必要がある
  • 2種類の帳票でスキーマが異なり、論理的には転記ができず、人間が解釈してつどつど修正しないといけなくなる
  • 紙が減ることの効率性だけに注目した結果、システム運用コストに気が回らず、気が付いたらかえってコスト高になってしまっていた
  • データベーススキーマの設計において正規化という点が考慮されず、データ解析に支障をきたしたり、あるいは解析自体が不可能な、品質の低いデータを蓄積してしまう。

「カミFileMaker問題」の本質

  • コンピュータ作業に最適なワークフローを検討し、転換しないために、結果的にさほどの効率化もされない
  • データ間のリンク構造を記録できないスキーマ上で、ビジネスデータが蓄積され、どうしようもなくなり、最悪はデータ活用に制限が出てきてしまう
  • データベースのスキーマを単に「紙にあった項目」のみで認識することで、ドメイン自体を表現するモデルの精度が低くなってしまう

[IM] MySQLでエンコードにはまったとき

INTER-Mediatorの話題です。こういうことがあるかどうは微妙かもしれませんが、私の郵便番号検索のサイトで、以下のような状況になりました。

  • 郵便番号検索のアプリケーション(A)はmysql_Connectで稼働している（あー、5.5ではついに書き直さないといかんなー）
  • UTF-8で動いているつもりだったが、MySQLで、エンコーディングの指定をしないままに動かしてしまっていた（これは失敗、でも、UTF-8でなんとなく動いている）
  • その上に、INTER-Mediatorで作った、書籍販売サイト(B)を動かす。これも、なんとなく動いている。郵便番号とは別のデータベースを作ったので、独立しているから問題なかった。
  • INTER-Mediatorでの郵便番号検索ページ(C)をいくつかの理由で立ち上げて、郵便番号データを読み込んでいるデータベースを利用して検索しようとしたら、文字化けた。

とまあ、要するに、2項目目が失敗なのですが、なんとなく動いているという状況下気づかなかったものの、最後の項目ではちゃんとやろうとして失敗に気づいたということです。my.cnfに、エンコードとしてUTF-8をつけると、(C)はきちんと動きました。それから、(A)もきちんと動きました。はいおしまいと思っていたら、(B)が文字化けます。つまり、(A)(B)(C)、同時に動かなくなったのです。なお、(C)の後追加した「character_set_client=utf8」が問題（かどうかも問題）のようで、これはmy.cnfから削除しました。(C)の発覚後、「character_set_server=utf8」も追加しましたが、最終的にはこれは残してあります。

結局どうしたか？　(A)は、実は、「SET NAMES utf8」というSQLコマンドを発行して、うまく動かしていたのです。つまり、これを動かさないとうまく行かない大昔の状況のまま運用していて、エンコードの指定が適切でなかったことに気づいたわけです。(A)(B)(C)全部を動かすために結局何をしたかというと、INTER-Mediatorのアプリケーションで「SET NAMES utf8」を実行するようにしました。クエリーするたびにまず、このコマンドを実施して、SELECTを出すようにしました。これも、定義ファイルの設定でできます。こんな感じの定義ファイルです。scriptというキーワードは、FileMakerではよく使いますが、すべてのデータベースで利用可能です。

IM_Entry(
    array(
        array(
            'name' => 'postalcode',
            'view' => 'pcode',
            'records' => 50,
            'maxrecords' => 50,
            'paging' => true,
            'script' => array(
                array(
                    "db-operation"=>"load",
                    "situation"=>"pre",
                    "definition"=>"SET NAMES utf8"
                ),
            ),
        ),
    ),
    null,
    array('db-class' => 'PDO'),
    false
);

そういうことで、あっさりトラブル解決できました。まあ、でも、郵便番号サイトは、今シーズン終わったら、PHP 5.5か5.6で動くように、全面改修だな。

FileMaker 13で、XMLおよびXSLTによる出力

久しぶりにタイトルのような事をやりました。この記事のハイライトは、変数でXSLTファイルの位置を指定できるようになったものの、エラーが出るという事象に遭遇しますが、その対処方法が分かったということです。

XML出力は、FileMaker 5くらいからありますし、出力するXMLデータにXSLTを適用して、テキストやらHTMLやらを生成することができるので、ちまちまと文字列処理を書かなくてもいいので便利です。XSLTの習得が大変という話もありますが、今時この種の情報は「基本知識」でしょうから、勉強すればいいのです。私自身は幸いにも、今はなくなってしまったXSLTでのWeb公開の時代に、かなり勉強していたし実稼働させたソリューションもあったので、自分的にはXSLTはOKです。この記事では、XMLやXSLTあるいはそれらを利用するFileMakerの機能については詳細には説明しませんので、必要な方は予習をしてください。

現実にXML/XSLTを使うとき、当然ながらXMLはテーブルを出力するときのフォーマットなので、テーブルから生成されることになります。一方、XSLTはどうでしょうか？　確実は方法は、Webサーバ等に配置して、URLで指定することですが、データベースファイルと別の管理対象ができて不便です。そこで、XSLTのテキスト自体をテーブルのフィールドにテキストとして保存しておくことで、データベースと一体化して管理ができて便利です。ただし、そのXSLTのテキストを利用するときにはファイルにしなければなりません。現実にはスクリプトを組むとして、1フィールド、1レコードだけのタブ区切りで出力すれば、余計な “” などは含まれません。ただし、その1フィールドに、改行が入っていると、コード番号12のものに置き換えられます。後から変更するのは面倒なので、XSLTのテキストから改行を除去する計算式を設定した計算フィールドをエクスポートすればいいのです。もちろん、XSLT内では改行の有無で動作が変わらないにしなければなりません。

さて、そこで、このXSLTファイルをどこに保存するのかということですが、WindowsでもMacで稼働できるようするには、テンポラリフォルダがいいのではないでしょうかということで、次のようなスクリプトで変数にパスを入れることにしました。順当な方法かと思います。

スクリーンショット 2014-06-26 10.47.20

この変数$templateJの結果を利用して、XSLTのテキストをエクスポートします。前に説明したように、スクリプトで、1レコードのみを対象レコードとして、改行を省いたテキストのフィールドだけをタブ区切りで出力します。出力ファイルに、変数$templateJを指定します。

ここで、XSLTによる変換をスクリプトのどこかで組み込むとします。スクリプトステップの「レコードのエクスポート」で、「出力ファイルの指定」を行い、OKボタンを押すと、ファイルタイプが「XML」の場合はさらに次のダイアログボックスが表示されます。ここで「XSLスタイルシートを使用」を選択し、ファイルを指定するわけですが、「ファイル」だとダイアログボックスが出て来て、特定のファイルの指定が必要です。Get ( テンポラリパス ) は一定のパスではない模様ですし、Win/Macでパスは違います。なので、「計算」を選択して、前の変数$templateJを指定して、実際に動かしてみます。ボタンと計算式の文字列が重なっているところにFileMaker社のこの機能への姿勢が見て取れます。

スクリーンショット 2014-06-26 10.46.40

すると、XMLのエクスポートをするときに、次のようなエラーが出ます。SAX（XMLのパーサ）のエラーがそのまま見えていて意味が分かりにくいですが、ようするにファイルが見つからないということです。Windowsでは、実際に見つからなかったパスも見えています。

スクリーンショット 2014-06-26 10.49.33

変数$templateJで出力し、その直後に変数$templateJでファイル参照して見つからない。ようするにバグなのですが、バグで使えません、以上ということでは前に進みません。バグは直らない可能性もあるからです。

そこで、変数$templateJの内容を、MacとWindowsで調べ見ました。Macだと、「/Macintosh HD/var/tmp/….」みたいになっています。Windowsだと、「/C:/Users/msyk/….」となっています。まず、Macは、明らかにパスの最初のコンポーネントを取り去れば、存在可能なUNIXパスになります。Windowsは…ともかく、まず、XSLTのテキストをエクスポートした後、以下のような「変数を設定」スクリプトステップを追加して、最初のコンポーネントを省いてみました。

スクリーンショット 2014-06-26 10.46.58

Macでは、予想通り、それでエラーなく動きました。一方、Windowsは別の対策をしないといけないかと思ったのですが、なんと、ちゃんと動きました。UNIXみたいなパスの与え方でどうやら動くようです。

XSLTのTipsを少し書いておきましょう。関連レコードのフィールドは、TOさえあれば出力できると思っていたら、ポータルに展開しないと出力されません。ポータルがない場合は、ちゃんと警告メッセージを出して、最初のレコードの値だけが出力されると言われます。ということで、ポータル作成はさぼれません。

関連レコードのデータは、たとえば2つのフィールドがあるとして、関連レコードが3つあると、次のように出力します。このノードの上位ノードのタグはROWになります。

<COL><DATA>1</DATA><DATA>2</DATA><DATA>3</DATA></COL>
<COL><DATA>abc</DATA><DATA>def</DATA><DATA>ghi</DATA></COL>

上記の2つのフィールドの番号を1、2とします。ROWタグがカレントノードのとき、上記のデータを展開するのにfor-eachを使うのですが、同じポータルにある関連レコードがいくつかるとき、for-eachをそのうち1つのフィールドに対して行います。次のような感じです。ネームスペースの略号は、xsl、fmrとしています。

<xsl:for-each select="fmr:COL[1]/fmr:DATA">
    <div>
        <xsl:value-of select="." />
        <xsl:value-of select="../../fmr:COL[2]/fmr:DATA[position()]" />
    </div>
</xsl:for-each>

最初のfor-eachは普通にDATAタグが複数あるので、それを1つ1つ取り出します。3行目の「.」によって、1つ目のフィールドの現在のDATAのテキストを取り出すので、「1」「2」「3」という値が順次取り出されます。2つ目のフィールドは、4行目にあるように、XPATHの記述で、カレントノードからROWまで「../..」でさかのぼり、そこから、COL、DATA集合へと下ります。そして「position()」というのは関数です。for-eachでループしているときに、何番目なのかを示す値を返します。これで、「abc」「def」「ghi」という文字列が順次得られます。

最後に大サービスで（笑）、FileMakerのXML出力向け（ただし、FMRXMLRESULTスキーマ）の汎用的なテンプレートを書いておきましょう。コピペして、あとはデータの順序に合わせてFMPXMLRESULTやROWタグ要素に対応するテンプレートにHTML等で出力テンプレートを書くだけです。

<?xml version="1.0" encoding="UTF-8"?>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
 　　　xmlns:xhtml="http://www.w3.org/1999/xhtml"
 　　　xmlns:fmr="http://www.filemaker.com/fmpxmlresult"
 　　　exclude-result-prefixes="xhtml fmr">
<xsl:output encoding="UTF-8" method="xml" indent="yes"
　　 omit-xml-declaration="yes"/>

<xsl:template match="fmr:ERRORCODE | fmr:PRODUCT | fmr:METADATA">
</xsl:template>

<xsl:template match="fmr:FMPXMLRESULT">
    <html><body><table>
       <tr><th>Name</th><th>Activity</th></tr>
       <xsl:apply-templates />
    </table></body></html>
</xsl:template>

<xsl:template match="fmr:ROW">
    <tr>
        <td><xsl:value-of select="fmr:COL[3]/fmr:DATA[position()]" /></td>
        <td>
            <table>
                <xsl:for-each select="fmr:COL[1]/fmr:DATA">
                   <tr>
                       <td><xsl:value-of select="." /></td>
                       <td><xsl:value-of select="../../fmr:COL[2]/fmr:DATA[position()]" /></td>
                   </tr>
                </xsl:for-each>
             </table>
         </td>
    </tr>
</xsl:template>

FileMaker Server 13トラブル対策メモ

Mac OS X Mavericks+Server v3上で稼働させているFileMaker Server 13が、再起動後ちゃんと動かなくなりました。トラブル対策をして動くようになったので、「今度また再起動したとき」に慌てないように、メモっておきます。

そもそも、あるデータベースに対して、スケジュールでスクリプトを動かそうとしたのでした。そうしたら、正しいアカウントで認証しても実行できるスクリプトがないと言われました。そんなはずはありません。他のパネルを見てみると、公開しているデータベースの一覧には何も出ていないのに、FileMaker Proからはデータベースを開くことができます。つまり、一覧がおかしいということでしょうか。ここで、Admin-Console再起動をするか、サーバの再起動をするか、非常に迷ったのですが、いろいろあってサーバの再起動をしました。正確には、30分待っても落ちなかったのでディスクアクセスをしていないタイミングでリセットしました。

その後、起動はして、FileMaker Proからのデータベース接続はできましたが、Admin-Consoleは開かず（ログインパネルすら出ない）、そしてWeb公開も失敗しています。Webサーバのデーモンhttpdが1つも上がっていない。

まず、やってみたのは、以下のコマンドの入力です。Admin-Consoleにログイン可能な管理アカウントは、ユーザ名がadmin、パスワードはpassword（もちろん架空のもの）です。まず、ここまでで、Admin-Consoleは接続できるようになりました。

fmsadmin stop adminserver -u admin -p password
fmsadmin start adminserver -u admin -p password
fmsadmin stop wpe -u admin -p password
fmsadmin start wpe -u admin -p password

しかし、まだ、Webサーバがこれでも動きません。次に行ったのは、次のようなコマンドです。

cd /Library/FileMaker\ Server/HTTPServer/
sudo touch stop
sudo touch start

つまり、FileMaker ServerのディレクトリにあるHTTPServerというディレクトリの中のstopおよびstartというファイルの更新日時を現在にします。別の記事で紹介した通り、このファイルが変更されると、FileMaker ServerのWebサーバが停止あるいは開始します。ここまでやると、実際にWebサーバが動き出しました。

fmsadminによるwpeサービスのstart/stopは不要なのかもしれませんが、Webサーバのデーモンhttpdを強制的に動かさないといけないのかもしれません。

FileMaker Server 13とOS X ServerのWeb

FileMaker Server 13と、OS X ServerのWebサービスの共存は基本的にはできません。となると、OS X ServerのWikiとかはあきらめるか、設定ファイルをあれこれということになりますが、ともかくいったんあきらめてFMS13を入れるといういう場合、80番と443番ポートが使われているのでインストールができないというメッセージに出くわします。

Webサービスを止めても、Wikiを止めてもまだそのメッセージが出ます。コマンドで落としてインストールしていたりしましたが、再起動したらやっぱりFMS側がだめになってどうしようもありません。徹底究明した結果、なんと、WebDAVが動いていました。ファイル共有でWebDAVを利用すると、Webサービスがオフでも、80番ポートを使ったhttpdが動いています。

では、WebDAVを全部オフにして再起動してみます。それでも、httpdは動いています。どうやら一度オンにすると、テコでも動くようです。そこで、すべての共有ポイントでWebDAVがオフになっていることを確認して、以下のコマンドを入れれば、おそらくすべてのプロセスが止まります。念のため再起動してもhttpdが動かないことも確認します。

sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist

httpdが動いているかどうかを確認するには、以下のコマンドを入れてください。このコマンドで80番や443番ポートをLISTENしているプロセスが見えるはずです。このコマンドで何も出てこなくなれば、OS X ServerのHTTPDのサービスはすべて止まった事になります。

sudo lsof -i | grep httpd

こうしてFMSをセットアップしますが、Web関連のフォルダが大きく変わります。/Library/FileMaker Server/HTTPServer以下に必要なファイルがあります。Webの公開フォルダはHTTPServer/htdocsにあります。ここにファイルを起きますが、httpdプロセスはfmserverアカウントで稼働していることに注意が必要です。_wwwではありません。

設定ファイルは、HTTPServer/conf/httpd.confがまず読み込まれます。設定を変更するには、まずこのファイルから確認しましょう。OS X Serverのよう「全部バーチャルホスト」的な設定ではなく、デフォルトのドキュメントエリアを使います。以下はその設定例です、ほとんど自分のメモみたいなもんです（笑）。赤字は追加記述です。.htaccess等を稼働させるには、AllowOverrideの指定が必要です。PHPはすでに動いていますが、既定のファイルはindex.htmlだけです。なので、DirectoryIndexの指定も行います。もちろん、必要に応じて設定は加えます。

<Directory "${HTTP_ROOT}/htdocs">
     Options All -Indexes -ExecCGI -Includes
     AllowOverride All
     Order allow,deny
     Allow from all
 </Directory>

DirectoryIndex index.php index.html

ここで、設定ファイルを変更したらapachectl gracefulと思いたいところですが、普通にこのコマンドを入れても、OS X ServerのApacheの状況を変えようとするだけで、FMSが起動しているhttpdには適用されません。FMSのhttpdのスタート、ストップ、そして設定の反映は、次のようなコマンドを打ち込みます。

sudo touch /Library/FileMaker\ Server/HTTPServer/start
sudo touch /Library/FileMaker\ Server/HTTPServer/stop
sudo touch /Library/FileMaker\ Server/HTTPServer/graceful

もちろん、フルパスでなくてもかまいません。これらのファイルの修正日を更新するのです。こうすると、/S/L/LaunchDaemonsにあるcom.filemaker.[start|stop|graceful].plistによるファイル修正の監視が行われていて、FMSのhttpdデーモンの処理を行います。これらのlaunchdファイルを見れば分かりますが、/Library/FileMaker Server/HTTPServer/bin/httpdctlというコマンドが用意されていて、このコマンドを経由して、httpdをコントロールするようです。

そういうわけで、設定ファイルを変えてはsudo touch gracefulとやればいいということです。日曜日はOS X ServerとFileMaker Serverのメンテで終わってしまった…。

FileMaker Server 13の管理コンソールが別のコンピュータから接続できない理由

*** 内容が少し違っていたので、修正しました。2013/20/50 ***

FileMaker Server 13になって、管理コンソールが純粋なWebアプリになり、クライアント側ではJavaのバージョンなどは気にしなくてもいいようになりました。これは非常に便利です。サーバ側はTomcatなので相変わらずJavaですが、そちらは管理された環境なので、利用者はJavaのバージョン等は気にしなくていいようになりました。

一方、FMS13では、16000ポートがHTTPSで、16001ポートがHTTPでの接続ができるようになっています。管理コンソールへの接続条件は、インストールしたサーバでは「https://localhost:16000」「http://localhost:16001」で接続ができます。FMS12のときと、HTTPSとHTTPが入れ替わっています。また、他のコンピュータから「https://ホスト名:16000」での接続は可能ですが、「http://ホスト名:16001」の接続はできません。

なぜか？　パケットをキャプチャしてみました。コンソールへのログインをするときに、クライアントからサーバへのリクエストをダンプしてみました。以下の最初の数行の固まりはヘッダです（クッキーは省略しています）。そして、行をあけて1行だけあるのがボディです。

POST /admin-console/APP/connector/3/304/login HTTP/1.1
Host: homeserver.msyk.net:16001
Connection: keep-alive
Content-Length: 29
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://homeserver.msyk.net:16001
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://homeserver.msyk.net:16001/admin-console/APP/connector/3/304/login
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ja,en-US;q=0.8,en;q=0.6
Cookie: JSESSIONID=6706...888

username=admin&password=abcdef

わお！ユーザ名とパスワードがそのまま流れています（もちろんabcedfは置き換えてあり、abcdefの代わりに本物のパスワードが見えました）。ハッシュですらありません！　つまり、localhostからの接続でないと、通信経路上での盗聴で簡単にログインのアカウントとパスワードを取り出せてしまうのです。サーバのコンピュータからしかログインできなくなっているのはそのためでしょう。同一コンピュータ内なら、パスワードをそのまま流しても、問題になることはないと言えます。しかし、他のコンピュータから接続するという状況では明らかに問題です。すなわち絶対に通信そのものを暗号化しないと危険なので、HTTPSでの接続しかできなくなっています。

それでも、どうしても、他のコンピュータから16001ポートを使って管理コンソールに接続したいという方は、以下のファイルを修正してください。OS Xでは必要に応じてsudoで作業をしましょう。Windowsは、多分、「FileMaker Server」がProgram Filesにあると思うので、それ以下は同じと思います。

/Library/FileMaker Server/Admin/admin-master-tomcat/conf/server.xml

このファイルの最初に以下の部分があります。開いて「16001」を検索します。このポート番号はここだけです。最後の方の下線、赤字の部分を削除してファイルを保存してください。

<Connector port="16001" protocol="HTTP/1.1" maxHttpHeaderSize="8192" maxThreads="150"
 minSpareThreads="5" maxSpareThreads="75" enableLookups="false"
 redirectPort="8443" acceptCount="100" connectionTimeout="20000"
 disableUploadTimeout="true" address="127.0.0.1" URIEncoding="UTF-8"/>

この後、サーバの再起動をしますが、管理コンソール自体を再起動させます。うまく行かない場合にはコンピュータの再起動を行いましょう。そうすれば「http://ホスト名:16001」で管理コンソールに接続できます。ホスト名はIPアドレスでももちろんかまいません。

くれぐれも、この状態で、インターネット経由での接続は細心の注意を払ってください。パスワードがバレない限りは他人にアクセスはできませんが、現状では容易にバレてしまうような通信方法です。安心な方法は、FMS13を稼働させているコンピュータにVPNで接続することですが、一手間増えるならVNCでサーバにログインしてページを開くのとあまり変わらないですよね。したがって、こうした変更はしないで、現状通り使うのが安全です。あるいは、自己署名証明書である点が微妙ですが、16000ポートで接続しましょう。いくら暗号化されているとは言え改善を期待したいですが、次のバージョン以降なのでしょうか。

FileMaker Server 13の「デーモングループ」とは何か？

FileMaker Server 13のインストーラで次の図のような画面が出てきます。FileMaker Server 12までは、fmserverという決められたユーザでしか稼働できなかったのですが、任意のユーザでの実行が可能になったのです。

shot0050

つまり、今ログインしているユーザで稼働させることができるのです。そうなると、FileMaker Server内のフォルダやファイルが、ログインしているユーザが所有者となるため、削除や名前の変更をアクセス権のことを気にしないでできるようになります。自分のMacにFileMaker Serverを入れて開発をしている人に取っては一手間、二手間が減るということになります。以下の図は、私のmsykのアカウントでインストールした結果です。Web用のファイルのフォルダやデータベースのフォルダの所有者がmsykとなり、ログインしている私msykに読み書き権限があります。

shot0052

このように、fmserverアカウント以外での運用をするには、インストーラでインストールするときに指定をします。しかしながら、ログインをしているユーザを単に指定すると次の図のようなシートの警告が出て来て、インストールができません。

shot0051

デーモングループ？　なんでしょうか？　これ、日本語にすると意味が分からないのですが、OS Xにはdaemonという名前のグループアカウントがあり、そのグループに所属しているユーザでないと、指定ができないですよということです。なので「daemonグループ」と翻訳しないで書かないと意味は通りません。既定値ではdaemonグループには、rootユーザしか登録されていませんが、ここでは私のアカウントmsykを登録しておく必要があります。しかしながら、マニュアルに具体的には書かれていません。システム環境設定ではできません。

では、どうすればいいでしょうか？　以下のように、ターミナルでコマンドをたたいてください。どうしてもGUIで作業したいという方は、「ワークグループマネージャ」をダウンロードしてやれなくはないですが、手順は簡単ではありませんので、ここでは省略します。コマンドの方がはるかに簡単です、と言い切ります。msykの箇所は実際に利用するユーザ名に変えますが、あとはこのままです。2行目は追加されている事を確認するためのコマンドです。

sudo dseditgroup -o edit -a msyk -t user daemon
sudo dseditgroup -o read daemon

2つ目のコマンドでは、daemonグループに関するさまざまな情報が表示されるので、その中で、グループに含まれるユーザを示すdsAttrTypeStandard:GroupMembership以降にユーザ名が追加されているかを確認します。インストールの途中でターミナルを立ち上げて作業してもOKでした。

こんなコマンドは見た事がない？　そんな方は、こちらの書籍をお勧めします（さりげない宣伝）。アカウントについても詳しく書籍で紹介があります。

こうしてインストールすると、fmserverdなどのデーモンやWeb共有のhttpdといったプロセスは、全部msykアカウントで稼働します。セキュリティ上大丈夫なのかと気にする人もいらっしゃるかもしれませんが、FileMaker Serverに変なバグがなければ大丈夫です。Webで公開するものは気をつけた方がいいかもしれませんが、たぶん、自分で開発しているアプリを入れるのが普通なので、通常のWebとは違ってグローバルIPにさらされることはほぼないこともあり、問題になることはほとんどないと思います。もっとも、こういう仕事をしている人は「問題になる状況かどうか」を自分で判断できるものじゃないかとも言えますし、自分で回避できるだろうとも言えます。

「FileMaker® Server 13入門ガイド」のp43に次のような事が書かれています。他のページにはアカウントの事はあまりきちんと書かれていません。インストールのところでも、ここを見ろというリファレンスがあるだけです。

OS X: アカウントは OS X のローカルユーザアカウントであり、ローカルファイルへのアクセス（デーモングループのメンバーシップを含む）に関して fmserver アカウントと同一の権限を持っている必要があります。ディレクトリサービス（Active Directory または Open Directory など）に由来するアカウントは使用できません。リモートボリュームにデータベースまたはオブジェクトデータフォルダを追加して設定する場合、アカウントはこれらのリモートフォルダに対する完全なアクセス権を持っている必要があります。

例によって解釈しづらい文章です。ここで、fmserverアカウントのアクセス権をidコマンドで確認してみます。ここで、1(daemon)、および61(localaccounts)がポイントなのではないかと思います。Open Directoryのアカウントは、localaccountsグループには所属していません。ローカルに作ったアカウントだと、足りないのがdaemonグループへの所属だけなので、前記の方法でFileMaker Serverの実行アカウントとして利用できるようになります。

$ id fmserver
uid=502(fmserver) gid=499(fmsadmin) groups=499(fmsadmin),1(daemon),12(everyone),61(localaccounts),100(_lpoperator),402(com.apple.sharepoint.group.1),240(com.apple.access_loginwindow)

FileMaker Server 13はWebDirectなどいろいろ新しい機能が増えていますが、こういう地道なところでも変化がありますね。

[FMRP] 繰り返しフィールド、ポータル、ポータルフィルタ

しばらくさぼってしまっていましたが、FileMaker Relationship Patternsの続きです。

カテゴリ：1対多

名前：繰り返しフィールド

問題：

1エンティティに対して複数のエンティティが存在する場合に、複数のエンティティを一覧表示したい

解決策：

繰り返しフィールドを必要な数、つまり複数のエンティティに対応するフィールドの数だけ定義して、レイアウト上に配置する

フォース：

TO間の結合を定義するのではなく、フィールドのオプション設定として、繰り返す数の上限を1より大きな値に設定する事で、繰り返しフィールドを用意する

繰り返しフィールドで複数のレコードに対する保存は確保できるが、厳密な意味でのテーブル間結合ではなく、第一正規形も満たしていない点を考慮する必要がある

複数エンティティを起点としたリレーションシップは確保できず、集計処理などができない。たとえば、伝票で明細を繰り返しフィールドで作れば「伝票」という帳票は作成できるが、明細行のレコードに関して商品ごとの売り上げ集計はできなくなる。

繰り返し数の上限は、データベースの定義で決める必要がある。繰り返し数が後から足りなくなった場合に増やす事もできるが、データベースの設計変更を伴う

繰り返しフィールドはスクロールができないため、レコード数が多数になると、レイアウトの広い範囲を繰り返しフィールドが占めてしまい、使い勝手が悪いレイアウトができてしまう

関連パターン：

ポータル

カテゴリ：1対多

名前：ポータル

問題：

1エンティティに対して複数のエンティティが存在する場合に、複数のエンティティを一覧表示したい

解決策：

レイアウト上にポータルを配置して、レイアウトのTOとリレーションシップでつながっている別のTOを割り当てる。これにより、レイアウトのTOのレコードと対応関係にあるポータルのTOのレコードが、ポータルに一覧される

フォース：

典型的な1対多の展開である。リレーションで直接つながっているTOだけでなく、複数のTOを経由した先のTOでもポータルには配置できる。

ポータルの中にポータルは配置できない。ポータルの中では1対1のリレーションシップの先の単一のフィールドしか配置できない。

関連パターン：

ポータルフィルタ、繰り返しフィールド

カテゴリ：1対多

名前：ポータルフィルタ

問題：

ポータルに表示するレコードを条件に応じて制限したいが、制約をリレーションシップで定義したくない

解決策：

ポータルフィルタの設定を行う

フォース：

FileMakerのリレーションシップの制約の1つは、複数のTOが存在するTOGにおいて、すでに2つ先になっているTOと直接結合することができないことである。つまり、条件の設定をSQLのように柔軟にできないため、リレーションシップだけで必要なレコードに絞り込むことが困難な場合も出てくる。ポータルフィルタは単にレコードに式をあてはめて、表示するかどうかを判定するだけである。ただし、式に使えるフィールドはリレーションシップに影響する可能性が発生するが、1つの解決方法はグローバルフィールドを用いて条件を与え、式で判定させるということができる点がある。従って、レイアウトに表示するという状況では、リレーション以外に制約を与える方法が存在するため、すべてをリレーションで解決する必要はない。

フィルタにより一部のレコードだけが表示されるが、フィルタの式の結果がすべてtrueつまり、フィルタ前のすべてのレコードを一度は読み込むため、レイアウトを表示した最初のときに非常に時間がかかるケースも発生する。FIleMaker 12の段階では、サーバサイドでフィルタを適用しているのではなく、クライアントサイドで適用していることが原因と考えられる。

関連パターン：

ポータル

7つのデータベース7つの世界

「7つのデータベース7つの世界」という書籍の書評を書こう（久しぶりに書評を書くぞ）。「7つの言語…」が有名な米国のPragmatic Bookshelfから出版された翻訳本であり、この書籍についてはオーム社から発売された。原書は手にしていないので、翻訳本についての紹介になる。

本書で紹介しているのは、PostgreSQL、Riak、HBase、MongoDB、CouchDB、Neo4J、Redisとちょうど7つだ。まず、このチョイスにMySQLがないことがポイントだ。データベースと言えばRDBという時代が長く続いたがここ数年来NoSQL（Not-only SQL）がブームになっている。とは言え、RDBやSQLがなくなるわけではなく、データベースにも適材適所の時代が来たということである。NoSQLにもいろいろなタイプがあり、キーバリュー、列指向、ドキュメント指向、グラフ指向から代表的なものを選択して紹介しているわけである。

1つのDBあたり、30〜40ページというところで、すべてを知るための書籍ではない。これは「7つの…」シリーズで踏襲されている「その世界をツアーしガイドする」というコンセプトによる。DBの概要となると、言語とは少し違う。本書では基本的なデータの扱いの概念と、そのDBを使ったおいしい事例というところにフォーカスされている。詳細や他の世界との接点については「宿題」として自分で考えましょうというスタンスだ。たとえば、MongoDBではMapReduceの事例をしっかりと紹介しているが、ショートカットや正規表現については宿題として自分で調べることになっている。

NoSQLは何だと言われても、うまく答えは見つからないが、本書はNoSQLの世界への非常に巧みなガイダンスとなっている。DBは何と言っても基本的なデータの扱いという絶対にはずせない情報があり、そこはどのDBについても実践的な解説でうまく体験できるような説明となっている。それぞれのDBについての最初の解説を読むだけでも、DBのコアな仕組みが見えてくる。NoSQLに興味がある人は、まず最初に手に取って読んでみることを勧めたい。

ここからは余談…コンピュータ書籍はオライリーの独断場のような様相であると言い切るとして、その中で、Pragmatic Bookshelfの企画力には注目していた。オライリーはユニークな企画ものもあるけど、やはり「Perl」とか「SSH」といった直球勝負な書籍が中心だ。そのオライリーにもっと早い重い直球で勝負するぞと意気込んだところでなかなか勝てない。しかし、Pragmaticはある意味オライリーがだしそうにない書籍という点で注目できるのである。個人的には「SQL Antipatterns」のファンでもある。そのSQL Antipatternsは、日本ではオライリーから出た。え？なんで？と思って調べたら、Pragmatic Bookshelfの書籍のディストリビューション（意味的には販売会社だろう）はオライリーだったのである。やっぱりオライリーの独断場なのだろうか。

余談は続くが、Pragmaticの書籍をアメリカのアマゾンから買って読んでいた頃、ふと、電子版は割引と書いてある。紙の書籍を持っていないと買えない仕組みである。その絶妙な価格付けで、思わず電子版を買ってしまった。書籍の4分の1ほどの値段で電子版が購入でき、しかも改訂があれば最新版が手に入る。紙の書籍を買って、必要なら電子版を買い、読んだら紙の書籍は古書流通に流す…。これだと、自炊もしなくてもいいし、軽いPDFやePubファイルが手に入る。中身の翻訳はもちろん歓迎されることだが、こうした仕組みも含めて出版社にはローカライズして欲しいところだ。