Pago Scheduler

El objetivo principal es gestionar el FDP automático (Pago con Fecha Futura)scheduling comandos a demanda (crear, actualizar, eliminar). Esos comandos están relacionados con el scheduler en sí mismo, NO pagos, y se basan en MPS externo Domain Functions. Además, este concepto está utilizando el Persistent Scheduler para almacenarlo dentro de la base de datos.

El esquema general se representa aquí:

payment scheduler flow

Función de Programación

Esta función sirve para scheduler creación y en MPS, la solicitud se ve de la siguiente manera:

Nombre Descripción Business Data Respuestas

Schedule Request

Programe el FDP con el tiempo de antelación adecuado para activar correctamente la transferencia de crédito en la fecha de ejecución.

Hora programada

Nombre: Programar Respuesta Descripción: Respuesta a la solicitud Business Data: none Response Codes: AceptarORechazar Reason Codes: <no reasonCodeSet> Completar: verdadero

Dentro del MPS flujo, esta es una parte donde sucede:

scheduling flow mps

Ahora, examinemos el código. La primera parte es un generado MPS puerto de acción, que necesita ser implementado:

public interface PaymentSchedulerActionPort {

    CompletionStage<Void> execute(ScheduleRequestAction scheduleRequest);

}

La implementación es una parte clave aquí:

@Slf4j
@AllArgsConstructor
public class SamplePaymentSchedulerAdapter implements PaymentSchedulerActionPort {

    SchedulingModuleInterface schedulingModuleInterface;

    @Override
    public CompletionStage<Void> execute(ScheduleRequestAction scheduleRequest) {
        var cron = CronExpressionHelper.calendarToCron(scheduleRequest.getScheduledTime());
        var jobSpecification = JobSpecificationDto.builder()
                .jobSpecificationKey(new JobSpecificationKeyDto("DEBTOR_CT_JOB_ID"))
                .schedulingSpecification(cron)
                .jobRequestor(scheduleRequest.getId())
                .triggerCommand(new PaymentSchedulerCommand(scheduleRequest.getId()))
                .triggerIdentifier("triggerIdentifier")
                .build();
        return schedulingModuleInterface.scheduleJob(jobSpecification);
    }
}

Puede notar que hemos instanciado nuestro comando dentro del parámetro triggerCommand. Ese comando se presenta a continuación:

@Data
@AllArgsConstructor
public class PaymentSchedulerCommand implements SchedulingCommand {
    private String id;
}

Parece bastante básico, como podemos ver, es solo un parámetro de ID dentro de él. Implementa SchedulingCommand interfaz de compartido-scheduling biblioteca. Hablando de esa biblioteca, hay otra interfaz que debe utilizarse para trabajar:

public interface SchedulingHelper {

    CompletionStage<Void> execute(String id, final SchedulingCommand request);

    boolean supports(SchedulingCommand request);
}

Nuestra implementación está aquí:

@Slf4j
@RequiredArgsConstructor
public class PaymentSchedulerHelper implements SchedulingHelper {

    @Override
    public CompletionStage<Void> execute(String s, SchedulingCommand schedulingCommand) {
        PaymentSchedulerCommand paymentSchedulerCommand = (PaymentSchedulerCommand) schedulingCommand;
        return CredittransferDomain.paymentScheduler()
                .handle(new ScheduleResponseInput.Builder(paymentSchedulerCommand.getId(), AcceptOrRejectCodes.Accepted).build())
                .thenAccept(it -> log.debug("Scheduled"));
    }

    @Override
    public boolean supports(SchedulingCommand schedulingCommand) {
        return schedulingCommand instanceof PaymentSchedulerCommand;
    }
}

Último, pero no menos importante, necesitamos tener un bean definido, que devolverá una instancia de nuestra implementación SchedulingHelper:

@Bean
public PaymentSchedulerHelper paymentSchedulerHelper() {
    return new PaymentSchedulerHelper();
}