Partager via

Différences entre l’utilisation du .NET Assembly Connector et l’écriture d’un connecteur personnalisé

  • Article

Dernière modification : mercredi 7 juillet 2010

S’applique à : SharePoint Server 2010

Dans cet article
Utilisation du .NET Assembly Connector
Écriture d’un connecteur personnalisé
Avantages et inconvénients du .NET Assembly Connector par rapport à un connecteur personnalisé
Quand utiliser l’une ou l’autre approche ?

Cette rubrique explique quand utiliser le .NET Assembly Connector fourni avec Microsoft Business Connectivity Services (BCS) et quand écrire un connecteur personnalisé pour établir une connexion à des systèmes externes qui ne sont pas pris en charge directement par Business Connectivity Services.

Un connecteur personnalisé est écrit de façon à être agnostique par rapport aux types de contenu externe qui se connectent à un genre de système externe (par exemple toutes les bases de données ou tous les services Web), tandis que chaque assembly de connectivité .NET est spécifique à un type de contenu externe. De plus, un connecteur personnalisé fournit une intégration à l’interface utilisateur Administration, ce qui n’est pas le cas d’un assembly de connectivité .NET.

Utilisation du .NET Assembly Connector

Lorsque vous utilisez le .NET Assembly Connector au lieu d’écrire un connecteur personnalisé, vous devez procéder comme suit :

  1. Écrivez du code en tant que classes Microsoft .NET Framework et compilez les classes en une DLL principal et en plusieurs DLL dépendantes.

  2. Publiez les DLL dans la base de données Service BDC (Business Data Connectivity).

  3. Utilisez Microsoft SharePoint Designer pour découvrir l’assembly de connectivité .NET et créer un modèle.

  4. Mappez chaque entité à une classe dans la DLL et mappez chaque opération BDC dans cette entité à une méthode à l’intérieur de cette « classe ».

Au moment de l’exécution, lorsqu’un utilisateur exécute une opération BDC, la méthode correspondante dans la DLL principale est exécutée.

Écriture d’un connecteur personnalisé

Lorsque vous écrivez un connecteur personnalisé au lieu d’utiliser le .NET Assembly Connector, vous devez procéder comme suit :

  1. Implémentez des interfaces ISystemUtility, IConnectionManager et ITypeReflector (seule ISystemUtility est obligatoire). Il est éventuellement possible de substituer le gestionnaire de connexions par défaut et les interfaces EntityInstance. En outre, l’implémentation d’IAdministrableSystem fournit une prise en charge de la gestion des propriétés de l’interface utilisateur Administration et l’implémentation d’ISystemPropertyValidator fournit une validation au moment de l’importation des propriétés LobSystem (pas sur le client Microsoft Office).

  2. Compilez le code à l’étape 1 en une DLL et placez-la dans le Global Assembly Cache sur le serveur et les clients.

  3. Créez le code XML pour la source de données personnalisée (SharePoint Designer 2010 ne prend pas en charge d’expérience de création de modèle pour les connecteurs personnalisés).

  4. Au moment de l’exécution, lorsqu’un utilisateur exécute une opération BDC, la méthode Execute est appelée dans la classe ISystemUtility. Ainsi, la responsabilité de l’exécution de la méthode principale incombe à la méthode Execute (telle qu’implémentée par le connecteur personnalisé).

Avantages et inconvénients du .NET Assembly Connector par rapport à un connecteur personnalisé

Le tableau suivant répertorie les avantages et inconvénients de l’utilisation du .NET Assembly Connector par rapport à un connecteur personnalisé

.NET Assembly Connector

Connecteur personnalisé

La DLL qui implémente la logique métier est stockée dans le magasin BDC. Par conséquent, il est inutile de placer la DLL séparément dans le Global Assembly Cache sur le client et le serveur.

Les binaires qui implémentent un connecteur personnalisé doivent être placés dans le Global Assembly Cache sur le client et le serveur.

La DLL .NET Framework qui implémente la logique métier est déployée sur les ordinateurs clients enrichis via un déploiement Business Connectivity Services basé sur ClickOnce.

Un processus de configuration distinct est nécessaire pour installer les binaires qui implémentent un connecteur personnalisé.

Aucun privilège d’administrateur n’est nécessaire sur l’ordinateur client pour le déploiement.

Des privilèges d’administrateur sont nécessaires sur l’ordinateur client afin de placer l’assembly dans le Global Assembly Cache.

La mise hors connexion des listes externes est transparente car les assemblys requis sont déployés par le biais de ClickOnce.

La mise hors connexion des listes externes provoque une rupture si la configuration du client ne place pas l’assembly dans le Global Assembly Cache.

Fournit une approche utile si la logique métier peut être exposée par le biais d’API statiques qui changent rarement.

Fournit une approche utile lorsque les interfaces principales changent fréquemment (autrement dit, quand elles sont dynamiques).

Ne permet pas la substitution du composant TypeReflector (Business Connectivity Services) par défaut qui interprète les types comme des types .NET Framework.

Permet de substituer le TypeReflector par défaut et implémente un TypeReflector personnalisé.

Le mappage un-à-un de l’entité BDC et de la classe .NET Framework est nécessaire. Par conséquent, si une entité BDC doit agréger plusieurs classes, un wrapper doit être écrit. Cela nécessite une recompilation et un redéploiement de l’assembly de connectivité .NET.

Il n’existe aucune restriction de ce genre.

Les interfaces de DLL fonctionnent comme un système principal pour Business Connectivity Services ; ainsi, le système principal réel est totalement abstrait de la pile Business Connectivity Services. La DLL d’assembly .NET Framework étant chargée in-process avec Business Connectivity Services, il n’existe aucune exigence de sécurité. Elle est toujours considérée comme « Passthrough ».

Avec le connecteur personnalisé, différents genres de mécanismes de sécurité offerts par Business Connectivity Services peuvent être utilisés, notamment un mécanisme de sécurité personnalisé (Business Connectivity Services offre une prise en charge native de RevertToSelf, Passthrough, Credentials et WindowsCredentials).

Business Connectivity Services propose des outils pour la prise en charge du .NET Assembly Connector à la fois dans SharePoint Designer (découverte) et dans Visual Studio 2010 (développement et déploiement de la DLL et du modèle).

Aucun outil de prise en charge n’est fourni pour les connecteurs personnalisés.

Quand utiliser l’une ou l’autre approche ?

Le .NET Assembly Connector et le connecteur personnalisé sont tous deux des mécanismes d’extensibilité de connectivité Business Connectivity Services très précieux offerts par Business Connectivity Services.

Le recours au .NET Assembly Connector est recommandé si le système externe est statique. Autrement, pour chaque modification dans le système principal, vous devez apporter des modifications à la DLL d’assembly de connectivité .NET, ce qui requiert une recompilation et un redéploiement de l’assembly et des modèles.

Si les interfaces principales changent fréquemment, il est conseillé d’utiliser un connecteur personnalisé. Avec cette approche, seules des modifications au modèle sont requises.