Quelques notes d'architecture, suite et fin.
Animateurs : Pierre Couzy et Steeve Sfarz (Microsoft – Architecte Avant Vente)
Autre étude, autre résultat : 80% des volumes d’information sont hors du Système d’Information ! On les trouve sur les postes des collaborateurs, sur les serveurs de fichiers… Alors, pourquoi intégrer si tard ?
En général, un projet SI a une durée de 12 à 40 mois. Les mises en production sont longues. On privilégie l’industrialisation et la robustesse : la communication avec le SI est critique, induisant des contraintes de montée en charge, de sécurité, d’audit. Voilà pourquoi tout n’est pas intégré ! Et il est donc nécessaire d’appeler une autre couche d’intégration.
Car un SI bien conçu tient bien la charge, unifie les sources, garantit les accès, mais combien de projets sont planifiés hors du SI ? Combien d’applications « pirates » fleurissent au sein des directions métiers ? Non planifiées, non documentées, non migrables, non sécurisées ?
Quelle approche peut-on proposer pour rendre cohérent cette dualité au sein du portail ?
Les problèmes spécifiques :
- identification de l’utilisateur : de moins en moins proche du SI, l’authentification ne suffit pas
- intégration : deux écueils ; si les données sont récupérées trop près du SI, le couplage est trop fort, trop de responsabilités sont données au portail ; si les données sont récupérées trop loin du SI, le couplage est trop fort avec le scénario de production de la donnée, le travail d’intégration est trop fort.
- comment récupérer les données collaboratives non structurées ?
- quant au décisionnel, il faut une rétro action du SI vers le portail.
Où récupérer les données ?
- depuis une IHM
- depuis une application métier
- depuis la couche de données
Intégration d’autres IHM
- Screen Scraping : simplicité de mise en œuvre, mais limité aux interactions anonymes
- utiliser une couche Web Services : séduisant mais complexe en ce qui concerne la gestion de sessions
- les deux solutions sont disponibles depuis SharePoint 2003 (composant Web Capture).
Cependant, l’intégration d’autres IHM ne semble pas la solution la plus naturelle comme mode de partage au sein du Portail. Il semble préférable de consommer directement la donnée.
Connexion directe au backend
Il existe plus de 200 connectivités incluses en standard, et il est toujours préférable d’acheter une connexion supplémentaire plutôt que chercher à la développer soit même.
Intégration par les données directement
C’est le cadre idéal. La performance est bien meilleure que l’accès direct métier, la mise en cache est rendue possible.
Dans Share Point, on trouve le Business data Catalog (BDC) : ramener dans une base locale les données nécessaires (fichier XML) de configuration et de requêtes. Ensuite, sur MOSS, dans le module BDC Application, on récupère le module XML et l’application devient native et s’intègre aux fonctionnalités du portail.
Exemples :
- affichage des congés restant personnalisés en fonction de l’utilisateur,
- base clients intégrée au moteur de recherche
Pour la gestion des identités, elle est organisée en standard au sein d’ASP.NET par un système de provider et des user et rôles. Il est donc tout à fait possible de combiner Active Directory et les rôles d’une application métier sous Sql Server. En standard, Microsoft propose Active Directory et Sql, mais il existe beaucoup de providers disponibles hors Microsoft.
Dans MOSS, on gère les profils et les audiences, pour améliorer la finesse de lecture. Ainsi, ce n’est pas parce qu’une information n’est pas affichée, que l’utilisateur ne peut pas y accéder.
Maintenant que le contenu est agrégé, comment doit-il être composé ? Ce que l’on recherche, c’est construire un point central à l’information. L’enjeu est de placer des composants hétérogènes dans une interface homogène. Deux possibilités nous sont offertes : le desktop ou le web.
Web
MOSS repose sur les web parts, nouveaux composants .NET, fonctionnellement identiques aux modules DotNetNuke, affiché dans un espace délimité de la page. Il faut ensuite faire communiquer ces web parts. Dans le framework 2.0, fusion du moteur de rendu des Web Parts WSS et .Net.
Deux modes de hosting différents peuvent être mis en œuvre :
- application Web asp.net 2.0 : du sur mesure complet, les web part nécessitent du développement asp.net, de la modularité et de la communication.
- WSS V3 : accès à tous les services, portail sur étagère.
Un framework dédié existe : le Composite Web Application Block. Important : le moteur Workflow Foundation a été implémenté dans le CWAB. (Projet Global Bank). La limite : c’est la complexité, la courbe de productivité longue. Pour remédier à cela, Microsoft propose une factory : la Web Client Software Factory, un méga projet disponible sur le portail open source CodePlex. Cette factory propose des scénarios d’usage, des modules business et foundation, des page flows, la logique, le déploiement. L’ensemble mérite une étude attentive.
Desktop
Le pendant de la Web Application Block, le UI Application Block. Le framework embarque le métier dans Office, à travers les Winforms. Le produit DUET, par exemple, propose une connexion à SAP, sur quelques scénarios dédiés.
Et Office ?
Un projet d’add-in Office 2003 et 2007 pour Visual Studio existe : le VSTO, Visual Studio Tool Office. Il s’agit simplement d’embraquer dans les applications Office la logique .Net. Une sorte de méga successeur de VBA…
Conclusion
Parmi les 3 approches : Web, Desktop, Office, aucune ne peut suffire, c’est l’infrastructure permettant la composition de l’ensemble qui est primordiale.
Les commentaires récents