| Table of Contents |
|---|
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 cacheThis is likely to be used by more techncial users when integrating with unreliable systems.
This step allows a user to retry a set number of times to try to achieve a succesfull result.
We will show the steps where the row can be returned to
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.
| Info |
|---|
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.
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
The following settings can be configured:
Setting | Description |
|---|---|
Step Name | Name of the step |
Loop counter field | The field that will be used to hold the retry counts. You can choose to use any integer field including the standard loopcount field added by our Realtime Input and Process Future event steps. |
Number of Retries | The number of times a row will be retried. This can be set via parameter if required. Maximum of 10 retries. |
Target Step | Dropdown list of steps where a row could be placed to retry. The eligle steps are defined through the following conditions:
|
Delay Type |
|
Delay Time (m) | Sets the delay time for the step up to 5000 ms. Default 1000 ms. |
Scenario 1
The filter rows step identifies failed posts via the “HTTP status code”. The Retry HTTP Post step picks up the row and places it back in the main flow at “Unreliable HTTP post” to be tried again. If the number of retries exceeds the Number of Retries it flow through the retries step to the Fail output.
Scenario 2
The Check Status Code step dentifies failed posts based on the HTTP status code. In the event of a failure, the "Retry HTTP Post" step retrieves the row and reintroduces it into the main flow at the HTTP post step for another attempt. If the number of retries surpasses the specified limit (Number of Retries), the process progresses from the retries step into the Fail output.
We evaluate the result of the post, and if we are dissatisfied with the outcome, we make another attempt using the "Retry HTTP 2" step, which places the row back into the HTTP Post stage for further processing.