User Guide

The functionality of the Visibility Levels feature is primarily restricted to System Administrator users in Enterprise Architect, in order to set up and configure models to limit access to certain Packages in a model. Generally, users will not be aware of Visibility Levels; they simply will not see certain Packages in the model.

Defining Visibility Level Aware Database Managers

For the most part, the process of defining Database Managers in the Sparx Systems Pro Cloud Server Configuration Client is the same as the process for non Visibility Level Database Managers. However, to facilitate different user groups being able to access different sections of the repository, a separate Database Manager will be needed for each user group, with the database user defined within the Database Manager's connection string controlling what areas of the repository the Enterprise Architect user has access to.

Consider the scenario of an environment that consists of three user groups: Management, Sales and Technical. Each user group will have one or more Packages within the repository for their exclusive use; members from the other two groups will not be able to view the contents of these Packages. Each user group will require their own Database Manager defined on the Pro Cloud Server and therefore must be provided with the appropriate connection string to their Database Manager. This means that the Pro Cloud Server connection strings should be kept private and only shared with the appropriate group of users. Note: the use of encrypted connection strings should be considered.

Differences between a Traditional and a Visibility Level Aware Database Manager are outlined here:

DBMS	Discussion
All Oracle connections require a 'DefaultSchema={schema_name};' option manually added to the connection string, where {schema_name} is the physical name of the schema that owns the Enterprise Architect tables. For example: Provider=OraOLEDB.Oracle.1;Password=pass;Persist Security Info=True;User ID=user1;Data Source=ORA_SN;DefaultSchema=owner_user; In a typical Oracle connection to an Enterprise Architect repository the 'User ID' option is both the owner of the tables and the user credentials that are being used to access the data. However, in a repository using the Visibility Levels feature these options are different, so the 'DefaultSchema' option has been added to define the table owner.
All SQL Server connections require an 'Alias' field value that uniquely identifies the Database Manager on the current server. The 'Alias' value is the name by which Enterprise Architect users know the repository. In previous versions (pre version 2) of the Pro Cloud Server, the Database Manager 'Alias' for SQL Server-based connections was automatically determined by the database name, which meant that each SQL Server database could only ever have one Database Manager defined in the Pro Cloud Server. Now, with the use of the 'Alias' field, a single database can have an unlimited number of Database Managers defined.

DBMS

Discussion

All Oracle connections require a 'DefaultSchema={schema_name};' option manually added to the connection string, where {schema_name} is the physical name of the schema that owns the Enterprise Architect tables. For example:

Provider=OraOLEDB.Oracle.1;Password=pass;Persist Security Info=True;User ID=user1;Data Source=ORA_SN;DefaultSchema=owner_user;

In a typical Oracle connection to an Enterprise Architect repository the 'User ID' option is both the owner of the tables and the user credentials that are being used to access the data. However, in a repository using the Visibility Levels feature these options are different, so the 'DefaultSchema' option has been added to define the table owner.

All SQL Server connections require an 'Alias' field value that uniquely identifies the Database Manager on the current server. The 'Alias' value is the name by which Enterprise Architect users know the repository.

In previous versions (pre version 2) of the Pro Cloud Server, the Database Manager 'Alias' for SQL Server-based connections was automatically determined by the database name, which meant that each SQL Server database could only ever have one Database Manager defined in the Pro Cloud Server. Now, with the use of the 'Alias' field, a single database can have an unlimited number of Database Managers defined.

Enabling the Extended OLSC Interface on a Database Manager

In order for the Pro Cloud Server to allow the use of Visibility Levels in a model the 'Enable Pro Features (OSLC, WebEA and Integration)' option must be selected. This is achieved by opening the Sparx Systems Pro Cloud Server Configuration Client application (SSProCloudClient.exe) connecting to the appropriate server. You then select the Database Manager in the list and click on the Configure button. On the resulting Configure Database Manager screen select the 'Enable Pro Features (OSLC, WebEA and Integration)' checkbox.

Visibility Level Administration

When the Ultimate Edition of Enterprise Architect is used to connect to a model that has Visibility Levels configured, there is an additional menu item, 'Set Visibility Level...' available under the 'Package Control' context menu of each Package object in the Browser window.

If your model has security enabled, then all application users that require access to the 'Set Visibility Level...' menu item will need to be allocated the 'Visibility Level Admin' or 'Administer Database' security permission, using standard Enterprise Architect permission assignment.

Set a Package's Visibility Level

From within the Ultimate Edition of Enterprise Architect, the Visibility Level of a Package can be set using the Browser window context menu item 'Package Control | Set Visibility Level...'.

This menu item will only be available:

in models that have been set up for Visibility Levels,
are being accessed via a Pro Cloud server connection and
where the user has an Enterprise Architect Ultimate License.

Once a Visibility Level has been set on a Package, that Package and all of its children can be viewed, accessed and updated only by users with the corresponding access level.

To remove a visibility level from a Package (and all its children), simply set the Visibility Level back to unrestricted.

Visibility Levels users can apply

Users can only set the Visibility Levels on Packages to levels the current database user has access to. For example, an Enterprise Architect client connected to a Cloud connection that uses a database user that has been assigned levels 3 & 4 can update the Visibility Level of any Package to the levels unrestricted, 3 or 4.