On activating a queue listener, it enters an Activated state (following temporary assumption of a Waiting for Trigger state). Its configuration panel's properties are read-only when Activated.
When Activated, a queue listener begins monitoring the listener queue for the arrival of JSON packages that include a reference to its Listener key. Such packages may be placed on the queue by a third party, or via the submission of an RPI web form.
The JSON package format is as per the following example:
{
'TriggerKey':'5df1c3d2-fc20-419c-8462-982e7769524a',
'SendAddress':'jim.hinder@Redpoint.net',
'Parameters':
{
'FirstName':'John',
'LastName':'Smith'
},
'RepeaterParameters':
[
{
'OrderTitle':'Purchased',
'ParamProductName':'Product X',
'ParamProductValue':'9.99',
'ParamProductDate':'04/07/2016 00:00:00'
},
{
'OrderTitle':'Purchased',
'ParamProductName':'Product X',
'ParamProductValue':'9.99',
'ParamProductDate':'04/07/2016 00:00:00'
}
]
}
Please note the following:
•TriggerKey must be set to the required queue listener's Listener key GUID value.
•If the posting of the JSON package to the queue is to initiate the sending of an email, the recipient's email address must be supplied as the SendAddress.
The Parameters section represents data that is to be substituted at parameter attributes (e.g. contained in email offer content). The names of the passed parameters must match the names of the parameter attributes to be substituted.
The RepeaterParameters section is used to pass details of repeating entities that are to be output in offer content. For example, you might want to send a customer a confirmation email listing the products that they purchased. You can pass the products' details in the RepeaterParameters section, then include parameter assets representing the same in a table asset in the email offer they are to be sent.
Queue listener repeater parameters, as defined at a queue activity’s audience definition, are stored in a data warehouse table named ‘[Queue listener resolution table name]_RP’. For more information, please see the Audience Definition section in the Configuration documentation.
Any packages for the attention of a specific queue listener that are placed on the listener queue when the queue listener is in a Deactivated state are ignored.
The listener queue is checked every second for the arrival of JSON packages. Packages are processed in batches. The maximum number of records that can be processed in the same batch is defined by cluster system configuration setting ListenerQueueMaxBatchSize. For example, if 9 records arrive on the queue, and ListenerQueueMaxBatchSize is set to 5, 2 batches (1 of 5, 1 of 4) are processed.
Upon a queue listener's receipt of a JSON package with a matching Listener key, any downstream queue activities are executed. Such packages may be placed on the listener queue by an external system, or through submission of an RPI web form that has been configured with an interaction and queue listener.
When a queue listener's Realtime Event section has been configured, on the occurrence of a realtime event, and subsequent execution of the Web events importer system task, the queue listener will fire if the type of event matches the listener's configuration, with any Event detail filters applied and all matches at specified event metadata. Any parameters defined in the QueueListenerConfiguration, as sourced from the visitor profile, will be available to the queue listener (these can be used e.g. to personalize content, or can be written to the queue listener resolution table). If a subsequent appropriate event occurs in respect of a specific individual within the duration defined by the Prevent repeat sends for property, the queue listener does not fire.
When you execute a queue activity in Production mode, data from the JSON package's parameters is written to the queue listener resolution table, as defined by the queue activity's audience definition. To be stored in the queue listener resolution table, the name of a passed parameter must match the name of the column in that table (in turn defined by the audience definition's Queue listener attributes. When a column value is not supplied, the parameter attribute's default value is written to the table instead. When the package contains a parameter not in the resolution table, it is ignored. When resolution table structure has been changed, any legacy column values are set to NULL.
If offer content contains a non-parameter attribute with a name matching that of a passed parameter, the parameter value is substituted.
If a queue activity's Generate offer history radio button is selected, a record is written to offer history; If Don't generate... is selected, an offer history record is not written.
If a queue activity is configured with an email offer, an email is sent to the SendAddress recipient using the selected channel's email service provider (note that this takes place after offer history has been written). Any parameter attributes are substituted in email offer content (including any RepeaterParameters to be output within embedded table assets).
If the offer with which a queue activity is configured is edited, its new version is picked up only when the queue activity's queue listener is de- and re-activated.
When you execute a queue activity in Test mode, data is not written to the queue listener resolution table. If the queue activity is configured to write data to offer history, data is written to the offer history sandbox table defined by its audience definition. If configured with an email offer, note that emails are sent when a queue activity is executed in Test mode. If configured with a data extract offer, only the full export file is generated (the channel's Create files in Test mode property being ignored).
On deactivating a queue listener, it once again enters an Inactive state. Any downstream queue activities are also Deactivated. Having deactivated a queue listener that was executing in Production mode, you can re-activate it. You can also make changes to an existing queue activity's properties, including its offer, when Deactivated. Note that you cannot add additional queue activities to a Deactivated queue listener.
If a downstream workflow uses a queue listener workflow as an input workflow, the input workflow must be executed in the same mode. Any activities in the downstream workflow act upon the records sourced from the queue listener workflow. You can execute a downstream workflow irrespective of the current queue listener workflow's status. Note that, if activities in the downstream workflow are to make use of the records gathered by the queue listener, they can make use of the appropriate queue listener resolution level to facilitate their targeting.
On submission of a web form at which a Queue listener interaction and workflow is selected, a JSON package is automatically placed on the listener queue and is picked up by the queue listener with which the web form is submitted. Any queue activities downstream from the queue listener are fulfilled.
If such a queue activity is configured with an email offer, the email is delivered to the email address as submitted in an Email form element. If any web form element parameters are included in the email offer's content, the values submitted in the web form are substituted. If the web form does not contain an Email element, emails are unable to be delivered (the queue activity's Log, as displayed in the Results Window, advises of this fact).
You can execute a Post-channel execution web service following execution of a queue activity offer. HTTP Post/JSON and RPDM Web Service calls can be made. SOAP Web Service calls are not supported in this context, and any such channel settings are ignored.
If configured, Realtime in Outbound can be used to vary delivered content served by a queue activity.