Previous: Extending Enterprise ArchitectNext: Index

Cloud Services

Sparx Systems

The Sparx Systems Cloud Services application provides a convenient mechanism for hosting models. It provides easy access to people within your team, and optionally to external customers and consultants anywhere around the world.

This page aims to do the following:

  1. Familiarize you with the concepts involved
  2. Discuss considerations for when and where you should use a cloud server
  3. Walk you through the process of setting up a server with one or more models
  4. Walk you through the process of connecting for the first time
  5. Highlight some of the additional functionality available by using the cloud server

Introducing Cloud Services for Enterprise Architect

Enterprise Architect models are stored in databases. Prior to the introduction of Cloud Services Enterprise Architect required users to install the appropriate drivers for the database and create a connection. Enterprise Architect would then use that connection to connect directly to the database and run the model. With the introduction of Cloud Services that model has changed in ways that provide a number of benefits.

  1. The process of setting up drivers and connections can now be performed once by an administrator during the server configuration. The only set-up required on a user machine is to install Enterprise Architect and connect to any model required on the cloud server.
  2. Database servers no longer need to be exposed through a firewall. The cloud server can be run from inside a corporate firewall. All model connections are now created using http allowing firewalls to completely isolate your database server.
  3. A cloud server can be configured to ensure all communication is encrypted. Using standard TLS/SSL protocols, you can be sure that your data is not intercepted during transmission on insecure networks.
  4. A cloud server can be configured to provide http level authorization to any model directly from the model user list. Even when the model is exposed on a public network you can be assured that only authorized users are able to access your model.

When to use a cloud server

A cloud server offers benefits whenever:

  • You would like to reduce the set-up requirements for each of your users
  • You would like to expose any models outside of a private network
  • Any users are connecting over slow connections

Setting up a server

One of the benefits of a cloud server is that the set-up needs to be performed once on the server instead of for all users who are connecting. The following describes the process for installing, configuring the ports and databases for the server.


The installer for Sparx Systems Cloud Services requires administration permission for installation. Run it as administrator, accept the license agreement and specify the target location. The installer provides options for installing the service itself, the management client and the IIS integration files.

IIS Integration

IIS configuration is not set-up by default, only the files are copied to the install location.


In the service install directory you will find a file SSCloudServices.config. Edit this file to set the ports the server will listen on and other configuration options. Any changes to this file will require restarting the server for changes to take effect. This is done using the Windows Services list.

TCP connection

The first settings in the file are for the port used for admin tasks. The default values are:

SERVER_PORT is used when you connect the administration client or opt to use the IIS integration instead of the integrated webserver. We recommend that this port is not exposed to any external networks as encryption cannot be applied to this port.

SERVER_PASSWORD is the password to protect the administration functions of the server. This can also be changed directly within the admin client.

General Settings

The next list of settings are global settings across the entire service.

DBMAN_DEFAULTMAXSIMQUERIES is the default value used for maximum number of queries that can be run at a time for any configured database. It can be changed directly within the admin client.

AUDIT_TIME_PERIOD is the number of seconds between the system logs recording activity on each database.

TEMP_DIRECTORY is the location used to write temporary files before they are sent to clients. You should not generally need to change this.

LOGGING_LEVEL determines how verbose the server should be when writing log files. The valid values are: OFF, FATAL, WARNING, INFO and SYSTEM. This value can be changed directly within the admin client.

LOGGING_DIRECTORY, LOGGING_FILECOUNT, LOGGING_FILESIZE collectively determine where log files are written, and how much history will be kept.

HTTP Ports

The cloud server allows you to define an arbitrary number of different ports to listen to http connections, each with a different configuration. Each one is denoted in the config file with an open and close parenthesis on their own line.

SERVER_PORT is the port that the server will listen for http connections on, each one needs to be unique and not be used by any other services on the machine.

REQUIRE_SSL should be set to 1 to enable https on this port. This should be enabled for all connections that are being exposed on public networks but requires a private key (server.pem) to be included in the same directory before it will run.

DEFAULT_MODEL allows a single model to be exposed on a port, making it possible to use a different port for each model.

MODEL_AUTHENTICATION can be set to 1 to request http authorization using the security users in the model being connected to. Note that if you are not using SSL to connect, the usernames and passwords will be sent in plain text. This option is mutually exclusive with GLOBAL_AUTHENTICATION.

GLOBAL_AUTHENTICATION can be set to the name of a model with security enabled that will provide the list of users for all models provided by the connection. This is helpful if you want to provide multiple models but only manage one list of users. This option is mutually exclusive with MODEL_AUTHENTICATION.

OSLC_SUPPORT option is enabled by default. It allows models to be queried using the Open Services for Lifecycle Collaboration standard. This is discussed further below. Set to 0 to disable.

Configuring models

Once your service is configured, you can connect to the admin client to configure any databases you want to provide using the cloud server.

Open the admin client and you will be presented with an empty list of Database managers. Click 'Add' to configure a new one. This will prompt you with a dialog allowing a connection string that the server should use when connecting to a model. If you are running the admin client on the same machine as the server you will be able to click the ellipsis (...) button to open the Data Link Properties dialog to build a connection string.

Please see the Enterprise Architect help for more information on the supported types, creating a project and options required for connections.

This dialog can also create a new Firebird database with all tables set up. This is the easiest way to get a connection running, and you do that by entering your desired model name followed by '.fdb'.

Once you have added one or more database managers, they will appear in the list in the main dialog. Select any of these and click configure to allow connections to this model. This shows a number of options for the selected model.

Accept Queries must be set to allow users to connect to this database.

Max Simultaneous Queries allows you to control the maximum number of simultaneous connections that will be created to this model. When the database was created this number came from the system setting for this. To tweak constraints of system performance against resource usage you can look at the audit history for each database to see how many connections have been used in the specified time period.

Run Scheduled Tasks allows the server to run periodic updates to this model. This is discussed further below.

Read-only connection allows a model to be shared without allowing any changes to be made.

Require a secure and authenticated connection flags that security is required for this model. No connections will be accepted unless via https with either model authentication or global authentication set.

Security considerations

As with any web connected service, there are a number of security concerns that need to be considered when setting up a new service.

If any data is considered private, always use a https connection and require user authentication. There is an option on the database itself to require this.

There is an implicit trust in sharing a model with anyone. Security is available to prevent users doing things that they shouldn't, but because Enterprise Architect allows user written sql to be used in queries in a number of places any information can be at least retrieved. Of note, this includes users and hashes of their passwords, although this can be prevented by using global authentication instead of model authentication.

Connecting to a server

Enterprise Architect provides a link on the start page to connect to a cloud model. On this dialog you can enter the details of the requested model.

Name is the text that the model is identified as on your machine. It can be any value and does not need to match any values on the server.

URL provides the protocol, path and port for the server. If you were connecting to a server running on your own machine it would be as follows:

First there will be http:// or https:// depending on if encryption is being applied to the connection.

Next will be the name or ip address of the server.

Finally you can specify the port. This is optional if using the default http port (80) or default https port (443) as Enterprise Architect will use the defaults.

Fields are provided for username and password, but these are not required as Enterprise Architect will prompt if the server requires authentication.

Additional Functionality

In addition to the core functionality of providing a model over a http connection, cloud services offer three additional things that add value to setting up a server.

Open Services for Lifecycle Collaboration (OSLC)

Open Services for Lifecycle Collaboration (OSLC) is an initiative to allow easier integration between requirement tools. It uses HTTP to list, add, modify and delete requirements.

The service provider definition to direct any OSLC client to will be:

For example, if you are connecting to a server running on your own machine using the default settings the connection will be:
See for more information.

Re-usable Asset Service

The re-usable asset service (RAS) portion of the cloud server allows packages to be defined that can be used in any model. Enterprise Architect and the cloud server will track cross-package dependencies and ensure everything required by a package is available when a package is requested.

Scheduled Tasks

The cloud server includes optional support for running time based updates to data.

At this stage this is limited to updating a Time Series chart automatically to provide a dynamic view into how a model is changing over time. Please see the Enterprise Architect help file for more information.