De

<keywords content="keywords"> errores, error, capa SOA, invocacion, servicio web, </keywords>

Asuntos de la Capa SOA

Manejo de Error en la Invocación de Servicios Web

La capa SOA ofrece características transaccionales para las acciones realizadas en los servicios expuestos para el manejo de error. Entonces, un rollback automático de las transacciones activas será desarrollado cuando se detecta inconsistencias de datos durante una inserción o actualización de las entidades. La característica rollback no permite almacenar información inconsistente en la base de datos.

El mensaje de la excepción generada se encontrará en la salida xml cuando un error o excepciones son lanzadas durante la invocación del servicio. La salida xml se mostrará también en la sección del documento de entrada xml donde el error ocurrió.

La salida xml para aquellos métodos que realizan inserciones y actualizaciones junto con la clasificación de caso automática se muestra a continuación.

Las inserciones en la entidad relacionada ClientVariableData son ilustradas en el documento mostrado abajo; una cadena es pasada en el atributo idMaritalStatus correspondiente al id de la entidad paramétrica de tipo entero. Esta clase de tipo de datos de errores de correspondencia son detectados por la capa SOA, la cual lo muestra en la salida xml.

El mensaje de error incluye los siguientes tags:

<Node>: Este tag muestra el número de nodo donde el error fue generado.

<Path>: Este tag muestra el camino de la información en el documento xml donde la excepción fue generada; la entidad raíz V_ClientRequest y idClientVariableData son mostradas en el ejemplo.

<Atrib>: Este tag se refiere al atributo procesado.

<Value>: El valor a ser asignado al atributo mencionado está contenido en este tag.

<ErrorMessage>: El mensaje de la excepción generada es mostrado en este tag.

De forma similar, los tags enlistados abajo pueden observarse luego que el nodo <Error> se cierre.

<V_ClientRequest> con valores de 665 y 666, lo que significa que el documento de entrada contiene 3 nodos de los cuales el primero generó la excepción y los otros dos tags no mostraron alguna inconsistencia durante la inserción de datos; entonces, esos tags fueron grabados satisfactoriamente en la base de datos y las llaves generadas para estos nodos fueron 665 y 666, respectivamente. La información correspondiente al primer nodo no fue insertada por alguno de sus niveles porque un rollback de la transacción fue ejecutado cuando la excepción fue lanzada.

El documento de entrada xml es presentado para archivar los casos a través de la capa SOA; asimismo, un campo entero fue puesto en la cadena de caracteres.

La salida generada indica la causa de la excepción, el camino, el atributo evaluado y su valor. Adicionalmente, el nodo evaluado que genera el error entre los tags <NodeInformation> es mostrado; añadiendo la llave se puede habilitar esta última característica.

<add key = "returnSoaNodeInfo" value = "0"/> en web.config y cambiando su valor a 1

Otras Ventajas de Usar Llaves de Negocio

Los registros ids deben conocerse mediante el método usado para actualizar los atributos de entidad. Saber si la información existe en la base de datos de Bizagi  puede llevar a una complejidad inherente. Basándose en este escenario, la capa SOA permite a través del uso de llaves de negocio realizar una búsqueda del registro requerido. La capa SOA inserta el registro con los valores provistos cuando el registro no existe; de lo contrario, el registro es actualizado con los valores respectivos si la llave de negocio coincide.

El número de identificación de cliente usado como llave de negocio en el documento xml se muestra a continuación. La capa SOA realizará una búsqueda restringida del número de identificación del cliente. Los registros serán actualizados si uno de los registro coincide con la llave y un error será generado si muchos registros contienen la misma llave. El registro será insertado cuando la llave no coincida con algún registro existente. La salida xml retornará surrogateKeyValue del registro para inserciones o actualizaciones.

Saber con anterioridad los ids de las entidades paramétricas es requerido para insertar, actualizar y guardar las operaciones realizadas en las entidades maestras. La llave de negocio puede ser una alternativa cuando los ids de entidades paramétricas son desconocidos; por ejemplo, el nombre corto de una tarjeta de identidad nacional puede ser C y única para una entidad paramétrica del tipo de documento. Este criterio puede ser usado para fijar la entrada xml y reemplazar los ids de Bizagi asociados a los datos paramétricos. UN ejemplo de esta situación se muestra a continuación.

Los valores en la entidad maestra Cliente son ingresados y se usa la llave de negocio para los campos que contienen la entidad paramétrica, tal como tipo de identificación, sexo y estado civil. <comments />