Manejo de errores en la infraestructura de mandatos de BOD

Hay dos tipos de excepciones que pueden general los módulos de servicio. Normalmente, generará el primer tipo de excepción, una excepción de aplicación. Es un módulo de servicio que indica un problema de lógica de negocio, como una validación de entrada, cuestiones de autorización y demás problemas de la empresa. El segundo tipo de excepción es un error de aplicación del sistema, que es una excepción no verificada y que los clientes no necesitan detectar explícitamente. Estas excepciones del sistema indican un problema interno que detectará y manejará la infraestructura y no el módulo de servicio. Si desea generar excepciones del sistema, amplíe la clase abstracta de excepción del sistema para el registro cronológico común y otras razones de calidad de servicio.

Cuando aparece una excepción de aplicación, el mandato de documento de objeto de negocio principal genera la excepción. Cuando se produce esta excepción, el procesador del Documento de objeto de negocio lleva a cabo la lógica de ejecución adecuada para explicar los motivos de la excepción y, a continuación, llama a la instancia del mandato y le pasa la excepción que se produjo. El mandato recibirá una notificación de la excepción y deberá cambiar el Documento de objeto de negocio de respuesta para que indique la excepción que se ha producido. Esto significa que los datos excepción básicos deberán rellenarse pero el mandato podrá añadir más información como, por ejemplo, áreas en el nombre que causó problemas.

Aunque los clientes de un servicio podrán realizar alguna validación inicial en los datos de entrada, solo podrán realizar validaciones simples. Cualquier validación que no pueda expresarse mediante el XSD o reglas muy sencillas sobre cómo construir la petición, será una validación del servidor. Cuando se trate de una validación del servidor, el servicio validará la entrada de BOD y devolverá una lista de errores de aplicación en el área ChangeStatus del verbo de respuesta.

En el siguiente código de ejemplo puede ver un ejemplo de generación de una excepción de aplicación:

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

Éste es un ejemplo de clase de excepción de aplicación. Observe que amplía 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);
	}

}

En la implementación de SOI, utilizando mandatos de pares nombre-valor, solo se da soporte a una acción y, por lo tanto, la respuesta de servicio solo puede devolver un error de aplicación. Si el BOD de petición contiene varios problemas en la entrada, es posible que se produzcan varias peticiones hasta que el cliente comprenda todos los problemas relacionados con el BOD de petición.

La implementación de la infraestructura del mandato BOD tiene soporte para varias acciones y, por lo tanto, la infraestructura da soporte a la devolución de varios errores. Aunque el BOD de petición sigue considerándose una unidad de trabajo transaccional y el BOD entero se confirma o se retrotrae, si en el BOD contiene varios errores, podrán devolverse todos los errores de aplicación. Todos los errores de aplicación se indican como un ApplicationError. Los ApplicationError se pueden asociar a la AbstractApplicationException para proporcionar una lista de motivos por los cuales el servicio no puede procesar el BOD de entrada. Esto incluiría datos no válidos junto con la validación de lógica de negocio adicional.

Los errores de aplicación pueden representar un conjunto de problemas y el usuario puede añadirlos a la excepción, como puede verse en el siguiente código de ejemplo.

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

Compensación

Cuando se produce un error durante el proceso y la lógica de negocio ha de retrotraerse, la lógica de negocio puede requerir una compensación. Siempre que se produce una excepción que pueda requerir alguna lógica de R, se llama al método handleException() del mandato BOD. La finalidad de la lógica de compensación es deshacer cualquier operación que se haya producido como resultado de haber deshecho la operación actual. Por ejemplo, si se procesa un servicio ProcessOrder (procesar pedido) y parte de esa lógica de negocio hace peticiones al servicio de pagos (Payment), es posible que la petición de pago necesite algún tipo de compensación para justificar el ProcessOrder que no se ejecuta correctamente. Sin la lógica de compensación adicional, es posible que se procesen peticiones erróneas en el sistema de pagos. Esta compensación puede emitir peticiones para cancelar las peticiones anteriores.