
今回の Community Live は、Claris FileMaker の最近の機能追加の中でもっとも使い出がありそうな「FileMaker Data API を実行」スクリプトステップを掘り下げる Webinar です。
去年秋のユーザアンケートでは、ダントツでもっとも興味がある新機能だったそう。
講師を務めるのは、Cross I.T. Services and Solutions の Todd さん。3月の Claris Engage で、同内容のセッション(3/26 Wed 9:00am~ @Sculpture Falls)を予定しており、今回の内容はその Sneak Peek (本公開前のちら見せ) となっています。
Claris Community 内に今回の Webinar の告知ページがあり、参考情報へのリンクも多く掲載されています。
ライブ配信のアーカイブ: https://www.youtube.com/watch?v=D-iaBlgfJWo
Claris Community 内の Webinar 告知ページ: https://community.claris.com/en/s/question/0D5Vy00000YThWLKA1/february-20-2025-community-live-unlock-the-execute-filemaker-data-api-script-step
これは一体何?
「FileMaker Data API を実行」スクリプトステップは、FileMaker 17 で FileMaker Server の REST API として提供された機能が、ベースとなっています。
この API の機能が、FileMaker 19 でスクリプトステップとして提供されました。
スクリプトステップになったことで、ホストされていないファイルでも実行が可能になりました。しかしその当時は、read アクション(データの取得)のみへの対応にとどまっていました。
FileMaker 2024 (ver. 21)で、データ操作系のアクション ( create, update, delete, duplicate ) にも対応し、REST API と同等の機能を持つようになりました。
どんなことができるの?
レイアウトを指定することで、そこに紐づいたデータを、リレーション先のテーブルも含めて、構造化された形で、一回の問い合わせで取得することができる、使いこなせばとても便利な機能です。
Todd さんの実際の活用例として、2つのファイルが紹介されました。
一つは発注システムで、同内容の発注を自動で作成するときに、レコード複製ではなく、「FileMaker Data API を実行」スクリプトステップを使っています。

明細行を子として持つ発注レコードの画面でスクリプトを実行すると、

必要なフィールドだけを転記した新規レコードが作成され、その後ほかのフィールドに手で入力してレコードを確定します。
「レコード複製」ステップでは、レコードの作成と同時にすべてのフィールドが複製されてしまうのと、子レコードの作成には対応していないという点で、そのままでは使えない場合があります。そのような場合に「FileMaker Data API を実行」ステップを使うことで、必要なフィールドを選択して複製するためのデータを、子レコードも含めて、比較的簡単に準備することができるようになります。
もう一つは、script log というファイル。サーバー上で実行されたスクリプトのデバッグなどを行なうときに、現在のコンテキストに依存せずどこからでも実行できるという利点を活かして、「FileMaker Data API を実行」ステップを使って、スクリプトの実行結果をログテーブルにレコードとして記録するしくみを作成します。
– FileMaker Pro からでも簡単にスクリプトのデバッグが可能になります。
– サブスクリプトとして、既存のスクリプトに簡単に組み込めて汎用的に利用できます。

サーバー上で実行されたスクリプトの内容や結果を詳細に記録するためのモジュール
まず見るべき場所
このスクリプトステップを正しく理解するためにまず参照すべきは、もちろん公式のヘルプです。
また、JSON キーの詳細については、以下も合わせて参照する必要があります。
[FileMaker Data API を実行]スクリプトステップのヘルプ
: https://help.claris.com/ja/pro-help/content/execute-filemaker-data-api.htmlClaris FileMaker Data API ガイド
: https://help.claris.com/ja/data-api-guide/content/index.html
サーバーの REST API との比較

共通点
レスポンスで返される JSON の形式は同じ
違い
・ホストされていないファイルでも実行可
・Web サービスの呼び出しの仕組みを使わない
・fmrest を有効にする必要がない
・リクエストの形式が JSON オブジェクト。エンドポイント URL、メソッド、cURL オプションで指定するヘッダ情報などは不要
使い方
・リクエストもレスポンスも JSON
・スクリプトステップで指定する引数は、内容全体を選択(チェックボックス)、ターゲット、リクエスト の3つ
・基本的にレイアウトに紐づく(一部 metaData 関連のアクションは TO に紐づく)
・現在のコンテキストには縛られない(どこから呼び出しても OK)
・後のトラブルを避けるため、レイアウトは専用のものを用意し、’API_’ などの接頭辞を付ける(REST API と共用する場合は、URL に含まれることを考慮しスペースなども避ける)
・リクエスト JSON のキーの一つである version について、特に v1 と v2 の違いについて説明がありました。v1 では、レイアウトがフォーム形式か表形式かによって、ポータルの複数のデータを返すか、最初の1レコードのみを返すか、の違いがあるとのこと。対して、v2 では常にフォーム形式ですべてを返します。
操作例
後半は、具体的にデータを操作するようすが示されました。
metaData 4種、read、データ操作系 4種について、それぞれリクエスト JSON、それを作る計算式、結果として返されるレスポンスJSONを確認することができました。
metaData 系


read アクション


データ操作系 (create, update, delete, duplicate) のアクション


データ操作系のアクションでは、リクエスト JSON が複雑な構造になり、レスポンスは基本的に成功か失敗かを示す単純なものになります。
失敗の場合のレスポンス JSON の例

Q&A
その他、参加者から以下のような質問がありました。
・サーバー上実行でも、create, update, delete, duplicate は可能か?
→ 可能。ただし、(REST API と比較して)同時にスクリプト実行はできないので、別のステップとして指定する必要がある。
・ExecuteSQL と比較して速度は?
→ 遅い。しかし、プログラミング全体のコストを比較して、どちらを選択するのかを考慮するべき、とのこと。
・指定するレイアウトには、フィールドを配置する必要があるか?
→ read にはフィールドが必要。ソート指定のフィールドは不要。create, update などのデータ操作系にはフィールドは不要。
・元データか、レイアウト上でフォーマットされたデータのどちらが返されるか?
→ 元データ。
・ポータルのソートやフィルタは、レスポンスデータに反映されるか?
→ 反映される。
Q&A の中で、サンプルファイルは入手可能かという質問もありましたが、Claris Engage のセッションで使われるため、セッション終了後に入手可能になる予定、とのことでした。