Si vous avez déjà vu ce message d'erreur après avoir exécuté votre modèle dans Mendix, alors ce post est pour vous.
Il existe de nombreuses raisons pour lesquelles un message d'erreur apparaît et plusieurs variantes de messages. Dans cet article, je vais vous expliquer comment trouver la cause de ces erreurs, comment corriger certaines des erreurs les plus courantes et comment minimiser le risque d'erreurs lors de votre développement.
Tout au long de cet article, j'utiliserai également des exemples. L'application utilisée pour ces exemples comporte trois entités : Order, OrderLine et SaleOffer. Dans notre application, nous pouvons ajouter des OrderLines à la commande et nous pouvons y joindre une SaleOffer.
Trouver la cause profonde
Une fois que vous avez reçu une erreur, la première chose à faire est de trouver où l'erreur s'est produite.
Si votre application est exécutée localement :
Vous pouvez simplement ouvrir le Business Modeler et afficher la console. Dans la console, vous trouverez une ligne en rouge avec un « X » rouge au début. Cette ligne nous fournira les informations dont nous avons besoin.
Double-cliquez sur la ligne rouge pour obtenir plus de détails sur le message d'erreur et la trace de la pile.
Cette trace de pile contient trois informations clés :
- Le nom du Microflow et l'emplacement de l'erreur Microflow:Dans cet exemple, l'erreur se trouve dans « IVK_DeleteOrderLine » dans le split exclusif (passerelle) avec la légende « Nombre > 0 ? »
- L'erreur qui s'est produite:Dans cet exemple, l’erreur concerne java.lang.NullPointerException.
- L'expression précise qui a échoué. Dans ce cas, l’échec concerne un élément de la division exclusive qui a provoqué l’exception de pointeur nul.
Si votre application est exécutée dans le Cloud ou depuis la console de service
Dans ce scénario, vous devez accéder aux fichiers journaux et rechercher une ligne commençant par « ERROR » avec un horodatage correspondant à l'heure de votre erreur. Tous les détails nécessaires sont affichés dans l'ordre dans le journal.
Maintenant que nous savons comment trouver l’emplacement de notre erreur, examinons deux erreurs courantes et certains modèles pour vous aider à les éviter.
Erreurs de pointeur nul
L'erreur de pointeur nul se produit lorsqu'aucun objet n'est renvoyé à partir d'une récupération ou lorsqu'un attribut d'un objet est vide. Dans mon premier exemple, le Microflow a échoué car nous avons supprimé une OrderLine, mais nous avons vérifié que le nombre était supérieur à zéro.
Nous voyons la division exclusive qui est à l’origine du problème (du point (1) précédent), et puisque nous connaissons maintenant les causes potentielles de notre exception, nous pouvons commencer à résoudre le problème.
Correction des erreurs de pointeur nul – option 1 :
Ajoutez une vérification pour voir si l’attribut Number est vide ou si l’objet OrderLine est vide.
Ces vérifications ne sont pas toujours nécessaires : s'il est impossible que l'objet soit vide, il n'y a aucune raison de vérifier s'il est vide. Notez que « true » mène toujours horizontalement : il s'agit d'une bonne pratique.
Ces contrôles peuvent également être effectués en une seule fois :
$OrderLine != vide
et
$OrderLine/Numéro != vide
et
$OrderLine/Number>0
Sur le plan fonctionnel, ces éléments sont identiques, mais les divisions séparées peuvent rendre le Microflow plus facile à lire et à comprendre. Notez que l'ordre est important ici ; vous devez d'abord effectuer les vérifications vides, sinon l'évaluation de $OrderLine/Number>0 provoquera toujours une erreur de pointeur nul.
Correction des erreurs de pointeur nul – option 2 :
Si la récupération d'une entité renvoie un résultat vide, essayez d'implémenter un modèle « GetCreate ». Ce modèle est implémenté en utilisant une action Microflow au lieu d'une action Retrieve. Cet exemple montre ce qui se passe lorsque nous voulons mettre à jour SaleOffer sur la commande, mais qu'aucune SaleOffer n'est encore associée à la commande.
Utilisez le modèle GetCreate dans ce cas. Au lieu de simplement récupérer la SaleOffer, appelez un Microflow qui garantit de renvoyer une SaleOffer. Le Microflow ci-dessous montre comment fonctionne ce modèle.
La première étape du modèle Get Create consiste à tenter d'obtenir (récupérer) la SaleOffer. Une fois cette tentative effectuée, nous vérifions si elle a réussi. Si une SaleOffer est trouvée, nous renvoyons simplement cette SaleOffer. Si la récupération échoue, nous créons alors une nouvelle SaleOffer et l'associons à la Order. De cette façon, la prochaine fois que ce Microflow sera appelé, la récupération réussira. Enfin, nous renvoyons la NewSaleOffer.
Ce modèle ne doit être implémenté que lorsqu'il est possible de créer en toute sécurité une nouvelle instance de l'objet. Selon la situation, il peut ne pas toujours être approprié de le faire. Dans ce cas, vous devez simplement effectuer la vérification vide et procéder en conséquence.
Erreurs de sécurité
La sécurité est un élément important de tout modèle de domaine, Microflow et page. Cependant, lorsque vous effectuez des tests avec la sécurité activée, vous pouvez obtenir des messages d'erreur contenant la phrase « échec pour des raisons de sécurité ». L'une des erreurs de sécurité les plus courantes concerne l'accès aux entités.
Appliquer l'accès aux entités est un paramètre dans les propriétés du Microflow. Le moyen le plus rapide de savoir si l'accès aux entités est appliqué est de vérifier la couleur d'arrière-plan d'un Microflow. Une légère teinte apparaîtra sur le Microflow si l'accès aux entités est appliqué.
Dans l'exemple ci-dessus, le Microflow illustré à droite dispose d'un accès aux entités appliqué. Lorsque l'accès aux entités est appliqué, la sécurité définie sur l'entité aura la priorité sur l'accès au Microflow.
Pour les besoins de cet exemple, supposons que nous ayons deux rôles d'utilisateur, « Utilisateur » et « Administrateur », et deux rôles de module, « Utilisateur » et « Administrateur », avec « Utilisateur » mappé au rôle de module « Utilisateur » et une construction similaire pour « Administrateur ».
Lorsque nous examinons une erreur de sécurité, nous suivons les mêmes étapes que précédemment : nous allons dans la console pour trouver les informations surlignées en rouge qui nous mèneront à l'action qui a provoqué l'erreur. Par exemple, nous découvrons que notre erreur se produit ici :
Nous voyons que ce Microflow a un accès d'entité appliqué (par la teinte de l'arrière-plan), nous savons donc que nous devons vérifier la sécurité de l'entité et du Microflow. Le Microflow est accessible aux utilisateurs avec le rôle d'utilisateur « Administrateur » et les paramètres de sécurité suivants sur l'entité SaleOffer :
À partir de là, le problème est identifié : l'« administrateur » tente de créer l'entité SaleOffer dans le Microflow mais n'a pas les autorisations pour le faire. Il existe deux façons de résoudre ce problème, mais gardez à l'esprit que la solution appropriée dépendra du cas d'utilisation spécifique :
- Ajoutez l'autorisation de créer l'offre de vente au rôle de module « Administrateur »
- Rendre le Microflow inaccessible aux « administrateurs »
Voici quelques exemples d'erreurs d'exécution que vous pouvez rencontrer. En rencontrez-vous d'autres fréquemment ? Y en a-t-il une qui est difficile ou déroutante ?