AUTOR
| Fecha Evento |
|
|---|---|
| Fecha Documento |
|
| Estado del Documento |
|
| Autor | Arturo Sosa |
| Informador | |
| Version | 230315.1 |
| Ticket | 3465 |
| Resumen | Informe de lo sucedido con Kaarupora |
...
DESCRIPCION
Escenario específico del error: para las trx reclamadas inicialmente por el Participante. IdSesion:bd1519b3381640ba1e2a485f6ce170de48df8ba0, IdSesion:585eaf5fad3dd664e50fae5a01c6f5f9e6fe5a0b
1- El 1A origen va a Ñemby para su validación. Ñemby responde OK.
2- El 2A destino va a Kaarupora para su validación. Kaarupora responde OK. (Y por la forma en la que implemento el Participante, realiza el credito. Comportamiento similiar al participante 1600).
3- Ocurre un error interno en el Sicoop Server. codRespuesta=S025, txtRespuesta=Error en procesamiento de la orden.
4- El 4A origen se envía a Ñemby, para que no ejecuten el débito. El participante no realiza el debito.
5- El 3B destino se envia a Kaarupora, para que no ejecuten el crédito (según la implementación del participante, al recibir la mensajería realiza el reverso). Pero el participante no ejecuta el reverso por que no recibe el mensaje 3B con la orden de cancelacion.
El flujo normal de mensajerías es la sgte.: un mensaje normal que se envía del GW llega a su servidor por el software de integración, se envía al software de Kernel y luego al api del Participante que impacta en su core.
Haciendo el seguimiento de la transacción, en los servidores de kaarupora, según sus logs llegamos a la sgte conclusión: En el escenario especifico donde se da el error luego de la confirmación del 2A y siendo el Participante Originante distinto a Kaarupora, el mensaje 3B que debe indicar la orden de cancelacion, no llega a su api.
Las evidencias de esto están en los logs de los servidores de Kaarupora. Donde se evidencia que:
- El software de integración de Cabal loguea el Request y Response del mensaje del 3B.
- El software de Kernel solo loguea el Request 3B, no asi el response.
- La api de Kaarupora no loguea el Request del 3B, por lo que concluimos el que mensaje 3B con la cancelacion no llega al api de Kaarupora.
Cabe destacar que ante el mismo escenario de error, donde Kaarupora también es el origen si les llega el 3B y si ejecutan el reverso.
...
BITACORA
28/02/23 10:36 - Recibo el llamado de Victor, funcionario del Participante Kaarupora para consultar respecto a 2 transacciones de 3 millones que no fueron debitados en el origen pero si acreditados por parte de Kaarupora. Hago la revisión de la mensajería correspondiente e informo del caso a OperacionesDimo y a mi Superior.
28/02/23 11:02 - Recibo respuesta de OperacionesDimo:
...
28/02/23 12:08 - Me escribe Gustavo Amarilla, funcionario del Participante, para preguntarme sobre lo ocurrido y le dije lo sgte.:
Invitándoles que este presente también su desarrollador externo. (También le dije lo mismo a Víctor por llamada)
...
01/03/23 09:08 - Se contacta devuelta Gustavo para agendar la reunión para el dia sgte., con el desarrollador externo presente.
02/03/23 10:07 - Tuvimos una reunión virtual con las sgtes personas presentes.:
...
Al terminar remito un resumen a OperacionesDimo (11:07)
y una minuta de lo conversado con el participante.
...
14/03/23 - Recibo una comunicación por parte de Víctor, volviendo a insistir con dar de baja el servicio. Comunico la intención del Participante lo que dispara todos los correos sgtes. respecto a este tema.
...
SOLUCION
...
RECOMENDADA
1- Trabajar con el desarrollador externo para hacer la conexión directa sin Kernel, atendiendo que no tenemos el código fuente para debuguear su aplicación y que ese mismo ejercicio ya lo habíamos resuelto satisfactoriamente con el mismo desarrollador pero con otro Participante (Barriojarense).
2- Aprovechar que el desarrollador externo iba a trabajar con Kaarupora, para implementar también todas las transacciones que Kaarupora rechaza en producción.
...
SOLUCION DE
...