Infrastructure
All information related to dydu infrastructure is available on this page.
Disk and bandwidth usage
The javascript file of the complete dialog box (regardless of the chosen integration) weighs around 250 kilobytes.
In the particular case of integrating the dialog box into popin, the javascript code of the dialog box is split into two files.
The first file includes the bare necessities to download the second one that contains the entire dialog box. The first file weighs less than 10 kilobytes.
Thus, the bandwidth required for the dialog box is reduced since only the users who request the bot will trigger the download of the javascript file of the complete dialog box.
Internal server connections
Main server → Backup application server or vice versa:
HTTPS connection.
Main server → Server for dumps backups:
SSH connection by key.
Main server → Antivirus server:
Unsecured connection.
Main server → app1.mercury:
HTTPS connection.
Important: all applications establish a secure connection (HTTPS). However, it is possible that some of your web services function in HTTP according to your parameters.
High availability
In case of failure of the main server, a backup server is configured to take over.
Switching from the main server to the backup server should be as transparent as possible for the user, the customer interface (on the chatbox side) has to address one or the other server.
There are two special cases:
The first case concerns users of a web interface (chatbox). Requests are automatically redirected to the back-up server, whether during a dialog with a bot or in Livechat:
Technically, a new dialog is initiated on the back-up server and will continue until it is complete, even if the primary server is reachable again.
The second case concerns operators connected to the Livechat desk. A server change is made transparently by reloading the page. This is done only when the operator is connected to a URL of type "app1.xxx.com/router". Otherwise (the operator is connected to a URL of type app1.xxxx.com/livechat2), the operator must manually switch to the back-up server (change of address from app1.xxxx to app2.xxxx). This last case should no longer appear today because there is an automatic redirection of "app1.xxxx.com/livechat2" to "app1.xxxx.com/router".
Dialogs on the back-up server are automatically repatriated to the main server through synchronization every hour. This leads to a duplication of dialogs - in the history of dialogs and analytics - initiated on the main server and restarted on the backup server by the same user.
The synchronization between the main server and the backup server (knowledge base, bot configuration, access, etc.) is done weekly but full copies are made daily for manual restoration in case of problems.
For On-Premise clients, this disposition requires a special configuration:
Creating a Rescue Server (Client Action);
Install the dydu application on this server in "back-up server" mode (the information must be provided by the client for the generation of a specific Docker image by dydu);
Update of the main server with the address of the back-up server (update of the Docker image by dydu then update of the server by the client);
New generation of the chatbox on the main server so that it can direct its requests to the main server or back-up server (Client Action);
Creation of a regular task to dump the main server and restore it to the backup server (Client action with stop of the backup server needed during the restore).
Proxy configuration (On-premise environment)
To configure the proxy, you must use the following file (available in the latest version of docker-compose (43.3050+)):
env_file:
~/.dydu/options.env
The following variables are available (standard Java variables):
http.proxyHost
http.proxyPort
http.proxyUser
http.proxyPassword
http.nonProxyHosts
https.proxyHost
https.proxyPort
https.proxyUser
https.proxyPassword
Notes:
"https.nonProxyHosts" does not exist and must use "http.nonProxyHosts";
Values can not be entered or quoted;
Values must not contain spaces.
Configuration example
http.proxyHost=*.localdomain.com
http.proxyPort=80
http.proxyUser=login
http.proxyPassword=mdp
Important: rebooting the platform is required for the configuration to be functional.
Last updated
