Tratamiento de excepciones en mensajes HTTPX (Por ejemplo error 500)
Si bien se puede aplicar la siguiente metodología para distintos tipos de excepciones, se lo explicará en base al ejemplo de un error 500:
Los siguientes son ejemplos de mensajes y de lo que devuelve cada uno:
- Error 500 sin datos / error de conexión (sin transformación)
Mensaje: HTTPX|HTTP_GET|http://localhost/SvcEngage5904/SvcEngageRest.svc/rest/ThrowException|10|00204434-B8EB-487E-AFFE-B3DB8327E66C|94983b69-79dc-488c-8175-b91941339fa2|rolandob||ExceptionMessage=|AsFaultException=False[EOM]
Información en el archivo de log:
- Error al recuperar la respuesta HTTP [No es posible conectar con el servidor remoto].
- No es posible conectar con el servidor remoto
Respuesta transacción: ERROR|No es posible conectar con el servidor remoto
- Error 500 con datos de error, pero en blanco (sin transformación)
Mensaje: HTTPX|HTTP_GET|http://localhost/SvcEngage5904/SvcEngageRest.svc/rest/ThrowException|10|00204434-B8EB-487E-AFFE-B3DB8327E66C|94983b69-79dc-488c-8175-b91941339fa2|rolandob||ExceptionMessage=|AsFaultException=False[EOM]
Información en el archivo de log:
- Error al recuperar la respuesta HTTP [Error en el servidor remoto: (500) Error interno del servidor.].
- Error en el servidor remoto: (500) Error interno del servidor.
Respuesta transacción: ERROR|Error en el servidor remoto: (500) Error interno del servidor.
- Error 500 con datos de error, pero con contenido (sin transformación)
Mensaje: HTTPX|HTTP_GET|http://localhost/SvcEngage5904/SvcEngageRest.svc/rest/ThrowException|10|00204434-B8EB-487E-AFFE-B3DB8327E66C|94983b69-79dc-488c-8175-b91941339fa2|rolandob||ExceptionMessage=Test Error 500!|AsFaultException=False[EOM]
Información en el archivo de log:
- Error al recuperar la respuesta HTTP [Error en el servidor remoto: (500) Error interno del servidor.].
- Información del error de la respuesta HTTP [{“Message”:”Test Error 500!”,”MethodName”:”ThrowException”,”TimeStamp”:”\/Date(1594127553079-0300)\/”}].
- Error en el servidor remoto: (500) Error interno del servidor.
Respuesta transacción: ERROR|Error en el servidor remoto: (500) Error interno del servidor.
- Error 500 con datos de error, pero con contenido (con transformación)
Mensaje: HTTPX|HTTP_GET|http://localhost/SvcEngage5904/SvcEngageRest.svc/rest/ThrowException|10|00204434-B8EB-487E-AFFE-B3DB8327E66C|94983b69-79dc-488c-8175-b91941339fa2|rolandob|TEST_FAULT_500|ExceptionMessage=Test Error 500!|AsFaultException=False[EOM]
Información en el archivo de log:
- Error al recuperar la respuesta HTTP [Error en el servidor remoto: (500) Error interno del servidor.].
- Error en el servidor remoto: (500) Error interno del servidor.
INSERT INTO TEST_FAULT_500_DATA (METHOD_NAME, MESSAGE, TIME_STAMP, PKEY, PAR_KEY, TS_BEGIN, TS_END, TS_USER_ID) VALUES (‘ThrowException’, ‘Test Error 500!’, ’07/07/2020 10:13:07′, ‘a6cc096f-8e90-43b7-a437-d1b94e05a92d’, ‘00204434-B8EB-487E-AFFE-B3DB8327E66C’, Getdate(), Getdate(), ‘rolandob’)
Respuesta transacción: ERROR|Error en el servidor remoto: (500) Error interno del servidor.
Resumiendo conceptualmente:
- Ante un error 500, el mensaje de respuesta de EIS a la transacción siempre será “ERROR|Descripción”.
- Si no viene información asociada al error 500, haya o no haya transformación (ejemplos de mensajes 1 y 2) -> en el log de EIS sólo se registrará la descripción del error.
- Si viene información asociada al error 500 y no hay transformación (ejemplo de mensaje 3) -> en el log de EIS se registrarán la descripción del error y los datos asociados.
- Si viene información asociada al error 500 y además se utiliza una transformación (ejemplo de mensaje 4) -> en el log de EIS se registra la descripción del error y a los datos asociados se les aplica la transformación indicada, persistiéndose los datos de error en la base de datos.
A partir de 2020.1.1 Patch 1 Acumulativo, las transformaciones de FAULTS están disponibles también para HTTPX.
Se explica muy brevemente:
- En el mensaje a EIS se informa la transformación que se aplicará sobre los datos recibidos.
- Dentro de esa transformación, hay un tag que se llama “OnFaultException”, y en el atributo “CallTransformation” se informa el ID de transformación que se aplicará sobre los datos en caso de error. En el ejemplo adjunto, se informa “TEST_FAULT_500” en el mensaje, pero en caso de error se utiliza “TEST_FAULT_500_CONTENT”.
- En la transformación de FAULT se puede usar una clase de serialización basada en JSON, y para que la deserialización funcione hay que tomar los siguientes recaudos:
- En el tag “JSONSerialization” siempre debe decir “.” en el atributo “Source”
- En el tag “Output” siempre debe decir “Result.Message” en el atributo “SourceData”