和紀Commentsこんにちは。ライジングサン・システムコンサルティングの岩佐です。おけるスクリプトの実行方法について解説していきます。シリーズの1・2・3、及び4の内容を理解している必要があります。そちらの記事をご覧いただいていない方は、こちらの記事から学習をスタートされると、スムーズに進められると思います。チュートリアル1・認証https://risingsun-system.biz/filemaker-data-api-authentication/こんにちは。ライジングサン・システムコンサルティングの岩佐です。使い方について全5回に分けてお送りします。pocketsまた、今回の学習でもPostmanを利用します。環境変数の自動更新を設定していますので、そちらも確実にできるようにしておいてください。前の記事でご案内しているサンプルソリューションも、この先実際に手を動かして学習を進めていく上で必要となります。ホストしておいてください。検索APIに合わせて実行することになります。メソッドで実行可能なスクリプトのタイミングについて確認したいと思います。上記の通り、スクリプトを実行できるタイミングは大きく3つ用意されています。そのタイミング毎に、任意のスクリプトとスクリプト引数を設定できる仕様になっています。Record(s)でのスクリプト実行は割愛しています。Record(s)のAPIでもスクリプトの実行は可能ですが、URL内部にスクリプト名やスクリプトパラメータを埋め込むことになるため、現実的にはあまり利用する機会はないと思われるからです。検索メソッドに合わせてスクリプトを実行する必要があります。これだけではどうしても実現できない機能要求が発生することも当然出てきます。関しては、レコードの処理単位が1件づつになります。API経由で複数のレコードをまとめて登録したい場合は、そのレコード件数分APIをコールするしかありません。この方法はクライアント側、サーバ側ともに様々なオーバーヘッドが発生しそうな処理で、プログラマとしてはあまり採用したくはありません。データモデルが採用されます。売上伝票ヘッダレコードと売上伝票明細レコードが同時に存在して初めて整合性のあるデータとなるため、一般的にはトランザクション処理が必要になります。標準機能のみだとどうしても限界が出てきます。簡単な工夫を施すことで、この限界を超えて複雑な機能をAPIとして実装、公開することも可能です。それでは、実際に簡単な機能要求を仮定して、その方法について考察してみたいと思います。複数レコードの更新処理を実装するまずは複数のプロダクトアイテムに対して、一括して取扱中止日を設定するという機能要求を仮定してみたいと思います。実行することになります。これは処理対象のレコード件数が少なければ良いのですが、まとまった数を一気に処理したい場合は、非常にコストの高い処理を実装する必要があります。コールのみで実現できる方法を考えてみましょう。組み合わせて任意のスクリプトを実行できると良いのではないかと思います。処理自体は極めてゼロに近い負荷で、任意のスクリプトを実行できるのではないかと考えました。いうグローバルフィールドのみで構成され、レコード件数が常に1件のテーブルを用意し、そのテーブルへの検索を実行すると同時に、スクリプトを実行するというサンプル機能を実装してみたいと思います。仮の機能要求:JSON配列で指定したJANコードをもつアイテムの中止日を一括更新まずはプロダクトアイテムテーブルに登録されている複数のレコードに対して、同一の中止日を設定するというシナリオでサンプル機能を実装してみます。スクリプトにわたす引数を考えてみます。引数はJSONフォーマットで渡すことがWebAPIの慣例かと思いますので、次のような引数で渡したいと思います。JSON配列担っており、その中に任意の数のJANコードを設定すると、それらの取り扱い終了日が一括設定されるというシナリオです。次にスクリプトですが、今回の記事はFileMakerのスクリプトに関するテクニックをご紹介するものではありませんので、サンプルソリューションをダウンロードいただき、完全アクセス権でファイルを開いてご確認ください。引数の妥当性チェックや、適切なエラーハンドリングも一切実装していない、極めて簡易的なスクリプトが実装されています。Postmanから終了日の一括更新スクリプトを実行それでは実際にPostmanを操作して、スクリプトを実行してみましょう。APIのリクエストボディには、以下のJSONパラメータを設定してください。いう常にレコードが1件のみ登録さてている、グローバルフィールドのみで構成されたテーブルです。"{\"end_date\":\"2018/12/31\",\"jan_code\":[\"4901170017330\",\"4901170018436\",\"4901170017453\",\"4901170017590\",\"4901170017514\"]}"}queryパラメータは、trueというフィールドが1の値を検索する指定になっています。これは1レコードしか存在しなく、かつ常に1という値を持っているフィールドなので、検索負荷はほぼゼロといって良いと思います。動画で実際の動きを確認それでは、スクリプトを実行する様子を動画で確認してみましょう。親子関係のあるレコードを登録する次に、親子関係のあるレコードを一回のスクリプトで登録してみましょう。今回のサンプルソリューションで親子関係を持っているテーブルは、メーカーとプロダクトアイテム。売上伝票ヘッダテーブルと、売上伝票明細テーブルがあります。一般的に、メーカーとプロダクトアイテムの関係性は、1:0〜nになると思いますが、売上伝票ヘッダテーブルと売上伝票明細テーブルの関係性は、1:1〜nになります。標準機能のみでこれを処理するとなると...1.売上伝票ヘッダテーブルにヘッダレコードを1件登録2.レコードの新規追加APIのレスポンスにから、新規追加したレコードIDを取得。メソッドを実行して、新規追加したレコードのプライマリキー値を取得。4.取得した売上伝票ヘッダテーブルのプライマリキー値を外部キー値として、売上伝票明細テーブルにレコードを必要件数分登録...と、非常にコストの高い処理を実装しなければなりません。状況が発生し、あまり好ましい状態とは言えません。親子関係のあるデータを一括処理する引数を設定そこで今回は、売上伝票ヘッダテーブルと明細テーブルに、1回のリクエストで処理するための引数を考えてみましょう。一般的にはこのような引数になると思います。2018年12月10日の12時00分に、5品目の商品が5点づつ売れたことが目視で想像がつくと思います。APIの引数は、このように「何を処理しようとしているのか」を、引数を見るだけでさっと確認できることがとても重要です。複雑なスクリプト引数は、Base64で渡す前のスクリプト引数と比較すると、今回のスクリプト引数はJSON配列の中に、更にJSONオブジェクトがあるような複雑な構造を持っています。実際のソリューションを構築する場面では、もっと複雑なJSONを渡す必要も出てくるでしょう。JSON形式のリクエストボディに、JSON形式のスクリプト引数を埋め込む必要があるので、ダブルクオーテーションや改行コードなど、特定の文字列はバックスラッシュでエスケープする必要があります。このエスケープはなかなか面倒で、何が特殊文字かを予めプログラマが把握しておく必要がありますし、思わぬバグが内在してしまう可能性もあります。このような複雑な構造のJSONデータを渡す場合は、Base64でエンコードしてしまうと、APIをコールする方もされる方も非常に楽です。今回の引数は、Base64でエンコードして渡すことにしましょう。こちらが、PostmanからBase64でエンコードされたJSONデータをスクリプト引数として渡している様子です。動画で実際の動きを確認それでは実際の動きを動画で確認してみましょう。標準機能のみでは実装が困難な複雑な機能要求を、スクリプトで実装する方法について解説してきました。ここで紹介した以外にも様々な方法があると思いますし、ある観点から見ると今回ご紹介した方法はあまり好ましい実装方法ではないかもしれません。セキュリティに関する考慮また、今回お配りしているサンプルソリューションでは、引数のバリデーションや、SQLデータベースで言うところのSQLインジェクションに該当するような、不正な処理が実行されてしまう可能性のある引数を無効とするような処理は実装していません。APIを公開するということは、FileMakerプラットフォームとは全く無縁の方であったり、公開の範囲によっては悪意のあるクラッカーから攻撃を仕掛けられるケースも考えられます。このような背景から、引数を設定させてのAPIを介したスクリプト実行には、十分な考慮とテストが必要になります。大きなエコシステムの一部としてのFileMakerプラットフォームの可能性FileMakerプラットフォームで開発したソリューションは、これまではどうしても他システムと結合するためにODBC接続などによる「密結合」でしか実現ができませんでした。正式リリースされたことで、企業内における様々なシステムと、相互に「疎結合」できる事になりました。各システム間を疎結合で結んで、緩やかなエコシステムを構築することは、現在の非常に大きなトレンドのひとつです。FileMakerプラットフォームもそのトレンドに対応できたことで、より広域にFileMakerに蓄積されたデータやビジネスロジックを利活用することができるようになりました。ご存知の通り、FileMakerプラットフォームは、ある意味得意な分野と不得意な分野がはっきりと別れている開発プラットフォームです。FileMakerが不得意な部分は、思い切って他の開発プラットフォームで実装し、FileMakerプラットフォームは、自らの強みが活かせる部分にフォーカスするような考え方が、今後ますます重要になってくると思います。APIの使い方は必ずマスターしておきたいものです。世界を堪能し、新たな可能性に対して思いを馳せてみてください。BMWジャパンやDOLCE&GABBANAジャパンといった外資系企業、及び東証一部上場企業において、情報システム部門の立ち上げから基幹システムの企画・開発・運用まで幅広い経験と実績を持つ。2006年にフリーエージェントのITコンサルタントとして独立。株式会社ライジングサン・システムコンサルティングを創業する。現在はFileMakerプラットフォームとアジャイル開発を用いたシステム開発の内製化をサポートしている。