Access Cache
- Ben Clark
Overview
Journey Orchestration has access to a cache stored in Apache Cassandra
Data passed into or generated in the Rule can:
Read values from the cache
Write values into the cache (Update / Insert)
Update numeric values in the cache (Increment / Decrement)
Delete from the cache
Field Value Write discrete field values to the cache
The cache is organised into tables
Every record must have a unique identifier e.g. CustomerID
When data is written to the cache, it can be set to:
Expire after a period
Best Practice: Set the expiry time so that the Cache is self maintaining See this page for more details on controlling the persistence of your data
Example:
A rule has been created that requires Customer information to be stored into the Cache. The rule reads the incoming JSON, Decodes the JSON into fields and then writes the data to the Cassandra Cache.
Step | Description |
|---|---|
 | The following JSON message will be passed to the rule from a website. The Realtime Input will receive this JSON. {
"Customer Id": 1,
"Email Address": "ExampleOne@domain.com",
"Customer Name": "Example One",
"Order Date": "28/02/2020 11:14:00",
"Order Number": "12345",
"Product Name": "3 Seater Sofa"
}
|
 | The Decode JSON will decode the JSON into fields:  |
 | The Access cache step will write the data to a cache table in cassandra using the “customer Id” as the primary key: 
|
Plugin Configuration
Step
Within the Step tab:
The following settings can be configured:
Setting | Description |
|---|---|
Step Type |
|
Server names(s) | The name of the cache server(s) you are using. If the rule is running in Journey Orchestration then this is automatically populated when the Template is loaded and the provided here value will be ignored. In the example below we are looking at the template in Template builder where this value and the keyspace are automatically configured.
|
Keyspace | Tables exist in a Keyspace (similar to a database). If the rule is running in Journey Orchestration then this is automatically populated when the Template is loaded and the provided here value will be ignored. In the example below we are looking at the template in Template builder where this value and the keyspace are automatically configured. This is only required if you are running this plugin locally. Best Practice: Providing the keyspace name in the format client_target (acadiantravel_dev) allows this step to identify the keyspace you have previously been writing into and will allow you to select from the existing fields from this keyspace when the Get Fields functionality is used when Reading from the Cache. |
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. |
Expiry Time (secs) | The amount of time in seconds after which the data in the cache table should expire. This can be specified as either a static value or populated by a value in a field:  Specifying the value in a field allows the time to be dynamically populated for each row of data. See this page for the default values that are applied to the data saved to the cache. Several layers can apply. |
Update TTL Value after Reading | With this option selected each read of a value in the cache will automatically rewrite the value. This allows the the expiry time set above to be reapplied. This ensures that data that is regularly used is persisted and data that is not accessed is safely and cleanly removed after the chosen timeframe. |
Key | The field that contains the unique key (primary key) which identify items in the cache. e.g. Customer ID or Order ID |
Timeseries | Allows you to save the data against specific timeseries |
Values
Within the Values tab:
The following settings can be configured:
Step Type | Description |
|---|---|
Read | The column to read from the cache specifying the:
 When the Server name, Keyspace and Table are configured correctly in the step screen clicking on Get Fields* in the top bar will popup a dialogue that shows the fields already available in the chosen table:
Note: The Get Fields functionality only works when calling the remote DDE server and does not work when run locally |
Write | 
The column to write into the cache specifying the:
 When the step is placed into a Rule clicking on Get Fields* in the top bar will popup a dialogue that shows the fields flowing into the step:
How to Write… Overwrite - Will replace the current value with the new value. Append - Will append the current value to the existing values. Append if not already present - Will check to see if the value being written already exists. If the column contains the value, nothing is written. If the column does NOT contain the value, the value is appended. Write Once - This options writes a column to the cache ONCE for a specific key. If the column contains a value, nothing is written. If the column does NOT contain a value, the value is written. Additionally, if a value was written AND the step is doing error handling, the row will be placed on the error branch as a "cache miss". You can optionally choose to automatically read out the value once written. Simply select your value field in the “Output written value into field” dropdown. |
Update | For numeric values only:
 When the Server name, Keyspace and Table are configured correctly in the step screen clicking on Get Fields in the top bar will popup a dialogue that shows the fields already available in the chosen table:
|
Delete | The column to delete from the cache specifying the:
When the Server name, Keyspace and Table are configured correctly in the step screen clicking on Get Fields* in the top bar will popup a dialogue that shows the fields already available in the chosen table:
|
*Note: The Get Fields functionality only works when calling the remote DDE server and does not work when run locally