...
The EchoSystemServer software comes bundled with a java-based web server called Jetty. Jetty is responsible for serving up all web UI elements and product downloads, processing API calls, and providing EchoPlayer elements for Rich Media presentation playback. Jetty is enabled by default , and is capable of efficiently handling requests on small or low-load deployments. However, if you have a large number of users accessing the system simultaneously, we highly recommend offloading all playback requests to an external web server. Jetty will still be running on the application host for API requests and the web UI, but configuring the playback components to be offered by an external server can greatly reduce the overall load on the system and result in improved performance.
...
The Active Content Directory is defined as the location of all available Echo content that can be viewed by users. This setting is specified in the EchoSystem Server under System > System Settings > Active Echo Settings > Content Folder. The content can located be located on a drive local to the ESS, on a mounted SMB/CIFS file share, or on mounted NAS/SAN storage. Regardless of where this directory is physically located, this folder must be accessible by both your external web server and the ESS host.
Additionally, in order for the external web server to find and serve up Echo content delivered by the ESS, your active content directory network share must be one that the the external web server has read and write access to.
Consult your operating system’s documentation for configuring file shares, or contact Echo360 Technical Support for guidance.
| Note | ||
|---|---|---|
| ||
It is important that you never use mapped drives when configuring storage locations. If configured incorrectly, these are not persistent across restarts, and the local system account may not have access to the mapped drives in the first place. If you are using a SAN with system mounted volumes, the use of such a drive letter is acceptable; otherwise, you are likely to run into errors if you use this feature of Windows. When in doubt, always use a UNC path for networked storage. |
...
When setting up an external web server, you can configure either HTTP or HTTPS access. The port used is your choice , though we recommend sticking to standard ports (80, 443, 8080, 8443 etc.). The EchoSystem Server is typically configured to offer up content over HTTP on port 8080 or HTTPS on port 8443. The application itself always runs over HTTPS. Reference the documentation for your external web server for configuring ports and protocols.
While not recommended, it is possible to configuring configure an external web server to run on the same physical host as the ESS. If this is done, it's important to note that the external web server cannot run on the same protocol and port as the application. In other words, if the ESS application is configured to run on HTTP/8443, then the external web server cannot use port 8443. A different port, such as 443, must be used in this case.
| Tip | ||
|---|---|---|
| ||
For security reasons, recent versions of major web browsers block "mixed mode" content - in other words, HTTP content served in an HTTPS wrapper. This will cause certain features of the EchoSystem, such as editing, to be inaccessible or break entirely. Therefore, we highly recommend serving content over HTTPS. Not only does it prevent these problems from occurring, but it's a far more secure way of serving content. The ESS also has a built-in mechanism to re-direct users who access content over HTTP to HTTPS if the switch is made. To enable this on the ESS side , set the Protocol option in the Application Network Settings area of the System tab in the ESS to "All HTTPS". Note: Mixed mode content is no longer supported as of ESS 5.4 SP3. |
...