The Data (DT) Parameter

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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

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.

Rollforward recovery on SQL database connections is an essential part of deploying Softdial Campaign Manager™ into large-scale installations and into the cloud. Rollforward recovery mitigates 3 key operational problems:

1. Socket buffer overflows leading to socket closure on the connection underlying an ODBC datbase connection. These overflows are more often than not caused by database server peak load problems.
2. The same problem caused by temporary or absolute network bandwidth shortages between the server hosting the Softdial Campaign Manager™ instance and the database server host.
3. Unreliable network connectivity with cloud provider database instances.

When using DateTime type fields in a Softdial Campaign Manager™ table, the format of the date-time string used in the agent layer is tied to the Softdial Campaign Manager™ application data format.

• When using the XML/ JSON data framing options, Softdial Campaign Manager™ uses parameter binding and passes a string object to the ODBC API. The ODBC layer accepts certain date time formats:

  yyyy-mm-dd[ hh:mm:ss[.9999999][ plus/minus hh:mm]]

  For more information, please refer to:
  • http://technet.microsoft.com/en-us/library/bb677233.aspx
  • http://msdn.microsoft.com/en-us/library/bb677267.aspx
• When using the legacy application data option (i.e. not XML or JSON), Softdial Campaign Manager™ creates an expanded UPDATE statement and the field text value is inserted in to the query string. SQL Server accepts and parses an ISO 8601 formatted string:

  yyyy-mm-ddThh:mm:ss[.999]

  This format is output by the Softdial Scripter™ 2 Current Date Time step.
  
  For more information, please refer to:
  • http://msdn.microsoft.com/en-us/library/ms190977(SQL.90).aspx