myContactCenterManual

Set up the website connection

Prepare the Routing Service, skill, language, chat flow and HTTPS entry point for website integration.

Prepare the Contact Center

  1. Check that the Routing Service is running, connected to the server and active in failover. A passive Routing Service does not process new chat or WebCallback requests.
  2. Create the required skill and language. Submit their exact names as configured in the Contact Center. The Routing Service compares names directly. A language value such as de-DE matches only if that is the actual name of the configured language.
  3. Assign the appropriate qualifications to agents and check their login and availability for the relevant channel.
  4. For chat: map a chat flow to the skill and language pair. Without a matching mapping, no chat flow starts. See Flow mapping and Channel settings.
  5. For WebCallback: check callback distribution, telephone numbers and outgoing calls. WebCallback creates a callback in the virtual queue; it does not start a chat flow.

Network and public address

The Routing Service exposes all three hubs over HTTP on port 6010. The HTTPS listener is not enabled in the documented code. A public HTTPS website therefore needs an HTTPS reverse proxy in front of this service. An HTTPS page must not call the hub over plain HTTP: the browser blocks such mixed content.

Example mapping on your web server:

Public address Internal target
https://kontakt.example.org/chatHub http://routingserver:6010/chatHub
https://kontakt.example.org/callbackHub http://routingserver:6010/callbackHub
https://kontakt.example.org/acdHub http://routingserver:6010/acdHub

Forward child paths too, particularly /negotiate. The proxy must support the SignalR connection, including WebSocket upgrades. With multiple Routing Services, the public address must lead to the active service. An existing chat connection does not automatically become a resumed chat session after a service switch.

The hub code has no authentication of its own and its CORS policy allows requests from any origin with credentials. Limit publication to the required paths and configure suitable access restrictions and protection against large volumes of requests at the public entry point. CORS is not access control.

Provide JavaScript

Load the ASP.NET Core SignalR JavaScript client once, for example as a locally hosted signalr.min.js file. The old jQuery SignalR client and /signalr/hubs do not match these hubs. The examples expect the library to provide the signalR object.

Register event handlers before connection.start(). Enable the form and sending only after the connection succeeds. Display connection errors and handle them separately from acceptance of the request by the Contact Center.

Test the integration

Test a chat and callback with a logged-in agent who has the appropriate qualifications. Then test a closed skill, an incorrect language, a missing chat mapping and an interrupted connection. Check conversations or the callback queue in Administration and the Routing Service logs. A registration return value of true alone does not confirm successful contact with an agent.

    ↑ ↓ select · Enter open · Esc close