The Data (DT) Parameter
Many SDMP messages (e.g. Agent Connect [AC], Transaction Complete [TC]) support data transfer using the Data (DT) parameter.
Associative behaviour of the Data (DT) parameter
Some time ago we made provision in Softdial CallGem™ for the Data (DT) parameter to be associative, based on its use in Softdial Campaign Manager™ but also for keeping session data to be passed between different business processes during the session lifetime.
The Data (DT) parameter string may have one of 3 formats:
- A set of key-value pairs where the key and data values are represented by an XML stanza. This is the current generation Softdial Campaign Manager™ data exchange format.
- A set of key-value pairs where the key and data values are represented by a tokenised string separated by tilde (~) characters. This is the legacy Softdial Campaign Manager™ data exchange format.
- A freeform string. This enables third party applications to use their own schemes for data exchange.
Softdial CallGem™ parses the Data (DT) parameter on input and determines what type of framing the parameter has. If a set of key-value pairs of either form, it stores the data in a dictionary keyed by column name. Interactions with the session where the Data (DT) parameter value is changed result in the passed string being parsed and the dictionary entries being updated or added to.
Why is this behaviour necessary?
Surely the Data (DT) parameter is application-specific?
The answer is that Softdial CallGem™ is a session manager and tracks session state and session data throughout its lifetime.
Let us consider a simple use case of an inbound call.
- An inbound call may initially be terminated to an IVR process. The IVR process will solicit information from the customer that may not persist into a database, but will be necessary to the lifetime of the call; for example the nature of the customer’s enquiry.
- As well as this the IVR may perform a customer lookup using CM to get the customer’s account information. Both the account information AND the IVR choices need to be attached to the call.
- On transfer to an agent for processing the agent will need to make use of the account information and IVR data, and may also add data used for fulfilment processing that does not persist.
- The agent may transfer the call or session on to a fulfilment agent (or a fulfilment process robot) that is following a workflow that makes use of all of the data captured to perform the right fulfilment actions.
- Finally on completion, Softdial Campaign Manager™ needs to update the customer database with those pieces of data that have been updated and need to persist.
As you can see from this everyday real-world example, the need to keep a data dictionary associated with a session is fundamental to having joined-up workflows in the contact center.
How associative behaviour works
Aficionados of programming languages like BASIC, PERL, Python and AWK will be familiar with associative behaviour when declaring variables. To declare a variable, just use it. If it does not exist it will be created and null-initialised.
With the Data (DT) parameter things are fairly similar.
If an IVR script gathers 3 pieces of data named foo, bar and qux and then transfers the session to a third party it will use the Data (DT) parameter to contain these 3 pieces of data (using legacy or XML framing).
Softdial CallGem™ now maintains a session data table looking like this:
| Key | Value |
|---|---|
| foo | Hello |
| bar | Everyone |
| qux | 603.1769 |
The next application handling the call can use this data, and may add/ create data value of its own. Let us assume that the value for bar is set to “Everyone” and the value for norf is set to “Keys 1 to 5”
On passing this data back in to Softdial CallGem™ via one of the various APIs that handle the Data (DT) parameter, the session data would be updated to:
| Key | Value |
|---|---|
| foo | Hello |
| bar | Everyone |
| qux | 603.1769 |
| norf | Keys 1 to 5 |
At each stage where data is added to the data dictionary, Softdial CallGem™ does not discard previous data. This allows session data to be exchanged between potentially disparate contact center workflows.
Use of the Data (DT) parameter by integrators
From V10.6.568 - a breaking change has been made to the format of the XML document used with the Data (DT) parameter. For details of this change, see the Softdial Campaign Manager™ Data (DT) Parameter - XML Format page.
Use of the Data (DT) parameter has evolved with Sytel’s ongoing development of Softdial Scripter™, Softdial Campaign Manager™, Workflow Server (for multimedia) and our core ACD. All of Sytel’s applications support use of the Data (DT) parameter in either legacy or XML framing modes. For third parties using the Data (DT) parameter with either XML or legacy framing we would advise as follows:
- Treat the data as a dictionary. If you need a data value, look it up by key rather than relying on a token position in the Data (DT) parameter string.
- If adding to the set of data for the purpose of data exchange between different workflows acting on the same session, make the new keys unique - something that couldn’t possibly be in the database. CM creates keys that are database column names.
- Ensure you use the same framing throughout your applications. Softdial CallGem™ will not mix legacy and XML framing. Softdial Campaign Manager™ configuration determines the framing type that will be used.