by nomfjmt

FileMaker Data APIのトランザクション対応

前回に引き続き、今回はFileMaker 17で正式版になったData APIのトランザクションに関するBeezwaxの記事を紹介します。

beezwax

How Transactional is the FileMaker Data API?

(元記事はこちら)

Vincenzo Menanno
2018/6/1

FileMakerプラットフォームに新しい機能が追加されるたびに、私はいつもワクワクします。単に新機能が興味深いだけでなく、プラットフォーム全体に起こる変化によって、アイデアを呼び起こす革新が生まれます。今回で言えば、FileMakerでトランザクションを使ったレコード編集を行うための新しい方法です。今回はこのトピックに関する複数回シリーズの第1回です。

データAPIとトランザクションのデモファイル
デモファイル(ページ下部のリンク)をダウンロードしてから、記事を読み進めてください。

では始めましょう。

FileMakerバージョン7.0より前の時代

以前は、フィールドにカーソルを入れるとすぐにレコードの占有者になりました。もしあなたがカーソルをフィールドに入れたままでランチに行ったなら、あなたはすぐに注目の人になったでしょう。ランチから戻ったとき、あなたは周りのジロジロ見る目に気づきます。それはあなたがそのレコードをロックしていて、長いゆっくりとした昼休みから戻ってくるまで、他の誰もそのレコードを変更することができなかったからです。

早送りして、現在

FileMaker v7.0以降、カーソルをフィールドに入れるだけでレコードがロックされることはなくなりました。レコードをロックするには、実際にレコードの編集を始めなければなりません。しかしロックされることに違いはありません。名前のスペルを調べるためにあるレコードで画面を凝視するとき、貴重なミリ秒の間、そのレコードがロックされたままになります。下のスクリーンショットでは、”U2 Tour”のレコードをロックしているだけでなく、ユーザがすべてのタスクレコードを変更できないようになっています。

1つのフィールドを介してレコード全体をロックする

そのため、Enterキーを押すかフィールドの外側をクリックして変更を確定してレコードのロックを解除するように、ユーザを教育するようになりました。編集が終わったらFileMakerがどのようにデータを保存するのか、ユーザはすぐに学習します。これはFileMakerを使い始めてすぐ、[保存]メニューがないのを見て、最初に学ぶことです。

悲観的レコードロック

ユーザに対してこのようにレコードをロックするモデルは、 悲観的レコードロックと呼ばれます。これがFileMakerが何年も前から採用している方式です。

しかし、 FileMaker Data APIという新技術が導入されました 。レコードロックに関する従来のルールの多くに従う一方で、これは新しく「若い」ので、若い人の特性として楽観的な傾向があります。

楽観的レコードロック

FileMaker Data APIは、FileMaker 17プラットフォームで正式にリリースされました。正式版となり価格体系がフィックスされた今、Data APIは本格的に使われ始め、いくつかのとても創造的なユースケースが出始めています。

Data APIがトランザクション処理に対応していることは、おそらく一部の人にとってはそれほど驚くことではないでしょう。しかし私にとっては驚きでした。理由は、それが楽観的レコードロックモデルで動作するからです。これは、送信されたデータ(JSON)のすべてのレコードが更新されるということを意味します。関連レコードのいずれかが空であるか、他のユーザによって使用されている場合、何も更新されません。すべてが更新されるか、何も更新されないか、のいずれかです。

Darren Burgessと私は、APIのトランザクションの特性をいろいろ試し、この機能を実際に見えるようにするためにData API Transactionデモファイル (アカウント名: admin; パスワード: admin)を作成しました。ファイルをダウンロードして、FileMaker Server 17にアップロードし公開してください。Data APIの入門書が必要な場合は、Using Rest and cURL with FileMaker 17’s Data APIを参照してください。こちらにも素晴らしいデモファイルが含まれています。

以下がData API Transactionデモのリレーションシップグラフです。PROJECTとTASKだけの非常にシンプルな例です。

関係グラフ上のプロジェクトとタスク

トランザクションによるデータ作成

PROJECTレコードを、関連の子レコードと一緒に作成したい場合、JSONの形式が有効で、レコードを作成できるアクセス権があれば、準備は完了です。正しいJSONデータを送信すると、親レコードと子レコードがすべて1ステップで作成されます。以下は、1つの親レコードとすべての関連レコードを、Data APIを使用して作成するのに必要なJSONの例です。

{
  "fieldData": {
    "PROJECT": "U2",
    "ROAD_MANAGER": "Tony Menanno"
  },
  "portalData": {
    "road_manager_tasks": [
      { "TASK::DATE": "5/26/2018", "TASK::DESCRIPTION": "Review Contract" },
      { "TASK::DATE": "5/31/2018", "TASK::DESCRIPTION": "Plan Travel" },
      { "TASK::DATE": "6/1/2018", "TASK::DESCRIPTION": "Book Hotel" },
      { "TASK::DATE": "6/10/2018", "TASK::DESCRIPTION": "Rehearsal Schedule" }
    ]
  }
}

この親レコードと関連する子レコードのトランザクションが機能するために、[このリレーションシップを利用して、このテーブルでのレコードの作成を許可]オプションを有効にします。

関係の編集 - レコード作成を許可

これにより、 親レコードと任意の数の子レコードを1つのトランザクションでまとめて作成できます。この点はとても重要です。 たとえば、これらのレコードのいずれかに[入力値の制限]が設定されていてそれに合致しない場合、送信したデータのいずれも登録できません。すべて登録されるか、一つも登録されないかのいずれかです。

注：確かに、FileMakerでも完全に同じ機能を実現できますが、ここではData APIに焦点を当てて、それによって可能になったことと、見落としがちな相違点について見ていきます。

トランザクションによるデータ編集

次にトランザクションを使ってデータを編集する場合を見てみます。具体的には、複数の変更を加えたJSONを送信した場合、それらの変更はすべてがデータベースに反映できた場合にのみコミットされます。例えば、すべてのタスクは日付が必須入力だとしましょう。日付を削除したJSONを送信すると、登録に失敗します。あるいはこれは、JSONを組み立てる前に、ローカルで検知することもできますが、フェイルセーフとして、実際のテーブルで常に検証を行うのはいい方法です。

デモファイルではこれを実際に操作して確認することができます。[2A – Edit Record]ボタンをクリックして、ポップオーバーに表示されるJSONデータの値を変更してみます。親レコードと子レコードの値を変更してから、[Edit Record]をクリックしてください。

親レコードと子レコードがそれに応じて更新され、結果が成功であることを示すJSONオブジェクトが返されます。

{
  "messages" :
  [
    {
      "code" : "0",
      "message" : "OK"
    }
  ],
  "response" :
  {
    "modId" : "20"
  }
}

次に、子レコードの1つをロックしてみます。[1 – LOCK CHILD RECORD]ボタンをクリックしてください。これにより新しいウィンドウで複数のタスクレコードが開き、そのうちの1つのレコードの編集が開始され、子レコードがロックされます。ここで、親レコードを編集しようとするとどうなるか注目してください。Data APIへのリクエストは失敗し、結果のJSONで301エラーが返されます。データは変更されません。親レコードを削除しようとした場合も、同じことが起こります。

注: 現在はレコードを作成したり、レコードを編集する(ポータル内の関連レコードではない )場合、レイアウト上にそのフィールドを置く必要がないように見えます。関連レコードについても、ポータルにオブジェクト名をわざわざ付けるのではなく、テーブルオカレンスを指定するだけで済むのであればいいのにと思います。ですがそうでない理由もわかっているつもりです。同じポータルを複数置けるからにはそれらを区別する必要があるからです。

なぜわざわざData APIを使うのか

あなたは今こう思っているでしょう…FileMakerでネイティブにできるのに、なぜわざわざデータをパッケージ化してData APIを介して送信するのか、と。FileMakerでトランザクション処理は可能です。レコードを編集する場合も、他のユーザとデータが競合してしまうことはありません。確かにその通りです…それでも、私は状況によってはData APIを使う価値があると思っています。

私たちが取り組むプロジェクトには、世界中のどこからでもユーザがシステムにアクセスしなければならないというものがたくさんあります。そして私たちは常に可能な限りパフォーマンスの高いソリューションを構築するよう努めています。Data APIを使うことで、あなたにとっても選択肢が増えます。

もう一つの理由は、制御の一元化です。制御を一元化することによって、私たちは監査機能を活用することができます。トランザクションが成功した場合は、変更内容を確実に監査できます。念のために言っておくと、FileMaker Data APIを介したトランザクションによる編集は多くの稼働部分が絡む複雑な処理(今後の記事で取り上げる予定です)であり、従来のFileMakerの考え方とは多少異なります。そのため、複雑さを押してでも導入することに十分なメリットがあるかどうかを、ケースバイケースで評価する必要があります。

開発時の選択は常に、優雅さと複雑さの間の正しいバランスを見つけることです。このエキサイティングな発見から、ユースケースを見つけて、そこからインスピレーションを得られることを願っています。

さらに続きます

今後のブログ記事では、FileMaker Data APIを介して、トランザクションを使用してデータを編集するテクニックを詳しく説明する予定です。 エキサイティングな楽観的レコードロッキングアドベンチャーが続くのでご期待ください。

デモファイルをダウンロード (アカウント名: admin; パスワード: admin)

Leave a Reply