Create Future Events
- Mike Ashton
- Ben Clark
Overview
A timer that will expire some time in the future
Rules containing this step, must have a sister rule with a Process Future Events step to act on the expired timers
Plugin Configuration
General
Within the General tab:
The following settings can be configured:
Setting | Description |
|---|---|
Server names(s) | The name of the cache server(s) you are using locally. When the rule is running in CX (DDE) then this will be automatically populated and the value will be ignored. |
KeySpace | Tables exist in Keyspace (similar to a database). If the rule is running in DDE then this is automatically populated with the client name within DDE and the value will be ignored. |
Table | The name of the table which will be created in Cassandra. If left blank this will be the same as the key field name. |
Key | The field that contains the unique key (primary key) which identify items in the cache. e.g. Customer ID or Order ID |
Timestamp | The datetime field to be used to offset the expiry times against, If “Use constant for offset” is selected, the amount of minutes in the future the Timestamp date/time should be entered in which to set the event to expire. In the below example, the rule data is set to expire 30 minutes after the current datetime (Time stored as UTC). This assumes the field “Time Stamp” contains the current datetime:  The “Use field for offset” can be used to dynamically pass the same value into the plugin based on a field value. In the below example, the data containing the amount of minutes is passed into the plugin using a field called “MinutesIntheFuture”.  |
Use Single Input Field | If “Use Single Input Field” is selected, the “Input Field” drop down should contain the field containing the JSON that should be passed to the sister rule with a Process Future Events step. In the below example the input field “message” containing the JSON to expire is passed into the step:  |
Build JSON From Input Field(s) | If “Build JSON From Input Field(s)” is selected, the JSON that is set to expire will be built from the fields specified in the “Select Fields” tab:  In the above example, the data set to expire will be create a JSON object with the following structure: {
"Customer Name": "Joe Bloggs",
"Email Address": "example@alterian.com"
} |
Discard all unprocessed events for this key | This option will take the key selected above and discard “All” other future events with this key. The option should be selected where it is determined that all previous future events should be discarded. This could at the point of processing a future event, creating a new one or in a separate rule, it depends what the trigger is. For example, if you were implementing an abandoned basket process, each time an item is added to the basket a new future event could be created containing the current basket content. This way, when the basket is left for longer than the designated period with nothing new added, a process future event rule can send out an email. However, on the completion of a checkout, the conversion rule can now include a CFE step with the discard option set. This will mean the PFE will never be triggered for this user as all the events will be discarded. |
Write only if | Decide whether this plugin should trigger if the data in this row has been proven to be invalid. |
Fields
When the option “Build JSON From Input Field(s)” is selected, the Fields tab is required to be populated with the fields containing data that should be passed to the sister rule with a Process Future Events step.
Example
An example use case can be found in the Process Future Eventpage