こんにちは。株式会社VALGOエンジニアのヌマです。
地元秋田からリモートで全国各地のお仕事をしています。
今回はMulesoftのエラー処理に関して紹介します。
Error処理の重要性
Mulesoft以外のシステムでも同様ですが、システムの安定性・信頼性の確保やユーザー体験の向上、セキュリティリスクの低減のために重要とされています。
予期せぬエラー（不正入力、ネットワーク障害など）でプログラムが停止したり、誤った動作をしたりするのを防ぎ、安全かつ継続的に利用できるようにするために不可欠です。
適切に実装することで、エラー発生時も適切なメッセージ表示や代替処理が可能になり、デバッグや保守も容易になります。
Salesforce 認定 MuleSoft デベロッパー試験にも60問中8%(4~5問)出題されるので身に着けておきたいです。
Mulesoftの主なエラー処理とコンポーネント
エラー処理は上のフローにあるようなコンポーネントが良く使われます。
- Error Handler
- On Error Continue
- On Error Propagate
- Raise error
(+ Try スコープ)
中でもSalesforce 認定 MuleSoft デベロッパー試験の出題範囲から設定方法を紹介します。
Global Error Handler の実装
Error Handlerを利用して1つエラー処理を作成します。
作成後Global Elementsを開き、Createを押します。
Global ConfigurationsのConfigurationを選択し、OKを押します。
Default Error Handlerで先ほど作成したError Handlerを選択する
このように設定することで、下記のようにRaise error後、Error handlingに設定していなくても、Default Error Handlerで設定したError_Handlerというフローに遷移します。
On Error Continue と On Error Propagateの実装
- On Error Continueはエラーだったことを隠蔽します。
- On Error Propagateはデフォルトのエラー処理動作と同じ動作を行います。
複数の Error Handler の組み合わせ(On Error Continueの場合)
Requestコンポーネントから呼び出すAPIでOn Error Continueを使っているとすると、下図のようなイメージになります。
- Request コンポーネントから別のフローを呼び出します
- 呼び出されたフローはListenerでリクエストを受け付けます
- Raise errorでエラーを起こします
- On Error Continueでエラー処理を行います
- RequestコンポーネントからhttpStatusは200で受け取ったので後続の処理を行います
複数の Error Handler の組み合わせ(On Error Propagateの場合)
Requestコンポーネントから呼び出すAPIでOn Error Propagateを使っているとすると、下図のようなイメージになります。
- Request コンポーネントから別のフローを呼び出します
- 呼び出されたフローはListenerでリクエストを受け付けます
- Raise errorでエラーを起こします
- On Error Propagateでエラー処理を行います
- Requestコンポーネントからエラーで受け取ったので後続の処理には行かずにエラー処理を行います
Try スコープの実装
Try スコープを利用するとTry スコープ内のコンポーネントの実行時に発生するエラーを処理できます。
- Request コンポーネントからAPIを呼び出します
- 呼びだしたAPIからエラーが返ってきたらTryスコープ内のError handlingに入りエラー処理します
- （上図ではOn Error Continueを入れているので）後続の処理を行います
Custom Error
Custom Errorでは、新しい名前空間を宣言します。エラー種別の名前空間は、エラーの起源を特定するのに役立ちます。
上図のようにTypeで名前空間(name space)を定義し、Descriptionでエラー説明を入力することで、エラー時にError Descriptionとして出力することができます。
おまけ（ validation module )
バリデーションチェックを行うとエラー処理の実装が不可欠になります。
上図の実装の場合、バリデーションチェックでエラーが発生してもOn Error Continueでpayloadがセットされ、正常系としてpayloadが返却されます。
上図の実装の場合、バリデーションチェックでエラーが発生し、On Error Propagateでpayloadがセットされ、異常系として返却されます。
ListenerのResponse設定がデフォルトであればerror.discriptionが設定されているので、”Is null”のバリデーションコンポーネントで発生したエラーが返ります。
実践動画
上記のフローを例として考えます。
Is nullでエラーが発生する場合、返却値はどのようになるでしょうか。
動画をご覧の通り、正常終了し、最後にセットしたpayloadである”main flow success”が返却されます。
まとめ
Mulesoftのエラー処理を記載しました。
基本的な内容にはなりますが、Mulesoftの学習のお手伝いになれば幸いです。
またMulesoftの記事の別の記事も記載しているのでよかったら見て行ってください！