DDE Rule
- Mike Ashton
- Ben Clark
Overview
Used to call another rule, to load data into the cache
The plugin can be used outside of DDE to call a rule as part of a data load process that stores data into the cache
Essentially making a REST call to a rule
A sister rule should be created to receive the JSON and write the data to the cache
Plugin Configuration
General
Within the General tab:
Controlling the Client and Target
Where you have rules within Journey Orchestration that call from one rule to another you need to be careful around what happens to your linked rules when your promote the rule throught your targets.
The current functionality will maintain the same linked rule when a rule is copied to another target.
For example:
Rule A in development is calling out to Rule B in the development target
Rule A is copied from development to test
Rule A in test will still be is calling out to Rule B in the development target
If you would like the target of the linked rule to change depending on the target it is copied into you can take advantage of the standard Global Parameters below. Adding DDE_Target as the target would allow the target to change as the Rule is Copied. Don't forget however that the rule being called does needs to exist!
Global Parameter name | Parameter | What this supplies |
|---|---|---|
DDE_Client | ${DDE_Client} | Will update this parameter with the name of the client in which this template is sitting |
DDE_Target | ${DDE_Target} | Will update this parameter with the target in which this template is sitting |
DDE_Rule | ${DDE_Rule} | Will update this parameter with the name of the rule in which this template is sitting |
The following settings can be configured:
Setting | Description |
|---|---|
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 that will subsequently receive the JSON and write the data to the cache. In the below example the input field “message” containing the JSON to load into the cache is passed into the step:  |
Build JSON From Input Field(s) | If “Build JSON From Input Field(s)” is selected, the JSON that is passed to the subsequent rule will be built from the fields specified in the “Select Fields” tab:  The Mapped Names column shows the Existing fields the fields will be mapped to. When you first start to use Alterian CX we will have prepopulated this list with some commonly used fields. This allows us to provide Public Rules to allow you to pull fields into your Rules. If a Field already exists please try to reuse it as this will make Rule Designer much more flexible. If “Build JSON From Input Field(s)” is selected we will pass through all fields if no specific fields are selected. This allows Rules to much more generic. |
Rule result | The name of the field that should contain the API call status after the step is invoked. |
Fire and Forget | Where you do not require a response back from the system you are calling you can set the Fire and Forget flag. This continues processing without waiting for a response making the processing quicker. If Fire and Forget is selected then the Rule result even if populated will be greyed out and will not be provided. |
Rule URL | The invoke URL of the rule that will receive the JSON. In the below example a rule called “myautouploaded” within the “demord” client in the “dev” target will be invoked. |
Optimise for bulk loading | If “Optimise for bulk loading” is selected, the logging for the subsequent rule will be disabled so that the bulk loads run faster. |
Rule Management | When “Manage the rule automatically for loading” is selected you will need to select the fields to load from the “Select Fields” tab. A Rule Management tab also appears: 
|
Type of Rule | What to do with the records. In the future we may add further values. Currently we only provide the ability to write directly to the Cache. |
Name of Cache Table | Which table to write the values to |
Key Field | What is the Key field to use when loading the records into the Cache table. We would always recommend using the Alterian CXID where possible as this provided the greatest flexibility in the future. |