Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

Overview

Image RemovedImage Added

  • 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:

Image Removed

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:

Image Removed

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:

Image Removed

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:

Image Removed

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

Image Added

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:

  • It must be upstream of the retry step.

  • It must have the same input fields (or fewer) than the retry step

  • There must not be any step that changes the number of rows inbetween the retry step and the retry target - i.e. “Split field to rows”, “Row normaliser”, “Row denormaliser”

  • The retry target must have a single input connector

Delay Type

  • None - We will retry the row immediately

  • Constant - Allows you to stipulate a delay. This is set in the Delay Time field below.

Delay Time (m)

Sets the delay time for the step up to 5000 ms. Default 1000 ms.

Scenario 1

Image Added

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

Image Added

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.