Architecture d'InfoPath Forms Services
Dernière modification : vendredi 12 mars 2010
S’applique à : SharePoint Server 2010
Dans cet article
Intégration à Office SharePoint Server
Architecture générale
Architecture d'exécution
Rendu et paramètres de requête
Cycle de vie d'un modèle de formulaire
Convertisseur de modèle de formulaire
InfoPath Forms Services, en tant que composant de Microsoft SharePoint Server 2010, est un véritable système multiniveau. L’architecture d’InfoPath Forms Services comprend Microsoft InfoPath 2010 et le contrôle de navigateur XmlFormView sur l’ordinateur de bureau. Ils communiquent avec le niveau intermédiaire directement ou via les services Web d’InfoPath Forms Services, lesquels communiquent avec les composants sous-jacents d’InfoPath Forms Services et de SharePoint Server 2010.
Intégration à Office SharePoint Server
InfoPath Forms Services s’intègre à la plateforme principale et aux composants avancés de SharePoint Server 2010, dont plusieurs produits et composants de serveur sont conçus sur la plateforme Microsoft SharePoint Foundation 2010. Du fait que InfoPath Forms Services, SharePoint Server 2010 et les produits apparentés sont conçus sur la plateforme commune de SharePoint Products and Technologies, les développeurs peuvent utiliser un jeu commun d’outils et de techniques de développement pour intégrer et développer tous les produits.
Architecture générale
Quatre composants principaux d’InfoPath Forms Services permettent de convertir, rendre et faire fonctionner des fichiers de modèles de formulaire (.xsn) dans un navigateur à peu près comme dans le client InfoPath :
IIS et modules ASP.NET de prise en charge : renvoient du code HTML au navigateur, lancent des demandes de fichier au Générateur de pages et au Convertisseur et transfèrent des informations de publication à traiter par le Générateur de pages.
Gestionnaire HTTP d'InfoPath Forms Services : transfère les demandes d'IIS et des modules ASP.NET de prise en charge et du Générateur de pages.
Convertisseur : convertit les fichiers de modèles de formulaire (.xsn) en modules de solution et en pages .aspx, met les données de solution en cache et transfère les fichiers convertis au Gestionnaire HTTP d’InfoPath Forms Services.
Générateur de pages : communique avec les sources de données externes, stocke et récupère les états de session, récupère les données et modèles de solution initiaux, traite les données du journal des événements de publication et renvoie les données à IIS et aux modèles ASP.NET de prise en charge en fonction de la demande du Gestionnaire HTTP d’InfoPath Forms Services.
Architecture d'exécution
Par défaut, si InfoPath est installé sur l’ordinateur à l’origine de la demande du formulaire, celui-ci est ouvert dans InfoPath. Lorsqu’un formulaire activé pour le navigateur est demandé et qu’InfoPath n’est pas installé sur l’ordinateur, InfoPath Forms Services redirige la demande vers la page FormServer.aspx et envoie au navigateur du code JScript pré-généré et des tableaux de données JScript propres à l’application. Le tableau de script côté client non modifiable est généré en deux étapes : lorsque le modèle de formulaire est converti et lorsque le formulaire est demandé. Il fonctionne d’une façon similaire à celle du code AJAX (Asynchronous JavaScript and XML) dans sa manière de gérer la génération d’HTML et la communication du serveur sur le client. Le tableau de script gère les tâches suivantes :
la génération et le rendu du code HTML en fonction du tableau JScript du serveur ;
la génération d'un journal des événements retraçant ce qui se passe sur le client lors du processus de publication sur le serveur ;
la validation des données ;
les calculs ;
les règles ;
la modification des actions, comme l'insertion ou la suppression de certaines parties du formulaire ;
la mise en forme conditionnelle.
Lorsque l’utilisateur entre des données dans le formulaire ou le met à jour, un journal des événements enregistre toutes les actions de l’utilisateur. Ce journal est renvoyé au serveur lors de la publication suivante sous la forme d’un tableau de données JScript. Le serveur répète ensuite les actions du journal sur les données XML d’origine et exécute les règles et autres logiques métier appropriées. Le serveur envoie ensuite au navigateur un tableau de données JScript mis à jour. Cette architecture client/serveur combinée permet au formulaire de fonctionner dans le navigateur sans avoir à communiquer avec le serveur pour chaque action de l’utilisateur. Toutefois, lorsque la communication avec le serveur est indispensable, le client et le serveur communiquent avec le tableau de données JScript du journal des événements pour optimiser le temps de réponse et mettre à jour le formulaire avec les modifications différentielles, au lieu d’échanger le formulaire entier et le code JScript pré-généré avec chaque demande.
Envoi de formulaires
L’envoi d’un formulaire est géré par le serveur pour le navigateur. Contrairement à l’envoi d’un formulaire à partir du client InfoPath, qui est un simple processus d’envoi XML, l’envoi d’un formulaire à partir du navigateur commence par l’envoi du journal des événements au serveur via XMLHTTP, après quoi le serveur relit le journal des événements et envoie le XML au destinataire final. Ce processus d’envoi en deux étapes peut présenter des problèmes d’authentification, communément appelé « problème du double saut », mais l’utilisation du proxy InfoPath Forms Services peut contribuer à résoudre ce problème. Pour plus d’informations sur l’utilisation du proxy, voir À propos de la connexion de données, de l'authentification et du mappage des accès de substitution.
Rendu et paramètres de requête
Les composants de rendu d’InfoPath Forms Services sont les pages FormServer.aspx et MobileFormServer.aspx, qui se trouvent respectivement dans les dossiers _layouts et _layouts/Mobile du serveur. Dans les cas où plusieurs serveurs WFE (Web Front-End) et un serveur de base de données forment une batterie, ces composants se trouvent sur le WFE.
Lorsqu’un modèle de formulaire basé sur le navigateur est rendu par la page FormServer.aspx, les données XML d’origine et le code HTML représentant le formulaire sont envoyés au navigateur, accompagnés des modules de solution JScript de prise en charge non modifiables. Ces modules gèrent les opérations côté client, telles que les calculs simples, la mise en forme conditionnelle et la validation des données. Ils gèrent également la communication des modifications incrémentielles des données XML avec le serveur. Les résultats de ces modifications sont ensuite utilisés dans les modules de solution JScript pour mettre à jour la page HTML représentant le formulaire, augmentant ainsi les performances en réduisant les publications de pages entières sur le serveur.
La gestion d’un modèle de formulaire basé sur le navigateur par la page MobileFormServer.aspx est similaire. Toutefois, le traitement côté client via les modules de solution JScript est absent. Davantage d’opérations du formulaire mobile requièrent une communication avec le serveur et chacune d’elles entraîne la publication d’une page entière. Au lieu de communiquer les modifications incrémentielles, les paires nom/valeur de chaque contrôle de la vue sont envoyées au serveur.
InfoPath Forms Services prend en charge les paramètres de requête pour contrôler le rendu d’un formulaire, son emplacement de sauvegarde, ainsi que la page vers laquelle un utilisateur est redirigé lors de la fermeture du formulaire. Pour plus d’informations sur l’utilisation des paramètres de requête, voir Procédure : utiliser des paramètres de requête pour appeler des formulaires InfoPath activés pour le navigateur.
Cycle de vie d'un modèle de formulaire
La figure 1 illustre les différents états possibles d’un modèle de formulaire dans InfoPath Forms Services :
Figure 1. Cycle de vie d’un modèle de formulaire
Pour plus d’informations sur le cycle de vie d’un modèle de formulaire, voir Cycle de vie du développement et du déploiement d'un formulaire.
Convertisseur de modèle de formulaire
Lors de la conversion du formulaire, un fichier de modèle de formulaire (.xsn) est développé vers les fichiers qui le composent, comme le fichier manifest.xsf, les fichiers de schémas (.xsd) et les fichiers de vues (.xsl). Ces fichiers sont stockés sur le serveur et permettent de générer des scripts et d’autres composants nécessaires à InfoPath Forms Services pour rendre le formulaire dans le contrôle XmlFormView.