Registro y trazabilidad central

Para que una petición se pueda atribuir, la línea del registro central necesita cuatro cosas: qué credencial la presentó (la clave virtual), qué aplicación la mandó, en nombre de quién (el usuario final, que la aplicación pasa en una cabecera porque la pasarela no lo conoce) y un identificador de petición que la pasarela devuelve y la aplicación guarda en su propio registro. Con eso se cruza en los dos sentidos: de la queja a la aplicación, de la aplicación a la pasarela.

Añade el modelo que respondió de verdad (que puede no ser el pedido si entró un alterno), el consumo y el resultado. El contenido de los mensajes es otra decisión: si se guarda, se guarda aparte, enmascarado, con retención corta y acceso restringido, porque un registro central con todo el texto de la empresa es en sí mismo un dato sensible.

La pasarela no sabe quién está al otro lado de una aplicación: lo sabe la aplicación, y tiene que decirlo en cada petición. Si no lo hace, la línea queda con la aplicación pero sin persona, y la investigación se detiene en «fue el sistema». Distingue un fallo puntual de una aplicación que nunca lo envía.

El reclamo da un cliente y una hora. El registro de la aplicación une ese cliente con su operador y con el identificador de la pasarela. Sigue la cadena sin saltarte un eslabón: de la línea que encuentres en la pasarela saldrá qué modelo hizo el resumen, y ese dato abrirá la siguiente pregunta de la investigación.

Para dimensionar el hueco de trazabilidad, cuenta las peticiones de la ventana que no tienen usuario final, vengan de la aplicación que sea. Un error del proveedor también es una petición y también cuenta.