モデルを実行した後にこのエラーメッセージが表示された場合 Mendixそして、この投稿はあなたのためです。
エラー メッセージが表示される理由は多数あり、メッセージのバリエーションもいくつかあります。この記事では、これらのエラーの原因を見つける方法、よくあるエラーを修正する方法、開発中にエラーが発生する可能性を最小限に抑える方法について説明します。
この記事全体を通して、例も使用します。これらの例に使用されているアプリには、Order、OrderLine、SaleOffer の 3 つのエンティティがあります。このアプリでは、OrderLines を Order に追加し、SaleOffer を Order に添付できます。
根本原因の発見
エラーが発生した場合、最初に行う必要があるのは、エラーが発生した場所を見つけることです。
アプリがローカルで実行される場合:
ビジネス モデラーを開いてコンソールを表示するだけです。コンソール内に、先頭に赤い「X」が付いた赤い行項目があります。この行には必要な情報が表示されます。
赤い線をダブルクリックすると、エラー メッセージとスタック トレースの詳細が表示されます。
このスタック トレースには 3 つの重要な情報があります。
- マイクロフロー名とマイクロフローエラーの場所: この例では、キャプション「Number > 0?」の排他的分割 (ゲートウェイ) の「IVK_DeleteOrderLine」内にエラーが見つかります。
- 発生したエラー: この例では、エラーは java.lang.NullPointerException に関連しています。
- 失敗した正確な表現この場合、失敗は、ヌル ポインター例外を引き起こした排他的分割内の部分に関連しています。
アプリがクラウドまたはサービスコンソールから実行される場合
このシナリオでは、ログ ファイルにアクセスし、エラーが発生した時刻と一致するタイムスタンプを持つ「ERROR」で始まる行を探す必要があります。必要な詳細はすべて、ログに順番に表示されます。
エラーの場所を見つける方法がわかったので、次に、よくある 2 つのエラーと、そのエラーを回避するためのパターンを見てみましょう。
ヌルポインタエラー
ヌル ポインタ エラーは、取得から返されるオブジェクトがない場合、またはオブジェクトの属性が空の場合に発生します。最初の例では、OrderLine を削除したが、その数値が 0 より大きいことを確認したため、マイクロフローが失敗しました。
問題の原因となっている排他的分割（前述のポイント（1）から）を確認し、例外の潜在的な原因がわかったので、問題の修正を開始できます。
ヌルポインタエラーの修正 - オプション 1:
Number 属性が空かどうか、または OrderLine オブジェクトが空かどうかを確認するチェックを追加します。
これらのチェックは必ずしも必要ではありません。オブジェクトが空になることが不可能な場合は、空であるかどうかを確認する理由はありません。「true」は常に水平方向に進むことに注意してください。これはベスト プラクティスです。
これらのチェックは、1 つの排他的分割で実行することもできます。
$注文行 != 空の
の三脚と
$注文行/番号 != 空の
の三脚と
$注文行/番号>0
機能的には同じですが、分割することで Microflow が読みやすく理解しやすくなります。ここでは順序が重要であることに注意してください。最初に空のチェックを実行する必要があります。そうしないと、$OrderLine/Number>0 の評価で null ポインター エラーが発生します。
ヌルポインタエラーの修正 - オプション 2:
エンティティの取得で空が返される場合は、「GetCreate」パターンを実装してみてください。このパターンは、Retrieve アクションではなく Microflow アクションを使用して実装されます。この例は、Order の SaleOffer を更新したいが、Order に SaleOffer がまだ関連付けられていない場合に何が起こるかを示しています。
この場合は GetCreate パターンを使用します。SaleOffer を単に取得するのではなく、SaleOffer を返すことが保証されている Microflow を呼び出します。以下の Microflow は、このパターンがどのように機能するかを示しています。
Get Create パターンの最初のステップは、SaleOffer を取得 (取得) することです。これを試みたら、成功したかどうかを確認します。SaleOffer が見つかった場合は、この SaleOffer を返します。取得に失敗した場合は、新しい SaleOffer を作成し、それを Order に関連付けます。こうすることで、次にこの Microflow が呼び出されたときに、取得が成功します。最後に、NewSaleOffer を返します。
このパターンは、オブジェクトの新しいインスタンスを作成しても安全な場合にのみ実装する必要があります。状況によっては、必ずしもそうすることが適切ではない場合があります。その場合は、単に空のチェックを実行し、それに応じて続行する必要があります。
セキュリティ エラー
セキュリティは、あらゆるドメイン モデル、マイクロフロー、ページ内の重要なコンポーネントです。ただし、セキュリティを有効にしてテストすると、「セキュリティ上の理由により失敗しました」というエラー メッセージが表示される場合があります。最も一般的なセキュリティ エラーの 1 つは、エンティティ アクセスに関連しています。
エンティティアクセスを適用する マイクロフローのプロパティの設定です。エンティティ アクセスが適用されているかどうかを確認する最も簡単な方法は、マイクロフローの背景色を確認することです。エンティティ アクセスが適用されている場合、マイクロフローはわずかに色づきます。
上記の例では、右側のマイクロフローにエンティティ アクセスが適用されています。エンティティ アクセスが適用されると、エンティティに設定されたセキュリティがマイクロフロー アクセスよりも優先されます。
この例では、ユーザー ロール「ユーザー」と「管理者」の 2 つと、モジュール ロール「ユーザー」と「管理者」があり、「ユーザー」が「ユーザー」モジュール ロールにマップされ、「管理者」にも同様の構造があると仮定します。
セキュリティ エラーを調査するときは、前と同じ手順に従います。コンソールに移動して、赤く強調表示された情報を見つけ、エラーの原因となったアクションに進みます。たとえば、ここでエラーが発生していることがわかります。
このマイクロフローにはエンティティ アクセスが適用されていることがわかります (背景の色合いでわかります)。そのため、エンティティとマイクロフローのセキュリティを確認する必要があることがわかります。マイクロフローには、ユーザー ロール「管理者」を持ち、エンティティ SaleOffer に次のセキュリティ設定を持つユーザーがアクセスできます。
ここから、問題が特定されます。つまり、「管理者」が Microflow で SaleOffer エンティティを作成しようとしていますが、権限がありません。これを解決するには 2 つの方法がありますが、適切な解決策は特定のユースケースによって異なることに注意してください。
- SaleOfferを作成する権限を「管理者」モジュールロールに追加します。
- マイクロフローを「管理者」がアクセスできないようにする
これらは発生する可能性のあるランタイムエラーのほんの一例です。他にもよく見かけるエラーはありますか？また、分かりにくいエラーや混乱を招くエラーはありますか？