Planifier une application pilotée par des formulaires

 

S’applique à : SharePoint Server 2010

Dernière rubrique modifiée : 2016-11-30

De nombreuses applications SharePoint Server contiennent des formulaires InfoPath. Un sous-ensemble de ces applications est en réalité piloté par un formulaire. En règle générale, ces applications pilotées par un formulaire partagent les caractéristiques suivantes :

  • Elles automatisent un processus d’entreprise, tel que le passage d’une commande ou l’évaluation des performances des employés.

  • Il existe une information structurée clé, dont les instances passent par différentes activités pour réaliser le processus d’entreprise.

Bien que chaque application pilotée par un formulaire soit unique, la structure présente dans ces applications est souvent commune sur le plan conceptuel. Si votre application est compatible avec cette conception commune, vous pouvez utiliser la conception présentée dans cet article et la modifier en fonction de vos besoins.

Cet article décrit une conception pour un type particulier d’application Microsoft SharePoint Server 2010 qui utilise des formulaires. Il n’explique pas comment concevoir d’autres types d’applications SharePoint Server ou comment concevoir les formulaires proprement dits. Pour plus d’informations sur la conception de formulaires Microsoft InfoPath 2010, voir Office.com (https://go.microsoft.com/fwlink/?linkid=187550&clcid=0x40C).

Dans cet article :

  • Structure d’une application pilotée par un formulaire

  • À propos de la planification d’une application pilotée par un formulaire

  • Identification de l’information clé

  • Utilisation d’une liste ou d’une bibliothèque de formulaires

  • Flux de travail

  • Sources de données supplémentaires

  • Portails

  • Résumé

Structure d’une application pilotée par un formulaire

Une application SharePoint Server complexe pilotée par un formulaire peut contenir les composants suivants :

  • Un site SharePoint dans lequel héberger l’application.

  • Un modèle de formulaire qui capture l’information clé. Le modèle de formulaire peut offrir différents affichages selon le groupe d’utilisateurs ou la phase du cycle de vie des informations.

  • Une bibliothèque ou une liste SharePoint dans laquelle stocker les instances du modèle de formulaire achevé (formulaires).

  • Un flux de travail qui dirige un élément à travers un processus d’entreprise. Le flux de travail démarre lorsqu’un formulaire est créé.

  • Des listes SharePoint qui contiennent des informations auxiliaires permettant de renseigner les champs du modèle de formulaire. Vous pouvez associer des formulaires et des flux de travail à ces listes pour gérer les informations qu’elles contiennent.

  • Des bases de données externes ou des applications cœur de métier qui fournissent des données pour le modèle de formulaire ou le flux de travail.

  • Une logique métier représentée sous la forme de règles de validation dans le modèle de formulaire ou dans le cadre du flux de travail.

  • Une page Web qui fait office de portail et qui permet aux utilisateurs de créer une instance du modèle de formulaire et d’afficher d’autres informations sur les formulaires. Il peut exister plusieurs portails pour différentes audiences.

Il n’est pas nécessaire que votre application épouse exactement cette structure. Certaines applications SharePoint Server pilotées par des formulaires ne contiennent pas tous ces composants, tandis que d’autres applications présentent de légères variantes, telles que l’existence de plusieurs flux de travail.

À propos de la planification d’une application pilotée par un formulaire courante

Pour concevoir un type courant d’application pilotée par un formulaire, vous déterminez d’abord l’information clé qui pilote le processus d’entreprise. Ensuite, vous déterminez s’il est nécessaire de stocker les informations dans une liste SharePoint ou dans une bibliothèque et définissez le flux de travail permettant de traiter les informations. Ensuite, vous déterminez les sources de données supplémentaires éventuellement requises. Enfin, vous concevez les portails par le biais desquels les utilisateurs accéderont à l’application.

Identification de l’information clé

La première étape de la planification d’une application pilotée par un formulaire consiste à déterminer l’information clé autour de laquelle l’application est articulée. Dans de nombreuses situations, l’information clé est évidente. Dans une application de support technique, par exemple, l’information clé est probablement une demande de service. Dans un processus d’évaluation des performances des employés, l’information clé est probablement un formulaire d’évaluation des performances. Dans un système d’achat, l’information clé est probablement une commande.

Identifiez l’information clé qui pilote le processus. Si l’information clé n’est pas évidente, envisagez les suggestions suivantes :

  • Si l’application est appelée à automatiser un processus existant, existe-t-il un document ou un fichier qui passe d’une personne à l’autre au fil du processus ? Ce document ou fichier est susceptible d’être l’information clé.

  • Un processus démarre-t-il lorsqu’un élément est créé ou lorsqu’un élément apparaît à un emplacement donné ? Cet élément pourrait être l’information clé.

  • L’information clé possède probablement une structure et peut croître ou évoluer au fil de son traitement. Par exemple, une commande contient le nom et l’adresse du client, une liste d’articles complète indiquant la quantité et le prix, ainsi que d’autres détails. Des informations supplémentaires telles qu’un numéro de suivi, sont ajoutées à la commande à mesure qu’elle est traitée.

  • Un statut évoluant dans le temps est probablement associé à l’information clé.

Si vous ne pouvez pas déterminer l’information clé qui pilote le processus, il est probable que la conception présentée dans cet article ne convienne pas pour votre application.

Lorsque vous implémentez l’application, vous créez un modèle de formulaire pour cette information clé. Ce modèle de formulaire est appelé « formulaire principal » tout au long de cet article.

Utilisation d’une liste ou d’une bibliothèque de formulaires

Déterminez si vous stockerez les instances du formulaire principal dans une liste SharePoint ou dans une bibliothèque de formulaires SharePoint Server.

Dans la mesure du possible, utilisez une liste. Une solution basée sur une liste est plus simple et plus efficace. Toutefois, dans certaines situations, une liste ne fonctionne pas. Si l’une des conditions suivantes est satisfaite, utilisez une bibliothèque de formulaires :

  • Vous devez conserver un historique des modifications apportées aux instances du formulaire.

  • Le formulaire principal contient des sections récurrentes, telles qu’un nombre arbitraire de réalisations dans le formulaire d’évaluation d’un employé.

  • Le formulaire principal possède des données imbriquées, telles qu’un formulaire de commande qui contient un article, pouvant lui-même posséder un code de produit, une quantité, une taille et un prix.

  • Le formulaire principal est appelé à contenir du code.

    Les situations dans lesquelles un formulaire peut contenir du code sont par exemple les suivantes :

    • Le formulaire comprend des boutons qui permettent d’exécuter des actions personnalisées.

    • La valeur d’un champ du formulaire repose sur une combinaison complexe d’autres valeurs du formulaire.

  • Les instances du formulaire principal seront signées numériquement.

  • Vous devez stocker les données relatives à chaque instance du formulaire principal au format XML.

Si vous stockez les instances du formulaire principal dans une liste, chaque champ du formulaire principal devient une colonne dans la liste, tandis que chaque instance du formulaire principal devient un élément de liste. Si vous stockez les instances du formulaire principal dans une bibliothèque de formulaires, chaque instance devient un document XML et les documents sont stockés dans la bibliothèque.

Flux de travail

Le processus d’entreprise démarre lorsque se produit un événement lié à une instance du formulaire principal. Souvent, la création d’une instance du formulaire principal proprement dit démarre le processus d’entreprise, mais d’autres événements, tels que la modification d’une instance du formulaire principal ou son affectation à une personne, peuvent également démarrer un processus.

Le processus d’entreprise dirige l’instance du formulaire principal vers les différentes personnes et les différents systèmes qui doivent effectuer des actions. Si le formulaire principal est une demande de service, par exemple, la création d’une demande de service peut démarrer un processus qui assigne la demande de service à un représentant du service afin qu’il interagisse avec la personne à l’origine de la demande. Le représentant du service peut effectuer différentes actions suivant l’issue de la discussion avec la personne à l’origine de la demande : par exemple, faire suivre la demande à un représentant principal, marquer la demande comme étant résolue, la faire suivre au département en charge des commandes si la personne à l’origine de la demande doit obtenir un article de remplacement, etc.

Identifiez les étapes et les points de décision impliqués dans le traitement d’une instance du formulaire principal. Cette séquence d’étapes est représentée dans SharePoint Server sous la forme d’un flux de travail. Pour plus d’informations sur les flux de travail, voir Planifier des flux de travail (SharePoint Server 2010).

Sources de données supplémentaires

Un modèle de formulaire peut récupérer des données de sources externes telles qu’une base de données, un service Web ou une liste SharePoint. Une utilisation courante de données externes consiste à renseigner une liste de valeurs valides pour un champ du modèle de formulaire, telle qu’une liste de centres de coût. Vous pouvez également utiliser une règle pour calculer la valeur d’un champ en fonction d’une combinaison de données externes et des valeurs d’autres champs. Par exemple, la valeur d’un champ « approbateur » peut être obtenue à l’aide d’une source de données externe permettant de rechercher le responsable de l’employé dont le nom a été entré dans le champ « soumis par ».

Identifiez les données externes auxquelles le formulaire principal aura accès. Pour chaque source de données externes, indiquez la provenance des données. Par exemple, les données sont-elles issues d’une liste SharePoint, d’une base de données SQL, d’un système LOB tel que SAP ou d’une autre source ?

Notes

Vous pouvez accéder aux données LOB directement à partir de listes SharePoint Server en créant un type de contenu externe. Pour plus d’informations sur la création de types de contenu externe, voir Vue d’ensemble de Business Connectivity Services (SharePoint Server 2010).

Pour toute liste SharePoint fournissant des données au formulaire principal, analysez la façon dont vous gérerez les données de la liste. Créerez-vous un formulaire pour la saisie de nouvelles données dans la liste ? Des flux de travail sont-ils requis pour la gestion des éléments de la liste ? Par exemple, si le formulaire principal utilise une liste de centres de coût, vous pouvez ajouter un flux de travail d’approbation à la liste.

Portails

Qui est appelé à utiliser l’application ? Existe-t-il différents rôles d’utilisateurs, dont les membres effectuent des actions ou affichent des informations spécifiques ? Si des utilisateurs de différents rôles sont appelés à effectuer différentes opérations avec l’application, envisagez la création d’un portail pour chaque rôle. Adaptez les actions et les informations disponibles dans chaque portail au rôle des utilisateurs qui recourent au portail.

Par exemple, dans une application d’évaluation des performances des employés, il existe probablement au moins trois rôles :

  • les employés, qui renseignent les formulaires d’évaluation des performances ;

  • les responsables, qui ajoutent des informations aux formulaires d’évaluation des performances et qui approuvent les évaluations des performances ;

  • les spécialistes des ressources humaines, qui créent des rapports et compilent les informations issues des évaluations des performances.

Les employés peuvent accéder à l’application d’évaluation des performances par le biais d’un portail des employés qui permet à chacun de créer un formulaire d’évaluation des performances et de déterminer si son évaluation des performances a été approuvée par son responsable. Les responsables peuvent accéder à l’application par le biais d’un portail des responsables qui affiche une liste de leurs employés indiquant si chaque employé a déjà soumis un formulaire d’évaluation des performances et comportant un lien qui permet d’ouvrir le formulaire d’évaluation des performances d’un employé. Les spécialistes des ressources humaines peuvent accéder à l’application par le biais d’un portail des ressources humaines qui affiche des statistiques récapitulatives sur le nombre de formulaires d’évaluation des performances approuvés, soumis, mais pas encore approuvés ou pas encore soumis.

Le type de portail le plus simple à créer est un affichage sur la liste SharePoint ou la bibliothèque dans laquelle les instances du formulaire principal sont stockées. Vous pouvez utiliser un filtre ou appliquer une mise en forme conditionnelle pour personnaliser l’affichage en fonction de l’utilisateur.

Vous pouvez également concevoir une page Web personnalisée pour chaque rôle d’utilisateur et attribuer à chaque utilisateur l’URL appropriée vers le rôle correspondant afin qu’il puisse accéder à l’application. Dans les pages Web des portails, vous pouvez inclure certains des éléments suivants :

Résumé

Si votre application présente des caractéristiques reprises dans la plupart des sections précédentes, vous pouvez probablement implémenter l’application en suivant le paradigme d’une application pilotée par un formulaire. Créez un site SharePoint destiné à héberger l’application. Créez un modèle de formulaire pour le formulaire principal, créez une liste ou une bibliothèque dans laquelle stocker les instances du formulaire principal et associez le modèle de formulaire à la liste ou bibliothèque. Ajoutez un flux de travail déclenché lorsqu’un nouveau formulaire est ajouté à la liste ou bibliothèque. Créez et remplissez toute liste supplémentaire requise pour fournir des données au modèle de formulaire. Créez un ou plusieurs portails par le biais desquels les utilisateurs interagiront avec l’application.

See Also

Concepts

À propos des formulaires dans SharePoint Server 2010
Administration des formulaires InfoPath (SharePoint Server 2010)