| Fecha Evento |
|
|---|---|
| Fecha Documento |
|
| Estado del Documento |
|
| Versión | 230315.2 |
| 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, validando el mensaje 1A.
2- El 2A destino va a Kaarupora para su validación. Kaarupora responde OK, validando el mensaje 2A. (Y por la forma en la que implemento el Participante, realiza el crédito. Comportamiento similar 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 débito.
5- El 3B destino se envía 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 cancelación.
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 cancelación, 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 que el mensaje 3B con la cancelación, 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.
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.