If a script causes changes in the database, any updates are reported to the server via SOAP using HTTP and Port 80 (by default - the Port address can be changed via the Server Configuration Tool (see Server Port in the ClearSCADA Guide to Server Administration). For this reason, the ports and any firewalls need to be configured so that the client and server are able to communicate via the relevant port.
When a Mimic that contains a script is first displayed on a ViewX client, the client requests the server to provide information about which port to use. The Mimic then uses the port number specified by the server, so any subsequent changes to the port number will cause the script to stop working (as the Mimic cannot be updated via the new port number). A similar situation can occur with Alarm Banner scripts, except that they only request port information from the server when a user selects an Alarm Banner option that calls the Server or Object property of an alarm.
On WebX clients, Mimics use the same port that is used for the WebX connection. If a proxy server or proxy firewall is used between the WebX server and WebX clients, the WebX clients might be set up to communicate with ClearSCADA via the proxy - if so, the Mimics will use the mapped proxy port. In either case, if the port (defined in the server configuration) is already in use by another application such as IIS when ClearSCADA is run, WebX will be unable to connect to the server. If WebX is able to connect to the server and a Mimic is displayed, the scripting will work as expected. However, if the port number is changed at the server while the Mimic is displayed in WebX, the scripting and navigation features of that Mimic will no longer work correctly (as WebX will have lost its connection to the server).
NOTE: Firewalls may block requests and stop scripts from functioning correctly. We recommend that you set up an exception for your firewall so that it allows your scripts to make requests and run as intended.