Checkpoints
La implementación de Checkpoint se utiliza para capturar la relación causal entre "pseudo-eventos" que ocurren dentro de IPF.
El ProcessingContext contiene un campo actualizable checkpoint que se relaciona con un identificador único de un objeto de procesamiento de IPF dado.
ConnectorMessageMetadata
public class ConnectorMessageMetadata {
private String messageLogId;
private Checkpoint checkpoint;
private Checkpoint previousCheckpoint;
}
La clase ConnectorMessage contiene un elemento llamado ConnectorMessageMetadata. Este elemento de metadatos permite asignar ciertas propiedades al ConnectorMessage que se pasa entre las etapas del Connector sin influir directamente en el ProcessingContext del mensaje.
ReceiveConnector
Para un ReceiveConnector, el ProcessingContext del mensaje entrante se actualiza a través de las siguientes etapas del Connector:
-
CorrelationStage
-
Si el mensaje recibido contiene un processing context, cualquier processing context contenido en la correlación se fusionará con el contexto del mensaje. Consulte la documentación Context Merging para más detalles.
-
-
MessageLoggingStage (solo aplica si se proporciona un MessageLogger al connector)
-
El checkpoint del ProcessingContext del mensaje entrante se pasa al mensaje registrado.
-
Si el MessageLogger proporcionado es una instancia de CheckpointAwareMessageLogger, el
messageIdúnico de MessageLogEntry se asigna al campocheckpointdel ProcessingContext.
-
El ProcessingContext se persiste en el resto del flujo del Connector.
SendConnector
Para un SendConnector, el ProcessingContext del mensaje saliente se actualiza a través de las siguientes etapas del Connector:
-
Antes de cualquier etapa, cuando se crea la instancia de MessageDelivery
-
Se calcula un nuevo
messageIdy se asigna al campomessageLogIdde ConnectorMessageMetadata. -
Si el MessageLogger proporcionado es una instancia de CheckpointAwareMessageLogger, el
messageIdse asigna al campocheckpointde ConnectorMessageMetadata. -
El checkpoint del ProcessingContext de la SendRequest actual se asigna al campo
previousCheckpointde ConnectorMessageMetadata. -
Si está presente el campo
checkpointde ConnectorMessageMetadata, tanto el ProcessingContext de ConnectorMessage como el ProcessingContext del mensaje de destino (si el mensaje de destino es una instancia deUpdatebleProcessingContextHolder) se actualizan con este valor, creando un vínculo causal entre el objeto IPF previo y el ProcessingContext.
-
-
MessageLoggingStage (solo aplica si se proporciona un MessageLogger al connector)
-
previousCheckpointde ConnectorMessageMetadata se pasa al mensaje registrado y se usa como valor paraprocessingContext.checkpoint.
-
El ProcessingContext se persiste en el resto del flujo del Connector.
RequestReplySendConnector
Para un RequestReplySendConnector, el ProcessingContext del mensaje saliente puede actualizarse dependiendo de la instancia de MessageLogger proporcionada:
-
El MessageLogger proporcionado es una instancia de CheckpointAwareMessageLogger:
-
El ProcessingContext del mensaje saliente se actualiza en línea con la funcionalidad de SendConnector.
-
El ProcessingContext del mensaje de destino y el Processing Context de ConnectorMessage se actualizan para hacer Checkpoint al mensaje de log emitido.
-
El mensaje de log emitido para la solicitud se checkpointa al campo Checkpoint del ProcessingContext original.
-
-
Cuando el RequestReplySendConnector recibe una respuesta.
-
Se emite un mensaje de log, checkpointado al ID del mensaje de log emitido durante la fase de solicitud.
-
El Checkpoint de ConnectorMessage se actualiza al ID del mensaje de log emitido durante la fase de respuesta.
-
-
-
El MessageLogger proporcionado no es una instancia de CheckpointAwareMessageLogger o no se proporciona en absoluto:
-
El ProcessingContext de ConnectorMessage no se actualiza a lo largo del flujo del connector.
-
Ambos mensajes de log emitidos (si aplica) se checkpointan al Checkpoint del ProcessingContext desde la solicitud inicial.
-
El ProcessingContext se persiste en el resto del flujo del Connector.