Assemblys [Analysis Services]

Microsoft SQL Server 2005 Analysis Services (SSAS) offre de nombreuses fonctions intrinsèques à utiliser avec les langages MDX (Multidimensional Expressions) et DMX (Data Mining Extensions), conçues pour effectuer toutes les opérations possibles, des calculs statistiques standard au parcours des membres d'une hiérarchie. Cependant, comme dans tout autre produit complexe et robuste, il est toujours nécessaire d'étendre la fonctionnalité de ce type d'outil.

Par conséquent, Analysis Services vous permet d'ajouter des assemblys à une base de données ou à une instance d'Analysis Services. Les assemblys vous permettent de créer des fonctions externes définies par l'utilisateur à l'aide de tout langage CLR (Common Language Runtime), tel que Microsoft Visual Basic .NET ou Microsoft Visual C#. Vous pouvez aussi utiliser des langages d'automatisation COM (Component Object Model) tels que Microsoft Visual Basic ou Microsoft Visual C++.

Les assemblys vous permettent d'étendre les fonctions d'entreprise de MDX et de DMX. Vous créez la fonctionnalité que vous souhaitez dans une bibliothèque de liens dynamiques (DLL), et vous ajoutez la bibliothèque en tant qu'assembly à une instance d'Analysis Services ou à une base de données Analysis Services. Les méthodes publiques de la bibliothèque sont alors exposées en tant que fonctions définies par l'utilisateur aux expressions, procédures, calculs, actions et applications clientes MDX et DMX.

Appel de fonctions définies par l'utilisateur

L'appel d'une fonction définie par l'utilisateur dans un assembly est semblable à l'appel d'une fonction intrinsèque, excepté que vous devez utiliser un nom complet. Par exemple, une fonction définie par l'utilisateur qui renvoie un type attendu par MDX est insérée comme ceci dans une requête MDX :

Select MyAssembly.MyClass.MyStoredProcedure(a, b, c) on 0 from Sales

Les fonctions définies par l'utilisateur peuvent aussi être appelées à l'aide du mot clé CALL. Vous devez utiliser le mot clé CALL pour les fonctions définies par l'utilisateur qui renvoient des jeux d'enregistrements ou des valeurs de type void, et vous ne pouvez pas utiliser le mot clé CALL si la fonction définie par l'utilisateur dépend d'un objet dans le contexte de l'instruction ou du script MDX ou DMX, tel que le cube en cours ou le modèle d'exploration de données. Une utilisation courante d'une fonction appelée en dehors d'une requête MDX ou DMX est l'utilisation du modèle d'objets AMO pour effectuer des fonctions d'administration. Si vous souhaitez par exemple utiliser la fonction MyVoidProcedure(a, b, c) dans une instruction MDX, utilisez la syntaxe suivante :

Call MyAssembly.MyClass.MyVoidProcedure(a, b, c)

Les assemblys simplifient le développement de bases de données en permettant à du code commun d'être développé une seule fois et d'être stocké à un seul emplacement. Les développeurs de logiciels clients peuvent créer des bibliothèques de fonctions pour Analysis Services et les distribuer avec leurs applications.

Les assemblys et les fonctions définies par l'utilisateur peuvent dupliquer les noms des fonctions de la bibliothèque de fonctions de Analysis Services ou d'autres assemblys. Dès lors que vous appelez la fonction définie par l'utilisateur avec son nom complet, Analysis Services utilise la procédure correcte. Pour des raisons de sécurité et pour éliminer la possibilité d'appeler un nom dupliqué dans une autre bibliothèque de classes, Analysis Services requiert l'utilisation des seuls noms complets pour les procédures stockées.

Pour appeler une fonction définie par l'utilisateur depuis un assembly CLR spécifique, la fonction définie par l'utilisateur est précédée du nom de l'assembly, du nom complet de la classe et du nom de la procédure, comme dans l'exemple suivant :

AssemblyName.FullClassName.ProcedureName(Argument1, Argument2, ...)

Pour assurer la compatibilité amont avec les versions antérieures de Analysis Services, la syntaxe suivante est également acceptable :

AssemblyName!FullClassName!ProcedureName(Argument1, Argument2, ...)

Si une bibliothèque COM prend en charge plusieurs interfaces, l'identificateur d'interface peut également être utilisé pour résoudre le nom de la procédure, comme dans cet exemple :

AssemblyName!InterfaceID!ProcedureName(Argument1, Argument2, ...)

Sécurité

La sécurité des assemblys est basée sur le modèle de sécurité de .NET Framework, qui est un modèle de sécurité d'accès du code. .NET Framework prend en charge un mécanisme de sécurité d'accès du code qui suppose que le module d'exécution peut héberger à la fois du code d'un niveau de confiance total et d'un niveau de confiance partiel. Les ressources qui sont protégées par la sécurité d'accès du code de .NET Framework sont généralement intégrées à du code managé qui demande l'autorisation correspondante avant d'autoriser l'accès à la ressource. La demande d'autorisation est satisfaite seulement si tous les appelants (au niveau de l'assembly) de la pile d'appels ont l'autorisation pour la ressource correspondante.

Pour les assemblys, l'autorisation d'exécution est passée avec la propriété PermissionSet sur l'objet Assembly. Les autorisations reçues par le code managé sont déterminées par la stratégie de sécurité effective. Il y a déjà trois niveaux de stratégie effectifs dans un environnement hébergé non-Analysis Services : entreprise, machine et utilisateur. La liste effective des autorisations reçues par le code est déterminée par l'intersection des autorisations obtenues par ces trois niveaux.

Analysis Services fournit un niveau de stratégie de sécurité au niveau de l'hôte au CLR (Common Language Runtime) quand il l'héberge ; cette stratégie est un niveau de stratégie supplémentaire sous les trois niveaux de stratégie qui sont toujours effectifs. Cette stratégie est définie pour chaque domaine d'application qui est créé par Analysis Services.

La stratégie de niveau hôte de Analysis Services est une combinaison de la stratégie fixe de Analysis Services pour les assemblys système et de la stratégie spécifiée par l'utilisateur pour les assemblys utilisateur. La partie spécifiée par l'utilisateur de la stratégie d'hôte d'Analysis Services est basée sur le propriétaire de l'assembly spécifiant un des trois compartiments d'autorisation pour chaque assembly :

Quand le CLR est hébergé par Analysis Services, la vérification des autorisations basée sur le parcours de pile s'arrête à la limite avec le code Analysis Services natif. Tout code managé dans des assemblys Analysis Services tombe toujours dans une des trois catégories d'autorisations dont la liste est donnée ci-dessus.

Les routines d'assembly COM (ou non managée) ne prennent pas en charge le modèle de sécurité CLR.

Emprunt d'identité

Quand du code managé accède à une ressource en dehors d'Analysis Services, Analysis Services suit les règles associées à un paramètre de la propriété ImpersonationMode de l'assembly de façon à garantir que l'accès se fait dans un contexte de sécurité Windows approprié. Étant donné que les assemblys qui utilisent le paramètre d'autorisation Safe ne peuvent pas accéder à des ressources en dehors d'Analysis Services, ces règles sont applicables seulement pour les assemblys utilisant les paramètres d'autorisation ExternalAccess et Unsafe.

• Si le contexte d'exécution en cours correspond à une connexion authentifiée Windows et qu'il est le même que le contexte de l'appelant d'origine (c'est-à-dire qu'il ne s'y trouve pas d'instruction EXECUTE AS), Analysis Services prend l'identité de la connexion authentifiée Windows avant d'accéder à la ressource.
• S'il y a une instruction EXECUTE AS intermédiaire qui a changé le contexte relativement à celui de l'appelant d'origine, la tentative d'accès à une ressource externe échoue.

La propriété ImpersonationMode doit être définie à ImpersonateCurrentUser ou à ImpersonateAnonymous. Le paramètre par défaut, ImpersonateCurrentUser, exécute un assembly sous le compte de connexion réseau de l'utilisateur en cours. Si le paramètre ImpersonateAnonymous est utilisé, le contexte d'exécution correspond au compte d'utilisateur de connexion Windows IUSER_servername sur le serveur. Il s'agit du compte Invité Internet, qui a des droits limités sur le serveur. Un assembly s'exécutant dans ce contexte peut seulement accéder à des ressources limitées sur le serveur local.

Domaines d'application

Analysis Services n'expose pas directement les domaines d'application. Grâce à un ensemble d'assemblys s'exécutant dans le même domaine d'application, les domaines d'application sont capables de se découvrir les uns les autres au moment de l'exécution à l'aide de l'espace de noms System.Reflection dans .NET Framework ou par d'autres moyens, et ils sont capables d'y faire des appels en mode de liaison tardive. De tels appels font l'objet des vérifications d'autorisations utilisées par la sécurité basée sur les autorisations de Analysis Services.

Il est recommandé de ne pas se baser sur la recherche d'assemblys dans le même domaine d'application, dans la mesure où la limite du domaine d'application et les assemblys qui vont dans chacun des domaines sont définis par la mise en œuvre.

Voir aussi

Concepts

Définition de la sécurité pour les procédures stockées (Analysis Services)
Utilisation des procédures stockées (Analysis Services)

Aide et Informations

Assistance sur SQL Server 2005