[FOR_SIS06 Incidente ]

AUTOR

DESCRIPCION [Descripcion detallada del evento]

Se verificó un problema para transaccionar con el participante 1600.
Las peticiones iban al autorizador, se procesaban en CEIBO pero no se tenía una respuesta hacia el SICOOP lo que hacía que se cancele la operación.

Se reportaron problemas con las transacciones DIMO/SICOOP, el usuario DIMO no podía realizar transacciones desde o hacia sus TCs/TPs.

BITACORA [Bitacora de sucesos y tareas realizadas]

En fecha 12/12/2022 14:30:00 aprox. se reporta un problema con las transacciones DIMO/SICOOP. El escenario reportado indicaba que el CEIBO aprobaba las transacciones pero el SICOOP las rechazada.--

Analizando mas a fondo de identifico que todas las transacciones que involucraban al participante 1600 y 3601, ya sea como origen o como destino eran rechazadas por el SICOOP pero procesadas correctamente en CEIBO.--

Se identifico que estos escenarios se debían a una demora en el circuito de procesamiento api-autorizador→autorizador-ws→autorizador/ceibo. Se identificaron demoras significativas entre una operación y la siguiente ejecutada por el circuito de autorización (api-autorizador→autorizador-ws-→autorizador/ceibo). Esto explicaba el comportamiento del SICOOP que rechazaba la transacción, básicamente por la demora en recibir la respuesta de la transacción por parte del API-autorizador.--

No se reportaron ni se identificaron problemas con el procesamiento de tarjetas que ingresan por la ISO 8583. Con lo cual descartamos los elementos involucrados en el circuito de Autorización de la ISO de TCs/TPs.--

Tampoco se reportaron problemas con las transacciones que involucraban al XPRESS desde Caja de Ahorro a Banco, ni de Banco a Caja de Ahorro. Con lo cual descartamos todos los elementos involucrados en el circuito XPRESS. Esto reforzó la teoría que el problema se centraba en el circuito api-autorizador→autorizador-ws→autorizador/ceibo.--

Revisando el Gateway SICOOP, las transacciones con el fallo tenían el mensaje: "GW131", "txtRespuesta": "Problemas de conexion, intente mas tarde por favor".--

Se revisaron los logs de los Backend de DIMO/SICOOP donde se identifico este mensaje:

2022-12-12 15:38:37,432 INFO [DailyLogger] (default task-17827) AuthorizatorServiceLogger|advances= Se realizo la transaccion de advances, con el request: Request(pan=6043610000000069, terminalId=SICOOP1, amount=10000000, posEm=0100, currencyCode=830, transactionDateTime=12122022153702, rrn=016708702227734, uuid=04b2a620ed341b797eb8acb713f087953495291b, aditionalParameters=[]) - UserData(user=SICOOP, customerIdCabal=9300003, networkCode=10000000023, idAccess=20052020, userAccess=SICOOP) y con el response: Response(exitCode=-1, messageCode=Ocurrio un error al intentar ejecutar la autorizacion. Contacte con el Administrador, authorizationNumber=, authorizationResponse=)
2022-12-12 15:38:37,432 INFO [stdout] (default task-17827) Error con la ejecucion del metodo del autorizador. Paso 1
2022-12-12 15:38:37,432 ERROR [stderr] (default task-17827) py.com.cabal.proxyAutorizador.config.exception.TransacctionException: Error con la ejecucion del metodo del autorizador. Paso 1: Ocurrio un error al intentar ejecutar la autorizacion. Contacte con el Administrador.

Al no identificarse de forma exacta el origen del problema y con el objetivo de dar una pronta solución, se solicito a Infraestructura reiniciar los servicios de DIMO (Backend1 y Backend2) y el servicio del Autorizador-Ws que esta localizado en otro servidor (10.5.1.33). Sin resultado positivo, el problema persistía.--

Se recurrió a Tesabiz para buscar algún inconveniente en el Gateway SICOOP, y tampoco identificaron nada nuevo que pueda aportar luz a la investigación.--

Dado que ninguna de las medidas ejecutadas hasta ese momento dieron resultado positivo, y ya con el objetivo de cortar el escenario con fallo se configuro el Gateway SICOOP de modo a rechazar las peticiones que iban dirigidas al participante 1600 (CABAL) y 3601 (PANAL) como origen o como destino.--

Prosiguiendo con el objetivo de ir descartando el origen de las demoras en el procesamiento de las transacciones, se recurrió a Edgar Rojas de modo a realizar pruebas en el CIEBO. Las pruebas realizadas mostraron que los tiempos de ejecución estaban dentro de lo esperado (menos de 1seg); descartando con esto algún problema con la función del autorizador y con la Base de Datos Oracle.--

Ya como ultima medida, se solicito a Infraestructura reiniciar físicamente el servidor que alojaba el Autorizador-Ws, y luego de realizar pruebas se confirmo que el problema fue resuelto.--

Cabe mencionar que el Autorizador-ws tuvo su ultima modificación el 15-junio-2022 (hace aprox. 5 meses). Tampoco se alteraron datos ni parámetros del Autorizador/CEIBO, durante el proceso de investigación.--

Finalmente, NO se identifico con precisión el origen el problema.--

SOLUCION APLICADA [Indicar la solucion rapida aplicada]

Como primera medida se re-inicio el servicio del Autorizado-Ws, sin resultado positivo, el problema persistía. Finalmente, se solicito reiniciar físicamente el servidor que aloja al Autorizador-WS.--

SOLUCION DE FONDO [Recomandaciones para resolver o mitigar]

Al no identificarse el origen del problema, recomiendo aplicar las siguientes medidas para mitigar la reaparición de este tipo de incidentes:

1. Actualizar el Autorizador-Ws de modo a trabajar con la ultima versión del servidor de aplicaciones Wildfly.--

2. Agregar a nivel de código, logs para mejor monitoreo de las actividades del Autorizador-Ws. Mismo para el API-Autorizador.--

3. En el API-Autorizador, aplicar reverso automático ante demoras del Autorizador-Ws.--

4. Implementar el modulo Autorizador-Ws en 2 servidores, para balanceo y redundancia.--

5. Implementar monitoreo a nivel de Hardware, Sistema Operativo y Base de Datos para la medición de uso de recursos de memoria RAM, swap, almacenamiento, CPU y conexiones de RED.--

6. Aplicar tunning de parámetros al Tomcat/Java, mismo para los servidores que operan con Wildfly.--

7. Realizar tunning de parámetros a nivel de Sistema Operativo.--