Prev Next

Cloud Server Configuration

This topic discusses the configuration of the Cloud Server itself, whether as the original Sparx Systems Cloud Services or as a component of the Pro Cloud Server. If you are installing the Pro Cloud Server, there are several other configuration files associated with the Keystore, WebEA and Row Level Security components of the server. The procedures for editing those files are described in the separate topics for those features.

Many configuration settings for the Cloud Server are set by directly editing the configuration file SSCloudServices.config, which is found in your Service directory. To edit the configuration file, open it in a text editor (using the 'Run as administrator' option).

Once you have opened the file, you can edit it to set configuration options, including the ports the server will listen on.

There are two different types of configuration option defined in the Cloud Service configuration file. The first type are global and apply to the entire Cloud Service, while the second type (which are enclosed in parentheses) apply to an individual port that the Cloud Service will listen on. Typically there are multiple port definitions, each enclosed in their own set of parentheses.

Note:  It is important to realize that the Cloud Service only reads the configuration file once, when it starts up.  If you manually change the options in the configuration file then the Cloud Service must be restarted.

Configuration Client Connection Settings

Normally the first settings you will see in the configuration file are to control how the Configuration Client will connect to the server. The default values are:



Use of the Configuration Client is discussed in the Cloud Services Configuration Client topic.




SERVER_PASSWORD is the password to protect the administration functions of the server.

Note: This can be changed within the Configuration Client, which means a full server restart will not be necessary.


SERVER_PORT is used when you connect to the Configuration Client or opt to use the IIS integration instead of the integrated web-server. For more detail see the Cloud Server Using IIS topic.

Note: When changing this, check firewall settings and other services using the port. Additionally, when the service is running on Wine you should not use privileged ports - those below 1024. Under Wine, most applications are only able to listen on ports above 1024.

General Settings

The next list of settings includes the default global settings across the entire service:












The default for the maximum number of simultaneous queries that can be run at a time for any configured database. This can be changed directly within the Management Client (see Default Max Simultaneous Queries under Global Server Options in the Cloud Services Configuration Client topic). There is no explicit limit for this default value.

Note: As this can be set directly within the Configuration Client, a full server restart will not be required if you change it.


The number of seconds between the recording activities by system logs on each database.


The location to write temporary files before they are sent to clients. You should not generally have to change this.


Determines how verbose the server should be when writing log files. The valid values are: OFF, FATAL, WARNING, INFO and SYSTEM. The value can be changed directly within the Management Client. (See Log Level under Global Server Options in the Cloud Services Configuration Client topic).

Note: As this can be set directly within the Configuration Client, a full server restart will not be required if you change it.


Defines where the log files are to be stored. The default is set to:


Note: The =%SERVICE_PATH% refers to the directory where the Cloud service is installed.


Determines the maximum number of rolling log files that should be kept. When the file count is exceeded, the oldest file is automatically deleted.


Determines the maximum file size of each log file. When the logging file size is reached a new log file is created.

For more details on using the logs see the Cloud Server Troubleshooting topic.


(For a Pro Cloud Installation); this option defines the licensing information of your Pro Cloud Server and will be supplied to you after your purchase has been processed correctly.

Port Settings

Using the Cloud Server you can define an arbitrary number of different ports on which to listen for connections from Enterprise Architect, each with a different configuration. Each port is denoted in the configuration file, with open and close parentheses, on their own lines.












The port on which the server will listen for HTTP connections; each connection must be unique and not used by any other services on the machine. You must check that no firewalls are blocking this port on the client or server. You can use the standard HTTP port (80) or HTTPS port (443).

Note: When changing this, check firewall settings and other services using that port. Additionally, when the service is running on Wine you should not use privileged ports - those below 1024. Under Wine, most applications are only able to listen on ports above 1024.


Should be set to 1 to enable HTTPS on this port; HTTPS should be enabled for all connections that are being exposed on public networks. HTTPS requires a private key file (server.pem), to be included in the same directory as the configuration file, before it will run.

Note: This unique file must be user-created. See Creating a Self-Signed Certificate using OpenSSL.


Allows a single model to be exposed on a port, making it possible to use a different port for each model. Model names are discussed further in the Connecting Enterprise Architect to a Cloud Server topic.


Can be set to 1 to request HTTP authorization using the user security defined in the Enterprise Architect model being connected to. Passwords must be explicitly and individually assigned in that model using the Maintain Users procedure; the default administrator password and any passwords imported from Windows Active Directory do not work. Note that if you are not using SSL to connect, the usernames and passwords will be sent in plain text.

If the model does not have security enabled, the Cloud user is not prompted for a password.

This option is mutually exclusive with GLOBAL_AUTHENTICATION.


Can be set to the name of an Enterprise Architect model with security enabled that will provide the list of users for all models accessed by the connection. This is helpful if you want to provide multiple models but only manage one list of users. Passwords must be explicitly and individually assigned in the reference model using the Maintain Users procedure; the default administrator password and any passwords imported from Windows Active Directory do not work.

This option is mutually exclusive with MODEL_AUTHENTICATION.


Enabled by default. It allows models to be queried using the 'Open Services for Lifecycle Collaboration' standard. This is discussed further in the OSLC Requirements Management topic.

Set to 0 to disable.

Restarting the Sparx Cloud Server

If you make any changes to the configuration file you must restart the server for the changes to take effect (unless otherwise stated). A server restart is carried out in the Windows Services application.

Depending on the server operating system, there are two methods for restarting the Cloud Server:

1)  Using Window Services. This is available in all versions of Windows (see 'Control Panel | Administrative Tools | Services').

2)  Using the Server Manager on Windows Server 2012.

Firewall Settings

When setting up a server, you must check that the Firewall on the server is set to allow the incoming ports for the database connections that you have created.

For example, in the SSCloudServices.config file the ports default to 804 and 805 and are set as operative. If you have a firewall you must set these ports as enabled for inbound traffic.

For information on creating the Inbound Rule to identify the ports you have specified in the config file (the 'Sparx Systems Cloud Services' rule in the illustration), see the Windows online topic Create an Inbound Port Rule.

Note: A common cause of failure is that other services are already using the allocated ports. This is especially likely when using the default http (80) and https (443) ports. Check that no other services are using the allocated ports.

Using Multiple Configurations

The Sparx Systems Cloud Service can be run multiple times with different configurations by passing these additional arguments.



--config / -c

The argument following this will be interpreted as the path to the configuration file to read on startup. This allows a secondary instance of the cloud server to run on a different set of ports, use an altered logging level or different directories.

When multiple configurations are being used, you need to ensure that each instance reads a configuration file that specifies different paths. Otherwise only the first instance will start successfully.

By default this references SSCloudServices.config in the directory containing the service executable.

--path / -p

The argument following this will be interpreted as the absolute path to search for other resources. Changing this parameter changes where the configuration file is read from, along with all paths in the configuration file that specify %SERVICE_PATH%. Setting this to a directory other than the default is an easy way to separate multiple running instances of the cloud service.

--registry / -r

The argument following this will be interpreted as a registry path within HKEY_LOCAL_MACHINE where the models the cloud server provides are specified. Changing this parameter allows using different cloud servers to provide access to different models.

By default this is Software\Sparx Systems\SQLBridge.


This argument allows starting the SSCloudServices.exe as a standalone executable instead of requiring it to be launched as a Windows service.

This can be important if Windows firewall is blocking the service, as it will prompt to create a firewall exception.

Additionally, Wine by default closes services automatically when the last user process closes, but using the 'standalone' argument to run the server as an application will ensure that the service isn't terminated when no more user applications are running. Use the command line:

     wine SSCloudServices.exe standalone

Or, if you are launching from a terminal and want to close it:

     wine SSCloudServices.exe standalone & disown     or

     nohup wine SSCloudServices.exe standalone

(The 'disown' parameter and 'nohup' command both close the terminal but ignore the 'hangup' message that would otherwise disconnect Cloud Services again.)

Self-Signed Certificate using OpenSSL

In order to use a secure connection (HTTPS) to your model, a server certificate is required. For a production environment, particularly one providing access to external users, you should obtain a certificate from an appropriate certificate authority. However, to help with initial setup and testing purposes you can generate your own certificate, using these instructions.

The Cloud Services installer provides a simple batch file (openssl.exe) that assumes that OpenSSL is available on the windows path and is appropriately configured. You can create a second batch file into which you paste this code, and run it with the target hostname as a parameter. It will generate an appropriate server.pem key file, which can then be placed in the service install directory with the SSCloudServices.config file (..\Sparx Systems\Cloud Services\Service).

     echo off

     if not "%1" == "" goto generate

     echo ERROR: No target specified

     echo USAGE: %0 url

     echo EXAMPLE %0 localhost

     goto end


     echo on

     openssl genrsa -out %1.key 2048

     openssl req -new -x509 -key %1.key -out %1.cert -days 3650 -subj /CN=%1

     copy /b %1.cert+%1.key server.pem



If you need to assign passwords to user IDs for a model or models that will be accessed via the Cloud, then:

  1. Open the reference model using a direct connection or via a Cloud connection on a port that does not have either MODEL_AUTHENTICATION or GLOBAL_AUTHENTICATION set.
  2. Enable security and assign a new administrator password.
  3. Open the Cloud Server Management Client for the new database and set the checkbox 'Require a secure and authenticated connection'. (Now that you have a valid account, this model will no longer be accessible without https and http level authentication.)
  4. Connect to the model on a port that does have an _AUTHENTICATION setting and use the Maintain Users procedure to assign passwords to the user IDs in the model.

Learn more