Independiente Scheduler

El Persistent Scheduler puede ser incorporado en su aplicación como un embedded dependencia (ver Embedded Implementación). Alternativamente, el Persistent Scheduler puede configurarse como una aplicación independiente con un HTTP interfaz para interacciones entrantes y un Kafka publisher para scheduled trabajos.

Con la configuración independiente, usted puede:

  1. Enviar scheduling solicitudes superiores a HTTP a su Scheduling aplicación

  2. Tenga su scheduling las solicitudes se ejecutan a la hora indicada

  3. Publique el scheduled comando en Kafka

  4. Consuma el comando de Kafka y maneje la carga útil en su aplicación consumidora

Esta página no cubre cómo enviar solicitudes a través de HTTP. Eso está cubierto en Programe su primer trabajo

Paso 1: Agregue dependencias al Scheduling Aplicación

Para configurar su aplicación independiente, deberá agregar las siguientes dependencias en su aplicación.pom.xml:

<dependencies>
    <dependency>
        <groupId>com.iconsolutions.ipf.core.platform</groupId>
        <artifactId>scheduler-http-controller</artifactId>
    </dependency>
    <dependency>
        <groupId>com.iconsolutions.ipf.core.platform</groupId>
        <artifactId>scheduler-external-trigger-kafka</artifactId>
    </dependency>
</dependencies>

El scheduler-http-controller el artefacto introduce el HTTP controlador y el core Scheduler funcionalidad.

El scheduler-external-trigger-kafka el artefacto publicará el scheduled comando a un predefinido Kafka tema.

Paso 2: Agregue dependencias a la aplicación consumidora

En su aplicación que manejará el scheduled carga útil, deberá agregar las siguientes dependencias a la pom.xml:

<dependency>
    <groupId>com.iconsolutions.ipf.core.platform</groupId>
    <artifactId>scheduler-external-trigger-kafka</artifactId>
</dependency>

Este artefacto es un ReceiveConnector que consume los mensajes publicados por scheduler-external-trigger-kafka.

Paso 3: Configure la Aplicación Consumidora

Configurar Kafka Filtros de Encabezado

El Scheduler Kafka módulo de envío (scheduler-external-trigger-kafka) publica mensajes con los siguientes Kafka encabezados:

  1. source

  2. trigger-type

Esto permite a la aplicación consumidora filtrar mensajes utilizando estos encabezados.

Usted definió originalmente los valores para los encabezados de mensaje en el campo TriggerCommand de la HTTP solicitud al Scheduler HTTP Controlador. Para referencia, consulte Scheduling Su Primer Trabajo (a través de HTTP Biblioteca del Cliente).

Puede configurar su aplicación consumidora para filtrar valores específicos para estos encabezados añadiendo los valores al arreglo en las rutas de configuración a continuación:

Encabezado de Kafka Configurar un arreglo para agregar valor a

source

ipf.core.payment-releaser.adaptor.scheduler.kafka.expected-sources

trigger-type

ipf.core.payment-releaser.adaptor.scheduler.kafka.expected-trigger-types

 
Si no incluye valores para el Kafka filtros de encabezado en la configuración, todos los mensajes publicados por su Scheduling la aplicación será consumida.
 
Por defecto, la configuración de estos campos está establecida en `["any"]` para dejar claro que cualquier mensaje será filtrado.

El Kafka Los encabezados serán filtrados si cualquiera de las cadenas en el arreglo de configuración están presentes para un encabezado particular.

Ejemplo

ipf.core.payment-releaser.adaptor.scheduler.kafka {
    expected-sources = ["releaser", "other-system"]
    expected-trigger-types = ["INSTRUCTION", "TRANSACTION"]
}

Si la configuración anterior fue la suya, entonces los siguientes mensajes serían el resultado del filtrado:

Origen Tipo de disparador ¿Filtrado dentro o fuera?

liberador

INSTRUCCIÓN

IN

otro-sistema

INSTRUCCIÓN

IN

otro-sistema

TRANSACCIÓN

IN

liberador

algo

FUERA

algo

TRANSACCIÓN

FUERA

algo

algo

FUERA

Más allá customisation

Por defecto, hay un Criteria Spring Bean conectado de manera que filtra todos los mensajes. El predeterminado Bean respeta la configuración anterior. Sin embargo, si usted desea continuar customise filtración de mensajes, usted puede definir su propio Criteria spring bean en la aplicación consumidora. Un ejemplo Criteria Spring Bean--

import com.iconsolutions.ipf.core.connector.criteria.AndCriteria;
import com.iconsolutions.ipf.core.connector.criteria.Criteria;
import com.iconsolutions.ipf.core.connector.criteria.MessageHeaderCriteria;
import org.springframework.context.annotation.Bean;

@Bean
public Criteria scheduledCommandFilteringCriteria() {
    return AndCriteria.create(
            MessageHeaderCriteria.create("source", "your-source"),
            MessageHeaderCriteria.create("trigger-type", "INSTRUCTION_PAYMENT_RELEASE"));
}

Implementar ExternalSchedulingHelper Spring Beans

Para que su aplicación consumidora sepa qué hacer con los mensajes consumidos, debe implementar uno o más ExternalSchedulingHelper clases.

Estos definen la clase concreta del comando que apoyan (con el supports método) y lo que debería suceder con el comando soportado (con el execute método).

A continuación se presenta un ejemplo de implementación:

import com.iconsolutions.ipf.core.platform.api.models.ExternalTriggerCommand;
import com.iconsolutions.ipf.core.scheduler.client.connector.receive.kafka.helper.ExternalSchedulingHelper;
import lombok.RequiredArgsConstructor;

import java.util.concurrent.CompletionStage;

@RequiredArgsConstructor
public class TestExternalSchedulingHelper implements ExternalSchedulingHelper {

    private final MyExecutingSystem myExecutingSystem;

    @Override
    public boolean supports(ExternalTriggerCommand request) {
        return request instanceof TestExternalSchedulingCommand;
    }

    @Override
    public CompletionStage<Void> execute(ExternalTriggerCommand request) {
        return myExecutingSystem.execute(((TestExternalSchedulingCommand)request).getUnitOfWorkId())
                .thenApply(__ -> null);
    }
}

Debe entonces agregar su concreto ExternalSchedulingHelper clases como Spring Beans.