Standalone Scheduler
El Persistent Scheduler puede incorporarse a su aplicación como una dependencia embebida (vea Embedded Implementation). Alternativamente, el Persistent Scheduler puede configurarse como una aplicación independiente con una interfaz HTTP para interacciones entrantes y un publicador Kafka para trabajos programados.
Con la configuración independiente usted puede:
-
Enviar solicitudes de programación vía HTTP a su aplicación de Scheduling
-
Hacer que sus solicitudes de programación se ejecuten en el momento indicado
-
Publicar el comando programado en Kafka
-
Consumir el comando desde Kafka y manejar el payload en su aplicación consumidora
| Esta página no cubre cómo enviar solicitudes por HTTP. Eso se cubre en Programar su primer trabajo |
Paso 1: Agregue dependencias a la aplicación de Scheduling
Para configurar su aplicación independiente, deberá agregar las siguientes dependencias en el pom.xml de su aplicación:
<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 artefacto scheduler-http-controller incorpora el controlador HTTP y la funcionalidad principal del Scheduler.
El artefacto scheduler-external-trigger-kafka publicará el comando programado en un tópico de Kafka predefinido.
Paso 2: Agregue dependencias a la aplicación consumidora
En su aplicación que manejará el payload programado, necesitará agregar las siguientes dependencias al 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
Configure los filtros de cabeceras de Kafka
El módulo de envío a Kafka del Scheduler (scheduler-external-trigger-kafka) publica mensajes con las siguientes cabeceras de Kafka:
-
source -
trigger-type
Esto permite que la aplicación consumidora filtre mensajes usando estas cabeceras.
| Originalmente definió los valores de las cabeceras del mensaje en el campo TriggerCommand de la solicitud HTTP al Scheduler HTTP Controller. Para referencia, vea Programación de su primer trabajo (a través de la biblioteca de cliente HTTP). |
Puede configurar su aplicación consumidora para filtrar valores específicos para estas cabeceras agregando los valores al arreglo en las rutas de configuración siguientes:
| Kafka header | Arreglo de configuración al que agregar el valor |
|---|---|
|
|
|
|
|
Si no incluye valores para los filtros de cabeceras de Kafka en la configuración, todos los mensajes publicados por su aplicación de Scheduling serán consumidos. |
|
Por defecto, la configuración de estos campos se establece en |
Las cabeceras de Kafka serán aceptadas si cualquiera de las cadenas en el arreglo de configuración está presente para una cabecera particular.
Ejemplo
ipf.core.payment-releaser.adaptor.scheduler.kafka {
expected-sources = ["releaser", "other-system"]
expected-trigger-types = ["INSTRUCTION", "TRANSACTION"]
}Si lo anterior fuera su configuración, entonces los siguientes mensajes tendrían el resultado de filtrado:
| Source | Trigger-Type | ¿Filtrado dentro o fuera? |
|---|---|---|
releaser |
INSTRUCTION |
IN |
other-system |
INSTRUCTION |
IN |
other-system |
TRANSACTION |
IN |
releaser |
something |
OUT |
something |
TRANSACTION |
OUT |
something |
something |
OUT |
Personalización adicional
Por defecto, hay un Spring Bean Criteria cableado que filtra todos los mensajes.
El Bean por defecto respeta la configuración anterior.
Sin embargo, si desea personalizar aún más la filtración de mensajes, puede definir su propio Spring bean Criteria en la aplicación consumidora.
A continuación se muestra un ejemplo de Spring Bean Criteria:
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"));
}Implemente Spring Beans de ExternalSchedulingHelper
Para que su aplicación consumidora sepa qué hacer con los mensajes consumidos, debe implementar una o más clases ExternalSchedulingHelper.
Estas definen la clase concreta del comando que soportan (con el método supports) y qué debe suceder con el comando soportado (con el método execute).
A continuación se muestra una implementación de ejemplo:
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);
}
}Luego debe agregar sus clases concretas ExternalSchedulingHelper como Spring Beans.