Flujo Scheduling
El ipf-flo-scheduler el módulo proporciona la capacidad de interactuar con IPF flows y active scheduling capacidades.
Actualmente, hay tres tipos de scheduling características actualmente disponibles para su uso dentro de un flujo:
-
Action Timeouts: proporciona la capacidad para que el flujo continúe procesando si no se recibe una respuesta de una acción en un plazo de tiempo definido. -
Retries: esto proporciona un mecanismo para que el flujo pueda invocar reintentos de acciones cuando las respuestas no se devuelven en el plazo definido. -
Processing Timeouts: esto proporciona un mecanismo para definir que una sección del flujo (entre dos estados cualesquiera) debe completarse dentro de un plazo definido.
Existen entonces dos tipos diferentes de scheduler para proporcionar las implementaciones de estos dependiendo de los requisitos:
Para utilizar un scheduler, simplemente es necesario importar el relevante scheduler como se define a continuación y luego inyecte el scheduler puerto al instanciar el dominio como tal:
@Bean
public QuickStartModelDomain initialiseDomain(ActorSystem actorSystem, SchedulerPort schedulerAdapter) {
// All adapters should be added to the domain model
return new QuickStartModelDomain. Builder(actorSystem)
.withSchedulerAdapter(schedulerAdapter)
.build();
}El relevante scheduler la implementación proporcionará la implementación requerida.
Esto asume que ya ha cableado el dominio.ModelOperations bean para acceder a estas capacidades.
Si no, defínalo para su dominio de la siguiente manera:
|
@Bean
public QuickStartModelOperations quickStartModelOperations() {
return new QuickStartModelOperations();
}Akka Scheduler
Toda la documentación sobre akka scheduling se puede encontrar doc.akka.io/docs/akka/2. 5. 32/scheduler.html[aquí].
The scheduler in Akka está diseñado para un alto rendimiento de miles hasta millones de disparadores. El caso de uso principal es activar la recepción del Actor.timeouts, Futuro timeouts, interruptores automáticos y otros dependientes del tiempo events que ocurren todo el tiempo y en muchas instancias al mismo tiempo.
El Akka scheduler no está diseñado para el largo plazo scheduling y para eso debe usar Programador de Quartz. Tampoco debe utilizarse para el disparo altamente preciso del events. El tiempo máximo en el futuro que puede programar un event el tiempo para activar es de aproximadamente 8 meses, lo cual en la práctica es demasiado para ser útil, ya que esto asumiría que el sistema nunca se cayó durante ese período. Si necesita a largo plazo scheduling recomendamos encarecidamente considerar programadores alternativos, ya que este no es el caso de uso que Akka scheduler se implementa para.
Para utilizar el akka scheduler implementación, todo lo que debe hacer es proporcionar la dependencia:
<dependency>
<groupId>com.iconsolutions.ipf.core.platform</groupId>
<artifactId>ipf-flo-scheduler-akka</artifactId>
</dependency>Persistent Scheduler
El persistent scheduler la implementación utiliza el Icon ipf-persistent-scheduler como su base scheduler implementación.
Toda la documentación sobre Quartz scheduling se puede encontrar aquí.
Quartz es un trabajo de código abierto con muchas características.scheduling biblioteca que puede ser integrada en prácticamente cualquier Java aplicación.
Si su aplicación tiene tareas que deben ocurrir en momentos específicos, o si su sistema tiene trabajos de mantenimiento recurrentes, entonces Quartz puede ser su solución ideal.
Además de Quartz scheduling, IPF también admite la persistencia scheduled trabajos. En caso de fallo del sistema, cuando se restarts, el sistema puede rehidratar trabajos aún activos.
Para utilizar el quartz scheduler, simplemente añada su dependencia:
<dependency>
<groupId>com.iconsolutions.ipf.core.platform</groupId>
<artifactId>ipf-flo-scheduler-persistent</artifactId>
</dependency>Además, para quartz scheduling Es necesario proporcionar un almacén de datos para la persistencia. La siguiente configuración muestra cómo hacer esto:
ipf-scheduler {
mongodb = {
uri = "mongodb://localhost/ipf"
database-name = "scheduled"
}
}Akka Scheduler Vs Quartz Scheduler
| Tipo de Programador | Pros | Cons |
|---|---|---|
Akka |
Corto plazo events que debería durar de segundos a minutos. |
- Quizás el nombre " Scheduler "fue desafortunado, "Deferer" es probablemente más indicativo de lo que hace. - El Akka Scheduler está diseñado para configurar events para ejecutarse en intervalos de tiempo a partir de la fecha y hora actuales, por ejemplo, "ejecute este trabajo en 15 minutos y cada 30 minutos a partir de entonces". No admite tiempo fijo.scheduling por ejemplo, "ejecutar un trabajo todos los días a las 3 p.m.". - El valor predeterminado de Akka scheduler se ejecuta en torno a un HashedWheelTimer – una posible pérdida de precisión para los trabajos, ya que no proporciona garantías sólidas sobre la puntualidad de la ejecución. - Los trabajos programados se pierden cuando el sistema restarts. |
Cuarzo |
- Los trabajos son scheduled para ejecutarse cuando ocurre un Trigger dado. Los Triggers pueden ser creados con casi cualquier combinación de las siguientes directivas.
En un momento determinado del día (hasta el segundo), en ciertos días de la semana, y así sucesivamente. - Los trabajos son nombrados por su creador y también pueden ser organizados en grupos nombrados. Los disparadores también pueden recibir nombres y ser colocados en grupos, con el fin de organizarlos fácilmente dentro de la scheduler. Se pueden agregar trabajos a la scheduler una vez, pero registrado con múltiples Triggers. |
Más complejo para trabajos de "programar una vez" cortos. |
Configuración
Action Timeouts
HOCON la configuración puede ser proporcionada (generalmente en Akka application.conf) para configurar la duración del tiempo de espera de cada acción. Cuando la duración haya expirado, el flujo recibirá un Tiempo de Espera de Acción.event para esa Acción configurada.
El formato de los elementos de configuración está actualmente en flux y sujeto a cambios
El formato actual para la configuración es
ipf flow. FlowName. StateName. ActionName. Type=[Duration|Integer]-
FlowName: identificador de flujo o Any para comodín
-
StateName: State identificador o Any para comodín
-
Nombre De Acción: Identificador de acción o Any para comodín
-
Tipo: uno de timeout-duration, initial-retry-interval, o max-retries
Dónde Duration¿Está soportado algún formato por HOCON
ipf flow. OBCreditTransfer. ValidatingSchemeRules. ValidateAgainstSchemeRules.timeout-duration=2sEsto equivale a:
El Validate Against Scheme Rules acción en el ValidatingSchemeRules state en el OB Credit Transfer el flujo se agota si no se responde dentro de 2 segundos.
Cada parte en la configuración también admite el Any palabra clave que coincidirá con cualquier cosa para esa parte dada.
Es aplicable a flujos, estados y acciones.
-
Anyejemplo
ipf flow {
Any. Any. ValidateAgainstSchemeRules.timeout-duration=10s (1)
Any. CheckingFraud. CheckFraud.timeout-duration=20s (2)
}
| 1 | El Validate Against Scheme Rules acción en cualquier state en cualquier flujo se agota si no se responde dentro de 10 segundos. |
| 2 | El Check Fraud acción en el Checking Fraud state en cualquier flujo se agota si no se responde dentro de 20 segundos. |
Tipos de retroceso y jitter
La configuración permite determinar diferentes tipos de retroceso:
-
EXPONENTIAL: escalado 2^n (dondenes el retraso inicial). Este es el tipo predeterminado. -
LINEAR: escalado 2n (dondenes el retraso inicial). -
USER_DEFINED: Custom intervalos que están definidos en la configuración.
El jitter está habilitado por defecto, pero la configuración también permite deshabilitar el jitter en el caso de que los reintentos sean tan grandes que el jitter añadiría una cantidad significativa de delta. Imagina que se realiza un reintento en un plazo de un día, la variabilidad para eso sería de +/- 5 horas en cada dirección, lo cual podría no ser deseable.
Así - por ejemplo-para configurar 5 intentos del CheckFraud acción sin jitter, inicialmente reintentando después de 10 segundos pero luego cada 30 minutos, la configuración sería:
ipf flow {
Any. CheckingFraud. CheckFraud.max-retries = 4
Any. CheckingFraud. CheckFraud.backoff-type = "USER_DEFINED"
Any. CheckingFraud. CheckFraud.custom-backoffs = [10s,30m] (1)
Any. CheckingFraud. CheckFraud.jitter-enabled = false
}| 1 | Usando el HOCON formato de duración |
Otro ejemplo aquí muestra un reintento lineal (con jitter presente, por lo que se omite porque está activado por defecto):
ipf flow {
Any. CheckingFraud. CheckFraud.initial-retry-interval = 1000
Any. CheckingFraud. CheckFraud.max-retries = 4
Any. CheckingFraud. CheckFraud.backoff-type = "LINEAR"
}Este ejemplo volverá a intentar en 1/2/3/4 segundos.
Precedencia
La configuración más específica tiene prioridad, es decir, si coincide en las 3 partes (flujo,state y acción). Para acciones, cuando hay múltiples elementos de configuración que podrían aplicarse, el más específico state anulará la configuración de flujo más específica.
Flow: Flow1 State: State1 Action: Action1
Este sería el orden de precedencia de todas las posibles configuraciones que podrían aplicarse a esta acción:
1. Flow1. State1. Action1.timeout-duration 2. Any. State1. Action1.timeout-duration 3. Flow1. Any. Action1.timeout-duration 4. Any. Any. Action1.timeout-duration 5. Flow1. State1. Any.timeout-duration 6. Any. State1. Any.timeout-duration 7. Flow1. Any. Any.timeout-duration 8. Any. Any. Any.timeout-duration
Tiempo de Procesamiento
Duraciones
HOCON la configuración también puede ser proporcionada (generalmente en Akka application.conf) para configurar cuánto tiempo se permite gastar en pasar entre un par de estados, independientemente del trayecto tomado para alcanzar el destino.
Cuando la duración haya expirado, el flujo recibirá un ProcessingTimeElapsedEvent para el destino.state.
El formato actual para la configuración es
ipf flow.<flow-name>.processing-time.<source-state>.<destination-state>.timeout-duration=Duration|Integer]-
nombre-del-flujo: identificador del flujo
-
source-state: State identificador
-
destino-state: El state el flujo debe alcanzar en el tiempo asignado
Dónde Duration¿Es algún formato compatible con HOCON
ipf flow. OBCreditTransfer.processing-time. ValidatingAgainstSchemeRules. Complete.timeout-duration=2sEsto equivale a:
El flujo producirá un tiempo de procesamiento transcurrido.event si el tiempo tomado desde el ValidatingAgainstSchemeRules state a la Complete state excede 2 segundos.
Desplazamientos
Los offsets proporcionan un mecanismo mejorado para definir la duración del tiempo de espera. El tiempo de procesamiento básico observa simplemente el tiempo entre dos estados. Sin embargo, puede ser necesario que el tiempo de espera considere, por ejemplo, un específico customer hora de inicio definida. En este caso, podemos utilizar compensaciones como una forma de enriquecer la duración.
Por ejemplo, si el cliente proporciona una marca de tiempo aceptada y el flujo debe completarse dentro de los 5 segundos posteriores a esa hora, en lugar de 5 segundos después de que comience el flujo, IPF puede utilizar la marca de tiempo aceptada como un desplazamiento. El flujo se configura entonces con una duración de 5 segundos, y el tiempo de espera es triggered relativo al desplazamiento proporcionado.
Existen dos tipos de compensación:
-
System Offsets: cada vez que IPF alcanza un nuevo state, se crea un nuevo desplazamiento. -
Custom Offsets: estos son definidos por el usuario y pueden ser proporcionados a IPF.
Cada desplazamiento tiene dos atributos-unico offset-id y el tiempo de compensación en sí mismo.
Para utilizar un desplazamiento en el scheduling configuración, simplemente es necesario definir en la configuración el offset-id a utilizar. Esto se realiza mediante:
ipf flow. OBCreditTransfer.processing-time. ValidatingAgainstSchemeRules. Complete.offset-id=anOffsetIdPara proporcionar un custom desplazamiento a cualquier flujo, simplemente necesitamos proporcionarlo en la entrada a través del withFlowOffset método.
También es posible proporcionar los desplazamientos de un flujo a otro.
Esto es útil en relaciones padre-hijo donde existe un requisito para que un desplazamiento abarque múltiples flujos.
Para hacer esto, en todas las acciones se proporciona el mapa de desplazamiento del flujo actual como un parámetro y este puede ser simplemente pasado al nuevo flujo a través de su withOffsetMap método.