Política de gestión de errores SOAP

TIPOLOGÍA DE ERRORES

Dentro de toda llamada a servicios de interoperabilidad distinguir la siguiente tipología de errores:

• Errores de comunicación
• Errores técnicos de aplicación
• Errores funcionales de aplicación

1.1. Errores de comunicación

Se definen como errores de comunicación aquellos relativos al envío y aceptación de los mensajes por parte del sistema receptor de la misma.

Los receptores de la mensajería deberán realizar una validación sintáctica:

• Esquema
• Valores de los campos (opcionalidad y/o cardinalidad)
• Formato

Si el mensaje no supera las validaciones se deberá informar al sistema origen de la llamada.

1.2. Errores técnicos de aplicación

En el procesamiento de mensajería, el sistema proveedor es susceptible de producir errores, tales como:

• Errores en el código en el desarrollo
• Errores de caída de base de datos
• Errores de sistema operativo
• Errores no controlados
• Etcétera

1.3. Errores funcionales de la aplicación

Estos errores son los derivados del tratamiento de la información contenida en el mensaje aceptado por el sistema proveedor. Están directamente relacionados con el propio negocio de la mensajería y con el servicio en concreto.

PLAN DE ACTUACIÓN DE ERRORES DE MENSAJERÍA

2.1. Errores en la entrega del mensaje

Los sistemas responsables de formar y enviar la mensajería son los sistemas consumidores de los servicios. En el momento de realizar la entrega del mensaje pueden producirse problemas, como mini cortes en las comunicaciones, que impidan entregar el mensaje al sistema proveedor. Es responsabilidad del consumidor el definir los mecanismos que estime oportunos como medida a realizar cuando reciben un error en la entrega del mensaje.

La recomendación por parte de la OT-I es que sólo se de por finalizada la operación o recurso cuando se haya entregado.
Todos los servicios, independientemente de que estén definidos como síncronos o asíncronos, deben tener una respuesta para verificar que el mensaje se ha entregado correctamente y además cumple con una validaciones mínimas. En el caso de que se produzca algún problema en la comunicación, el propio protocolo de comunicación informará del error al origen de la emisión.

2.2. Errores en la validación de un mensaje recibido

Una vez que el mensaje es recibido por el sistema proveedor debe realizarse una validación sintáctica del mensaje. Esta validación se realizará a partir del esquema del mensaje, XSD, fichero que debe ser conocido por el sistema consumidor, junto con el contrato del servicio, y que cubrirá esquema, valores de los campos (opcionalidad y/o cardinalidad) y formato.

Cuando un mensaje supera la validación a realizar, el sistema proveedor debe generar un mensaje informando que la comunicación ha sido correcta. Por el contrario, si se produce algún problema en la validación, el sistema proveedor deberá generar un mensaje informando del error producido al sistema origen.

2.3. Errores en la validación de un mensaje recibido

Cuando el procesamiento desconectado de un mensaje genere o detecte un error funcional o semántico, caben dos posibilidades:

2.3.1. Error interno en la aplicación destino

Una vez entregado el mensaje, es responsabilidad del sistema receptor tratar el mensaje recibido. Durante el tratamiento del mensaje pueden darse errores del tipo tabla bloqueada, caída de BBDD, que deben ser informados al sistema que invocó el servicio.
Existen dos situaciones:

• Servicios síncronos: la respuesta del mensaje llevará información del error producido.
• Servicios asíncronos: se informará al sistema origen del error producido a través de un servicio asíncrono de notificación de error. Para ello, el sistema origen debe tener implementado el cliente del servicio para poder recibir dicha notificación.

2.3.2. Error provocado por el contenido del mensaje

Estos errores deben ser reportados al origen, se tratan básicamente errores provocados por la información contenida en el mensaje y que pueden provocar inconsistencia de datos entre los sistemas integrantes. Existen dos situaciones:

• Servicios síncronos: La respuesta del mensaje llevará información del error producido.
• Servicios asíncronos: se informará al sistema origen del error producido a través de un servicio asíncrono de notificación de error. Para ello, el sistema origen debe tener implementado el cliente del servicio para poder recibir dicho notificación.

CATÁLOGO DE ERRORES FUNCIONALES

Para conocer los errores funcionales que pueden presentarse en cada servicio debe consultarse el contrato de servicio correspondiente, donde se expondrán aquellos errores que sean propios del servicio. También, puede producirse algún error funcional que sea genérico para varios servicios existentes en el sistema de información proveedor. Para consultar estos últimos es necesario dirigirse al documento de elementos comunes del sistema.

IMPLEMENTACIÓN DE ERRORES PARA SERVICIOS SOAP

Una vez definida toda la política de gestión de errores, la cuál es independiente al tipo de Servicio Web, vamos a mostrar la implementación de errores necesaria para servicios web SOAP.

La respuesta de un servicio SOAP ante un error debe implementarse de dos formas diferentes según el error que se produzca:

• Errores desvinculados de la funcionalidad del servicio: dentro de esta implementación entran los errores de comunicación, los errores derivados de la validación del mensaje y los errores internos de la aplicación. Todos ellos serán implementados a través de soapFault, en su versión 1.2. (http://schemas.xmlsoap.org/soap/envelope/).
• Errores funcionales: todos aquellos derivados del tratamiento de la información obtenida del mensaje y que derivan en problemas como inconsistencia de datos, datos maestros no registrados en el proveedor. Estos errores se implementarán a través de un formato definido para ello.

ESQUEMA SITUACIÓN

Una vez definida la implementación según el tipo de servicio Web y el tipo de error se realiza resumen esquemático de las distintas posibilidades.

BIBLIOGRAFIA Y REFERENCIAS