A la découverte du Business Data Catalog (BDC) - Partie 1

Le Business Data Catalog ou BDC est une des fonctionnalités majeures de Moss 2007, qui va permettre, à des utilisateurs finaux, de travailler avec n'importe quelle source de données directement depuis l'interface web SharePoint, sans nécessiter de développement de webparts supplémentaires, et aux développeurs, d'attaquer toute source de données de manière uniforme, soit via un fichier ADF (Application Definition File) au format xml, soit via l'API fournie par le BDC.

Nous allons donc voir, dans cette série d'articles, comment travailler avec le Business Data Catalog, en tant qu'administrateur, développeur et utilisateur final.

Dans cette première partie, nous verrons comment travailler avec le Business Data Catalog à partir d'un exemple ; nous verrons donc comment importer nos données depuis l'administration des services partagés (en tant qu'administrateur), puis comment les utiliser ensuite dans nos sites SharePoint (en tant qu'utilisateur final), nous verrons également dans quelle mesure nous pouvons intégrer le BDC avec d'autres services partagés comme la recherche ou encore les profils

Dans les articles suivants, nous verrons également comment écrire nos propres fichiers pour requêter soit directement des bases de données, soit des applications tierces en passant par des web services, et enfin, comment travailler avec le BDC depuis le modèle objet de SharePoint.

Pour suivre ce tutoriel, vous aurez besoin des éléments suivants :

• Moss 2007 Entreprise,
• SQL Server (2005 de préférence),
• La base de données AdventureWorksDW (téléchargeable sur codeplex > http://www.codeplex.com/MSFTDBProdSamples/ ),
• Le fichier ADF de la base de données AdventureWorksDW (copier le bout de code xml > http://msdn.microsoft.com/en-us/library/ms494876.aspx et le copier dans un fichier portant l'extension xml ).

Le BDC est un service partagé, qui va nous permettre de requêter n'importe quelle source de données, soit en passant par des bases de données (qui peuvent etre hébergées sur n'importe quel SGDB, SQL Server, Oracle, DB2, etc.), soit en passant par des services web.

Ses avantages sont nombreux.

On pourra déjà citer d'une part le fait que quelque soit la source de données, la méthode d'accès reste la même ; ainsi, que nous souhaitions accéder à des données situées dans SQL Server, Oracle, SAP ou même SharePoint, nous allons utiliser la même méthode, écrire un fichier xml, portant le nom de ADF (Application Definition File). Pour personnaliser notre fichier ADF en fonction de notre source de données, nous n'aurons simplement qu'à modifier certains paramètres, et notamment les paramètres de connexion à notre source.

Ensuite, nous verrons également comment afficher notre source de données directement sur notre portail, et l'intégrer notamment aux listes SharePoint, à la recherche, aux profils, etc.

Mais avant tout, commencer par explorer la section Business Data Catalog de l'administration des services partagés.

Comme il a déjà été précisé, le BDC est un service partagé, et donc une section sur le site d'administration des Services Partagés lui est dédiée.

Import application definition va nous permettre d'importer notre fichier ADF et donc d'intégrer nos données au sein de SharePoint.

C'est donc ici que nous allons récupérer notre fichier à importer.

Dans la section File Type, nous avons 2 possibilités, soit Model, soit Ressource.

Un modèle est un fichier ADF « core » ; c'est celui qui va donc contenir toutes les informations brutes concernant nos données.

Avec un fichier ADF modèle, au minimum l'administrateur doit être capable de récupérer les données.

Un fichier Resource quant à lui, va nous permettre de modifier le « comportement » de notre ADF, en y intégrant par exemple des informations au niveau des permissions, la gestion de la langue ou encore la modification directe des propriétés.

Grace à un fichier ADF Ressource, nous allons par exemple pouvoir gérer des déploiements mulitlingues, ou encore modifier à la volée l'accès à nos données, ou même modifier les paramètres de connexion, si par exemple l'un de nos serveurs était déplacé.

View applications va nous permettre de lister nos applications déjà importées, et d'y modifier certains paramètres.

Ici par exemple, nous avons 3 applications qui ont été importées, 2 concernant des bases de données et 1 concernant un web service.

ViewEntites va nous permettre de lister nos entités, qui sont des objets (on peut dans un 1^er temps les considérer comme des tables), le tout en fonction de nos applications.

Business Data Catalog permissions, permet d'attribuer des autorisations à nos utilisateurs.

Ces autorisations sont au nombre de 4 :

• Edit, qui permet l'import de fichiers ADF, ainsi que la mise à jour et la suppression d'objets.
• Execute, autorise l'appel de méthode permettant de requeter les données.
• Select in clients, permet de sélectionner des entités lors de la configuration du BDC au niveau des webparts, listes, etc.
• Set permissions, permet de définir les autorisations

Edit page profile template, permet de customiser la page qui sera utilisée pour afficher le détail d'un item.

Maintenant que nous avons passé en revue la section BDC de notre SSP, nous allons à présent importer un fichier ADF.

Comme il vous l'a été signalé dans les pré-requis de cet article, le code de ce fichier ce trouve sur le site msdn ; de même, il vous faudra récupérer et installer la base de données AdventureWorksDW (voir également pré-requis) afin de pouvoir y récupérer les donnes.

Récupérez donc ce bout de code et copiez le dans un fichier xml, par exemple adworks.xml.

Si nous regardons de manière générale ce fichier (nous le regarderons plus en détails quand nous écrirons nos propres fichiers ADF), nous remarquons que l'élément racine est le LobSystem.

Cet élément va nous permettre de décrire tout le système que nous souhaitons requêter.

Il est également composé des nouds LobSystemInstances, qui va nous permettre de définir les informations de connexion à notre système, Entities, qui va nous permettre de modéliser nos différents objets (que nous pouvons grossièrement considérer comme des tables), et également Associations, qui va nous permettre de modéliser les relations qui existent entre nos différentes entités.

Nous allons à présent renseigner les informations de connexion, à savoir ou se situe votre base de données.

Pour cela, regardez le noud LobSystemInstance, puis Properties, et identifiez la propriétés Data Source (l'instance sur laquelle est installé votre base de données AdventureWorksDW), et renseignez cette propriété en respectant le critère « NomDuServer\NomDeL'instance ».

De mon coté, ma base de données AventureWorksDW se trouve sur ma machine locale et sur l'instance par défaut, donc je devrais avoir une valeur du genre « NomServeur » ou encore « (local) » ou encore « . » (local et . désignent comme vous l'aurez compris la machine locale, et l'instance par défaut n'a pas de nom, d'où l'absence de « \NomInstance »).

Voici un extrait de ma section Properties :

<LobSystemInstance Name="AdventureWorksDWInstance">
  <Properties>
    <Property Name="AuthenticationMode" 
        Type="Microsoft.Office.Server.ApplicationRegistry.SystemSpecific.Db.DbAuthenticationMode">
            PassThrough
    </Property>
    <Property Name="DatabaseAccessProvider" 
        Type="Microsoft.Office.Server.ApplicationRegistry.SystemSpecific.Db.DbAccessProvider">
            SqlServer
    </Property>
    <Property Name="RdbConnection Data Source" 
        Type="System.String">pc-de-test</Property>
    <Property Name="RdbConnection Initial Catalog" 
        Type="System.String">AdventureWorksDW</Property>
    <Property Name="RdbConnection Integrated Security" 
        Type="System.String">SSPI</Property>
  </Properties>
</LobSystemInstance>

Mais à présent, importons notre fichier ; pour cela, sur la page des SSP, cliquons sur Import application definition, récupérons notre fichier adworks.xml, sélectionnons modèle, et cochons toutes les cases de la section Resources To Import.

Après un court instant durant lequel votre fichier ADF est analysé et importé,

Vous recevez un message vous indiquant que votre application a été importée avec succès.

Vous pouvez dès à présent, à partir de votre site d'administration des SSP, commencer à explorer votre application ; d'ailleurs, en cliquant sur ok, vous etes redirigés vers la page View Application concernant votre application, à savoir AdventureWorks.

Ici par exemple, nous pouvons voir que nous avons 4 entités qui ont été défines, chose que nous retrouvons également dans notre fichier ADF, sous le noud Entities.

Si au niveau de notre page View Entities, nous cliquons sur une entité, par exemple Product SubCategory, nous obtenons le détail de cette entité.

Ici par exemple, nous remarquons que cette entité est composée de 2 champs, qu'elle possède des filtres (ces informations sont définies dans l'entité dans le fichier ADF), mais également qu'une action y a été définie, et que cette entité est mêlée à 2 associations

L'action View Profile est une action présente par défaut (et donc il est inutile de la créer dans le fichier ADF), qui nous donne les informations concernant le détail d'une action.

Le bouton Add Action, nous permet depuis cette interface de rajouter directement des actions ; par exemple nous pourrions rajouter une action qui va lancer une recherche sur le nom directement sur google.

Ici, nous avons tout simplement ajouté un paramètre que nous récupérons ensuite sous forme de querystring.

Comme vous venez de le voir, une action, c'est uniquement une url.

Ici, nous venons de définir une action qui s'appliquera à chacun de nos items appartenant à cette entité.

Si nous avions souhaité définir une action pour toute la liste, il nous faut définir une action sans paramètre.

Nous verrons ultérieurement le développement d'une action qui va nous permettre de générer un fichier excel à partir de nos items.

Si vous souhaitez visualiser/customiser le rendu de l'action View Entity, revenez simplement sur la page d'accueil des SSP et choisissez Edit page profile template. Vous etes redirigé vers une page de webparts qui sert de template, et vous pouvez ensuite la customiser à souhait.

Le dernier point important que nous allons pouvoir gérer au niveau de notre application est l'affectation des permissions aux utilisateurs.

Cette affectation aurait pu être définie directement dans notre fichier ADF, ou dans un fichier ressource, mais elle l'est également depuis la page d'administration des SSP.

Ici vous pourrez donc définir qui a accès aux informations et à quelles informations, et ensuite exposer vos données en toute sérénité.

A présent, voyons comment mettre à disposition ces données à nos utilisateurs.

Dans cette section, nous allons voir quelles sont les options natives OOTB (Out Of The Box) proposées par SharePoint pour récupérer nos données.

IV-A. Les WebParts du BDC▲

Si vous êtes un concepteur de sites SharePoint et que vous avez l'habitude d'ajouter des webparts à vos pages, vous avez du remarquer un groupe de webparts portant le nom « Business Data ».

La capture d'écran ci-dessous vous donne la liste des webparts (celles qui sont cochées) directement liées au Business Data Catalog.

IV-A-1. Le composant Business Data List▲

C'est ce composant qui va nous permettre de récupérer l'ensemble de nos données sous forme de liste.

Pour le configurer, il suffit d'ouvrir le toolpane puis de choisir l'entité que nous souhaitons afficher

Une fois validé, nous pouvons soit récupérer les données directement en cliquant sur le lien Retrieve Data, soit définir les filtres qui ont été intégrés.

Nous allons ensuite retrouver nos actions, ainsi que la possibilité de modifier la vue affichée.

En modifiant la vue, nous pourrons ainsi définir un certain nombre de paramètres, spécifiques aux listes SharePoint (filtre, tri des données, nombre d'items par page, nombre d'items affichés, choisir les colonnes affichées), mais également des données spécifique au BDC (type de requete exécutée, définir des critères pour la requête, empecher/autoriser un utilisateur à les modifier)

IV-A-2. Le composant Business Data Related List▲

Ce composant est similaire au composant Business Data List ci-dessus, à ceci près qu'il va utiliser une association (relation) pour récupérer des données.

Par exemple, nous avons vu au niveau de notre SSP qu'une association avait été définie entre ProductSubCategory et Product ;

Ci-dessus, nous avons créé une Business Data (BD) List, nous allons à présent créer une Business Data Related (BDR) List Product et utiliser l'association ProductSubCategoryToProduct.

Pour cela, en plus d'avoir créé et configuré notre BD List ProductSubCategory, nous allons à présent configurer notre BDR List Product ;

Pour cela, définissons le toolpane comme ci-dessous.

Une fois ceci effectué, il nous faudra utiliser les connexions des webparts pour que ca fonctionne.

Ensuite, tout devrait fonctionner à merveille.

IV-A-3. Le composant Business Data Item▲

Le composant Business Data Item va nous permettre d'afficher le détail d'un item en particulier.

Pour le configurer, depuis le toolpane, il faut sélectionner la liste à laquelle cet item appartient, et ensuite, on peut récupérer l'item soit de manière statique en le renseignant toujours depuis le toolpane, soit en utilisant les connexions des webparts, et en connectant notre webpart Business Data Item à une webpart Business Data List.

Voici le résultat.

IV-A-4. Le composant Business Data Action▲

Nous allons utiliser ce composant pour afficher des actions en function d'un item.

Il se configure comme le Business Data Item, sauf qu'au lieu d'afficher un item, il affiche les actions liées à cet item.

Nous pourrions par exemple connecter cette webpart avec une webpart Business Data List, et ensuite supprimer la toolbar de la Business Data List, afin d'offrir toutes les actions dans une toolbar, directement à portée de main.

IV-A-5. Le composant Business Data Item Builder▲

Ce composant se contente uniquement de récupérer les IDs spécifiés dans les paramètres en querystring d'une url, et de le transférer ensuite à une autre webpart.

Il est notamment utilisé dans les pages de profil, lorsque l'on clique sur l'action View Profile.

Ce qui nous permet d'ailleurs de naviguer à travers les items en modifiant directement la clé en querystring.

Ici, notre page est composée de 2 webparts connectées; 1 Business Data Item Builder qui envoie l'ID à 1 Business Data Item.

Si nous supprimons la connexion qui a été définie, il nous faudra ensuite paramétrer notre Business Data Item, comme nous l'avons vu ci-dessus.

Nous venons donc de voir comment récupérer nos données directement dans notre portail via un certain nombre de webparts, ma foi fort utiles, et surtout OOTB !

Vous allez surement me dire "Ok c'est bien tout ca, on a surtout vu que ces webparts avaient un comportement similaire aux listes natives SharePoint, mais ce qu'on Remarque, c'est que si l'on veut rajouter des actions similaires à celle disponible dans ces même listes, comme par exemple l'export vers Excel, il va nous falloir developer nos propres actions; il aurait été pas mal d'avoir directement nos données disponibles dans des listes SharePoint" et moi de vous répondre "N'allez pas plus vite que la musique, nous allons voir dans un instant comment intégrer nos données dans les listes SharePoint" !

IV-B. Les colonnes Business Data et l'intégration du BDC dans les listes SharePoint▲

Nous allons également pouvoir intégrer nos données directement dans des listes SharePoint, via des colonnes Business Data.

Pour cela, nous allons commencer par créer une nouvelle liste que nous allons appeler BDC List.

Une fois cette liste créée, nous allons lui ajouter une colonne

Et choisir une colonne de type Business Data que nous allons appeler Product, et qui va nous servir à récupérer l'entité Product.

Une fois ceci effectué, nous allons également choisir quelles sont les colonnes additionnelles que nous souhaitons afficher ; sélectionnons les toutes (à l'exception de Key que nous avons déjà affiché), et affichons les directement dans notre vue par défaut.

Maintenant, en créant un nouvel item, il nous est demandé de selectionner notre Data Item ; sélectionnons en un.

Voici le résultat.

Nous pouvons dès à présent utiliser sur nos données BDC toutes les fonctionnalités disponibles avec les listes, y compris créer des colonnes calculées, ou des colonnes de recherche, qui s'appuient sur nos colonnes Business Data.

Bien que cette méthode de récupération des données présente un certain nombre d'avantage, dont principalement :

• Le fait que les données présentes dans les listes ne soient pas mises à jour : en effet, si vous modifiez votre source de données sous-jacente, les données présentes dans les listes ne sont pas mises à jour ; vous pouvez néanmoins programmer un job SharePoint pour aller vérifier les données et faire la mise à jour dans les listes correspondantes si nécessaire.
• Le fait que l'on ne puisse pas rapatrier les données en masse directement dans notre liste ; il faut les rajouter une par une ; cependant la aussi, il faut suffit d'écrire un code snippet qui vous permette d'effectuer ce chargement en masse ; nous verrons ultérieurement comment récupérer les données en utilisant l'API du BDC.

Il est également possible de créer une source de données secondaire s'appuyant sur le BDC depuis le Profile Store.

De cette façon, il ne nous sera pas possible de créer directement de nouveaux profils depuis notre source de données basée sur le BDC, ceci sera effectué via une source AD ou autre LDAP, cependant, grâce aux BDC, nous allons pouvoir rajouter des propriétés, ou directement mapper des données issues de notre BDC directement dans nos propriétés définis dans nos profils.

La seule contrainte à respecter est que les données mappées entre le Profile Store et le BDC soit de même type.

Nous allons également pouvoir créer une nouvelle source de contenu basée sur nos applications du BDC et utiliser le service partagé de recherche de Moss 2007 pour rechercher nos données directement dans le BDC, comme nous le ferions pour nos sites SharePoint.

Dans cet article, vous avez appris à travailler avec le BDC de manière native, et comme vous avez pu le constater, dans la majorité des cas, ce sera largement suffisant.

Nous avons également vu que malgré toutes les fonctionnalités qu'il apportait, le BDC présentait cependant certaines limites, limites que nous pouvons facilement évincer en y rajoutant du code custom.

Les prochains articles seront axés un peu plus sur le développement, et notamment sur la production de nos propres fichiers ADF et sur le développement utilisant les API fournis avec le BDC ; vous y apprendrez par exemple comment écrire un fichier ADF pour accéder à une base de données, ou un service web, mais également comment créer des actions personnelles, comment accéder aux données directement via l'API du BDC, etc.