Gestion des assemblys de modèle multidimensionnel

Microsoft SQL Server Analysis Services fournit de nombreuses fonctions intrinsèques à utiliser avec les langages MDX (Multidimensional Expressions) et DMX (Data Mining Extensions), conçus pour réaliser des calculs statistiques standard ainsi que le parcours des membres au sein d’une hiérarchie. Toutefois, comme pour tout autre produit complexe et robuste, il est toujours nécessaire d’étendre davantage les fonctionnalités d’un tel produit.

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

Les assemblys vous permettent d’étendre les fonctionnalités métier de MDX et DMX. Vous générez les fonctionnalités souhaitées dans une bibliothèque, comme une bibliothèque de liens dynamiques (DLL) et 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 ensuite exposées en tant que fonctions définies par l’utilisateur aux expressions MDX et DMX, procédures, calculs, actions et applications clientes.

Un assembly avec de nouvelles procédures et fonctions peut être ajouté au serveur. Vous pouvez utiliser des assemblys pour améliorer ou ajouter des fonctionnalités personnalisées qui ne sont pas fournies par le serveur. En utilisant des assemblys, vous pouvez ajouter de nouvelles fonctions aux expressions multidimensionnelles (MDX), aux extensions d’exploration de données (DMX) ou aux procédures stockées. Les assemblys sont chargés à partir de l’emplacement où l’application personnalisée est exécutée, et une copie du fichier binaire d’assembly est enregistrée avec les données de base de données du serveur. Lorsqu’un assembly est supprimé, l’assembly copié est également supprimé du serveur.

Les assemblages peuvent être de deux types différents : COM et CLR. Les assemblys CLR sont des assemblys développés dans des langages de programmation .NET Framework tels que C#, Visual Basic .NET, managé C++. Les assemblys COM sont des bibliothèques COM qui doivent être inscrites sur le serveur

Les assemblages peuvent être ajoutés à des objets Server ou Database. Les assemblys de serveur peuvent être appelés par n’importe quel utilisateur connecté au serveur ou à n’importe quel objet du serveur. Les assemblées de base de données peuvent être appelées uniquement par les objets ou les utilisateurs connectés à la base de données.

Un objet simple Assembly est composé d’informations de base (Nom et ID), de collecte de fichiers et de spécifications de sécurité.

La collection de fichiers fait référence aux fichiers d’assembly chargés et à leurs fichiers de débogage (.pdb) correspondants, si les fichiers de débogage ont été chargés avec les fichiers d’assembly. Les fichiers d’assembly sont chargés à partir de l’emplacement dans lequel l’application a défini les fichiers, et une copie est enregistrée sur le serveur, ainsi que les données. La copie du fichier d'assemblage est utilisée pour charger l'assemblage chaque fois que le service démarre.

Les spécifications de sécurité incluent le jeu d’autorisations et l’emprunt d’identité utilisé pour exécuter l’assembly.

Appel de fonctions User-Defined

L’appel d’une fonction définie par l’utilisateur dans un assembly est effectué comme appeler une fonction intrinsèque, sauf que vous devez utiliser un nom complet. Par exemple, une fonction définie par l’utilisateur qui retourne un type attendu par MDX est incluse dans une requête MDX, comme illustré dans l’exemple suivant :

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

Les fonctions définies par l’utilisateur peuvent également ê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 retournent des jeux d’enregistrements ou des valeurs 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 MDX ou DMX ou du script, tel que le cube actuel ou le modèle d’exploration de données. Une utilisation courante pour une fonction appelée en dehors d’une requête MDX ou DMX consiste à utiliser le modèle objet AMO pour effectuer des fonctions administratives. Si, par exemple, vous souhaitez utiliser la fonction MyVoidProcedure(a, b, c) dans une instruction MDX, la syntaxe suivante est utilisée :

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

Les assemblys simplifient le développement de base de données en permettant au code commun d’être développé une fois et stockés dans un emplacement unique. Les développeurs de logiciels clients peuvent créer des bibliothèques de fonctions pour Analysis Services et les distribuer avec leurs applications.

Les assemblages et les fonctions définies par l’utilisateur peuvent dupliquer les noms de fonctions de la bibliothèque de fonctions d'Analysis Services ou d’autres assemblages. Tant que vous appelez la fonction définie par l’utilisateur à l’aide de son nom complet, Analysis Services utilisera la procédure correcte. À des fins de sécurité et pour éliminer le risque d’appeler un nom en double dans une autre bibliothèque de classes, Analysis Services exige que vous utilisiez uniquement des noms complets pour les procédures stockées.

Pour appeler une fonction définie par l’utilisateur à partir d’un assembly CLR spécifique, la fonction définie par l’utilisateur est précédée du nom de l’assembly, du nom de classe complet et du nom de procédure, comme illustré ici :

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

Pour la compatibilité descendante avec les versions antérieures d’Analysis Services, la syntaxe suivante est également acceptable :

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

Si une bibliothèque COM prend en charge plusieurs interfaces, l’ID d’interface peut également être utilisé pour résoudre le nom de la procédure, comme illustré ici :

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

Sécurité

La sécurité des assemblys est basée sur le modèle de sécurité .NET Framework, qui est un modèle de sécurité d’accès au code. .NET Framework prend en charge un mécanisme de sécurité d’accès au code qui suppose que le runtime peut héberger du code entièrement approuvé et partiellement approuvé. Les ressources protégées par la sécurité d’accès au code .NET Framework sont généralement encapsulées par du code managé qui demande l’autorisation correspondante avant d’activer 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 assemblages, l'autorisation d'exécution est transmise 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é en vigueur. Il existe déjà trois niveaux de stratégie en vigueur dans un environnement non hébergé par Analysis Services : entreprise, ordinateur 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 tout en l’hébergeant ; cette stratégie est un niveau de stratégie supplémentaire inférieur aux trois niveaux de stratégie qui sont toujours en vigueur. Cette stratégie est définie pour chaque domaine d’application créé par Analysis Services.

La stratégie au niveau de l’hôte des Analysis Services est une combinaison de la stratégie fixe des Analysis Services pour les assemblages système et de la stratégie spécifiée par l'utilisateur pour les assemblages utilisateur. L'élément spécifié par l'utilisateur de la stratégie d'hôte Analysis Services repose sur le fait que le propriétaire du module spécifie l'une des trois catégories d'autorisation pour chaque module.

Lorsque CLR est hébergé par Analysis Services, la vérification des autorisations basée sur la pile s’arrête à la limite avec du code Analysis Services natif. Tout code managé dans les assemblys Analysis Services se trouve toujours dans l’une des trois catégories d’autorisations répertoriées précédemment.

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

Usurpation d'identité

Chaque fois que le code managé accède à une ressource en dehors d’Analysis Services, Analysis Services suit les règles associées au ImpersonationMode paramètre de propriété de l’assembly pour vous assurer que l’accès se produit dans un contexte de sécurité Windows approprié. Étant donné que les assemblys utilisant le paramètre d’autorisation Safe ne peuvent pas accéder aux ressources en dehors d’Analysis Services, ces règles s’appliquent uniquement aux assemblys utilisant les paramètres d’autorisation ExternalAccess et Unsafe.

• Si le contexte d’exécution actuel correspond à la connexion authentifiée Windows et est identique au contexte de l’appelant d’origine (autrement dit, il n’y a pas EXECUTE AS au milieu), Analysis Services emprunte l’identité de la connexion authentifiée Windows avant d’accéder à la ressource.

• S'il existe un EXECUTE AS intermédiaire qui a changé le contexte de celui de l'appelant d'origine, la tentative d'accès à la ressource externe échouera.

La ImpersonationMode propriété peut être définie sur ImpersonateCurrentUser ou ImpersonateAnonymous. Le paramètre par défaut, ImpersonateCurrentUserexécute un assembly sous le compte de connexion réseau de l’utilisateur actuel. Si le ImpersonateAnonymous paramètre 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 dispose de privilèges limités sur le serveur. Un assembly s’exécutant dans ce contexte ne peut accéder qu’à des ressources limitées sur le serveur local.

Domaines d’application

Analysis Services n’expose pas directement les domaines d’application. En raison d'un ensemble d'assemblies s'exécutant dans le même domaine d'application, les domaines d'application peuvent se découvrir mutuellement au moment de l'exécution à l'aide de l'espace de noms System.Reflection dans le .NET Framework ou d'une autre manière, et peuvent les appeler par liaison tardive. Ces appels sont soumis aux vérifications d’autorisation utilisées par la sécurité basée sur l’autorisation Analysis Services.

Vous ne devez pas vous appuyer sur la recherche d’assemblys dans le même domaine d’application, car la limite du domaine d’application et les assemblys qui entrent dans chaque domaine sont définis par l’implémentation.

Voir aussi

Définition de la sécurité des procédures stockées
Définition de procédures stockées