Presentation

The purpose of this white paper is to help you understand how Self Help can be integrated into your technical environment.

Because individual constraints and technology choices make each client's infrastructure unique, every project will undergo a specific analysis during the pre-sales and/or installation phases.

Product glossary

Self Help is based on three main functions:

• A presentation function for procedures and the virtual agent.
• An edit function for procedures and the virtual agent.
• A Self Help Studio fat client installed on the procedure author workstations.

Depending on your project, the edition and presentation functions can be run on the same machine or split between machines. The target architecture and integration into your infrastructure must take this allocation into account.

Global architecture

Service components

Depending on the architectures and the workload, the edition and presentation servers can be run on the same machine.

The servers have identical installations and can support all Self Help functions.

Adaptability to requirements

Progressive scalability

The Self Help architecture is scalable. It can be reviewed and modified based on changes in your requirements. You can start your project with a basic architectural model and review it subsequently if the number of concurrent users increases, if your security rules change or if functionalities are added to the initial project scope.

Each tier can be scaled separately using more or less resources based on the requirements identified. Scalability primarily affects the Self Help presentation servers.

The diagram below shows a few examples of the possible presentation server architectures.

We recommend that a presentation server is not placed in a DMZ, instead use a REVERSE PROXY to publish the application.

Scalability

Our services can go from simple platforms with two servers, up to configurations comprising several dozen lines, potentially split into different security zones.

The first design criterion relates to scalability, the aim being to use the two dimensions available to you:

• Scale IN: Addition of CPU or memory resources to existing machines so they can handle a greater workload. While this approach is cost-effective (fewer VMs to manage, fewer licenses, etc.), it quickly reaches its limits because certain internal system resources are not expandable (thread, etc.).

• Scale OUT: Addition of new machines to take some of the workload. This approach is more flexible, but it means the architecture is more complex due to adding a load balancer to distribute users across servers.

Whatever the architecture and without other constraints than scalability, it is always interesting to use the SCALE IN as much as possible without adding new machines.

Resilience

What is the platform's desired availability level? A high level (24/7, for example) will involve a more complex architecture that includes additional lines based on the desired scalability conditions.

These additional platforms will take on the workload in the event of failure of one of the base lines defined as necessary for handling the target workload.

The technical solution will depend on the tolerance that you desire and, therefore, the degradation in service or the complete temporary loss of this. Here are some examples:

• Temporary loss of aSelf Help line: Add an additional line
• Temporary loss of a database server: The database server must be clustered for greater availability. But if a loss of several hours is tolerable, VM re-mount and database restore can be sufficient.
• Temporary loss of the load balancer: Load balancer clustering.

We recommend that you permanently integrate these additional resources into the production chain rather than keep them offline and ready to be started. Although the cost of a running machine is greater than the cost of an offline machine, this will ensure that these machines are correctly configured / up to date when you need them.

Maintenability

If your security policy requires that you regularly update operating systems, we recommend integrating an additional line to the line which has already been sized for scalability.

This additional line, which is not included in the workload demand, will allow you to update your operating systems without impacting production.

Here’s an example with three lines, A, B et C (C having been added while only A and B are required for the workload):

• A and B in production; C taken out of production + updated + returned to production.
• A and C in production; B taken out of production + updated + returned to production.
• B and C in production; A taken out of production + updated + returned to production.

Two lines are available at each step, ensuring that users are not penalized.

Load balancer

Our services can be placed behind a load balancer to evenly distribute users wishing to connect to the different lines available.

Your load balancer must allow "session persistence", in other words, a user that has already been authenticated by one of the lines must be directed to that line for as long as they are connected. If not, the user's previous authentication will not be found, and the service will ask them to log in again.

Reverse proxy

Our services can be placed behind a reverse proxy. The reverse proxy can, among other things, change the type of request (incoming https to http on the web front end), but it must not:

• Change input parameters;
• Change the URL itself (by adding folders, changing the domain, etc.).

If the reverse proxy includes content control functionality (WAF, antivirus, etc.), it must not change the content passing through it (parameters, content, etc.) apart from its own HEADERS parameters.

Security of your data in transit

To safeguard the confidentiality and integrity of data flows, we strongly recommend protecting the Self Help front-end servers with certificates.

We also advise the following:

• Use certificates provided by a trusted third party. Private certificates will work but will generate lots of errors when accessed from mobile devices outside your network (mobile phones, etc.).
• Configure your SSL so that it does not accept protocols, ciphers, etc. that are known to be vulnerable: SSL v2, SSL v3, TLS v1.0, RC4, 3DES, etc.

Here is an example to base the SSL layer on:

Need for other environments

As well as the production environment, you can create additional environments to meet your organization's needs.

We recommend creating and maintaining at least one additional environment so that you can test changes before applying them to your production environment, in particular:

• Fixes or major developments on our products;
• Changes in server component configuration (Apache, Tomcat, SSL etc.);
• Version updates or fixes for operating systems or server components.

Browsers

Suppliers

The browser market is constantly evolving, so please refer to our Supported browsers wiki page for an up-to-date list of compatible browsers.

Configuration

The limit of the local cache and temp files must be adequate (> 10 MB).

If you are using the SSL protocol, you should check that the cache is authorized for the secure page.

Others

Our services do not require APPLETs or ActiveX on the client browser.

Cookies

Our services use cookies to improve website functionalities and user experience. These cookies do not contain personal or sensitive data.

Your browser must authorize our services to create cookies.

Some architecture examples

Monoline architecture over LAN

A single line reduces hosting costs but does not guarantee maximum availability.

The edition and presentation servers can be grouped together on the same machine by allocating available resources (CPU, RAM, hard disk) accordingly.
         

Multi-line architecture over LAN

Multiple line architecture for presentation servers offers scalability (number of base lines) and high availability (an extra line for an equivalent service, even if one line is lost).
         

Application publishing

Self Help is published online using a proxy.

Technical interoperability

Schematic diagram

The following diagram presents the interoperability possibility of Self Help.
         

REST

REST supplier

Our services are available via RESR and SOAP 1.2.

REST client and SOAP 1.2

The services can use external REST or SOAP 1.2 services.

Email

Self Help must access your e-mail server to send e-mails to your users when handling incidents / changes.

The following protocols are supported: SMTP / SMTPS / SMTPS with TLS.

Interoperability with EasyVista Service Manager

Self Help communicates with Service Manager over https/http for the following functions:

• At the end of Self Help procedures, creation of tickets via REST or SOAP to Service Manager;
• Self Help Extractor: from Service Manager to Self Help over https to consolidate procedures in the knowledge base;
• From Service Apps, for presentation of procedures Self Help over https.

Interoperability with all other tools

Self Help communicates with your tool over https/http for the following functions:

• At the end of procedures Self Help, creation of tickets via REST or SOAP to your tool.

Server design

Caution: These figures are provided as a guide only because the resources required will vary depending not just on the number of users, but the number of incidents/requests created daily, web service activity and the type of use (Front Office, Back Office). The figures provided are based on our SaaS experience.

Remember, your target architecture will comprise one or more of the servers described below.

Server configuration

Single-server architecture

This architecture supports all Self Help functions, namely:

• Edition functions;
• Procedure presentation functions;
• The virtual agent.
   

Description of configuration:

Multiple presentation server architecture

This Self Help architecture is used to:

• Dedicate a server to edition functions;
• Dedicate other servers to procedure presentation functions and the virtual agent.
   

Description of edition server configuration: