|
|
|
|
Architecture des composants WebPart pour les applications commerciales : (réalisé en collaboration avec Avanade) SommaireIntroductionCe document décrit les procédures à suivre pour créer et déployer des composants WebPart pour la distribution d’informations stratégiques à partir d’un grand nombre d’applications commerciales. Il contient notamment des informations sur les méthodes d’architecture de composants WebPart pour des applications commerciales, les outils et compétences nécessaires pour les créer et les problèmes potentiels que le développeur devra surmonter lors de ces procédures.
Ce document présente l’architecture utilisée pour créer les boîtes à outils Microsoft-Avanade Siebel et SAP. Une boîte à outils est un ensemble de composants WebPart et de technologies associées. Dans le cas présent, les technologies associées comprennent des installateurs et composants COM.
Vous pouvez télécharger et installer les boîtes à outils SAP et Siebel à partir de la galerie de composants
WebPart Microsoft sur la page Digital Dashboard
Pour tirer profit des informations présentées dans ce document, vous devez bien connaître les technologies suivantes :
Conception d’un composant WebPart performant pour les applications commercialesLes composants WebPart sont des composants réutilisables contenant des données Web telles que XML, HTML et des scripts. Les composants WebPart possèdent un certain nombre de propriétés standards qui contrôlent la manière dont ils sont rendus dans un tableau de bord interactif. Ces propriétés font des composants WebPart et des tableaux de bord des composants totalement réutilisables et neutres du point de vue du stockage. Les composants WebPart étant tous basés sur une norme commune, vous avez la possibilité de les stocker dans des bibliothèques à partir desquelles vous pouvez créer un certain nombre de tableaux de bord interactifs pour votre entreprise.
Pour être performant, un composant WebPart doit afficher des informations de manière compatible avec le tableau de bord interactif. L’objectif d’un tableau de bord est de résumer, synthétiser et réduire les informations que les utilisateurs voient en permanence.
Une première étape importante dans la conception d’un composant WebPart performant est de déterminer les sous-ensembles de données d’applications requis pour les opérations quotidiennes des utilisateurs. En outre, le créateur de composants WebPart doit établir si un ou plusieurs sous-ensembles de données sont associés l’un à l’autre. Ceci peut être utile pour créer des composants WebPart qui communiquent entre eux afin de concevoir une application de tableau de bord interactif avec des composants distincts. Par exemple, un composant WebPart qui affiche les noms des clients à partir de Siebel peut être lié à un composant WebPart qui affiche les bons de commande des clients à partir de SAP, de manière à afficher les bons de commande dans le composant SAP lorsque l’utilisateur clique sur un nom de client dans le composant Siebel. Les composants WebPart personnalisés, dans lesquels l’utilisateur peut trier, filtrer ou ajouter/supprimer des colonnes de données, offrent des fonctionnalités supplémentaires.
Planification de l’architecture de composants WebPartLa conception de composants WebPart pour applications commerciales est similaire à la conception d’autres applications d’entreprise distribuées. Une architecture courante pour les applications d’entreprise est l’architecture 3-niveaux, ou n-niveaux, dans laquelle les services sont divisés entre les niveaux de présentation, professionnel et de données. L’architecture 3-niveaux classique est donc une architecture recommandée pour démarrer lors de la création de composants WebPart pour applications commerciales à l’aide de SharePoint Portal Server. La figure ci-dessous présente les trois niveaux.
Figure 1 Architecture 3-niveaux classique
Le niveau de présentationLes composants WebPart sont affichés dans un tableau de bord interactif et nécessitent la présence d’un navigateur Web sur la machine cliente. À l’heure actuelle, SharePoint Portal Server prend en charge les navigateurs compatibles avec HTML 3.2. Au risque de simplifier à l’extrême, les composants WebPart sont comme de petites pages Web. Les développeurs doivent donc faire face aux mêmes questions de compatibilité entre navigateurs, y compris décider s’ils veulent utiliser les technologies DHTML, XML et autres technologies côté client dans le composant WebPart.
Ils doivent par conséquent posséder les connaissances requises pour utiliser les technologies associées à la conception d’applications Web traditionnelles. Ces technologies comprennent HTML, JavaScript et VBScript. Afin de maintenir une apparence et un esprit uniforme sur l’ensemble des composants WebPart créés, il est recommandé que le développeur d’IU utilise les feuilles de style communes utilisées dans le tableau de bord. À ce stade du développement, des outils traditionnels tels que Microsoft FrontPage® et Microsoft Visual Interdev® peuvent être utiles pour le HTML et le développement de script. Le tableau de bord interactif offre en outre une gamme étendue de services en matière de communication et de gestion des états. Nous recommandons aux développeurs de planifier leur utilisation de ces services afin de créer des applications de tableau de bord uniques qui sont plus que la simple somme des composants WebPart individuels. Le tableau de bord interactif offre les services côté client par l’intermédiaire du composant DDSC (Digital Dashboard Services Component). Le développeur du niveau de présentation doit maîtriser l’utilisation du composant DDSC afin de créer des composants WebPart capables de communiquer entre eux.
Le composant DDSCLe DDSC est un composant côté client figurant comme objet masqué dans chaque page de tableau de bord. Ce composant rend les composants WebPart réellement réutilisables et plus faciles à créer grâce à une infrastructure standard pour les services suivants :
Pour plus d’informations sur le DDSC et l’usine de tableaux de bord, consultez le Kit de ressources Digital Dashboard.
Figure 2 Niveau de présentation avec DDSC
Niveau professionnelIl est recommandé de diviser le niveau professionnel en deux niveaux logiques : le niveau centré sur l’utilisateur, chargé de délivrer le HTML qui sera affiché dans le navigateur du client, et le niveau centré sur les données, chargé de la gestion complexe de l’accès aux ressources dans le niveau de données. Les propriétés des composants WebPart déterminent comment le composant sera rendu dans le tableau de bord.
Le niveau centré sur l’utilisateur L’usine de tableaux de bord interactifs est un moteur de code implémenté comme page ASP ou comme code compilé sur le serveur Web. Ce serveur réunit les composants WebPart en une disposition adéquate pour le rendu de ces composants dans un tableau de bord. Les composants WebPart peuvent contenir des éléments incorporés tels que HTML, scripts, contrôles Microsoft ActiveX® ou XML. Ils peuvent également contenir des liens pointant vers n’importe quel type de contenu Web situé à n’importe quel emplacement.
L’usine expose également un modèle objet de programmation et un hôte de script sur le serveur. Les services exposés par ce modèle objet comprennent la création d’objet côté serveur, l’interrogation de variables de serveur IIS standards, ainsi que l’interrogation de variables d’inspection de l’usine qui exposent des informations concernant le type d’usine et d’environnement dans lequel le composant actuel est exécuté. SharePoint Portal Server et le tableau de bord interactif utilisent Microsoft Internet Information Services (IIS) pour le rendu des composants WebPart. Les développeurs peuvent utiliser l’hôte de script pour créer un contenu WebPart complexe. Les composants WebPart sont définis comme spécifications ouvertes et conçus pour fonctionner indépendamment de la plate-forme sur laquelle ils sont exécutés. Par conséquent, les auteurs de composants WebPart doivent utiliser l’objet usine de l’hôte de script pour assurer la portabilité des composants.
Dans un environnement d’entreprise comprenant plusieurs navigateurs et périphériques, le composant WebPart doit pouvoir détecter quel type de navigateur client demande les données et envoyer le contenu Web approprié à cette plate-forme. Ceci peut être accompli en ajoutant à un composant WebPart un script qui interroge l’objet usine pour connaître le type de client puis envoie le contenu approprié.
XSLT constitue une méthode efficace pour la mise en forme dynamique des données brutes en contenu Web. En utilisant cette technique et en déterminant le navigateur de l’usine de tableaux de bord, le développeur est en mesure de mettre en forme les données brutes délivrées par le niveau centré sur les données en un contenu Web qui sera adapté à l’environnement spécifique de l’utilisateur. À l’aide de l’hôte de script fourni par l’usine, le développeur produit le contenu Web en implémentant une fonction nommée GetContent().
Figure 3 Niveau commercial centré sur l’utilisateur Centré sur les données
XML est la technologie la plus efficace pour le passage de données du niveau centré sur les données au niveau centré sur l’utilisateur. Elle donne au développeur du niveau centré sur l'utilisateur la flexibilité nécessaire pour formater les données en un contenu Web approprié. La première étape pour les développeurs de ce niveau est par conséquent de créer un générateur de XML. Il s’agit d’une enveloppe de composant autour de l’interface API pour l’application commerciale, chargée de récupérer les données et de les formater en XML.
Le développeur du niveau centré sur les données peut inclure une interface pour le composant afin de permettre au créateur du composant WebPart de définir certaines restrictions. Le filtrage et le tri des informations extraites de l’application commerciale constituent deux exemples de restrictions possibles.
Bien que le travail des développeurs centrés sur les données semble plutôt simple à ce stade, ils ont la tâche extrêmement difficile d’accéder par programmation aux données de l’application commerciale. Il s’agit là d’une procédure cruciale nécessitant une connaissance approfondie de l’application commerciale. Les applications commerciales sont par nature complexes. Les données contenues dans ces applications sont généralement stockées dans des magasins de données ayant un schéma complexe. Par exemple, une instance complète de SAP R/3 comprenant tous les modules nécessite une base de données contenant plus de 10 000 tables.
Étant donné la complexité des magasins de données des applications commerciales, la modification constante des schémas et le fait que la majorité des données soient enfermées derrière une couche de l’application particulièrement difficile à pénétrer, de nombreux vendeurs d’applications fournissent des mécanismes d’entrée/sortie (E/S) ou des interfaces API publiées pour accéder aux données. Microsoft Windows® étant utilisé dans la plupart des entreprises, de nombreux vendeurs d’applications utilisent des composants COM qui exposent ces API. Lors de la construction de composants WebPart pour le tableau de bord interactif, il est recommandé d’utiliser ces composants COM pour accéder aux données de l’application commerciale.
Nous soulignons encore une fois que les applications commerciales et héritées sont pour la plupart des applications complexes. Pour utiliser des données appropriées au composant WebPart, le développeur doit posséder des connaissances approfondies de l’application et de l'API ou mécanisme E/S nécessaire pour accéder aux données de l’application commerciale ou héritée. Si ce n’est pas le cas, il devra consulter des experts possédant ces connaissances.
Figure 4 Niveau commercial centré sur les données Problèmes potentielsAuthentificationLa plupart des applications commerciales et commerciales héritées utilisent des noms d’utilisateur et mots de passe distincts pour l’authentification dans le système, et ceux-ci ne sont pas basés sur l’authentification Windows. Ceci peut constituer un problème pour le constructeur de composants WebPart. Il n’est pas souhaitable que les utilisateurs soient contraints d’entrer un nom d’utilisateur et un mot de passe pour afficher les différents composants WebPart d'une même page. Les informations d’ouverture de session de l’utilisateur ne doivent être demandées qu’une seule fois pour chaque application commerciale, en particulier si plusieurs affichages des données sont nécessaires.
Afin de ne nécessiter qu’une seule ouverture de session, le développeur doit intégrer un autre composant pour traduire le nom d’utilisateur authentifié (NTLM) et le mapper vers le nom d’utilisateur et le mot de passe de l’application commerciale. Un certificat numérique signé est nécessaire pour assurer la sécurité du processus en cryptant le transfert du nom d’utilisateur et du mot de passe. Après l’authentification de l’utilisateur dans l’application commerciale, les autres composants WebPart demandant des données de la même application ne devront pas être authentifiés une seconde fois.
Le logiciel Avanade Security Broker est un utilitaire pratique conçu pour résoudre ce problème. Avanade Security Broker stocke des données cryptées en mappant les noms d’utilisateurs NTLM aux systèmes d’autorisation de sécurité des applications commerciales et héritées. Toutes les communications entre cet utilitaire, la base de données de noms d’utilisateur/mots de passe et le générateur XML appelant sont cryptées selon des normes PKI pour assurer la sécurité.
Figure 5 Niveau de données Latence des interfaces API de l’application LOBÉtant donnée la complexité des applications commerciales, il n’est pas surprenant que les interfaces API pour celles-ci puissent compliquer la procédure d’extraction des informations souhaitées. Par exemple, SAP comprend un jeu important d’interfaces API COM qui aident le développeur Windows à accéder aux données à partir de son application ERP courante, R/3. Toutefois, un grand nombre des appels de fonctions devant être effectués sur le système sont complexes et doivent être exécutés dans un ordre strict, une donnée d’un appel étant utilisée pour l’appel suivant, etc.
Cette complexité fait qu’il est souvent difficile d’extraire rapidement des données synthétisées. Dans ce cas, il est utile de créer une base de données de construction contenant des données synthétisées qui peuvent être récupérées rapidement. Cette technique permet d’augmenter l’efficacité d’un composant WebPart centré sur les données, et par là même son utilité pour l’utilisateur de l’application WebPart.
Figure 6 Application LOB du niveau de données
Déploiement de votre composant WebPartLe déploiement d’applications WebPart et de tableaux de bords interactifs doit être aisé pour un administrateur. En utilisant l’exemple donné dans ce document, une application Microsoft Windows Installer (fichier .msi) peut être utilisée pour installer l’application XML Generator COM+, régler les éventuelles dépendances de l’application commerciale et copier tous les composants WebPart indépendants vers une galerie. L’administrateur du tableau de bord peut alors permettre aux utilisateurs du domaine d’importer les composants WebPart dans un tableau de bord interactif.
ConclusionLe serveur Microsoft SharePoint Portal Server et le tableau de bord interactif offrent aux entreprises une plate-forme à la fois puissante, simple et peu onéreuse pour délivrer des informations tirées d’applications commerciales et héritées. En outre, des fournisseurs tiers mettent à disposition des composants WebPart préconstruits, permettant aux sociétés de sélectionner des composants rapidement intégrables à un tableau de bord interactif pour offrir des solutions à la fois rapides et performantes.
Visitez la galerie de composants WebPart en ligne afin de vous informer des dernières
versions de composants et d’outils disponibles, y compris les composants WebPart Microsoft Avanade SAP et Siebel. Vous trouverez le lien vers cette galerie sur la page
Digital Dashboard
Pour plus d’informations sur la création de composants WebPart, consultez le Kit de ressources Digital Dashboard 3.0, qui comprend le Kit de développement des composants WebPart.
Ce document préliminaire pourra être modifié de façon substantielle avant
sa diffusion commerciale. Il est fourni uniquement à titre d’information et Microsoft ainsi que EROL n’apportent aucune garantie, explicite ou implicite, le concernant. Les informations présentées dans le présent document peuvent être
modifiées sans préavis. L’utilisateur reconnaît assumer tous les risques liés à l'utilisation ou aux résultats de l’utilisation de ce document. Les exemples de sociétés, d’organisations, de produits, de personnes et d’événements décrits
dans ce document sont fictifs. Aucune association avec une société, une organisation, un produit, une personne ou un événement réel n’a été voulue ou ne doit être déduite. L’utilisateur est tenu de respecter toutes les lois applicables en
matière de droits d’auteur. Sans restriction des droits dérivés des droits d’auteur, aucune partie de ce document ne peut être reproduite, stockée ou introduite dans un système de récupération de données ou transmise à quelque fin ou par
quelque moyen que ce soit (électronique, mécanique, photocopie, enregistrement ou autre) ou dans quelque but que ce soit sans la permission expresse et écrite de Microsoft Corporation.
EROL / FICHE 31 :
21-févr.-2004 19:05:16 +0100
|
|
|
.
