Gestion des exceptions de règle dans l'environnement d'exécution

La méthode par défaut de la gestion des erreurs ou des exceptions dans l'environnement d'exécution de personnalisation permet au moteur d'imprimer une erreur de trace dans le journal stdout du serveur d'applications. Grâce à un utilitaire de gestion des exceptions, il est possible de spécifier le type de sortie (message d'erreur ou trace de pile) et le fichier journal de sortie à utiliser (stdout ou stderr) et d'indiquer si l'exception doit être renvoyée à la page JSP. Les autres fonctions de gestion d'exception peuvent être définies par requête ou de façon globale.

Par requête

Pour définir le schéma par requête, insérez le code suivant dans une zone de contenu d'une page JSP :

request.setAttribute(RuntimeUtils.PZN_RUNTIME_EXCEPTION_HANDLING_KEY, RuntimeUtils.HANDLING_SCHEME);

Où HANDLING_SCHEME représente une des options indiquées pour la méthode setRuntimeExceptionHandlingScheme décrite dans la section ci-dessous.

Cette méthode ne modifie que le schéma de gestion des exceptions pour les règles qui s'exécutent sur cette page JSP.

Global

Pour définir le même schéma pour toutes les règles fonctionnant sur un serveur, exécutez le code suivant :

RuntimeUtils.setRuntimeExceptionHandlingScheme(RuntimeUtils.HANDLING_SCHEME);
Pour réinitialiser le schéma de gestion globale des exceptions, appelez : 
RuntimeUtils.resetRuntimeExceptionHandlingScheme();
Remarque : Le redémarrage du serveur d'applications réinitialise automatiquement le schéma de gestion des exceptions.
Vous pouvez également modifier le comportement global du serveur en modifiant la valeur suivante dans PersonalizationService.properties : 
rulesEngine.exceptionHandling=logMessage_stdout
Remarque : Pour que les modifications soient prises en compte, vous devez redémarrer le serveur.

Méthodes RuntimeUtils

public static void setRuntimeExceptionHandlingScheme(String value)
Paramètre le système de traitement des exceptions sur la valeur indiquée. Les valeurs possibles sont les suivantes :
  • RuntimeUtils.IGNORE
  • RuntimeUtils.LOG_MESSAGE_STDOUT
  • RuntimeUtils.LOG_MESSAGE_STDERR
  • RuntimeUtils.LOG_MESSAGE_STDOUT_AND_RETHROW
  • RuntimeUtils.LOG_MESSAGE_STDERR_AND_RETHROW
  • RuntimeUtils.LOG_STACKTRACE_STDOUT
  • RuntimeUtils.LOG_STACKTRACE_STDERR
  • RuntimeUtils.LOG_STACKTRACE_STDOUT_AND_RETHROW
  • RuntimeUtils.LOG_STACKTRACE_STDERR_AND_RETHROW
  • RuntimeUtils.LOG_MESSAGE_AND_STACKTRACE_STDOUT
  • RuntimeUtils.LOG_MESSAGE_AND_STACKTRACE_STDERR
  • RuntimeUtils.LOG_MESSAGE_AND_STACKTRACE_STDOUT_AND_RETHROW
  • RuntimeUtils.LOG_MESSAGE_AND_STACKTRACE_STDERR_AND_RETHROW
  • RuntimeUtils.RETHROW_EXCEPTION
Remarque : Les paramètres comportant RETHROW transmettent l'exception à l'écran. Il est conseillé de les utiliser uniquement dans un environnement de test.
public static void resetRuntimeExceptionHandlingScheme()
Réaffecte au schéma de gestion d'exceptions en cours la valeur LOG_MESSAGE_STDOUT.
public static String getRuntimeExceptionHandlingScheme()
Renvoie le schéma de gestion d'exceptions en cours.

Processus de gestion des exceptions

Lorsqu'une exception se produit, si le code peut continuer, il se poursuit lors de la consignation de l'exception. Dans le cas contraire, l'exception est encapsulée dans une exception PersonalizationException qui est transmise à RuleTrigger. Ce dernier recherche un remplacement de requête pour le schéma de gestion des exceptions, traite le schéma et le renvoie à la page JSP. Toutes les sous-classes de Throwable risquent d'être encapsulées dans une exception PersonalizationException.

Suivi

Pour procéder au suivi des classes d'exécution, activez la fonction de trace pour com.ibm.websphere.personalization.*=all. Pour procéder au suivi des classes de portlet de création, activez la fonction de trace pour com.ibm.wps.caf.*=all.