Una conexión FIX puede recuperar su secuencia de mensajes esperada mientras que un orden todavía necesita investigación. El estándar de sesión de la Comunidad de Comercio FIX describe solicitudes de reembolso, indicadores duplicados y reajustes de secuencias. Esos mecanismos rigen la entrega de mensajes y recuperación; no reemplazan la necesidad separada de un corredor para determinar qué eventos empresariales fueron recibidos, procesados y reflejados en el registro de pedidos. FIX Trading Community: FIX Session Layer estándar técnico, junio 2020
Seguir las pruebas
Trace cómo el evento podría llegar a los mercados, y luego inspeccionar una explicación competitiva.
Compare las explicaciones
Intercambiar lentes para ver lo que explica cada cuenta, y lo que sigue siendo incierto.
Análisis WFN: supone que un corredor envía un pedido, pierde su conexión y vuelve a conectarse antes de que su sistema local haya registrado la respuesta. Varios estados son posibles: la contraparte nunca recibió el orden, lo aceptó, lo rechazó o ejecutó alguna cantidad. Restaurar la sesión por sí sola no identifica qué estado ocurrió. Eso requiere evidencia vinculada al orden y los registros de negocio de la contraparte.
Análisis WFN: supone que un corredor envía un pedido, pierde su conexión y vuelve a conectarse antes de que su sistema local haya registrado la respuesta. Varios estados son posibles: la contraparte nunca recibió el orden, lo aceptó, lo rechazó o ejecutó alguna cantidad. Restaurar la sesión por sí sola no identifica qué estado ocurrió. Eso requiere evidencia vinculada al orden y los registros de negocio de la contraparte.
Un útil comentario de incidentes registra la brecha de secuencia, el rango de reenviamiento, los mensajes de repetición y desactivación, luego los conecta a los identificadores de pedidos, identificadores de ejecución y cantidades acumuladas. Cuando la evidencia permanece incompleta, el estado de negocios no resuelto debe permanecer visible. Declarar un incidente cerrado porque el socket está conectado puede ocultar la pregunta que realmente importa la exposición del cliente.
Qué sesión de recuperación está diseñada para hacer
Los mensajes de FIX llevan números de secuencia. Una solicitud de reenviamiento pide mensajes dentro de un rango de secuencia especificado. Los mensajes repetidos usan indicadores duplicados, y un mensaje de secuencia en modo de archivo de brecha puede cubrir mensajes que no serán resentidos. El estándar distingue que el uso de recuperación de reajustar una secuencia después de una condición inalcanzable. FIX Trading Community: FIX Session Layer estándar técnico, junio 2020
Por lo tanto, un relleno de brecha no es un informe de ejecución de reemplazo. Avanza la comprensión de secuencias de la sesión sobre un rango, sin recrear un evento de negocios omitido. Esta distinción es central cuando se evalúa una conexión recuperada: recuperación de secuencias exitosas y un historial completo de pedidos de nivel de aplicación son preguntas diferentes. FIX Trading Community: FIX Session Layer estándar técnico, junio 2020
Una desconexión hipotética expone el límite
Análisis WFN: supone que un corredor envía una orden, pierde su conexión y vuelve a conectarse antes de que su sistema local haya registrado la respuesta. Varios estados son posibles: la contraparte nunca recibió la orden, la aceptó, la rechazó o ejecutó alguna cantidad. Restaurar la sesión por sí sola no identifica qué estado ocurrió. Eso requiere evidencia vinculada a la orden y los registros comerciales de la contraparte.
La presentación de la misma instrucción empresarial como nuevo orden puede crear un problema diferente de un mensaje perdido. Un diseño de recuperación necesita una manera de reconocer si una instrucción o ejecución ya se procesa, utilizando los identificadores pertinentes y el flujo de trabajo acordado. Los números de secuencia ayudan a explicar la historia del transporte; no deben ser tratados como un sustituto universal de la identidad comercial.
Los informes de ejecución repetidas requieren un cuidado similar. La aplicación receptora debe distinguir un mensaje que se ve de nuevo de un relleno realmente nuevo. Un panel que simplemente cuenta cada mensaje recuperado como un nuevo evento podría inflar la actividad o distorsionar posiciones, aunque el motor FIX haya restaurado su secuencia correctamente.
Revisar el resultado de la recuperación en ambas capas
Una revisión útil de incidentes registra la brecha de secuencia, el rango de reenviamiento, los mensajes de repetición y de filo de brecha, luego los conecta a ordenar identificadores, identificadores de ejecución y cantidades acumuladas. Cuando la evidencia permanece incompleta, el estado de negocio no resuelto debe permanecer visible. Declarar un incidente cerrado porque el socket está conectado puede ocultar la pregunta que realmente importa la exposición al cliente.
Prueba de recuperación contra escenarios realistas como un relleno parcial antes de una desconexión, un mensaje de repetición indisponible o una aplicación reiniciada después de la recepción. El objetivo es establecer el estado de pedido final una vez, con una historia explicable. Este artículo ofrece un marco de revisión, no una prescripción para restablecer sesiones en vivo; los cambios operacionales dependen de la versión FIX acordada y los procedimientos contrapartes.