Source Timer

Purpose

A Timer Source allows you to define a source, which can generate pre-defined messages which in turn are triggered in certain time-intervals.

You would want a Timer Source in the case that you want something to happen in regular intervals, for example. Every time the timer is triggered a message is sent onto the way in a Workflow, and the Workflow can start doing what it was designed for. Most times, the payload of the message will not be that relevant in the Workflow. What will be relevant is that something should happen, and the timer source makes sure that the Workflow is kicked into action.

Used by

• Input Message

Configuration

Name & Description

• Name : Name of the Asset. Spaces are not allowed in the name.

• Description : Enter a description.

The Asset Usage box shows how many times this Asset is used and which parts are referencing it. Click to expand and then click to follow, if any.

Required roles

In case you are deploying to a Cluster which is running (a) Reactive Engine Nodes which have (b) specific Roles configured, then you can restrict use of this Asset to those Nodes with matching roles. If you want this restriction, then enter the names of the Required Roles here. Otherwise, leave empty to match all Nodes (no restriction).

Throttling & Failure Handling

Throttling

The following parameters allow to control the maximum number of new stream creations per given time period.

• Max. new streams: Maximum number of streams this source is supposed to open resp. process within a given time period.
• Per: Time interval unit for the provided Max. new streams number from the drop-down list.

info

Configuration values for this parameter are dependent on the use case scenario. Assuming your data arrives in low frequency cycles these values are negligible. In scenarios with many objects arriving in short time frames it is recommended to have a closer look on adapting the default values.

Backoff Failure Handling

These parameters define the backoff timing intervals in case of failures. Based on the following parameters, the system will step by step throttle down the processing cycle based on the time boundaries of min. failure backoff and max. failure backoff. It thereby allows to slow down the processing during failure scenarios.

• Min. failure backoff: The minimum backoff time before the next source item processing (in case of failure scenario).
• Unit: The Unit that goes with the given minimum time value.
• Max. failure backoff: The maximum backoff time before the next source item processing (in case of failure scenario).
• Unit: The Unit that goes with the given maximum time value.

Based on these values the next processing will be delayed: starting with the min. failure backoff time interval the waiting time will be increased step by step up to the max. failure backoff.

• Reset after number of successful streams: The backoff failure throttling reset.
• Reset after time without failure streams: Time-based reset for backoff failure throttling .
• Unit: The Unit that goes with the given time-based backoff failure throttling reset.

Whatever comes first will reset the failure scenario throttling after the system is back to successful stream processing.

Operation Mode

A Timer Source can operate in two different modes:

1. Stand alone source: The Timer Source will operate independently of the timer service. It will use its own internal timer to trigger messages. Relevant timers are defined in the Timers section within this Asset.

2. Using timer service: The Timer Source will not use its own internal timer but will rely on the timer service to trigger messages. The timer service will be used to trigger messages at specified intervals.

Stand alone source

In this mode, the Timer Source will use its own internal timer to trigger messages. Relevant timers are defined in the Timers section within this Asset.

Timers

Timers define two things:

1. When to issue a new message to send downstream
2. Payload contained in the message.

You can create a theoretically unlimited number of timers which fire independently of each other. Timers work independent of each other on a per Workflow-instance. So if you have two instances of the same Workflow, then all timers you define here will be fired per Workflow instance.

Let's have a look.

To create a new timer, click the plus sign next to Timers.

A new timer with default values is automatically created. Let's go through the properties:

• Timer name : A unique name for the timer. This name will be passed downstream with the message so that you can identify which timer triggered the message.

• Timer description : Any description which helps to describe the timer better.

  • Timer type : Timers can be of three different types:

    1. Once : A timer which fires only one time up startup of the Workflow.

       • Delay of the timer [ms] : A delay in milliseconds to wait until the timer fires after Workflow startup. A value of 300000 for example signals that the time shall be fired once 5 minutes after Workflow startup.

       img class="frame" src="./.asset-source-timer_images/a7105830.png "Once timer (Timer Source)")

    2. Cyclic : A timer which repeats itself in a simple time pattern.

       • Interval of the timer [ms] : Time in milliseconds between timer firings.

       

    3. Cron : Define granular timer controls via cron settings.

       • Cron expression : Define the cron expression for when to fire the timer. Click the button to the right for UI-driven help.

       

• Payload : A triggered timer will generate a new message. It already contains metadata about the message and the timer which fired it.

  You can, however, also define a payload to send along with a timer triggered message, if necessary. This payload must be either empty or in valid JSON format.:

  

  Instead of only passing hard-coded payloads you may include environment strings as well:

  

Using timer service

In this mode, the Timer Source will not use its own internal timer but will rely on the timer service to trigger messages. The timer service will be used to trigger messages at specified intervals.

So instead of defining timers within the Timer Source, you will define them in the Timer Service.

Stream Settings

In this section you define whether you want to create timed batches, or timed events.

• Batches are the synthetic equivalent of reading individual files.
• Events have no batch beginning or end, but are issued based on the defined timers.

Batch Stream

Select to create a timer triggered batch stream, if you want to

1. Create a synthetic batch which opens, and potentially closes after a pre-defined amount of time. This allows you to define a time-span of an open batch. Something which is not possible with an event stream.
2. Create a trigger only, disregarding any potential payload within the batch. In essence, you only get a onStreamStart event which you can react to.

• Stream type : Select Batch Stream here.

• Stream name : Provide an individual name for the batch. This will show up in the batch payload which can be processed downstream in a Workflow.

• Batch creation timer type : Select between At fixed rate or Cron tab.

  • At fixed rate : Create a new batch every x seconds.

    • Batch creation interval [sec] : Number of seconds to wait in between creating a new batch

      

  • Cron tab : Define granular timer controls via cron settings.

    • Batch creation cron tab expression : Define the cron expression for when to fire the time. Click the button to the right for UI-driven help.

      

• Batch closing mode : Batch Stream mode allows you to define when to close the batch. There are three modes available:

  1. Immediately : The batch is closed right after being opened. No payload is being sent. A onStreamStart event is sent through the system that can be reacted upon. You can - for example - have a onStreamStart even in a Javascript Processor to react to this. Note that since no payload will be sent in this mode, there is no point to have a onMessage reaction in any of your scripts. You also do not require to set a Timer. It will never fire because the stream will immediately terminate.

     

  2. When all timers have fired : You can define individual timers below. This setting will then ensure that all of these timers are being observed. The batch will be closed when all timers were executed.

     

  3. After a fixed delay : Close the batch after a fixed amount of time. Timers as defined below will still fire until the delay has expired.

     

     • Fixed delay [ms] : Time in milliseconds to wait until the batch is closed. If you have defined timers below, then those timers which fire before this delay, will fire, others will be ignored.

Event Stream

An event stream implies that messages will not be in opening and closing batches. Instead, messages will be issued based on the defined timers below.

If you have a Workflow with a Javascript Processor, you can react to those messages by way of onMessage(message). The payload is defined in the timers below. A downstream script can then identify by the timer name which timer was fired and also retrieve the payload, if any.

• Stream name : Provide an individual name for the event stream. This will show up in the batch payload which can be processed downstream in a Workflow.

Message Structure

When a message is issued within a Batch or Event Stream and sent downstream in the Workflow, you can expect the following message structure:

• Group is the name of the Timer Source.
• Name is the name of the individual timer which triggered the message.
• ScheduledFireTime is the time when the timer was supposed to be fired. This only applies to cron-based timers.
• FireTime is the time when the timer was actually fired. This only applies to cron-based timers.
• Payload is the payload which you have defined in the with an individual timer.

Related Topics

Internal

• Input Message
• Timer Service

External

• Cron

---

Can't find what you are looking for?

Please note, that the creation of the online documentation is Work-In-Progress. It is constantly being updated. should you have questions or suggestions, please don't hesitate to contact us at support@layline.io .