先回に引き続き、Geist InteractiveのJeremy Brownさんによるトランザクションについてのシリーズ記事の第3回を紹介します。
シリーズの他の記事も合わせてご参照ください。
- FileMakerのトランザクション: 自信を持ってデータを更新する
- FileMakerのトランザクション: 正しくスタートする
- ポータルを使用したFileMakerのトランザクション処理
- FileMakerのトランザクション: マジックによるプロセス
- FileMakerのトランザクション: ゲームの終盤
- FileMakerのトランザクション:レコードを編集する
THE FILEMAKER TRANSACTION PROCESS WITH PORTALS
(元記事はこちら)
Jeremy Brown
2019/5/8
トランザクション処理、その中でレコードを作成/編集/削除するプロセスは、複雑な概念のように思えるかもしれません。しかし一度考え方を理解してしまえば、それらは実際にはどちらかと言えばシンプルです。開始コンテキストから、作成したリレーションを通じて、レコードを作成/編集/削除します。今回はポータルを使ったFileMakerのトランザクション処理を見ていきます。
前回の復習
トランザクションを開始するときに設定した内容を思い出してみましょう。
- EstimateかDBTransactionsタイプのいずれかのテーブルの開始コンテキストにいるとします。以下の説明では、 Karbonまたはmodularfilemaker.comのFileMaker transactionモジュールと同じように、DBTransactionsテーブルにいるとします。
- 開始コンテキストレコードと、OrderおよびOrder Line Itemテーブルの間にはリレーションが設定されていて、「レコードの自動作成」がオンになっています。DBTransactionsレイアウトに、名前付きのポータルが設定されています。
- 以下のいずれかの方法でデータが収集されています。APIリクエストがレスポンスを返したか、EstimateとEstimate Line Itemのデータ全体をJSONオブジェクトにまとめました。あるいは、開始コンテキストをそれ自身と関連テーブルからデータを取得できる場所に設定します。
- 現在のレコードは、Start Transactionプロセスが所有して(かつ開いて)います。新しいDBTransactionsレコードを作成し、Estimateレコードとその関連レコードを開くときにエラーは発生しませんでした。
記録すべきログ情報がある場合は、ここで設定されます。 - 説明が逆になりましたが、リレーションは以下のように設定しました。トランザクションのIDをOrderテーブルとOrder Line Itemテーブルに格納します。
シンプルで複雑
その概念はシンプルでかつ複雑です。レコードは、リレーションを介して作成/編集/削除されます。これはシンプルな部分です。
1つのOrderレコードと複数のOrder Line Itemレコードをそれぞれの関連テーブルに作成し始めると、話が複雑になります。方法は2つあります。それぞれのリレーションのポータルで(今回説明します)、またはポータルなしで(はい、これも可能です。次の記事で説明予定)、です。
さあ準備が整いました。EstimateとEstimate Line ItemをOrderとOrder Line Itemにコピーします。
このセクションでは、レコードの作成について説明します。他に既存のレコードの編集と削除があります。 3つの場合で基本的な考え方は同じですが、それぞれ詳細が若干異なります。
トランザクションスクリプトは次のように続きます(または別の「Do Transaction」スクリプトが始まります)。
ステップ1: Orderレコードを作成する
トランザクション処理の最初のステップは、Orderレコードを作成することです。とても簡単です。まず’order’ポータルに移動します。ポータルの最終行に移動し、JSONオブジェクトのデータを使用してその行のデータを作成します。そして関連テーブルのフィールドにデータを設定します。
留意点
- ポータルには数個のフィールドしかありません。これらは単にレコードが正しく作成されたことを目で確認するためのものです。どのフィールドでも構いません。ポータルには1つのデータフィールドと、デバッグの目的で任意のユーティリティフィールドを配置することをお勧めします。
- ポータルの最終行にデータを設定してリレーションを作成したら、レコードの残りの部分にEstimateのJSONデータを入力できます。
- Orderレコードを作成した瞬間、そのレコードは開いています。データビューアでは、Get ( RecordOpenCount ) は2になります。つまり、DBTransactionsレコードとOrderレコードの2つです。
ステップ2: Order IDを取得する
FileMakerのトランザクション処理の目的は、Orderレコードをその関連する複数のOrder Line Itemと一緒に作成することなので、今作成したOrderレコードの主キーを取得します。いたってシンプルです。
ステップ3:Order Line Itemを作成する
次に、Order Line Itemポータルを介してOrder Line Itemレコードを作成します。すでにJSONオブジェクトとして複数のEstimate Line Itemを(LineItemsフィールドに)取り込んでいて、それを解析する準備ができています。ここでも同じ操作を行います。
- Order Line itemsポータルに移動する
- ポータルの最終行に移動する
- その行のすべてのフィールドに、1つのEstimate Line Itemから見積データを設定する
- 外部キー(ID_Order)に上で作成したOrderの主キーの値を設定する
- 配列のすべての要素からすべてのデータがOrder Line itemsテーブルに設定されるまで、このプロセスを続ける
留意点
- 各order line itemレコードが作成されると、新しいレコードが開かれます。3つのline itemレコードを作成した後、5つのレコードが開かれています。
- DBTransactionsのレコード
- Orderレコード
- 3つのOrder Line itemレコード
- 常にポータルの最後の行に移動するのは、そこがレコードを作成する場所だからです。上のOrderの作成ステップのように、レコードを1つだけ作成する場合でも、最後の行に移動するようにします。それによって処理の一貫性を保ちます。
コミットの問題
FileMakerのトランザクションプロセスがポータルを使用してオブジェクト内にレコードを作成するたびに、もう1つレコードが開きます。私はその事実をここでわざわざ強調します。レコードセット全体(OrderとすべてのOrder Line Item)が作成されるまで、これらのレコードを開いたままにしておき、コミットしたくありません。そこで、以下のようなレコードをコミットする操作を行わないようにしてください。
- 検索を実行する
- フィールドの外をクリックする
- 「レコードを確定」クリプトステップ
それでは処理を走らせます。複数レコードをメモリ内に蓄積します。そして、すべてのレコードが作成されたら、それらをまとめてコミットしトランザクションを完了します。あるいは、問題がある場合は復元(revert)して作成を取り消します。
ポータルを使用したFileMakerのトランザクション処理
技術的には、FileMakerのトランザクション処理でポータルを使用する必要はありません。少し修正を加えるだけで、ポータルなしでレコードを作成するためのすべての作業を実行できます。
しかし、ポータルは開発者がトランザクションをデバッグしてプロセスを監視するための優れた方法です。スクリプトデバッガの実行中に、レコードが作成される(しかしコミットはされていない)ところを見ることができます。
OrderとOrder Line ItemテーブルにトランザクションのIDも格納しています。それによって、トランザクションが終了した後も、作成されたレコードをトランザクションを介して引き続き表示できます。
FileMakerのトランザクション処理は、まだ続きます
次回は、ポータルなしでFileMakerのトランザクション処理がどのように行われるかについて説明します。乞うご期待。面白いですよ。