Latest revision as of 18:56, 2 February 2016

1 Overview

From the original "Project: Data Push"

Data Output through Campaign Outcomes

Date: 2010-02-13

All n One’s bxp has the ability to "push" data to other systems in real time, without the need for custom development. This will allow real time systems integration with any system that can receive data.

2 Process

As with any general computer system, there are three process stages.

A simple example would be Google

• Input: Type what you're looking for
• Process: Google will search for you
• Output: The found pages are displayed on screen

The same sequence occurs when processing records in BE using Inbound Contact and Outbound Contact.

• Input: User enters data into a campaign script and chooses an outcome
• Process: The rules of the outcome are processed
• Output: The updated record is displayed on screen

Project Data Push expands outcome process functions and increases the output elements.

3 Outcome Processing

An outcome is processed in distinct steps. Understanding_the_Outcome_Process_Order

The DataPush step opens a large number of possibilities for the integration of BE with other systems.

4 Functionality

Essentially bxp can now create a custom block of data and push it to a number of destinations. This pushing is done at a server level and does not require any action or intervention by the user.

To explain this solution using non computer ideas:

I have some information I want to send to someone. I can send the information in a non structured way, like a handwritten note, or in a structured way, like filling out a form. (Structured or non structured formatting)

In order to move that information I could put in a letter, send a postcard, or mail the form. There are many possibilities. (Message format)

Obviously my intended recipient must have an address (Destination) and be able to collect from his letterbox and open the letter (Delivery mechanisms)

We also need some a mechanism to check that the whole message arrived and that it did so in the right order (Error management)

In the next section we examine each of these elements in detail.

5 Structured or non structured formatting

Every outcome in bxp can now be in any format or layout, as desired. An unstructured output might look like this:

Unstructured:

Dear XXXX,

Thank you for your email address (yyyy). Can I confirm your phone number (zzzz)

Kind regards,

Agent Name

Whilst a structured format (form) might look like this:

Structured: (xml formatting) <name>XXXX</name> <email>YYYY</email> <mobile>ZZZZ</mobile> <agent>Agent Name</agent>

bxp uses the structured annotation of –strCDA_J_field_K_L--, where the data field name is encapsulation in a -- notation. bxp dynamically replaces these fields during the sending process.

• J = Campaign Id,
• K and L = the field and element number to be sent.

To identify which field you wish to use, simply look each field's code up using: Form Management > Form Management > Field Mapping – Manage -> Choose your Form. This will list the field codes of every data field for a specific campaign.

Using the above examples for campaign with an Id of 40, we would see:

Unstructured:

Dear –strCDA_40_field_0_1--, Thank you for your email address (–strCDA_40_field_0_2--). Can I confirm your phone number (–strCDA_40_field_0_3--) Kind regards, –strCDA_40_field_0_4—

Structured: (xml formatting) <name>–strCDA_40_field_0_1--</name> <email>–strCDA_40_field_0_2--</email> <mobile>–strCDA_40_field_0_3--</mobile> <agent>–strCDA_40_field_0_4--</agent>

In this way system users can design the exact format they require.

6 Message format

When data is sent from one server to another, there is a setting in the transmission, which controls the Content Type. This allows the server at the far end to manage the incoming information properly.

(If you receive a letter, it has to be opened and then read whereas if it is a postcard, it is just read).

bxp supports a number of these data types:

• XML – eXtensible Markup Language. A very popular approach to managing data and transfer of data between systems
• Text – Pure unaltered text data
• HTML – HyperText Mark-up Language. A common formatting for web forms and other web published data.

Whilst the majority of receiving servers will generally support at least one of these formats, BE can if necessary, be expanded to support other types.

7 Delivery mechanisms

Currently all web deliveries are done using HTTP and HTTPS - HyperText Transfer Protocol (Secure) - delivery protocol.

HTTP is unsecured and as such, is not recommended for use as a delivery mechanism. Wherever possible use HTTPS. However either can be used depending on the functionality and technical level of the receiving server.

bxp uses the Microsoft MSXML2.ServerXMLHTTP object to allow bxp to perform a RESTUL POST of data to a receiving server.

8 Destination

There are a number of options for outputting data. It can be "pushed" directly to another server or, to accommodate systems that can't be "pushed" to, the data can be output to the screen. A "copy to clipboard" button is provided which will allow agents to paste the data into other applications manually in the event that automation isn't possible.

9 Error management

Due to the inconsistency of the Internet, delivery can fail for a number of reasons.

Stretching our postal analogy:

000 – Server gone away. The post man has arrived, but the building does not exist. This can happen when a server or internet connection fails at the receiving server end.

401 – Access denied. The post man arrived, but the dog in the garden would not let him deliver. This happens when security permissions are set up wrong, or have changed.

404 – Page not found. The post man arrived. However the address it's sent to does not exist at this address. E.g. Sent to flat 20, but the flat numbers only go as high as 10. This is usually a result of typo when setting up the outcome, or the receiving service has been turned off.

500 – Server error. The post man arrived but the builders are in and the door has been temporarily removed. This is usually a configuration error on the recipients’ server and often happens during initial setup or indeed if the processing rules on the recipients’ server have been changed.

In each of the above cases, bxp will keep a record of the data.

There is a 30 second timeout on delivery which means that if bxp cannot get an answer from the recipient server within 30 seconds, it will give up attempting delivery for this record, with this outcome.

If this happens, whilst a standard error message will always be shown to the user on screen, a number of other protocols can also be established, for example:

1. For any delivery status, a status message can be shown to the user

2. An error email can be sent to specified people, notifying them of the failure. Email delivery is to a nominated address and will also be CC'd to the All n One support team.

10 Outcome Section

Each outcome now has the following section added to it

Output Options: Explained as [Destination] previously

• Blank: This section is not used at all
• Screen: Resulting data will be displayed on screen only
• Server: Resulting data will be sent onto to the recipient server
• Both: Outputs to both

Content Type: Explained as [Message Format] previously

• Blank: If section used, the default, if not selected, will go to Text
• HTML: HTML formatted output
• Text: Pure text, no formatting
• XML: Pure data, will require XML header in Data

Post to URL: Explained as (Delivery Mechanisms) previously

The URL of the recipient data server. The full HTTPS address will need to be included. This field is also subjected to transformation of the – field annotation, so data can be included in the URLs being used.

Show Server Response:

When using the Output Option: Server, the server should always respond with some message, even an OK, or status code. Do you wish to show this server response to the user? Errors will be shown regardless; however, do you wish to display success status messages as well? Can be very useful for users if there is an authentication code sent back by the recipient server

On Fail – Email: Explained as [Error Management] previously

The email address or addresses, separated by commas, if the recipient server fails to get a data push. Support@allnone.ie is by default CC'd on this email.

Data: Explained as [Structured or non structured formatting] previously

Place your data, including -- annotations here.