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 origen message type(ejecutarSolicitudDePago)

  • firstEventTime - el tiempo que el primero event se registró la transacción

  • lastProcessedEventTime - el tiempo más reciente event se registró la transacción

  • lastEventName - el más reciente event nombre

  • 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 event detalles del resumen para todos los events sobre la transacción

  • payload - la carga útil para la transacción, según el 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 los datos recibidos en custom events. 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.

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

  • tipoDeMensajeOrigenProveedor-esto es necesario para especificar el nombre (de la message log) del mensaje inicial 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 utilizarse para realizar búsquedas.

  • getInitiatingTimestampFrom-por defecto, esto utiliza la hora de createdAt del primero event recibido, pero puede ser anulado para utilizar los datos de cualquier event.

  • getOriginatingIdFrom-por defecto, esto utiliza el commandId del primero event recibido, pero puede ser anulado para utilizar los datos de cualquier event.

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 un 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 transacción cache, 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