Introduction

 

Les Business Connectivity Services sont une évolution majeure du Business Data Catalog introduit en 2007. Je ne vais pas ici vous présenter cette fonctionnalité, je vais plutôt entrer en détail dans ce qu’il est possible de faire. Je passerai donc assez rapidement sur les bases.

Plaçons tout d’abord le contexte : imaginez que vous avez un système de gestion documentaire lambda qui stocke des fichiers, avec une partie métier pour gérer les contraintes, les métadonnées etc., et qu’un matin on vous demande « dis-moi Julien, pourrais-tu m’indexer tout ça dans le moteur de recherche de notre SharePoint 2010 ? ».

 

L’outil de gestion documentaire

Pour les besoins de cet article, j’ai « développé » (entre guillemets, car on ne parle pas ici d’un développement monstrueux) un outil de gestion documentaire. Les documents sont stockés dans un répertoire particulier de mon serveur, et les métadonnées dans une table SQL.

 

 

 

Mais pourquoi ne pas attaquer ce dossier directement depuis le moteur de recherche de SharePoint Server 2010 me direz-vous. Ce n’est pas faux, seulement, ma « GED » a des contraintes fonctionnelles qu’il faut respecter (comme la sécurité). Donc cette table et ce dossier sont attaqués via une application .NET, application qui expose des méthodes permettant de manipuler les documents. Et c’est justement cette API que je veux utiliser sans SharePoint.

 

D’ailleurs, cette GED possède en plus une interface utilisateur permettant d’exécuter trois commandes : « get », « add » et « update ».

 

 

« Add » permet d’insérer un document dans ma GED avec un titre.

 

 

Et enfin « Get» me permet de le récupérer ce document et de préciser le répertoire dans lequel il sera sauvegardé. Rien de bien sorcier jusque-là !

 

Voilà, les bases sont posées. Alors avant que vous me sautiez à la gorge, cette petite application n’a pas été développée dans un souci d’industrialisation. Je n’utilise pas de jolis patterns ou d’outils de tests unitaires, le but étant tout de même de voir comment SharePoint 2010 va pouvoir manipuler tout ça.

SharePoint 2010 Business Connectivity Services

 

Commençons par créer ce projet de connecteur .NET BCS depuis Visual Studio 2010.

 

 

Créons maintenant notre entité métier (en utilisant ou non le designer, libre à vous).

 

Le principe du BCS est de créer un objet métier qui sera envoyé à SharePoint, et de créer au moins deux méthodes : une permettant de renvoyer tous les éléments (sous forme de collection de ce fameux objet), et une permettant de renvoyer une instance de cet objet pour un ID donnée.

 

Il nous reste ensuite à faire un mapping (lien) entre des MethodInstance et nos propres méthodes de classe. Les deux MethodInstance au minimum à déclarer dans notre modèle BCS sont donc le Finder et le SpecificFinder. Le Finder va nous permettre de récupérer toutes les instances de notre objet métier. Le SpecificFinder, lui, va nous permettre de récupérer une instance particulière de notre entité métier pour un identifiant donné.

 

Je vous conseille vivement de lire les billets de Todd Baginsky sur le BCS, où il présente en détails ces deux méthodes (les liens intéressants autour des BCS sont en fin d’article).

 

Créons cette fameuse entité métier que SharePoint va pouvoir utiliser, avec ses deux méthodes obligatoires.

 

 

Nous définissions ici l’identifiant pour nos objets métier, ainsi que les deux méthodes.

 

Il est nécessaire ensuite de définir notre objet métier sous forme de classe partielle (heureusement, Visual Studio 2010 génère toutes les classes pour nous) :

 

 

Ce qui est important de noter ici c’est que deux propriétés sont nécessaires pour l’indexation du moteur de recherche SharePoint : « LastUpdated » qui va être utilisé par la recherche incrémentale (et du coup ne réindexer que les éléments qui ont changés depuis la dernière indexation) et « Extension ». Cette dernière va permettre au moteur de recherche de lancer le bon iFilter (filtre qui saura lire un type de fichier particulier) pour parcourir le fichier (ou le flux de données représentant un fichier, mais nous verrons tout cela dans un petit moment).

 

Il nous reste maintenant à implémenter ces deux méthodes « GetAllDocuments » et « GetDocumentByID » depuis la classe MyDocumentService générée par le modèle de projet (cette classe peut être assimilée à un proxy). Dans ces deux méthodes, nous implémenteront la logique pour récupérer les fichiers depuis notre source, ici cette fameuse GED mentionnée plus haut en utilisant l’API qui va bien:

 

 

Voilà son équivalent en XML :

 

 

Notez bien ici que chacune des méthodes de notre classe est associée à une MethodInstance attendue par les BCS.

 

GetAllDocuments ==> Finder
GetDocumentByID ==> SpecificFinder

 

De plus, au niveau de la méthode Finder vous trouvez deux propriétés essentielles pour la recherche :

RootFinder va permettre au moteur de recherche de savoir quelle méthode « Finder » utiliser. En effet, rien ne vous empêche de définir deux « Finder », une pour votre liste externe par exemple, et une autre pour la recherche. Dans cette dernière, vous pouvez retourner moins de champs pour ne pas surcharger l’index de données inutiles.

 

LastModifiedTimeStampField attend comme valeur le nom de la propriété de notre objet métier qui va contenir cette valeur de dernière modification. Une fois de plus, sans ce champ, l’indexation incrémentale ne pourra pas fonctionner.

 

Enfin, pour s’assurer que notre entité métier sera bien disponible dans la recherche, il faut ajouter au niveau du nœud LobSystemInstance, la propriété ShowInSearchUI (aucune valeur n’est nécessaire, il faut juste que la propriété soit présente). Sans cette propriété, vous ne seriez pas en mesure de créer une nouvelle source de contenu basé sur cet objet métier.

 

Si vous déployez à ce niveau votre solution, une nouvelle entité sera ajoutée aux BCS, et vous pourrez par exemple créer une liste externe ou indexer ce contenu dans la recherche. Nous reviendront sur le paramétrage de la recherche dans un moment.

La MethodInstance StreamAccessor

 

Ce qui nous intéresse ici, c’est de pouvoir indexer en plus nos fichiers stockés dans notre GED. Pour cela, les BCS exposent une MethodInstance StreamAccessor.

 

La signature de cette méthode au niveau de notre code doit ressembler à

 

 

Attention ici, un FileStream doit être renvoyé pour que la recherche puisse indexer le contenu. Il faut donc implémenter la logique pour renvoyer cet objet, toujours en utilisant l’API de ma GED exposant les bonnes méthodes.

 

Cette méthode fera donc appel à l’API de ma GED, qui renverra un FileStream du fichier tel qu’il est stocké dans la boite noire.

 

Il est ensuite important de faire évoluer le modèle BCS pour ajouter cet élément, voilà ci-dessous la définition XML. Comme précédemment, il faut faire un lien entre la méthode que nous venons de développer et la MethodInstance StreamAccessor attendue par les BCS.

 

 

Ce qui est important à noter ici pour la MethodInstance StreamAccessor, c’est qu’il faut rajouter la propriété « Extension » en lui donnant comme valeur le nom de la propriété de notre objet métier qui va exposer cette valeur. En effet, cette valeur va permettre d’utiliser le bon filtre pour indexer le flux de données. Une fois de plus, cette propriété est essentielle au bon fonctionnement de l’indexation.

 

Une fois le code déployé, il ne reste plus qu’à configurer la recherche.

Paramétrage du moteur de recherche

 

Depuis la gestion des services applications, assurez-vous dans un premier temps que les permissions sur l’objet métier soient bien spécifiées.

 

Naviguez jusqu’à la fenêtre de paramétrage de la recherche, et ajoutez une nouvelle source de contenu :

 

(si vous ne voyez rien, assurez-vous bien d’avoir ajouté la propriété ShowInSearchUI dans votre modèle).

 

Une fois l’indexation complète effectuée, naviguez jusqu’à votre site, si ce n’est pas déjà fait créez un site de Recherche puis recherchez pour un mot contenu dans un document existant dans la GED.

 

Et voilà, par magie, la recherche « trouve ».

 

 

Effectivement, à ce niveau, il faut développer une page permettant d’ouvrir simplement le fichier. Et c’est là que l’on s’appuie sur les « Actions » du BCS ou l’on peut associer des URL d’affichage à notre contenu métier.

 

Dans la solution Visual Studio associée à cet article, cette page existe. Elle se déploiera dans le dossier Layouts et pourra ainsi être référencée en temps qu’action sur notre entité métier.

Conclusion

 

Le Business Data Catalog introduit avec SharePoint 2007 était une fonctionnalité très intéressante, malheureusement encore à ses débuts : très peu de personnalisation possible, moins flexible sur les types de sources de données auxquels se connecter et surtout, une disponibilité uniquement dans la version Enterprise de Microsoft Office SharePoint Server 2007, ce qui rendait son adoption plus coûteuse.

 

Maintenant, les Business Connectivity services comblent beaucoup de ces manques : ils se connectent à tout (SQL Server, services Web asmx / WCF et classes .NET), ils sont personnalisables à souhait, bref, plus aucune limite. Mais la nouveauté, c’est tout de même la possibilité d’utiliser les BCS dès la version SharePoint de base, à savoir SharePoint Foundation 2010. Je pense sincèrement que les BCS seront incontournables dans SharePoint 2010!

 

Vous trouverez un zip contenant le projet GED, le script de création de la table SQL ainsi que le projet SharePoint BCS connecteur .NET.

Ressources