Mode d'emploi

La fonctionnalité de la fonctionnalité Niveaux de visibilité est principalement limitée aux utilisateurs de l'administrateur système dans Enterprise Architect , afin d'installer et de configurer des modèles pour limiter l'accès à certains Paquetages dans un modèle. Généralement, les utilisateurs ne seront pas conscients des niveaux de visibilité ; ils ne verront tout simplement pas certains Paquetages dans le modèle.

Définition des gestionnaires de bases de données sensibles au niveau de visibilité

Pour l'essentiel, le processus de définition des gestionnaires de bases de données dans le client de configuration du serveur cloud de Sparx Systems Pro Cloud Server est le même que le processus pour les gestionnaires de bases de données sans niveau de visibilité. Cependant, pour permettre à différents groupes d'utilisateurs d'accéder à différentes sections du référentiel, un gestionnaire de base de données distinct sera nécessaire pour chaque groupe d'utilisateurs, l'utilisateur de la base de données étant défini dans la string de connexion du gestionnaire de base de données contrôlant quelles zones du référentiel l'utilisateur Enterprise Architect a accès à.

Considérez le scénario d'un environnement composé de trois groupes d'utilisateurs : Gestion, Ventes et Technique. Chaque groupe d'utilisateurs aura un ou plusieurs Paquetages dans le référentiel pour son usage exclusif ; les membres des deux autres groupes ne pourront pas voir le contenu de ces Paquetages . Chaque groupe d'utilisateurs aura besoin de son propre gestionnaire de base de données défini sur le Pro Cloud Server et doit donc recevoir la string de connexion appropriée à son gestionnaire de base de données. Cela signifie que les chaînes de connexion Pro Cloud Server doivent rester privées et partagées uniquement avec le groupe d'utilisateurs approprié. Note : l'utilisation de chaînes de connexion cryptées doit être envisagée.

Les différences entre un gestionnaire de base de données traditionnel et un gestionnaire de base de données sensible au niveau de visibilité sont décrites ici :

SGBD	Discussion
Toutes les connexions Oracle nécessitent un 'DefaultSchema={schema_name};' option ajoutée manuellement à la string de connexion, où {schema_name} est le nom physique du schéma qui possède les tableaux Enterprise Architect . Par exemple: Fournisseur=OraOLEDB.Oracle.1;Password=pass;Persist Security Info=True;User ID=user1;Data Source=ORA_SN;DefaultSchema=owner_user; Dans une connexion Oracle typique à un référentiel Enterprise Architect , l'option 'User ID ' est à la fois le propriétaire des tableaux et les informations d'identification de l'utilisateur qui sont utilisées pour accéder aux données. Cependant, dans un référentiel utilisant la fonctionnalité Niveaux de visibilité, ces options sont différentes, donc l'option 'DefaultSchema' a été ajoutée pour définir le propriétaire du tableau .
Toutes les connexions SQL Server nécessitent une valeur de champ 'Alias' qui identifie de manière unique le gestionnaire de base de données sur le serveur actuel. La valeur ' valeur ' est le nom par lequel les utilisateurs d' Enterprise Architect connaissent le référentiel. Dans les versions précédentes (avant la version 2) de Pro Cloud Server , l'alias du gestionnaire de base de données pour les connexions basées sur SQL Server était automatiquement déterminé par le nom de la base de données, ce qui signifiait que chaque base de données SQL Server ne pouvait avoir qu'un seul gestionnaire de base de données défini dans le Pro Cloud Server . Maintenant, avec l'utilisation du champ 'Alias', une seule base de données peut avoir un nombre illimité de gestionnaires de bases de données définis.

SGBD

Discussion

Toutes les connexions Oracle nécessitent un 'DefaultSchema={schema_name};' option ajoutée manuellement à la string de connexion, où {schema_name} est le nom physique du schéma qui possède les tableaux Enterprise Architect . Par exemple:

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

Dans une connexion Oracle typique à un référentiel Enterprise Architect , l'option 'User ID ' est à la fois le propriétaire des tableaux et les informations d'identification de l'utilisateur qui sont utilisées pour accéder aux données. Cependant, dans un référentiel utilisant la fonctionnalité Niveaux de visibilité, ces options sont différentes, donc l'option 'DefaultSchema' a été ajoutée pour définir le propriétaire du tableau .

Toutes les connexions SQL Server nécessitent une valeur de champ 'Alias' qui identifie de manière unique le gestionnaire de base de données sur le serveur actuel. La valeur ' valeur ' est le nom par lequel les utilisateurs d' Enterprise Architect connaissent le référentiel.

Dans les versions précédentes (avant la version 2) de Pro Cloud Server , l'alias du gestionnaire de base de données pour les connexions basées sur SQL Server était automatiquement déterminé par le nom de la base de données, ce qui signifiait que chaque base de données SQL Server ne pouvait avoir qu'un seul gestionnaire de base de données défini dans le Pro Cloud Server . Maintenant, avec l'utilisation du champ 'Alias', une seule base de données peut avoir un nombre illimité de gestionnaires de bases de données définis.

Activation de l'interface OLSC étendue sur un gestionnaire de base de données

Pour que le Pro Cloud Server autorise l'utilisation des niveaux de visibilité dans un modèle, l'option "Activer les fonctionnalités Pro ( Fonctionnalités , WebEA et intégration)" doit être sélectionnée. Ceci est réalisé en ouvrant l'application Sparx Systems Pro Cloud Server Configuration Client (SSProCloudClient.exe) en se connectant au serveur approprié. Vous sélectionnez ensuite le gestionnaire de base de données dans la liste et cliquez sur le bouton Configurer. Sur l'écran Configurer le gestionnaire de base de données résultant, cochez la case "Activer les fonctionnalités Pro ( Fonctionnalités , WebEA et intégration)".

Administration du niveau de visibilité

Lorsque l'édition Ultimate d' Enterprise Architect est utilisée pour se connecter à un modèle dont les niveaux de visibilité sont configurés, il existe un élément de menu supplémentaire, "Définir le niveau de visibilité..." disponible dans le menu contextuel "Contrôle du Paquetage " de chaque object Paquetage dans le Fenêtre du Navigateur .

Si votre modèle a la sécurité activée, alors tous les utilisateurs de l'application qui ont besoin d'accéder à l'élément de menu 'Définir le niveau de visibilité...' devront se voir alloué l'autorisation de sécurité 'Administrateur du niveau de visibilité' ou 'Administrer la base de données', en utilisant l'autorisation standard d' Enterprise Architect mission.

Définir le niveau de visibilité d'un Paquetage

Depuis l' Ultimate Edition d' Enterprise Architect , le niveau de visibilité d'un Paquetage peut être défini à l'aide de l'élément de menu contextuel de la fenêtre Navigateur ' Paquetage Control | Définir le niveau de visibilité...'.

Cet élément de menu ne sera disponible que :

dans les modèles qui ont été configurés pour les niveaux de visibilité,
sont accessibles via une connexion au serveur Pro Cloud et
où l'utilisateur a une licence Enterprise Architect Ultimate .

Une fois qu'un niveau de visibilité a été défini sur un Paquetage , ce Paquetage et tous ses enfants peuvent être visualisés, consultés et mis à jour uniquement par les utilisateurs disposant du niveau d'accès correspondant.

Pour supprimer un niveau de visibilité d'un Paquetage (et de tous ses enfants), redéfinissez simplement le niveau de visibilité sur sans restriction.

Niveaux de visibilité que les utilisateurs peuvent appliquer

Les utilisateurs ne peuvent définir les niveaux de visibilité sur les Paquetages niveaux auxquels l'utilisateur actuel de la base de données a accès. Par exemple, un client Enterprise Architect connecté à une connexion Cloud qui utilise un utilisateur de base de données auquel ont été assignés les niveaux 3 et 4 peut mettre à jour le niveau de visibilité de n'importe quel Paquetage aux niveaux sans restriction, 3 ou 4.