Scheduler Trigger
Learn more about the Scheduler Trigger and how to use it on the Digibee Integration Platform.
Last updated
Was this helpful?
Learn more about the Scheduler Trigger and how to use it on the Digibee Integration Platform.
Last updated
Was this helpful?
When a pipeline is configured and published with any Scheduler Trigger variable, a function is created to execute the process in predefined pauses. This is done by following a defined in the configurations of this type of trigger.
Scheduler Trigger has 4 types. They are:
5-Minute Scheduler: has a 5-minute pre-configuration. When you deploy a pipeline with this variable, the executions are programmed for every 5 minutes.
30-Minute Scheduler: has a 30-minute pre-configuration. When you deploy a pipeline with this variable, the executions are programmed for every 30 minutes.
Midnight Scheduler: has a pre-configuration to be triggered at midnight. When you deploy a pipeline with this variable, the executions are programmed for midnight.
Custom Scheduler: doesn’t have a pre-configuration, allowing you to custom a cron expression. When you deploy a pipeline with this variable, the executions are programmed according to the cron expression you specified.
The Midnight Scheduler doesn’t allow the Time Zone to be configured. That way, the execution happens at Time Zone UTC midnight, which can be different from your Time Zone. If you need to configure the Time Zone, you can use the Custom Scheduler and then define the midnight-recurrence information in your parameters.
Take a look at the configuration options for the component. Parameters supported by are marked with (DB).
Cron Expression
N/A
String
Time Zone
Defines the Time Zone under which the pipeline executes. If unspecified, UTC standard is followed. For example, 12h UTC corresponds to 9h in São Paulo Time Zone.
N/A
String
Maximum Timeout
Limits the pipeline processing time before returning a response. Standard value is 30000, with a limit of 900000 milliseconds. If processing exceeds this duration, execution ends.
30000
Integer
Retries
Maximum number of attempts if execution fails.
0
Integer
Allow Redelivery Of Messages
False
Boolean
Allow Concurrent Scheduling
Indicates if the pipeline should start execution even if previous executions are ongoing.
False
Boolean
If a pipeline is set to execute every 3 minutes and a previous execution took 4 minutes, this parameter determines whether the next execution starts or waits for the ongoing one to finish. There are different scenarios:
If enabled: the following executions happen along with the current one.
If disabled: the following execution, on top of the other ones, won’t be started until the previous execution is finished.
This trigger can be used in some cases in which it’s necessary to search system data that don’t have the capacity to send data to Digibee using HTTP, REST, HTTP File, Kafka, RabbitMQ and JMS. Some of these scenarios are:
to search files in directories from SFTP, FTP, S3, Google Cloud Storage, etc.;
to search information directly in databases (in this case, we recommend the use of the Stream DB component with pagination);
to execute status verification calls in the Digibee Integration Platform endpoints that don’t have the capacity to sensitize pipelines through webhooks.
See how the trigger behaves in a determined situation and what its respective configuration is:
Scenario: Pipeline executed every 30 seconds, without overlap using a static data source
Observe how to configure a pipeline with Scheduler Trigger to be automatically executed every 30 seconds without an execution overlap. A 2-minute Timeout that follows the Sao Paulo Time Zone (UTC-3) will be configured.
Firstly, create a new pipeline and configure the trigger. The configuration can be done in the following way:
After having done that, every time that the pipeline is executed, the JSON defined as answer will be automatically returned.
Expression defining seconds, minutes, hours, and recurrence of a pipeline in days. For more information on expression format, refer to . Access to build these expressions.
If enabled, allows resending messages when the Pipeline Engine fails. Refer to the for further details.
Now observe how to configure a in the pipeline so it becomes the data provider that the endpoint returns in the end. Select the indicated component, connect it to the trigger and configure it with this JSON:
