Performance testing at scale.
大規模の負荷テストなどをどのようにするか解説するセッション。
FileMaker Server の負荷テスト
・Data API,Admin API,OData API は JMeter や Gatling で可能
・FMSE やSchedule実行も可能だよね
・FMP/FMGo、WebDirect のケースをどうするか
方法は結局AWS上にWindowsOSを数百作る
・Windowsに FileMaker Pro を入れて、大量作成。2CPUの4GB。
・大量作成するには AMI 作ってコマンドで作成、起動や停止もコマンド実行する管理ツールを作っていた
・PsExec を使って、FMP URLスキームで一斉にスクリプト実行などを行う
負荷の確認
・CPU,メモリ、ディスクのIOなどのメトリック、
・FMSが吐き出すログ、とくにFMS TopCallStats.log、ClientStats.log、Stats.log
・OSが吐き出すログ
Cut through integration chaos with Claris Connect.
Claris Connect の将来の新機能の詳しい説明セッション。
おそらく NDA 的な話が多いので割愛させていただきますが、より Claris 製品間の連携を強化し、他社API連携をローコードで構築する柱にしていく意図が感じられた。
AI under the hood session: Integrating Large Language Models.
Claris FileMaker に組み込む予定の AI 機能の紹介セッション。
おそらくこちらも NDA 的な話が多いので割愛させていただきますが、昨日まで聞いていた ChatGPT との連携ネタセッションはなんだったんだと過去の話に感じてしまうぐらい、本セッションで紹介されていた将来の Claris FileMaker はすごいことになりそうという印象です。
How far with OData?
文字どおりODataはどこまでできるか、結構いいじゃん、というセッション。
概要
・CRUDの操作が一通り揃っている
・拡張アクセス権 fmodata つけるだけ
・Basic認証だけ。Data API では token取得ー本番リクエストーtoken破棄の3回リクエスト必要だがこれは1回で済む
・サーバーにリクエストログが残る(Data APIも残る)
・テーブルオカレンスをターゲットにする。(Data APIはレイアウトをターゲットとするのが大きな違い)
・データ量課金（Data API同様）
スピーカーの本人が目指したいこと
FileMaker はデータ、レイアウト、スクリプトなどが1つのファイルに入ってしまい、高度なんだけど運用後の改修がしにくくなっている。
そこで、データとその他の機能は別ファイルに分けてその間の通信をODataで行うと良いのではないか。
注意点
・グローバルフィールドの扱い
・フィールド名の頭が _ は避ける。エスケープ文字を使えばなんとかなるが。
・スクリプト名に ; を使うな。確かに10年ほど前の弊社の命名規則では大量に使っていた。
・予約語を使うな
最後に
あっという間に3日目が終わりました。
充実感がハンパないです。
疲労感はいつも以上にあります。なぜなら必殺技ツールが発見されたから聞くときの集中力が相当必要になるためです。必殺技ツールは 番外編 でご紹介したいと思います。これで今回はほとんどのセッションの中身だけでなく Q&A についても理解することができました。
