Gestion des erreurs dans l'infrastructure de commandes BOD

Les modules de service peuvent renvoyer deux types d'exception : erreurs d'application et erreurs système. Vous rencontrerez généralement le premier type, à savoir des erreurs d'application. Il s'agit ici d'une exception du module de service indicative d'un problème au niveau de la logique métier, concernant par exemple une validation d'entrée, des problèmes d'autorisation ou d'autres motifs métiers. Le second type d'exception représente une erreur d'application système qui constitue une exception non contrôlée n'ayant pas besoin d'être explicitement interceptée par les clients. Ces exceptions système signalent un problème interne qui serait intercepté et traité par l'infrastructure et non pas par le module de service. Si vous désirez renvoyer des exceptions système, étendez la classe d'exception système abstraite pour journalisation commune et autre raisons de qualité de service.

Lorsqu'une exception d'application est rencontrée, cette exception est renvoyée par la commande BOD principale. Lorsque cette exception se produit, le processeur BOD (Business Object Document) exécute la logique d'exécution appropriée pour prendre en compte exception, puis appelle l'instance de la commande en lui transmettant l'exception rencontrée. La commande est notifiée de l'exception et doit modifier le BOD de réponse pour dépeindre l'exception survenue. Ceci signifie que les données élémentaires de l'exception doivent être renseignées mais que la commande peut leur ajouter des informations supplémentaires (comme les zones du nom à l'origine du problème).

Bien que les clients du service puissent effectuer une validation initiale sur les données en entrée, il ne peut s'agir que d'une validation simple. Toute validation ne pouvant être exprimée par le XSD, ou par des règles rudimentaires de construction de la requête, relève du serveur. Dans le cas d'une validation serveur, le service valide le BOD entré et renvoie une liste des erreurs d'application dans la zone ChangeStatus du verbe de réponse.

Un exemple de renvoi d'une exception d'application figure dans l'échantillon de code ci-dessous :

AuthorizationException exception = new AuthorizationException(searchExpression.getAccessProfile());
LOGGER.throwing(CLASSNAME, METHODNAME, exception);
throw exception;

Exemple de classe d'exception d'application. Notez qu'il s'agit d'une extension de AbstractApplicationException :

/**
 * An exception to represent an authorization exception where the current
 * context cannot executed the specified request object.
 */
public class AuthorizationException extends AbstractApplicationException {
			
	private static final String MESSAGE_KEY = FoundationUserMessageKeys.NOT_AUTHORIZED_TO_EXECUTE;

	/**
	 * Creates an instance of the authorization exception. 
	 */
	public AuthorizationException() {		
		super(MESSAGE_KEY, null, null);
	}
	
	/**
	 * Creates an instance of the authorization exception. 
	 * @param resource The name of the resource that cannot be executed due to
	 * authorization.
	 */
	public AuthorizationException(String resource) {		
		super(MESSAGE_KEY, new Object[] { resource } , null, null);
	}

}

Dans l'implémentation SOI utilisant des commandes avec paires nom-valeur, une seule action est prise en charge de sorte qu'une seule erreur d'application peut être renvoyée par la réponse du service. Si le BOD de la requête comporte plusieurs problèmes dans les données d'entrée, plusieurs réitérations de la requête peuvent s'avérer nécessaires avant que le client ne les ait tous identifiés.

L'infrastructure de commandes BOD prend en charge des actions multiples et donc le renvoi de plusieurs erreurs. Bien que le BOD de requête soit toujours considéré comme une unité d'oeuvre transactionnelle unique entraînant la validation globale du BOD ou l'annulation de la transaction, si plusieurs erreurs existent dans le BOD, toutes les erreurs d'application peuvent néanmoins être renvoyées. Toutes les erreurs d'application sont représentées sous la forme ApplicationError. Ces erreurs peuvent être associées avec l'exception AbstractApplicationException pour fournir une liste des raisons pour lesquelles le service ne peut pas traiter le BOD en entrée. Cette liste couvrirait les données non valides tout comme les résultats de la validation supplémentaire par la logique métier.

Les erreurs d'application peuvent représenter un ensemble de problèmes et vous pouvez les ajouter à l'exception, comme illustré dans l'exemple de code ci-dessous :

exception.addApplicationError(new ApplicationError(ApplicationError.TYPE_GENERIC_ERROR,
	FoundationUserMessageKeys.NOT_AUTHORIZED_TO_EXECUTE_ACTIONS_ON_BUSINESS_OBJECT,
		new Object[] { action, action} ,
			LOGGER.getResourceBundleName()							
	);
);

Compensation

Lorsqu'une erreur survient et que la logique métier doit être ramenée à son état antérieur, une logique de compensation peut devoir être appliquée. La méthode handleException() de votre commande BOD est appelée chaque fois que survient une exception pouvant requérir une logique de compensation. L'objet de cette logique de compensation est d'annuler toute opération découlant de l'opération actuelle annulée. Par exemple, si un service ProcessOrder est traité et qu'une partie de sa logique métier envoie des requêtes au service Payment, la demande de paiement peut nécessiter une forme de compensation pour prendre en compte l'échec du service ProcessOrder. Sans cette logique métier complémentaire, des requêtes erronées pourraient être traitées par le système de paiement. Cette compensation peut émettre des requêtes en vue d'annuler les précédentes.