Skip to main content
Skip table of contents

Interaction Designer - Interaction Execution

Overview

Having assembled activities to create one or more workflows within an interaction, you can then save the interaction and execute each workflow independently.

Executing a Workflow

Workflows within an interaction are executed independently of one another. A workflow’s execution commences with the activation or firing of its trigger. A workflow with a manual trigger commences execution immediately upon activation (subject to trigger constraints); scheduled and recurring triggers are activated and, at an appointed time, fired automatically (you can override the schedule by firing a trigger manually if required). Activity within a workflow controlled by an activity state trigger only commences when the criteria defined within the trigger’s configuration are realized.

For more detail on activating manual and scheduled/recurring workflows, please see the separate sections on these subjects.

If interaction and/or offer approvals are enabled within the current RPI server installation, certain approval criteria may need to be met before an interaction workflow can be executed. Full details of such criteria can be found in the File Approval documentation.

When a trigger is activated, the system checks that all audiences within its workflow are valid. If not, you are presented with a list of validation errors and the workflow is not activated. The following validation constraints are applied:

  • All required joins must exist.

  • All required database tables must exist in the RPI catalog.

  • All required database columns must exist in the RPI catalog.

  • Metadata to be written into the offer history meta table must be accordant with that table’s data types.

Following the firing of a workflow’s trigger, workflow activities within a given workflow branch are executed in sequence. Separate workflow branches are executed in parallel.

The currently-executing activity (if one exists) is surrounded by green halo.

If an activity’s execution fails, it is surrounded by a red halo.

Similarly, an expired workflow’s activities are surrounded by red halos. Workflow expiry occurs after a defined period of inactivity within an executing workflow.

A Completed activity is not surrounded by a halo.

Note that the input to any activity is constrained by the output of its preceding activity; for example, an offer may only be addressed to the records defined by a preceding audience.

If you attempt to execute an interaction workflow that contains a batch audience or interactive activity using an audience that is configured with a restricted audience definition, or, through its blocks, a restricted resolution level, a Permission Denied message is displayed and you may not proceed with the execution.

The same applies when the workflow contains an export activity using an export template configured with a restricted resolution level, or an offer activity, broadcast, export activity or control configured with a restricted channel.

Note also that if you attempt to execute an interaction workflow containing an offer activity using a channel that requires authorization, but which has not been authorized, a runtime validation error is raised.

Workflow Execution Modes

It is possible to execute workflows in the Interaction Designer in one of two modes: Test (the default) or Production. You can switch between modes using the dropdown available in the toolbar.

If a workflow is run in test mode, the results of execution are written to the ‘sandbox’ offer history and offer history meta tables. Fulfillment activities do not take place: e.g. data extract outputs are not generated, export files not created and emails not sent. During test execution, a workflow’s status is Test Mode. Following test execution, its status is Test Completed (if successful) or Test Failed (if not). Note that you can edit or reactivate a workflow after test execution.

If a workflow is run in production mode, the results of execution are written to the standard offer history and offer history meta tables. Fulfillment activities are carried out: e.g. data extract outputs are generated, export files created and emails sent. You cannot reactivate a workflow after execution in production mode.

Workflow Instances

When a workflow executes, a workflow instance is created. A workflow with a recurring trigger may have more than one workflow instance. If one or more workflow instances has been created in respect of a workflow shown within the Interaction Designer:

  • If more than one instance exists, details of the most recent instance are displayed.

  • Each activity’s current status is shown below the activity’s name.

Workflow Statuses

There are two types of status within a workflow:

Active status: indicates whether the workflow’s trigger has been activated, and the mode within which activated.

Workflow status: all activities within a workflow have a status. A trigger’s status is synonymous with the state of the workflow as a whole and is independent of its contained activities – for example, a manual trigger may be Playing, but an early activity within the sequence of workflow activities may be Completed. Each activity’s status is shown below the activity, using a textual label. In addition, a Playing or Failed activity is surrounded by a green or red halo, respectively.

The following workflow statuses are supported:

  • Waiting For Trigger: displayed whilst waiting for workflow activity to occur. A manual trigger assumes the Waiting for Trigger state temporarily upon being played. Scheduled, activity state and recurring triggers are displayed as Waiting for Trigger in advance of their firing. A wait for event activity enters this state in advance of the firing of its manual or scheduled trigger.

  • Deactivation Requested: displayed during deactivation of an active trigger.

  • Trigger Requested: displayed post-manual firing of a trigger.

  • Playing: when displayed at:

    • Trigger: indicates that activities within the workflow are currently non-dormant. Note that a Playing workflow may contain activities in other states.

    • Batch audience: shows that execution of the rules defined by the audience is currently ongoing.

    • Interactive activity: indicates that the interactive activity is currently live. The activity may currently be executing the rules defined by its audience (if configured with one) or may be waiting to execute in accordance with its defined frequency.

    • Export: records defined to be exported are being written to a file in accordance with the export’s configured export template.

    • Offer activity: fulfillment activities (e.g. generation of data extract export files or blasting of emails) are ongoing.

    • Decision offer: as per the offer activity – fulfillment of the winning offer is currently taking place.

    • Control: data is being written to the sandbox offer history tables.

  • Pause Requested: you have asked for a workflow, or an audience within a workflow, to be paused.

  • Pausing: the system is currently processing a request to pause a workflow or audience within a workflow.

  • Paused: if pause was invoked at the trigger, execution of the workflow is temporarily suspended (having completed ongoing activities as necessary). If pause was requested at an audience, rules within the audience cease execution at an appropriate juncture, and the activity enters a Paused state.

  • Resume Play Requested: you have requested that a workflow, or audience within a workflow, be played following a cessation of execution.

  • Stop Requested: you have has asked for a workflow to be stopped, or an audience within a workflow to be stopped and rewound.

  • Stopping: the system is responding to a stop request.

  • Stopped: if stop was invoked at a workflow, all activity has ceased within the workflow, and all trace of the workflow having executed has been erased. The workflow is effectively defunct and may not be played again.

If stop and rewind was invoked at an audience , all record of its execution is also removed (records are removed from offer history tables); however, in contrast to a Stopped workflow, a Stopped audience may be re-played.

  • Failed: an error occurred within workflow execution. The Failed status is displayed against both the activity within which the error occurred, and against its parent workflow.

  • Completed: the workflow or activity executed successfully.

  • Waiting Next Trigger: displayed at a recurring trigger only, this status indicates that one or more workflow instances has run, and that the system is awaiting the next firing of the trigger.

  • Counting Down Delay: relevant only to a delay activity. This status indicates that the delay is activity counting down the time remaining until workflow execution restarts.

  • Queued: an activity is awaiting execution, either due to the maximum number of activities currently executing concurrently, or due to an impending or current maintenance mode window.

Workflow Rollback

You can initiate the rollback of an interaction workflow post-its production execution using the Rollback current Workflow Instance button, displayed at its trigger's mini toolbar.

The ability to roll back an interaction workflow instance is controlled by the Interaction - Rollback functional permission.

Rollback is available when a workflow's status is one of Completed, Failed or Stopped. Invocation of rollback is protected by the Confirm Production Workflow Rollback dialog ('Are you sure you want to roll back the 'Manual' workflow? WARNING: Doing so will remove all offer history and file assets associated with this workflow instance.').

Having initiated a workflow rollback, it assumes the following statuses:

  • Rollback Requested

  • Rolling Back

  • Rolled Back

  • Rollback Failed

These are displayed at the workflow's trigger and all non-broadcast fulfillment, delay or wait for event activities (these are unaffected by rollback).

Following a successful rollback, all related records removed from the Offer History and Offer History Meta data warehouse tables. All data extract offer and export files are deleted. Having rolled back a workflow, you can re-activate it.

If you rollback a workflow with a recurring trigger only its most recent workflow instance is rolled back.

If you roll back an interaction workflow that includes audience containing a data process block, or a data process activity, the RPDM project specified at the data process project's Rollback repository path property will be executed.

Information Bubbles

Additional indicators as to the current state of a workflow are given via informational bubbles:

A bubble is displayed at a delay to advise of the amount of time remaining as the delay is executed:

Results bubbles are displayed at audiences, exports, offers, decision offers, controls and queue activities to indicate that results exist in a given context:

Activating a Manual Trigger

Execution of a workflow with a manual trigger commences immediately upon the trigger’s activation (subject to satisfaction of any related trigger constraints). A workflow instance is created and is assigned a unique integer ID. The workflow assumes a Playing state and the activities that it contains are executed appropriately. A workflow can be activated only when valid (note that other workflows, and the interaction as a whole, may be in an invalid state at this time).

Activating a Scheduled or Recurring Trigger

When a workflow with a scheduled or recurring trigger is Inactive, it may be activated by invoking Activate at the trigger’s mini toolbar. This sets its active status to Active. The trigger enters a Waiting for Trigger state until the arrival of its start date and time. When in this state, the workflow is read-only.

A workflow can be activated only when valid (note that other workflows, and the interaction as a whole, may be in an invalid state at this time).

When the trigger’s start date and time arrives it fires, creating a workflow instance, which is assigned a unique integer ID (firing is subject to satisfaction of any associated trigger constraints). In the case of a recurring trigger, the start time used is always local.

If the workflow is currently Active, but the trigger has not yet fired, the same button can be used to deactivate the workflow. A scheduled or recurring trigger within an Inactive workflow does not fire at the arrival of its scheduled date and time.

A workflow can only be activated if it is valid and contains no unsaved changes.

If you activate a scheduled or recurring trigger when its scheduled date and time have already passed, it fires immediately.

If the workflow’s trigger is a recurring trigger, its behavior depends on the setting at its Create property.

If Create is set to Single workflow instance, when the trigger fires, a workflow instance is created and, after its initial execution, the workflow enters a Waiting for Trigger state. On firing for a second or subsequent time, a new workflow instance is not created; instead, only qualifying records that have not yet been contacted within the workflow instance are targeted. Results bubbles continue to be shown when the workflow’s status is Waiting for Trigger.

If Create is set to New workflow instance each time trigger fires, following completion of the initial workflow instance, the workflow enters a Waiting for Next Trigger state. The next workflow instance is created in accordance with the trigger’s recurrence parameters, as defined within its configuration panel. The workflow continues creating instances, in accordance with its configuration settings, until all instances required have executed (unless configured to never end, in which case instances will continue to be created in perpetuity). Note that results bubbles do not continue to be shown when the workflow’s state is Waiting for Trigger.

A recurring trigger’s recurrence pattern is observed in the context of the time zone specified within the trigger.

Following deactivation of a Production recurring trigger, you can edit the trigger's schedule settings, and can re-activate workflow having saved your changes. This functionality is available irrespective of as to whether a workflow instance had been created by the trigger at the point of workflow deactivation.

If a recurring trigger is unable to start workflow execution (for example, if the Workflow Manager service happens to be unavailable), a series of retry attempts are performed. An attempt to start is made every 10 seconds for the first minute, then every 1 minute for the next 9 minutes, then every 10 minutes for the next 50 minutes. After this time the attempt to start the workflow is abandoned and the trigger reverts to its defined schedule.

If the Manual tab is selected at a recurring trigger, on activation, the trigger enters a Waiting for Trigger state. It is necessary to click the Fire Trigger button manually to invoke activity at the same. If end after is set, workflow execution ceases after trigger is fired the prescribed number of times. If end by is set, workflow execution ceases at the appointed time. If never end is set, there is no limit to the number of times the trigger can be fired.

Workflow Prioritization

Workflow prioritization settings are managed in triggers' Prioritization tabs. When prioritization is enabled at the current RPI tenant:

  • If a workflow is categorized as Urgent, any activities within the same are not placed in a wait queue. Otherwise, activities can be queued. A queued Normal priority activity takes precedence over a Low priority activity. Activities with the same priority are executed in accordance with the time they spend queueing.

  • The tenant's Maximum Concurrent Workflow Activities application setting defines the number of the tenant's workflow activities that can be executed at once. The Maximum Time Activities Can Queue application setting defines the maximum time an activity can sit in the wait queue (this can be overridden at the individual workflow level using the Maximum Queue Time Override property).

  • A workflow's Urgent Deadline defines the date and time when the workflow assumes an Urgent priority, and activities within the same are executed.

  • The tenant's Default Maintenance Mode Buffer Time application setting defines time prior to scheduled maintenance within which any activity will be held on the queue (regardless of priority). This can be overridden at the individual level workflow using the Maintenance Mode Buffer Override property.

Activities held in the wait queue are displayed with a status of ‘Queued’.

Trigger Constraint Execution

When a trigger is configured with one or more trigger constraints, all must be satisfied prior to the trigger’s firing.

  • A database count trigger constraint is satisfied if the count returned by the execution of the related selection rule is accordant with the supplied operator and value.

  • An external trigger constraint is satisfied if a call is received from an external source that utilizes the trigger’s unique GUID.

Trigger constraints are checked for satisfaction every minute.

If a recurring trigger is configured with one or more trigger constraints, all must be satisfied at each firing of the trigger.

Manual Trigger Constraints

If one or more constraints are provided for a manual trigger:

  • Upon the trigger’s activation, the system commences checking database count constraints at a frequency accordant with a system configuration setting (TriggerCheckCriteriaInterval).

  • The trigger remains in a WaitingForTrigger if it contains constraints that have not been met.

  • The trigger fires when all constraints are satisfied:

    • All database count constraints are met.

    • Calls have been received from all external services.

  • If any outstanding database count constraints remain unsatisfied when the Stop checking at date and time have already passed, the trigger does not fire.

  • If the trigger is deactivated, it is necessary to set Stop checking... to a future time in order to reactivate it.

Scheduled Trigger Constraints

If one or more constraints are provided for a scheduled trigger:

  • Upon activation, the system waits until the trigger’s scheduled date and time.

  • When that time is reached, it commences checking database count constraints at a frequency accordant with a system configuration setting (TriggerCheckCriteriaInterval).

  • If database count constraints exist and the trigger’s Stop checking at date and time have already passed, the trigger does not fire.

  • The trigger fires when all constraints are satisfied:

    • All database count constraints are met.

    • Calls received from all external services.

  • If any outstanding database count constraints remain unsatisfied when the Stop checking at date and time have already passed, the trigger does not fire.

  • If the trigger is deactivated, it is necessary to set Stop checking... to a future time in order to reactivate it.

Recurring Trigger Constraints

If one or more constraints are provided for a recurring trigger:

  • Upon activation, the system waits until the trigger’s initial instance’s scheduled date and time.

  • At that time, it commences checking database count constraints at a frequency accordant with a system configuration setting (TriggerCheckCriteriaInterval).

  • The trigger fires when all constraints are satisfied:

    • All database count constraints are met.

    • Calls received from all external services.

  • Following execution of the initial instance, the trigger commences checking constraints in accordance with its configuration settings.

Activity State Trigger Constraints

If one or more constraints are provided for an activity state trigger, behavior is as per a manual trigger, other than in the required activity state configuration having to be realized before any constraints are taken into account.

Playing a Paused Workflow Instance

You can resume playing a workflow instance that has been paused. This is done by pressing Play within the workflow’s trigger’s mini toolbar. What happens next depends on the type of the most-recently executing activity:

  • Batch audience: the workflow enters a Playing state, as does the batch audience.

  • Interactive activity: the workflow enters a Playing state, as does the interactive activity. Any immediately-downstream activities also commence Playing.

  • Delay: if the original delay duration has not passed, the workflow enters a Playing state, and the delay’s state is set to Counting Down Delay. If the duration has passed, the workflow enters a state appropriate to the current or most recent activity (e.g. if an audience is Playing, the workflow is also Playing; if all offers are Completed, the workflow is also Completed). The delay itself enters a Completed state.

  • Wait for Event: if its trigger is manual, the workflow enters a Playing state, as does the wait for event. If the wait for event’s trigger is scheduled, and the scheduled time has not passed, the workflow enters a Playing state and the wait for event a Waiting for Trigger state. If the scheduled time has passed, the workflow enters a state appropriate to the current activity, and the trigger is fired.

  • Export: the workflow enters a state appropriate to the current activity, and the export enters a Completed state (execution thereof having finished prior to the workflow entering a Paused state).

  • Offer activity: the workflow enters a state appropriate to the current activity, and the offer activity enters Completed state (execution thereof will have finished prior to the workflow entering a Paused state).

  • Decision offer activity: as per offer activity.

  • Control: the workflow enters a state appropriate to the current activity, and the control enters a Completed state.

Pausing a Playing Workflow Instance

It is only possible to pause a workflow instance when the workflow is Playing. The impact on the workflow’s currently-executing activity is as follows:

  • Batch audience: the workflow enters a Paused state, as does the audience.

  • Interactive activity: the workflow enters a Paused state, as does the activity. Any immediately-downstream activities also enter a paused state.

  • Delay: the workflow enters a Paused state, as does the delay.

  • Wait for Event: the workflow enters a Paused state, as does the wait for event. If the wait for event is associated with a scheduled trigger, the trigger does not fire at the trigger’s scheduled date and time if the workflow is Paused.

  • Export: the workflow enters a Pausing state, and a Paused state having completed export execution. Upon playing, the export completes.

  • Offer activity: the workflow enters a Pausing state, and a Paused state having completed offer execution. Upon playing, the offer activity completes.

  • Decision offer activity: as per offer activity.

  • Control: the workflow enters a Pausing state, and a Paused state having completed control execution. Upon playing, the control completes.

Stopping a Playing or Paused Workflow Instance

It is only possible to stop a workflow instance when its state is Playing or Paused. When a workflow instance is Failed, it is effectively defunct and may not be replayed. When Stopped in Production mode, a workflow cannot be replayed; however, it may be replayed in Test mode. Any interactive activities and activities downstream from them are shown as Terminated.

Reactivating a Stopped Production Workflow

If a workflow instance has been stopped in Production mode, you can reactivate it.

Invocation of Reactivate displays the Confirm Production Workflow Reactivation dialog ('Are you sure you want to reactivate the '[Workflow Name]' workflow? WARNING: Doing so will cause all activities, including those that have previously completed, to be executed again. In addition, any new records found will be targeted').

Proceeding with the reactivation restarts the workflow instance from the beginning. Any previous contacts are not targeted.

Note that Reactivate is not available at a recurring trigger configured to create a single workflow instance.

Batch Audience Execution

When a batch audience is executed, an audience instance is created and the blocks within its audience are run. Audience history data is stored for the duration of execution within a temporary table.

If the batch audience is preceded by another audience within the workflow, its rules are applied against that audience’s segments. In this case, the inputs to a batch audience are defined by:

  • The inputs selected from the previous audience’s segments within its configuration panel’s Inputs tab.

  • Any metadata filters applied to the previous audience’s selected segments within its configuration panel’s Filters tab.

If Pause before this activity completes has been set, following execution of the audience’s rules, execution ceases and the activity assumes a Paused state.

Following execution of the audience, a results bubble is displayed to the top right of the audience icon. It shows a rounded summary of the number of records retrieved by the audience. Results are shown to a single decimal place, e.g.:

1,203,492 = 1.2M

75,854 = 75.9K

You can view full results using the Results Window.

When a batch audience is executed in an interaction workflow, its count reflects the application of its audience definition’s global contact rule (if one exists).

If the audience with which a batch audience is configured contains an auxiliary rule, it is executed to determine a list of keys that match the rule’s criteria, and the results are written to a temporary table. This table can then be used to join to data warehouse tables to identify matching data warehouse records which will serve as the audience’s segment(s).

If sufficient joins do not exist to link the resolution levels of the auxiliary rule and the audience’s definition, a runtime validation error is displayed.

If the batch audience’s audience definition is configured to produce validation files, these are created when the audience executes, and can be accessed from the Results Window.

At execution of an audience based on a transactional audience definition, the offer history table is populated with transactional data in addition to standard resolution data. Transactional data is deduplicated in accordance with the settings recorded at the audience definition. Only records from the audience definition's resolution table with matching record(s) in the transaction table are retrieved. Any transactional attributes recorded in offer history must also be accordant with the selection rules utilized in the transactional audience. Note that this also applies to interactive activities configured with transactional audience.

When the current RPI installation is using a SQL Server data warehouse, if the system is unable to connect when executing an audience (for example due to the database server not being found, the database login failing (due e.g. to the database being detached) or because of a deadlock), a series of attempts to reach the data warehouse are made (over a maximum of a 10-minute period). After this time the series of retries are abandoned. All retry details are logged to the server log.

If an interaction workflow contains more than one linked batch audiences that are configured with separate audience definitions, and hence multiple sets of offer history tables, data is written to the final set thereof.

When an upstream audience targets zero records, a subsequent downstream audience enters a Paused state.

If a batch audience is hosted within a Manual, Scheduled or Activity State workflow, and if one of its Minimum or Maximum batch limit values is not met, the audience enters a Paused state, and a message is added to the execution Log ('The current activity batch count of [x] is [less]/[greater] than the [minimum]/[maximum] batch limit of [y] set for this activity'). You can click Play at the Paused activity to resume execution and ignore the limit.

If a batch audience is hosted within a Recurring workflow, the same applies on an individual batch basis. In addition to the Minimum and Maximum batch limits, the overall Maximum target limit continues to be applied.

If the audience is running in a single workflow instance recurring workflow, and its Maximum target limit property set, at the point at which the specified limit is reached or exceeded, the workflow enters a Completed state. If the workflow contains multiple batch audiences with the setting specified, as soon as the first limit is reached, execution ceases.

At interaction workflow execution, a runtime validation warning is raised if the resolution of an audience in the workflow has no configured primary key ('The audience definition's resolution table has not been configured with a primary key. This may impact on performance.').

Interactive Activity Execution

When an interactive activity executes, what happens depends on whether the activity was configured with an audience.

If the interactive activity was configured with an audience , the rules as defined within the template are run in accordance with its configuration settings and are applied to its input dataset (which may itself be constrained in accordance with Inputs and Filter tab settings). Execution of the audience is repeated in accordance with the frequency settings defined within its configuration panel. Records selected each time the audience’s rules are run do not include those selected within previous executions – in this way, the interactive activity’s results are built up cumulatively through time. Audience history data is stored for the duration of execution within a temporary table.

If the audience with which an interactive audience is configured contains an auxiliary rule, it is executed to determine a list of keys that match the rule’s criteria, and the results are written to a temporary table. This table can then be used to join to data warehouse tables to identify matching data warehouse records which will serve as the audience’s segment(s).

If sufficient joins do not exist to link the resolution levels of the auxiliary rule and the audience’s definition, a runtime validation error is displayed.

If the interactive activity was not configured with an audience, RPI checks the activity’s input dataset to determine to which records the interactive activity is to apply. This check is performed a number of times in accordance with the activity’s Check for data settings. Any records that match the fulfillment states configured within the Inputs tab are deemed to have been targeted by the interactive activity and are then passed through to any downstream fulfillment actions. As when configured with an audience, a given record will only be targeted once by an interactive activity, and results are cumulative

When executing, an interactive activity will run in accordance with its defined schedule. For example, if the activity runs initially at 1:00pm, and is scheduled to run again in an hour’s time, it next executes at 2:00pm. If the activities undertaken by the interactive activity are lengthy enough such that it is still running at the next scheduled time of execution, the activity will begin running at the earliest opportunity following cessation of the current cycle of execution

The activity continues to execute at the defined frequency until either the audience’s ‘For’ time period has passed, or ‘Until’ date and time has been reached.

Note that, when an interactive activity is in a dormant state whilst awaiting the next occurrence of execution activity, its status is shown as ‘Waiting for Trigger’.

During and following execution of the activity, a results bubble is displayed to the top right of its icon. It shows a rounded summary of the cumulative number of records targeted by the activity. Results are shown to a single decimal place, e.g.:

1,203,492 = 1.2M

75,854 = 75.9K

You can view full results using the Results Window.

When an interactive activity configured with an audience is executed in a workflow, its count reflects the application of its audience’s audience definition’s global contact rule (if one exists).

If a long-running interaction workflow contains an interactive activity that periodically initiates offer execution, and offer approval is enabled, the most recently-approved version of the offer is utilized; this means that, for example, an email offer’s contents can evolve through time, but updated content will only ever be sent to a recipient once approved.

If the Workflow Manager service becomes unavailable during interactive activity execution, if its period of unavailability intersects with the point at which an interactive activity was due to execute, the interactive activity will execute immediately on the service becoming available. Thereafter, behavior is contingent on the activity’s schedule:

  • If scheduled to execute e.g. every 10 minutes, the activity will execute 10 minutes after its initial execution post-the service’s availability, and every 10 minutes thereafter.

  • If scheduled to execute e.g. 2 weeks at 1300 on Wednesday, the activity will re-adopt its original schedule after its initial execution post-the service’s availability.

Note that, if an interactive activity is configured with an audience , and the audience’s definition is defined at producing validation files, such files are not produced at interactive activity execution.

At interaction workflow execution, a runtime validation warning is raised if the resolution of an audience in the workflow has no configured primary key ('The audience definition's resolution table has not been configured with a primary key. This may impact on performance.').

Metadata Overrides at Fulfillment Activity Execution

Metadata is persisted at the audience output level. One row is written into Offer History Meta per audience output produced during interaction workflow execution. If more than one fulfillment activity (offer, export, control) leverages an output, and different meta overrides are ascribed at different fulfillment activities, the last fulfillment activity to execute will take precedence, and will have its meta value written into Offer History Meta.

Playing and Pausing an Audience

You can play and pause both a batch audience and an interactive activity configured with an audience .

You can pause a Playing audience, which causes it to assume a Paused state (via Pause Requested and Pausing), temporarily ceasing activity within the audience.

You can play a Paused or Stopped audience, which causes it to assume a Playing state (via Resume Play Requested).

Note that undertaking these actions at the audience does not affect the status of the workflow as a whole.

Note also that an audience will assume a Paused state if its audience contains a block set to pause before playing.

Stopping and Rewinding a Batch Audience

This action is only available when a batch audience is currently Playing or Paused. Stopping and rewinding the audience causes the currently-executing activity within batch audience to cease. The audience assumes a Stopped state, and all trace of its execution is erased. However, the workflow remains in a Playing state.

Note that it is possible to resume playing a Stopped audience.

Data Process Activity Execution

At Production execution of a data process activity, the Redpoint Data Management project with which it is configured is executed. A bubble count is displayed at the activity. The activity's configured inputs and filters are applied; if a filter is applied at a data process activity, any restrictions thus imposed are ignored by subsequent downstream activities. Note that the activity will not fail if the data process project's configured project parameters do not match those configured in Redpoint Data Management.

At Test execution, the Redpoint Data Management project is still executed; you can leverage the RPITestFlag project parameter to determine whether a different action is to be taken by Redpoint Data Management if executed in Test mode.

Data Transfer Activity Execution

When you execute a data transfer activity in Test mode, no offer fulfillment takes place. When doing so in Production mode, offer fulfillment takes place – e.g. data extract files are created, or data written to the realtime cache. However, no records are inserted into Offer History or Offer History Meta.

Note that, when you execute a data transfer activity in a recurring workflow that is configured to produce a single workflow instance, or when you execute it downstream from an interactive activity, all qualifying records are targeted with the offer, rather than just new records.

Backfill Files

During audience execution, if the audience's definition is configured to generate backfill files, they are generated at workflow (in Test and/or Production mode, as specified). The backfill query type is INSERT, and separate files are generated for offer history ('[Table name]__[GUID]') and offer history meta ('[Table name]_[GUID]') tables (note the double underscore at the former). Files match the selected export template's basic settings and contain data as per a given table's structure.

In addition, an offer history details backfill file is generated in Production mode only.

When an audience instance is rolled back, if the audience's definition is configured to generate backfill files, such a file is generated at workflow rollback. The backfill query type is DELETE a file is generated for offer history ('[Table name]_Rollback_[GUID]') only. The file contains RPContactID, ChannelExecutionID and RowCounter fields.

In addition, an offer history details backfill file is generated to reflect the rollback.

Note that backfill files are also generated at receipt of records by a queue listener, if the activity is configured to generate offer history. Offer history meta backfill files are not generated in this context.

For more information on backfill files, please see the Audience Definitions section in the Configuration documentation.

In addition, the Export backfill state data system task generates offer history states and channel execution results backfill files. For more information, please see the Operations interface documentation.

Delay Execution

When a delay executes within a workflow, activity ceases within the delay’s workflow branch for the duration specified within the delay. While activity remains ceased, the delay’s status is Counting down delay. The workflow remains in a Playing state.

The delay shows in a bubble the amount of time remaining at the most recent refresh of the Interaction Designer.

Following execution of a delay, subsequent activities within the workflow begin. The delay assumes a Completed status after execution.

If a delay is sited downstream from a fulfillment activity that follows an interactive activity, the interactive display of time remaining is not shown – the original delay duration is displayed as a static figure. In such a circumstance, the delay time is applied separately to each group of records targeted by the interactive activity.

Note that a delay will continue to count down even when the workflow within which it is sited is Paused.

Wait For Event Execution

When a wait for event executes, activity within the current workflow branch ceases until the wait for event’s associated manual or scheduled trigger fires. During this time, the wait for event’s status is Waiting for Trigger.

Note that a wait for event can be associated with one or more database count constraints.

Upon the wait for event’s activation, the system commences checking database count constraints at a frequency accordant with a system configuration setting (TriggerCheckCriteriaInterval). The wait for event’s associated trigger may only fire when all database count constraints are met. If a manual wait for event, when all attached database count constraints are satisfied, the wait for event will fire immediately. If any outstanding database count constraints remain unsatisfied when the Stop checking at date and time have already passed, the associated trigger does not fire.

Constraints are ignored when firing a manual wait for event.

Following the firing of a wait for event’s manual or scheduled trigger, downstream activities within the workflow commence once again.

If an interaction workflow contains a scheduled wait for event that is configured with a date/time in the past, a runtime validation warning is shown at the workflow’s activation. If the warning is ignored, the wait for event will fire immediately at its activation.

Offer History Details

On execution of a production fulfillment activity, a row is inserted into the relevant audience definition’s [Offer History]_details table. This provides a summary of the activity’s execution, which can be queried for reporting purposes.

The table contains the following fields:

  • ChannelExecutionID

  • TriggerExecutionID

  • OfferExecutionID

  • FirstExecutionDate

  • LastExecutionDate

  • ExportFileName

  • ChannelName

  • DeliveryMethod

  • ActivityName

  • ActivitySubName

  • InteractionName

  • OfferName

  • FulfillmentCode

  • TargetCount

  • SeedCount

  • InteractionStateDate

  • InteractionEndDate

  • IsRolledBack

  • RolledBackDate

  • MessageListMasterID

  • MessageListInstanceID

  • MessageID

  • MessageListName

  • MessageName

If system configuration setting OfferHistoryDetailsSandboxEnabled is set to True, on the next execution of the Validate Audience Definitions job, Sandbox versions of all Offer History Details tables are created. Thereafter, on interaction workflow Test execution, data is written to the same. If the setting is subsequently set to False, there is no effect on the existing offer history details sandbox tables; however, on interaction workflow Test execution, data is no longer written to the same. Note that a change to the setting's value takes a few minutes to be picked up, as it is cached by the Execution Service.

‘Chunking’ Inserts

System configuration setting DatabaseInsertBatchLimit is used to determine how RPI undertakes the insertion of records into the audience and offer history tables.

If set to a value greater than 0, the insertion of records will take place in ‘chunks’, with the maximum number of records inserted at a time being accordant with the setting’s value, and, potentially, a number of separate SQL statements being executed to complete the insert.

If set to 0, no chunking takes place, with insertion of records being carried out en masse. This has the effect of executing a single SQL statement, but one that has the potential to be longer-running and more resource-intensive.

Note that, if running against a DB2 data warehouse, DatabaseInsertBatchLimit will also apply to inserts into all of the following database tables:

  • Dataflow_*

  • RP_BC_*

Control Execution

When a control activity executes, relevant records are written to the offer history and offer history meta tables. No other fulfillment occurs, and no contacts are made from RPI.

The records written in this way may be further restricted if the control channel used has been associated with a filter.

In addition, if the channel is configured to call an external service post-execution, that service is invoked immediately upon control execution. If an invalid service address was supplied at channel configuration, execution continues without failing.

If a channel is configured to call a Redpoint Data Management job post-execution, note that the job will be called when executed in both Test and Production mode.

Export Activity Execution

When an export activity executes, records are exported in accordance with the export’s selected parent outputs and applied metadata filters. The activity produces export files when executed in Production mode, or in Test mode when:

  • Use export template is selected and Create files in Test mode is checked.

  • Use extract channel is selected, and the channel's Create files in Test mode property is checked.

If the data extract channel with which the export is configured, or the activity’s export template, is configured to allow duplicates on resolution, if the channel’s export template or the export template is configured with any cross-resolution attributes, deduplication is ignored, and multiple records for a single resolution key can be output in the export file. Note that the activity's bubble count continues to reflect its deduplicated count.

On generation of an export file in Test mode, Offer History and Offer History Meta attribute values are replaced with sandbox equivalents. Note that when the same tables are referenced as aggregation tables, sandbox values are not substituted.

If the export activity’s export template is configured with a custom header, it is displayed in accordance with its definition. Any Record Count text parts reflect the full export file count.

By default, export files are created in accordance with system configuration setting FileExportLocation. Writing of files to a server folder, FTP site or external content provider root folder is supported.

If files are generated at the server, they are by default created in a sub-folder named in accordance with the following:

‘[(Global)FileOutputDirectory]\WFAI[WorkflowInstanceID]\Export files\[Export name]’

Where(Global)FileOutputDirectory is accordant with the configuration setting value defined at the cluster or tenant, Workflow Instance ID is the unique numerical identifier assigned to the workflow instance at its creation, and Export name is the name by which the export is known within the interaction.

When created at an FTP site or external content provider, ‘(Global)FileOutputDirectory’ is replaced by an ‘Export’ folder.

If configured to write to an external content provider, and no default file export provider has been identified, files are written to the RPI application server instead.

Three files are created:

  • actionExport.txt: the main export file. Contains records in a structure defined by the export’s configured export template.

  • actionExport.txt_summary.xml: an XML file that summarizes the contents of the main export file. The following elements and attributes are provided:

    • exportSummary

      • format

      • headerRow

      • lineDelimiter

      • dateFormat

      • addRowID

      • RowCount

      • File

      • CreationDate

      • CreationTime

    • delimiterSettings

      • columnDelimiter

      • otherDelimiter

    • Attribute

      • name

      • ordinal

      • start

      • size

      • precision

      • scale

      • dataType

  • actionExport_sample: contains a subset of data from the main export file. The number of rows output are defined by system configuration setting ExportSampleSize. The sample file is also accordant with the export’s specified export template.

Following execution of an export, a results bubble is displayed to the top right of the export icon. It shows a rounded summary of the number of records in the export’s results set. Results are shown to a single decimal place, e.g.:

1,203,492 = 1.2M

75,854 = 75.9K

Full results are available in the Results Window.

When executing an export activity, note that offer history details are recorded prior to the data’s being exported. This means that, if you include within the activity’s export template attributes based on metadata, they can be exported without incident.

Behavior of an export downstream from an interactive activity configured with an audience depends on its and its channel’s configuration. If the file to which data is to be written is local to the RPI server, rows are appended to the output file dynamically as they are targeted by the audience. If the export path has been specified, a new file is written at the arrival of new records.

If an export activity is configured to produce a file with a specific name, and the file in question exists already within the folder where due to be created, RPI creates the new file anyway, with its name’s uniqueness ensured by the appending of an integer (which can be incremented if necessary).

When PGP encryption is configured at an export activity, full export files generated using the channel are encrypted. Sample and summary files are not encrypted. PGP encryption is also applied when files are generated in Test mode, and when file compression is enabled.

If the export uses the Database Table extract location, data is persisted within a data warehouse table in accordance with activity or data extract channel settings. If using default settings, the table will be named ‘RPI_Export_[GUID]’ (the actual table name may be discerned within the export activity’s execution log). If the table already exists, it is dropped and re-created. If a lengthy custom table name has been specified, it is truncated in accordance with the maximum number of characters permitted by the database. The table is deleted by RPI Housekeeping in accordance with the relevant Days To Persist Table setting.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.

Contact Support Close