Definiendo El Lado De Lectura

El ipf-read-starter proporciona una configuración base de mongo que puede ser extendida para su uso en implementaciones. El lado de lectura admite múltiples flujos diferentes que se ejecutan con un solo lado de lectura.

La clave para la configuración del lado de lectura es la clase abstracta 'MongoReadModelEntity'. Proporciona:

  • persistenceId - el identificador de persistencia (el ID de IPF, por ejemplo, Payoutflow|ABC)

  • originatingId - el identificador de origen del flujo (por ejemplo, UPRID)

  • originatingMessageType - el tipo de mensaje de origen (por ejemplo, ExecutePaymentRequest)

  • firstEventTime - el momento en que se registró el primer evento en la transacción

  • lastProcessedEventTime - el momento en que se registró el evento más reciente en la transacción

  • lastEventName - el nombre del evento más reciente

  • initiatingTimestamp - cuando se inicie el flujo

  • alternativeIds - una lista de identificadores alternativos por los que la transacción puede ser conocida

  • eventSummaries - una lista de detalles resumidos de eventos para todos los eventos en la transacción

  • payload - el payload para la transacción, según la API (por ejemplo, podría ser CreditTransferPayload, ReturnsPayload, etc.)

La implementación de esta clase, si es específica de la aplicación, depende de ser poblada por datos recibidos en custom eventos. Por esta razón, es necesario que la aplicación proporcione la implementación concreta. Para hacer esto, será necesario implementar los siguientes métodos:

    protected abstract Supplier<T> payloadCreator();

    protected abstract BiFunction<Event, T, T> payloadUpdater();

  • payloadCreator-esto es necesario para proporcionar una nueva instancia del tipo de carga.

  • actualizadorDeCarga-esto es necesario para determinar cómo el evento dado debe actualizar la carga útil actual.

  • tipoDeMensajeOrigenProveedor-esto es necesario para especificar el nombre (del registro de mensajes) del mensaje iniciador para el flujo.

Además de los 3 métodos anteriores, hay una serie de métodos que tienen implementaciones predeterminadas que pueden ser anuladas:

    protected Set<String> getAlternativeIdsFrom(Event event) {
        return Collections.emptySet();
    }

  • getAlternativeIdsFrom - Al devolver por defecto una colección vacía, este método debe extraer cualquier id que deba ser utilizado para realizar búsquedas.

  • getInitiatingTimestampFrom - Por defecto, esto utiliza la hora de createdAt del primer evento recibido, pero puede ser anulado para utilizar los datos de cualquier evento.

  • getOriginatingIdFrom - Por defecto, esto utiliza el commandId del primer evento recibido, pero puede ser anulado para utilizar los datos de cualquier evento.

Una vez que se haya creado la implementación concreta de MongoReadModelEntity, debe registrarse creando una fábrica que determinará qué implementación debe utilizarse en función del ID de IPF que se reciba.

public interface ReadModelEntityFactory {
    ReadModelEntity create(String persistenceId);
}

com.iconsolutions.ipf.platform.read.transaction Esto debe ser registrado como una Spring bean.

Ejemplo

A continuación se muestra un ejemplo de implementación de MongoReadModelEntity.

@Data
@AllArgsConstructor
public class TestCreditTransferTransactionReadModel extends MongoReadModelEntity<CreditTransferPayload> {


    @Override
    protected Supplier<CreditTransferPayload> payloadCreator() {
        return () -> CreditTransferPayload.builder().build();
    }

    @Override
    protected BiFunction<Event, CreditTransferPayload, CreditTransferPayload> payloadUpdater() {
        return (evt, returnPayload) -> {
            if (evt instanceof TestFIToFICustomerCreditTransferEvent) {
                returnPayload.setCreditTransfer(((TestFIToFICustomerCreditTransferEvent) evt).getCreditTransfer());
            }
            return returnPayload;
        };
    }

}

Para registrar esto, creamos la fábrica:

@Slf4j
public class ReadModelEntityTestFactory implements ReadModelEntityFactory {

    @Override
    public ReadModelEntity create(String persistenceId) {
        log.debug("PersistenceId found on read side: {}", persistenceId);
        return new ReadSideFlowTestModel();
    }
}

Indexación

El ipf-read-starter tiene una configuración predeterminada para crear automáticamente MongoDB índices en la inicialización.

La creación de índices predeterminados puede ser desactivada con:

ipf.read-starter.mongodb.create-indexes=false

Los índices pueden ser deshabilitados globalmente con:

ipf.mongodb.create-indexes=false

Para deshabilitar la indexación globalmente pero mantenerla para la caché de transacciones, aplique lo siguiente, manteniendo el orden:

ipf.mongodb.create-indexes=false
ipf.read-starter.mongodb.create-indexes=true

Compromiso de Quórum

El quórum de confirmación puede ser controlado de manera similar con:

ipf.read-starter.mongodb.commit-quorum=1

O bien anulado globalmente con:

ipf.mongodb.commit-quorum=1