Installing and configuring WebSite

To deploy WebChat, WebForm, WebClick, WebCBack, WebMsg, or your own applications built on the WebSite module, you must first install and set up this module. The chapter describes the procedure, module architecture, security aspects, its installation and configuration, WebSite routing and the supplied test applications.

Solution architecture

Řešení chatu vyžaduje, aby bylo možné z internetu komunikovat s jádrem FrontStage - ProServerem, resp. jeho službou Pro.Service. Ústřední částí je modul nazvaný WebSite, který je přístupný z internetu, resp. přístupný webovému serveru zákazníka (provozovatele kontaktního centra). WebSite komunikuje s ProServerem, jenž je umístěný bezpečně v lokální síti se zbytkem součástí FrontStage.

Another specialized module, ServiceLink, is used for integration with social platforms. It must be accessible from the Internet, and it also communicates with ProServer in the local network.

ProServer acts as an orchestrator that controls communication among FrontStage components. From the agent’s point of view, conducting chat communication with a visitor on the customer’s website is the same as any job, and everything takes place for them in the familiar user environment.

../../_images/WebSite-architecture.png

The solution has the following parts:

  • Internet client - An anonymous or logged in person connected to the Internet

  • Client browser - An application for displaying HTML/CSS/JS used by the client (Firefox, Chrome, mobile browser, etc.)

  • Web server - A master server providing content to clients that runs the customer’s master website.

  • Web server with WebSite - An auxiliary web server that facilitates integration with FrontStage, usually hosted on a child domain. The server uses the ASP.NET technology and requires Windows and IIS to run - depending on the primary server technology, this may be the same environment, or it may be separate.

  • ServiceLink - A service associating connectors to various native instant messaging platforms; it usually runs in a separate location from the primary server.

  • Pro.Service - A hub facilitating communication among FrontStage modules; it uses the proprietary SimpleProt protocol for communication. There are .NET4 DLLs that allow communication from applications written in the .NET environment. Other platforms implement SimpleProt directly if they need to communicate.

  • iCC.ServiceSync - A communication broker and control component

  • iCC.ReactClient - A web application in which contact center agents work.

  • Agent browser - The environment in which iCC.ReactClient is displayed.

  • Intranet agent - A contact center agent logged in to ReactClient

  • Utils.WinChat - A test application that allows you to try a chat without having to connect FrontStage to a real IM network or website. It also serves as an open-source template for a programmer of specialized connectors.

Security

As these are system components exposed to the Internet, the security risks associated with them need to be considered. To ensure security, there is only a TCP connection between WebSite (or ServiceLink) and the FrontStage kernel using a dedicated SimProt protocol.

WebSite (or ServiceLink) should be located in the DMZ or hosted externally, while the FrontStage kernel (including e.g. the database server) is located in the operator’s intranet. Both locations should be separated by a firewall.

Even in this case, however, it is necessary to consider the possibility of DOS-type attacks. WebSite limits the number of messages it will send to ProServer, but this limit must be set correctly according to the expected traffic (e.g. the number of expected click-throughs or response web forms sent, etc.).

It is generally recommended to communicate with WebSite using SSL (https://). Traffic for ChatLink is mediated indirectly by the relevant external IM network, which almost always has a protection against DOS attacks implemented; the connector never communicates directly with visitors. Similar security measures should be applied in the case of direct integration into the chat interface for external applications, especially if they allow communication from the Internet.

WebSite module and WebSite applications

WebSite module is a web application deployable on an IIS web server.

A WebSite application is a product contained in the WebSite module in the form of a JavaScript application that you embed into the end customer’s web page using the <script src="..."> element. The WebSite module running on the web server provides the backend for these WebSite applications.

You configure the WebSite module and WebSite applications in FrontStage administration.

The most used applications are WebChat and WebForm. For example, WebChat is a chat window on the customer’s web page that a visitor can use to communicate with a FrontStage agent. A WebForm allows you to embed a form in the customer’s web page to be sent as a script to FrontStage.

Installation overview

The installation of the WebSite module is similar to the installation of other Web applications that form FrontStage, such as ReactClient, i.e. in principle it means adding the application to IIS.

Because WebSite is usually installed outside the LAN, i.e. on a different server than FrontStage, you need to perform all the steps before adding the application to IIS - install the .NET Framework and IIS on the Windows Server.

  1. Installing .NET and IIS

  2. Installing WebSite

  3. Configuring WebSite

System requirements

Technologically, WebSite is an ASP.NET web application designed for the IIS web server. It requires .NET Framework 4.6.2 or 4.7.1 to run.

The server for WebSite should have at least 2 cores, 3GHz (equivalent to Xeon E1620v3 or similar), 8GB RAM, 80GB for OS + logs.

Configuring WebSite

Configuration is done in the web application’s Web.config file.

In the <applicationSettings> section.

Field

Description

DebugIndicators

Logging level and method (Detail, App, SimProt, Events)

PbxProxyParameters

The ProServer name, used port, and default timeout

PbxProxyPassword

ProServer account password (if used)

InstanceName

The name of the FrontStage instance must match the entry in the Configuration table of the iCC central database; it is usually empty.

PeerAddress

The application address in the ProServerMSG sending system suitable for chat applications.

  • @AccountName - For all applications with the given ProServer account

  • =ExtensionNumber - For all applications that have the given branch registered.

  • ~AdminRight - For all applications that have the given administrative right.

  • !AppName - For all applications of the given type (e.g. ‘!iCC.WebSite’ or ‘!iCC.App.ServiceLink’)

WebSiteAddress

A basis for the WebSite URL (root); example - If the application is installed in the virtual directory at http://www.frontstage.cc/chat, then http://www.fronstage.cc/chat/ will be used here.

CookieExpiration

TrackingId validity interval [h], year = 8760

DatabaseCaching

A cache validity interval for the WebSiteRouting and the LiteralLookup tables. The recommended value is 120.

DefaultCulture

A default localization culture (unless it needs to be specified by rules)

ScriptCaching

A cache validity interval for individual scripts [s]; the scripts for each application are located in the Content folder.

ApiRoutingTimeOut

Interval of browser state recovery [s]. The recommended value 15.

ChatServiceCaching

Cache validity interval for information about chat availability [s]. The recommended value is 30.

TaskDelay

An HTTP response delay interval for long polling [ms]. The recommended value is 30000.

ChatServiceRetention

An interval for retaining chat information for a given Trackingid in the memory [m]. The recommended value is 30.

LogSize

The maximum log size (number of items); once it has been reached, an output will be created in the form of a CSV file or to a DB (depending on what is configured).

LogFlushInterval

A log output interval [s]; the log will be written to a CSV file or to a DB (depending on what is configured) at least at this periodicity.

LogCsvTarget

A destination file for logging to CSV; if the parameter is empty, no CSV log is displayed.

LogCsvSeparator

The delimiter used in the CSV file.

LogSqlConnection

A connection string for the target listing to the WebSiteEvent table in the local database (the DB name must be in the connection string); if the parameter is empty, no log is written to the local DB.

LogRemotely

An indication that logging should take place remotely using ProServerMSG messages to the central database in the FrontStage table.

Caution

This option loads the central server and is only suitable for websites with a low pageview or if WebSite is accessible only to logged-in users.

LogDepth

A crawl history depth for each TrackingId (not related to logging); the crawl history submission feature displays a maximum of this number of items (unique URL, by time).

PanelHistEnvelopeHtml

If the crawl history submission feature is turned on, then this parameter contains an HTML envelope to display this history; the parameter {0} is filled with an HTML body consisting of items; the parameter usually contains HTML tags - then it is necessary not to encode it for use in XML (ideally in an XML editor).

PanelHistItemHtml

If the crawl history submission feature is turned on, then this parameter contains an HTML template for displaying a single history item; parameter {0} is replaced by the URL, parameter {1} contains the time of the last visit); the parameter usually contains HTML tags - then it is necessary not to encode it for use in XML (ideally in an XML editor).

MaxFormFieldSize

The maximum length of fields sent by WebForm to the application server; these are text fields - if the field is longer, it will be truncated to this length; on the server side, XSS treatment is then performed according to the XssWebSiteApi rule.

CorsMethods

Enabled HTTP methods for dynamic CORS. If dynamic CORS is used, set GET, POST, OPTIONS; otherwise leave blank - then static CORS or none can be used (dynamic CORS on). Values are separated by commas and there are no spaces between them.

CorsHeaders

Enabled HTTP headers for dynamic CORS. The usual value is Access-Control-Allow-Headers, Origin, Accept, X-Requested-With, Content-Type, Access-Control-Request-Method, Access-Control-Request-Headers. Values are separated by commas and there are no spaces between them.

CorsMaxAge

The maximum validity of pre-authorization for dynamic CORS (preflight) in seconds; the normal value is e.g. day - 86400.
Example of Web.config
<applicationSettings>
    <Atlantis.iCC.WebSite.Properties.Settings>
        <setting name="PbxProxyParameters" serializeAs="String">
            <value>server,18320,20000</value>
        </setting>
        <setting name="PbxProxyPassword" serializeAs="String">
            <value>ABC</value>
        </setting>
        <setting name="InstanceName" serializeAs="String">
            <value/>
        </setting>
        <setting name="PeerAddress" serializeAs="String">
            <value>!iCC.WebSite</value>
        </setting>
        <setting name="ScriptCaching" serializeAs="String">
            <value>3600</value>
        </setting>
        <setting name="CookieExpiration" serializeAs="String">
            <value>24</value>
        </setting>
        <setting name="DebugIndicators" serializeAs="String">
            <value>Detail,RenameLogByDays</value>
        </setting>
        <setting name="TaskDelay" serializeAs="String">
            <value>50000</value>
        </setting>
        <setting name="DatabaseCaching" serializeAs="String">
            <value>120</value>
        </setting>
        <setting name="WebSiteAddress" serializeAs="String">
            <value>http://localhost:60660/</value>
        </setting>
        <setting name="DefaultCulture" serializeAs="String">
            <value>cs-CZ</value>
        </setting>
        <setting name="ChatServiceCaching" serializeAs="String">
            <value>30</value>
        </setting>
        <setting name="ChatServiceRetention" serializeAs="String">
            <value>120</value>
        </setting>
        <setting name="ApiRoutingTimeOut" serializeAs="String">
            <value>30</value>
        </setting>
        <setting name="LogSize" serializeAs="String">
            <value>100000</value>
        </setting>
        <setting name="LogCsvTarget" serializeAs="String">
            <value/>
        </setting>
        <setting name="LogFlushInterval" serializeAs="String">
            <value>60</value>
        </setting>
        <setting name="LogDepth" serializeAs="String">
            <value>20</value>
        </setting>
        <setting name="LogCsvSeparator" serializeAs="String">
            <value>;</value>
        </setting>
        <setting name="LogSqlConnection" serializeAs="String">
            <value/>
        </setting>
        <setting name="LogRemotely" serializeAs="String">
            <value>True</value>
        </setting>
        <setting name="TechChannelNavHtml" serializeAs="String">
            <value>&lt;button type='button' class='btn btn-danger btn-sm'&gt;&lt;b&gt;{0}&lt;/b&gt;&lt;/button&gt;</value>
        </setting>
        <setting name="PanelHistEnvelopeHtml" serializeAs="String">
            <value>&lt;table class="table table-bordered table-condensed margin-bottom-0"&gt;{0}&lt;/table&gt;</value>
        </setting>
        <setting name="PanelHistItemHtml" serializeAs="String">
            <value>&lt;tr&gt;&lt;td&gt;&lt;a href='{0}' target='_blank'&gt;{0}&lt;/a&gt;&lt;/td&gt;&lt;td&gt;{1:HH:mm:ss}&lt;/td&gt;&lt;/tr&gt;</value>
        </setting>
        <setting name="MaxFormFieldSize" serializeAs="String">
            <value>32768</value>
        </setting>
        <setting name="CorsHeaders" serializeAs="String">
            <value>
                Access-Control-Allow-Headers,Origin,Accept,X-Requested-With,Content-Type,Access-Control-Request-Method,Access-Control-Request-Headers
            </value>
        </setting>
        <setting name="CorsMethods" serializeAs="String">
            <value>GET,POST,OPTIONS</value>
        </setting>
        <setting name="CorsMaxAge" serializeAs="String">
            <value>86400</value>
        </setting>
    </Atlantis.iCC.WebSite.Properties.Settings>
</applicationSettings>

CORS

What is CORS?

You can add various other resources to the website - images, fonts, style sheets, scripts, etc. As long as the host page (which embeds) and the embedded resource are of the same origin, then it is a safe operation.

Two URLs are of the same origin if they have the same protocol, port, and host part. Otherwise, they are of cross origin. See the following table for examples of same-origin and cross-origin URLs for the host page of http://store.company.com/dir/page.html (taken from the Same-origin policy article on MDN):

URL

Origin

Reason

http://store.company.com/dir2/other.html

Same origin

The only difference is the path

http://store.company.com/dir/inner/another.html

Same origin

The only difference is the path

https://store.company.com/page.html

Cross origin

The protocols differ

http://store.company.com:81/dir/page.html

Cross origin

Only the ports differ (only http:// without a port means port 80)

http://news.company.com/dir/page.html

Cross origin

The hosts are different

However, some ways of using content of a cross origin (especially AJAX calls) compared to the host page are by default disabled by the web browser due to the same-origin policy.

For example, placing WebChat on the customer’s company.com site means embedding <script src="<url-na-webchat.js>"> into the HTML source of their site (see Embedding into page in the WebChat documentation). If the WebSite (containing webchat.js) is located at othercompany.com, for example, it is a cross origin. Executing a cross-origin JavaScript or AJAX request at a cross-origin URL is impossible by default by the browser.

However, before disabling it, the browser makes a preflight request to ask the foreign othercompany.com location if it would allow the company.com host location to use its content. The way the browser queries and the foreign location responds is called CORS (Cross-origin resource sharing, loosely translated as “shared resources from elsewhere”). CORS works by embedding and reading headers such as Origin and Access-Control-Allow-Origin into the HTTP communication.

Summary

CORS is a general security mechanism for web applications. To set up CORS appropriately, you need to familiarize yourself with it (e.g., https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS).

CORS is therefore set on the WebSite module side if it is located somewhere else than the host site (where we want to embed the WebSite application).

Example - the same origin

../../_images/cors-same-origin.nol10n.png

The following is stated in web.config:

<setting name="WebSiteAddress" serializeAs="String">
   <value>https://localhost:44330/</value>
</setting>

The part before the slash is the same as the page URL (https: // localhost:44330/index-form.html), and in this case no CORS settings are needed.

Example - cross origin

../../_images/cors-cross-origin.nol10n.png

The following is stated in web.config:

<setting name="WebSiteAddress" serializeAs="String">
   <value>https://localhost:44330/</value>
</setting>

The part before the slash is different from the URL of the page (http://frontsrv/test/website/index-form.html), and in this case it is necessary to set CORS - Cross Origin Requests.

Deployment example

Host pages that you want to enhance with a WebSite application are rarely hosted on the same origin as the WebSite module. Nor is this usually possible due to the different technologies of the host site and the WebSite module (e.g., the customer site requires Python running on a Linux server, the WebSite module is an ASP.NET application for an IIS server available only for Windows).

If the host site is e.g. https://company.com, it is recommended to place the WebSite module on https://chat.company.com.

  1. Create a DNS record chat.company.com pointing to the future IIS server.

  2. Install IIS and the web application of the WebSite module on it and expose it to chat.firma.cz.

  3. Obtain an SSL certificate for chat.company.com. You will need the certificate in the PFX format with a passphrase, which you will provide to the FrontStage vendor.

  4. Use the SSL certificate in IIS for chat.company.com. SSL certificates have limited validity. Once they expire, you must obtain a new one and upload it to IIS.

CORS and SSL

The AJAX requests toward the WebSite server must also include a TrackingCookie, which is used to identify the browser when switching between pages. Today’s web browsers allow the sending of cookies only if they are sent over a secure https connection - so-called SSL/TLS.

Only the following combinations are allowed between the host site and the WebSite server:

Page / WebSite

http

https

http

ico-false

ico-true

https

ico-false

ico-true

Simply put, in this case WebSite must always use SSL. This requirement naturally coincides with the requirement for the security of transmitted data in the chat or forms.

Dynamic CORS

You can configure CORS in two ways - either HTTP CORS headers are inserted by the web server or by the WebSite web application. Setting up CORS on IIS requires file editing, i.e. access to the server. However, WebSite includes the ability to control CORS according to the settings made in FrontStage administration. This is a more convenient way for most WebSite users.

Dynamic settings also allow you to configure many pages with different URLs against a single WebSite instance, plus these pages are stored in the FrontStage database (in the WebSiteRouting table) so they can be changed at a glance even for people who do not have direct access to the WebSite installation.

The configuration has two parts. First, the following parameters are firmly configured in web.config:

  • CorsMethods - HTTP methods allowed for dynamic CORS. Set: GET, POST, OPTIONS.

  • CorsHeaders – Allowed HTTP headers for dynamic CORS. Set: Access-Control-Allow-Headers, Origin, Accept, X-Requested-With, Content-Type, Access-Control-Request-Method, Access-Control-Request-Headers.

  • CorsMaxAge – The maximum pre-authorization validity for dynamic CORS (preflight) in seconds. Set the following value: 86400.

The section looks like this:

<setting name="CorsHeaders" serializeAs="String">
  <value>Access-Control-Allow-Headers,Origin,Accept,X-Requested-With,Content-Type,Access-Control-Request-Method,Access-Control-Request-Headers</value>
</setting>
<setting name="CorsMethods" serializeAs="String">
  <value>GET,POST,OPTIONS</value>
</setting>
<setting name="CorsMaxAge" serializeAs="String">
  <value>86400</value>
</setting>

Subsequently, in the administration in the section Configuration ‣ WebSite routing, fill in one entry for each allowed URL for a CORS application.

For this application, only the address (URL regex) is relevant, where the part before the slash needs to be stated from the URL of the pages and possibly the sequence (it indicates the order of evaluation; it generally does not matter). The other fields are not used for anything in respect of CORS.

Note

Only the part of the URL before the slash plays a role. The following URLs have the same core part of https://www.frontstage.cc, and one entry in WebSiteRouting is enough for all of them:

  • https://www.frontstage.cc/

  • https://www.atlantis.cz/profil-spolecnosti

  • https://www.frontstage.cc/vendors/jabra

  • https://www.frontstage.cc/support/technical-support/intro.html

The following URLs, on the other hand, do not have the same base and need more records:

  • http://www.frontstage.cc/

  • https://demo.frontstage.cc/

  • https://www.frontstage.cc:44330/

  • https://frontstage.cc/

Static CORS

Static configuration provides a similar functionality as dynamic, but for only one base URL; you cannot configure multiple URLs at the same time.

Static settings are possible by means of standard web server means.

  1. Disable dynamic CORS for the WebSite module. In the Web.config file, set the CorsMethods configuration parameter (allowed HTTP methods for dynamic CORS) to a null value.

    <setting name="CorsMethods" serializeAs="String">
  <value />
</setting>

  2. Set static CORS in IIS. In Web.config section <system.webServer>/<httpProtocol>/<customHeader>, set the CORS configuration.

    See also

    Fore more information, please refer to IIS documentation for CustomHeaders.

    Example:

    <httpProtocol>
    <customHeaders>
       <add name="Access-Control-Allow-Origin" value="*" />
       <add name="Access-Control-Allow-Headers" value="X-Requested-With, Content-Type, accept" />
       <add name="Access-Control-Allow-Methods" value="GET, POST, OPTIONS" />
    </customHeaders>
</httpProtocol>

Logging

The WebSite module allows you to log significant events during its operation. These can be stored either in a CSV file or in a local MS SQL database. In both cases, it is possible to transfer events to the main FrontStage database to the WebSiteEvent table.

For low-traffic installations, online logging to a central database using ProServerMSG messages is available; however, as this option directly exposes the FrontStage central server to the load from the Internet, consider the potential impact of a DOS attack.

Individual applications then generate specific events in a specific log as follows:

  • WebChat - Chat events in the ChatEvent table (conversations, technical messages, etc.)

  • WebForm - Logs only if WF is associated - then WorkflowEvent

  • WebClick - Logs only if WF is associated - then WorkflowEvent

  • WebCBack - Outbound call events in the CallEvent table

  • WebMsg - Inbound message events in the MessageEvent table

Data structure in the WebSiteEvent table:

Field

Data type

Description

WebSiteEventId

int

Primary key (identity 1…)

TimeUtc

datetime

Event time in UTC

EventType

smallint

Event type.

EventData

nvarchar(MAX)

Event text data; it varies by event type.

TrackingCookieId

uniqueidentifier

A unique session/client ID.

ClientIp

uniqueidentifier

The client IP address. IPv4 has the first 96 bits of zero, IPv6 uses all bits.

ReferenceId

uniqueidentifier

An event reference ID; it varies by event type.

Result

nvarchar(64)

Additional text data for the event; it varies by event type.

Example of data in a CSV file:

2017-06-19T23:20:58.5233844Z;12;0c7f42da-4a56-4db8-9620-787362a917c8;00000000-0000-0000-0000-000000000001;"http://localhost:60660/";41fe11e7-2955-e711-8ba5-0028f8303aaa;"Waiting"
2017-06-19T23:20:58.5233844Z;20;0c7f42da-4a56-4db8-9620-787362a917c8;00000000-0000-0000-0000-000000000001;"Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko";00000000-0000-0000-0000-000000000000;"cs"
2017-06-19T23:20:58.5233844Z;21;0c7f42da-4a56-4db8-9620-787362a917c8;00000000-0000-0000-0000-000000000001;;00000000-0000-0000-0000-000000000000;
2017-06-19T23:21:25.1410410Z;12;0c7f42da-4a56-4db8-9620-787362a917c8;00000000-0000-0000-0000-000000000001;"http://localhost:60660/";41fe11e7-2955-e711-8ba5-0028f8303aaa;"Waiting"
2017-06-19T23:21:55.3423376Z;12;0c7f42da-4a56-4db8-9620-787362a917c8;00000000-0000-0000-0000-000000000001;"http://localhost:60660/";41fe11e7-2955-e711-8ba5-0028f8303aaa;"Waiting"
2017-06-19T23:22:03.0400307Z;12;0c7f42da-4a56-4db8-9620-787362a917c8;00000000-0000-0000-0000-000000000001;"http://localhost:60660/index.html";41fe11e7-2955-e711-8ba5-0028f8303aaa;"Waiting"
2017-06-19T23:22:03.0400307Z;20;0c7f42da-4a56-4db8-9620-787362a917c8;00000000-0000-0000-0000-000000000001;"Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko";00000000-0000-0000-0000-000000000000;"cs"
2017-06-19T23:22:03.0400307Z;21;0c7f42da-4a56-4db8-9620-787362a917c8;00000000-0000-0000-0000-000000000001;;00000000-0000-0000-0000-000000000000;

Example of data in the WebSiteEvent table:

../../_images/websiteevent-table.nol10n.png

See also

Continue by describing logging by application:

WebSite routing

WebSite routing - A list of rules that determine how requests to WebSite applications from different websites are to be processed.

The rules are always relevant to the application. Then they are evaluated in order; the first matching rule is used and the next is not evaluated. If no matching rule is found, the application should not appear in the browser.

You can find them in the administration in the Configuration ‣ WebSite routing section; the fields have the following meanings:

Displayed name

AttributeName

Description

ID

WebSiteRoutingId

Primary Key.

Application

WebApp

For which application the rule is used.

Corresponds to WebSite functions (REST calls /api/Routing/webapp?RegionalTime=x&UserToken=y&IncludeSettings=z

The applications are WebChat, WebClick, WebForm, WebCBack, WebMsg.

The Lang special application is used to define the default language and is used when no localization is found for a particular application; if no localization is found even with Lang, the default localization web.config` is used;

Order

Rank

The order in which the rules are evaluated (but always for the application).

Browser language (ISO)

PreferredCulture

Preferred language two-character ISO code (cs, en, …)

Address (URL Regex)

PageUrlRegex

Regex for page address comparison; example: ^http:\/\/www\.atlantis\.cz\/servis.*$.

Browser (UserAgent Regex)

BrowserRegex

Mask on UserAgent string browser (REGEX syntax).

User mark (UserToken Regex)

UserTokenRegex

Mask on UserToken (REGEX syntax).

IP mask

ClientIpMask

The subnet filter where the application is called. IPv4 Syntax: 192.168.1.1/24 or IPv6: 2001: 0: 5ab7: 9082: 38a7: 3ac5: ad2f: d915 / 64

Calendar mode

TimeMode

Time condition (local server time). How to Interpret TimeFrom / TimeTo Fields. If it is NULL, time is not checked.

From

TimeFrom

Date and time of the time condition. YearInYear is ignored, DayInWeek is extracted only the day of the week. May be NULL only if TimeMode is also NULL. Local time.

To

TimeTo

Date and time end of time condition. YearInYear is ignored, DayInWeek is extracted only the day of the week. May be NULL only if TimeMode is also NULL. Local time.

Blocked (processing terminated)

Block

Indicates that, instead of applying the rule to the application, it evaluates that there is no rule for the application, so the application will not be rendered.

Processing of further rules for the application will be terminated and the same procedure will be followed as if no matching rule had been found.

Log

LogUrl

Indication to perform full logging of visits to the WebSiteEvent table.

If the parameter is disabled, only script downloads and their URLs are logged. However, since the script will often be cached by the browser or on the CDN, the logging may only serve for basic reference.

Script Template

Template

(WebMsg only) HTML template name and settings for rendering.

It is mainly used for JavaScript integration. If not filled in, the application name is used directly as the template name.

The template files are stored in a subfolder Content.”

Layout template

WebSiteTemplateId

Target HTML element

TargetElementID

Indication of how to render the application.

Blank usually means rendering on the page as an overlay. The name then indicates the ID of the HTML element (typically <div>) into which the application is to be rendered (sometimes referred to as TargetElementID).

Localization language

LiteralCulture

Select the localization to be used for rendering.

For the Lang application, this parameter is the only output. If no localization is found for a particular application (it is empty), the default one according to Lang is used; if not, the one specified in web.config in the DefaultLangugage parameter is used.

Routing outcome

WebResponse

A free text parameter that can be used for further processing, both on the external site side (passed as a literal) and on the central server side:

If WF is running, passed as InstanceKey, for chat it is used as the initial ExtReposnse in the ChatPreCondition processing.

Track chat URL

ChatTrackUrl

(WebChat only) Specifies how the visitor’s navigation should be tracked during the chat.

See Tracking chat URLs.

Scenario

ScenarioId

If the application uses a form, then scenarios of that form. Individual applications use the scenario as follows:

  • WebChat – A form at the start of a chat, optional; this form is used only for data collection on the external site, the form associated with the chat (for ICR purposes, etc.) can be changed using ChatGateCondition, then the data is copied to the target form based on the TargetColumn field name match

  • WebForm – A used form; if WF is used, the form is associated with WF, otherwise it is just stored; mandatory - if not filled, the form is not rendered

  • WebClick – A form to which the data from URL (QueryString) is fetched; if WF is used, the form is associated to WF, otherwise it is only stored; optional

  • WebCBack – A form when creating a callback, optional

  • WebMsg – A form for message creation, can be expanded into a template; optional

Working procedure

WorkflowId

Which workflow (WF) to run for the application (if used). Individual applications use the WF as follows:

  • WebForm – Submission of the form by a visitor triggers the WF; InstanceKey is the user’s TrackingId; InstanceRefId is the WebSiteRoutingId; the form is attached to the WF as a runtime form ScenarioResultId; optional

  • WebClick – URL invocation by a visitor starts WF, InstanceKey is the user’s TrackingId, InstanceRefId is the WebSiteRoutingId; if a form is attached to the application, then it is attached to WF as a running form ScenarioResultId; optional

  • WebChat, WebCBack Webmsg - not used

Outbound campaign

OutboundListId

(WebCBack only) The outbound campaign to which the outbound call should be based. Outbound calls are generated to the set campaign; mandatory.

Message template

MessageId

(WebMsg only) Messages are generated as inbound, according to the set template.

Not only the subject and body of the message are used from the template, but also all the data, especially the message type (Email, SMS, Fax), data like Mass Campaign, Project, Language. The template is expanded according to the form, if any.

Prompt delay [s]

SolicitationTimeOut

Time in seconds after which the application should actively reach the client. Specifically, for Webchat, it prompts you to display a chat window if the client is longer than this time on that page. NULL - function disabled.

Prompt display duration [s]

SolicitationDuration

The time in seconds for the automatic prompt to be displayed, after which the prompt is automatically hidden. NULL - don’t hide automatically.

Quiet period without prompting [s]

HonorRejectPeriod

Time in seconds during which the client will not be prompted even if the page is longer than SolicitationTimeOut if he / she actively closed the earlier challenge.

Technical address source.

TechnicalAddressSource

If set to take the address from a form field, the corresponding screen element must be named PartyAddress.

See also Visitor identification.

Remote party name source.

RemotePartyNameSource

0=SiteName, 1=UserToken, 2=FormField, 3=PartyToken, 4=Explicit.

If set to take the name from a form field, the corresponding screen element must be named PartyName.

See also Visitor identification.

Literal group

LiteralGroup

Tracking chat URLs

One of the important settings WebSite routing is Track chat URL, which determines how the visitor’s navigation should be tracked during the chat.

  • Navigation channel for co-browsing - Always the last URL is displayed in the agent’s chat editor; the URLs found in the navigation mapping under the ChatUrlMap key are clickable and launche a shadow page for co-browsing:

    ../../_images/chattrackurl-maps-are-clickable.png

  • Technical channel during each navigation - Every transition between URLs is recorded in the conversation.

    Caution

    If the visitor opens multiple windows at the same time, the situation may not be entirely clear to the agent; navigation information is registered when the page is first loaded (calling /api/Routing/WebChat including IncludeSettings=true), when starting a chat (/api/WebChat/Start) or when sending a replica conversation (calling /api/WebChat/Text).

    ../../_images/chattrackurl-multiple-windows.png

  • History from the log to the technical panel - When the chat starts, a list of unique pages is sent from the logged history to the client editor panel (maximum number of items is given by the LogDepth parameter in web.config); custom logging does not have to be enabled (history is tracked separately):

    ../../_images/chattrackurl-log-history.png

WebSite, application, and FrontStage versions

As part of the FrontStage release, you also receive the WebSite module. Therefore, it shares the same version number. However, the WebSite application is developed independently, so compatibility between FrontStage/WebSite and the WebSite applications is important.

Tip

Use the highest version available for new installations.

FrontStage/WebSite version

WebChat version

WebForm version

3.13

4, 5 or higher

2 or higher

3.14

4, 5 or higher

2 or higher

3.15

5, 6 or higher

2, 6 or higher

3.16

6 or higher

6 or higher

3.17

7 or higher

7 or higher

3.18

8 or higher

8 or higher

WebSite version

The version of WebSite applications may be important in troubleshooting. You can find this out from the console protocol after turning on the developer tools on the web page with the application (e.g. WebChat in the picture).

../../_images/webchat-version.png

Test applications

Two useful applications are provided to test and debug WebSite.

Utils.WinChat

../../_images/utils.winchat.en.png

WebSite test client

It is actually a part of Utils.WinChat and you can open it by clicking on the last icon at the top right.

../../_images/utils.winchat-website-test-client.en.png