今回は、FileMakerのスクリプトを書き始めた層が対象の記事です。

序章

FileMakerのスクリプトを書くときに一歩進んで実装して欲しいのが、

エラーコード

の確認です。

FileMakerはスクリプト実装を最小限で痒い所に手が届く便利なツールですが、もう少し細かい処理をしたい、となるとスクリプトで数行以上スクリプトステップを書くことになります。

へー、FileMakerってスクリプト書けるんだー

と初見でスクリプトステップを組んでいくと、あら、なんて素敵。
たった数行ですごいことができちゃうじゃないですか。

でも、ちょっと慣れてくると、「あれれ？なんか関連ページ開かないのに、データが更新されちゃった！？」みたいに「あると思ってたのにない」時の処理が必要であることに気づくんです。

一番簡単にエラー処理を実装するには？

それは、

スクリプトステップを1行実行するときに、エラーコードを拾うこと

です。

え、当たり前じゃん！？と思うあなたは、エンジニアとして勉強してきた方ですね。
しかし、ローコード、ノーコードでシステムを実装する界隈では、エンジニアだからシステムを組んだという人ではなく、現場で必要に迫られてシステムを作っている、という、一般の人が多いです。
一般の人がコード書いて動かすって、ここまでできるのは、本当はすごいことなんです。

しかし、「たられば」をたくさん考えるのが仕事のエンジニアは、通常動かないこともそのコードに実装することで、安全で強固なシステムに仕上がるのを知っています。

ただし、スクリプトステップすべてにエラー処理が必要なわけではありません。

不要なエラー処理

例えば、変数やフィールドに値をセットするときに、エラー処理は書かないことが多いです。

変数を設定 [$パス; 値: Get (ドキュメントパス) & "見積書_" & 見積書::見積書ID & "_" & 見積書::顧客名 & "_" & 見積書::案件名 & ".pdf"]

とか、

フィールド設定 [見積書::合計金額; Sum (見積書明細::小計)]

では、エラー処理はそんなに重要ではないです。

ただし、変数に値を設定する前に、設定するフィールド内容が空欄でないか、などのチェックは必要でしょう。

必要なエラー処理

では、必要なエラー処理とはなんでしょうか？
2パターンあると考えます。

まず一つ目は、単純にスクリプトステップが失敗したときに行うエラー処理。
二つ目は、システムを使う人が「この結果はまずいのでエラーにしたい」ときにエラーとして処理をすることです。

今回は、「関連レコードへ移動」というスクリプトステップを例に、2パターンのエラー処理を考えてみます。

「関連レコードへ移動」は、こんな感じで書きますね。

関連レコードへ移動 [関連レコードのみを表示; テーブル: 「見積書明細」; 使用するレイアウト: 「見積書明細」(見積書明細); 新規ウインドウ]

このスクリプトステップのヘルプページにはエラー処理は書いていませんので、ここにエラー処理を付け加えていきましょう。

サンプル

見積書の一覧と、その明細を表示する詳細画面があるとします。

一覧画面から詳細画面へは、「詳細」ボタンで画面遷移するようにします。

この時の「詳細」ボタンは、関連レコードへ移動を使っています。

この「詳細」ボタンの実装は、とても手軽にできます。
ただ、このままだと、見積書明細がまだ作られていない時はどのように処理されるでしょうか？

答えは
何も起こらない
です。

でも、デバッガで見ると、エラーコードをきちんと叫んでいることがわかります。

ちゃんと教えてくれているのに、気づかない私たち。

単純にスクリプトステップが失敗したときに行うエラー処理

このようなエラーコードは、単純にスクリプトステップが失敗しているときにでます。

画面遷移しないということは単純にまだ作成途中かもしれません。
その場合は、何もないことを伝えるカスタムメッセージを出すと、使っている人に優しいですね。

ボタンの実装を「単一スクリプト」から「スクリプト」に変換して続きを追加します。

さっき何も反応しなかった見積書ID:2はどうなったでしょうか。

カスタムダイアログが表示され、無反応で何が起こったかわからない、という事態は免れましたね！

そうではなく、必ず明細が作られてからこの一覧に表示しています、という場合は、何かしらシステム的に問題が発生したかもしれません。
そんな時は、運用に応じてカスタムメッセージを次のように変えてみるのもいいかもしれません。

運用的に許されるのか否か、で表示されるメッセージを変更して対応を促すことができれば、現場にあったシステムと言えそうですね。

また、エラーコードは101以外が返ってくるかもしれません。
未知のエラーの場合は、エラーコードがユーザーやシステム管理者に分かれば、解決につながるかもしれません。

「この結果はまずいのでエラーにしたい」ときに行うエラー処理

明細は存在するけれど、そもそも明細画面に遷移してはいけない、というケースを考えてみます。

例えば、見積書の有効期限を過ぎている場合は、担当者が見積書の破棄（削除フラグを1にするなど）をする現場だったとします。
うっかり見積書破棄を忘れている場合、有効期限が過ぎていても見積書明細が見られるようになってしまいます。
有効期限が過ぎている見積書は明細を表示しない（画面遷移しない）という運用の場合、関連レコードに移動する前にチェックができます。

これで、有効期限が原因で見積書の明細画面に遷移できないことがユーザにもわかります。

では、有効期限が過ぎていても明細に画面遷移して何らかの確認ができるけれど、有効期限が過ぎていることを伝えたい場合はどうでしょう。

関連レコードに正常に移動したというエラーコード=0の時に、その旨を追加してみます。

では、詳細ボタンをクリックしてみましょう。

閲覧しかできないことがユーザに伝わりましたね！

システムの「たられば」によってエラー処理をするために、エラーコードの確認をする

最初の１行だけのスクリプトステップの実装を元に、エラーコードを確認する処理を追加することで、だいぶシステムの安全性が高まりましたね。

極論を言ってしまえば、誰にでも起こりうるミスを回避するために、エラーコードを確認してその後何事もなかったように日常が進むためにエラーコードを確認しましょう、ということになります。

例えば、今回サンプルとして出した関連レコードへの移動のエラー処理をしなかったために、後続の処理が進んでしまい、本来の意図と違う内容を更新してしまったらどうしましょう。。。

実行したスクリプトステップがもしうまくいかなかったら、、、

これを考えるのはとても骨の折れる作業です。
しかし、このエラーコードを取得して適切なエラー処理をすることで、現場もあなたも無駄な労力を少なくすることができるはずです。

自分の書いたコードにスクリプトステップ、一度見直してみませんか？