Contents
Contact-Processed Notifications
Starting with release 8.1.528.21, OCS can deliver contact-processed HTTP[S] notifications to an external Web or Application Server.
This feature can be used in an environment where feedback from OCS call processing results is required in real time and must be integrated with the customer's backend CRM or similar systems, to provide real-time synchronization of call results and outbound activity outside of the OCS/CX Contact solution. OCS sends notifications of call processing results through HTTP POST requests in a JSON body, delivered over HTTP and HTTPS (TLS 1.2) protocols to a Web or Application Server. HTTPS notifications can be sent via a tunneling HTTP Proxy.
In a typical scenario, a record is retrieved from a calling list and dialed; a call is considered successful and an agent dispositions the call. OCS sends a notification containing a call result to a third-party Web server, based on which the customer CRM system performs further actions.
OCS sends a contact-processed notification per contact (per chain) upon completion of the chain processing for contacts or chains in any dialing mode and for Campaign Groups handling voice, email, and SMS media types. Notifications contain only chain and primary record-specific information in the JSON body of the message.
Feature Configuration
Use the following OCS options to enable this feature:
- contact-processed-notification
- contact-processed-notification-uri
- http-retry-applies-to
- http-retry-max-attempts
- http-connection-pool-size
- http-custom-headers
- http-proxy
- http-response-timeout
Message Content Details
OCS generates a message for a chain when the chain reaches the processed state in its Finite State Machine. For example, a negative call result is received for a chain and a treatment (if present) is prepared to be applied, or an agent has finalized the chain processing from the desktop.
Message Headers
The message contains standard HTTP message headers (similar to pre-dial validation requests). The http-custom-headers option, defined at the Application or Host object level, specifies custom headers that can be added to the message. For example:
Accept: */* User-Agent: OCS/8.1.528.15 Host: 172.21.83.91:80 ETag: <Value of GSW_MESSAGE_GUID> Content-type: application/json Content-length: 1307
Message Body
The following table describes attributes that can be included in the JSON body.
Field | Description | Type | Mandatory |
---|---|---|---|
GSW_MESSAGE | ContactProcessed | String | Yes |
GSW_MESSAGE_GUID | The unique ID of the HTTP notification message being sent. It also is passed in the ETag header of the HTTP POST request. If a notification is re-sent because of the HTTP retry logic, GSW_MESSAGE_GUID remains the same. | String, GUID | Yes |
GSW_TIMESTAMP | The UTC timestamp when the message is being generated. If it is resent because of the HTTP retry logic, the timestamp remains the
same. |
String, Unix UTC epoch dot milliseconds | Yes |
GSW_CALL_ATTEMPT_GUID | The unique ID of the call processing attempt. | String, GUID | Yes |
GSW_PHONE | The phone number (contact_info) field of the primary record in the chain. | String | Yes |
GSW_PHONE_TYPE | The phone type (contact_info_type) field of the primary record in the chain. | Integer | Yes |
GSW_CHAIN_ID | The value of the Chain ID field of the primary record. | Integer | Yes |
GSW_CHAIN_N | The value of the Chain N field of the primary record. | Integer | Yes |
GSW_RECORD_HANDLE | The Record Handle of the primary record in the chain, for troubleshooting purposes. | Integer | Yes |
GSW_REASON | The reason code for the event generation that is equal to the Cause of the GOChainProcessed event—for example, GOCauseChainProcessingDone. | Integer | Yes |
GSW_CHAIN_LIFO_GUID | The GUID of the chain that is created by CX Contact if the Campaign Group is a CX Contact and LIFO Campaign Group. This field is CX Contact specific. It allows to identify LIFO-processed contacts vs. standard contacts. | String, GUID | No |
GSW_CUSTOMER_ID | The ID that is taken from the c_client_id field of the Calling List (this field is configured with the GSW_CUSTOMER_ID send_attribute). This field is optional but it is sent if it is defined in the Calling List table. | String | No |
GSW_CALL_RESULT | The call result field of the primary record. | Integer | Yes |
GSW_DISPOSITION_CODE | The value of the Disposition Code that is provided to OCS by the agent desktop in a record finalization request or third-party validation server in a 409 Cancel negative response body in the GSW_DISPOSITION_CODE key-value pair. This field is important; it affects processing on the remote end. | String | No |
GSW_CAMPAIGN_NAME | The name of the Campaign (not Campaign Group). | String | Yes |
GSW_CAMPAIGN_TEMPLATE_NAME | The name of the Campaign Template (the Script of type Outbound Campaign, referenced by the Campaign Group via the scriptDBID attribute). This field is CX Contact specific. | String | No. It will not be delivered by OCS if the Campaign Group does not have a reference to the Template (possible in non-CX Contact configurations). |
GSW_CONTACT_MEDIA_TYPE | As set for the Campaign Group, "voice" | "sms" | "email". | String | Yes |
GSW_CALLING_LIST | The name of the Calling List. | String | Yes |
GSW_CAMPAIGN_GROUP_NAME | The name of the Campaign Group. | String | Yes |
GSW_CAMPAIGN_GROUP_GUID | The Campaign Group (Session) GUID, which is taken from uuid_generator::to_str(Session.pSessionGUID). | String | Yes |
GSW_GROUP_NAME | The Agent or Place Group name. | String | Yes |
GSW_QUEUE_NAME | The name of the Voice Transfer Destination DN. | String | Yes |
GSW_DIAL_MODE | Current dialing mode of the Campaign Group. | Integer | Yes |
GSW_AGENT_ID | The Agent ID field value. | String | No. The field is available for successful calls only. |
GSW_RECORD_TYPE | The record type of the primary record after the processing. | Integer | Yes |
GSW_RECORD_STATUS | The record status. For chains that are finalized into the calling list, the status is final (Updated), not intermediate (Retrieved). For chains that are kept processing in memory by a treatment, the status may be Retrieved. | Integer | Yes |
GSW_OPTIMIZE_BY | The optimization method. | Integer | No. The field is available for Predictive modes only. |
GSW_OPTIMIZE_GOAL | The optimization goal. | Integer | No. The field is available for Predictive modes only. |
GSW_START_PROCESSING | The timestamp when OCS starts processing a given call attempt. If pre-dial validation is in place, this is the time when a pre-dial validation request is sent. | String, Unix UTC epoch dot milliseconds | Yes |
GSW_CALL_TIME | The time when OCS sends a request to the dialer (for example, TMakePredictiveCall). | String, Unix UTC epoch dot milliseconds | No. The field is available when a request was actually sent. The field is not available for negative pre-dial validation. |
GSW_SCHEDULED_TIME | The time when the record is rescheduled. GSW_DATE_TIME in OCS desktop protocol terms. | String, Unix UTC epoch dot milliseconds | No. The field is available only with records of particular types. |
GSW_DIALING | The timeDialing value that is taken from FTC timestamps. | String, Unix UTC epoch dot milliseconds | No |
GSW_RINGING | The timeClientRinging value that is taken from FTC timestamps. | String, Unix UTC epoch dot milliseconds | No |
GSW_RELEASED | The timeBadCallReleased value that is taken from FTC timestamps. | String, Unix UTC epoch dot milliseconds | No |
GSW_ANSWERED | The timeClientPickedUp value that is taken from FTC timestamps. | String, Unix UTC epoch dot milliseconds | No |
GSW_CPD_COMPLETED | The timeCPDFinished value that is taken from FTC timestamps. | String, Unix UTC epoch dot milliseconds | No |
GSW_QUEUED | The timeQueued value that is taken from FTC timestamps. | String, Unix UTC epoch dot milliseconds | No |
GSW_AGENT_RINGING | The timeAgentRinging value that is taken from FTC timestamps. | String, Unix UTC epoch dot milliseconds | No |
GSW_AGENT_ANSWERED | The timeAgentEstablished value that is taken from FTC timestamps. | String, Unix UTC epoch dot milliseconds | No |
GSW_DIVERTED | The timeAMDiverted value that is taken from FTC timestamps. | String, Unix UTC epoch dot milliseconds | No |
GSW_ABANDONED | The timeAbandoned value that is taken from FTC timestamps. | String, Unix UTC epoch dot milliseconds | No |
GSW_AGENT_RELEASED | The timeAgentCallReleased value that is taken from FTC timestamps. | String, Unix UTC epoch dot milliseconds | No |
GSW_ACW_COMPLETED | The time when After Call Work is completed. | String, Unix UTC epoch dot milliseconds | No |
GSW_COMPLETE_PROCESSING | The time when processing of a call attempt is completed. The time when an outbound record for the given call is considered completed and is removed from OCS active processing. | String, Unix UTC epoch dot milliseconds | No |
User-defined fields: <USER FIELD KEY NAME 1> |
Any user-defined fields with the send_attribute defined, which have been modified during this round of chain processing—for example, Other1-OtherX fields as modified by the agent desktop. | String | No |
Feature Limitations
- Authentication (except for providing pre-configured HTTP headers) is not supported. OAuth and similar authentication schemas with OCS acting as a client are not possible.
- OCS delivers a notification per chain, not per record. For scenarios involving chain processing (with multiple records from the chain participating in the processing), the message will contain information for a primary record in the chain only. In the scenario below, the primary record is record 1, so the notification is sent with user data updated for record 1. No notifications to a third-party system about records 2 and 3 user data are being updated.
- A chain consists of 3 records.
- A call is placed using record 1 (the primary record) and delivered to the agent desktop.
- An agent requests all chains, record 2 and 3 are sent to the desktop.
- The agent releases the call.
- The agent updates user data in record 2 (by sending an UpdateCallCompletionStats desktop request).
- The agent updates user data in record 3 (by sending an UpdateCallCompletionStats desktop request).
- The agent updates user data in record 1 and finalizes the chain with a RecordProcessed desktop request.
- HTTP redirections are not supported.