Vous pouvez ajouter un formulaire à un élément de recueil lorsque vous souhaitez rendre un formulaire disponible pour les utilisateurs.
Avant d'ajouter un formulaire, vous devez définir un modèle de formulaire. Pour plus d'informations sur la définition de formulaire, reportez-vous à la rubrique Définition d'un Modèle de formulaire.
Note : | |
Sélection des mécanismes de révision et d'envoi
Lorsque vous ajoutez un formulaire, vous devez spécifier les mécanismes de révision et d'envoi. Un mécanisme de révision fournit un stockage intermédiaire des données, ce qui vous permet d'ouvrir de nouveau un formulaire envoyé précédemment et de le modifier plus tard. Un mécanisme d'envoi fournit un stockage ou un traitement permanent des données et réinitialise les champs du formulaire à leur valeur par défaut à chaque ouverture du formulaire. Vous devez sélectionner au moins une des stratégies de mécanisme pour chaque formulaire :
Après avoir choisi une stratégie de mécanisme, vous devez sélectionner le type de mécanisme que vous souhaitez utiliser.
L'organigramme suivant explique comment définir les options de révision et d'envoi requises pour un formulaire.
Note : | |
Utilisation d'un mécanisme de révision uniquement
Si vous sélectionnez un mécanisme de révision, vous pouvez stocker les données intermédiaires du formulaire. La prochaine fois qu'un utilisateur ouvre un formulaire après l'avoir modifié, Content Server affiche les valeurs précédemment entrées et autorise l'utilisateur à les modifier. Les utilisateurs activent le mécanisme de révision en cliquant sur le bouton du formulaire qui transfère les données vers Content Server.
Utilisation d'un mécanisme d'envoi uniquement
Si vous sélectionnez un mécanisme d'envoi, vous pouvez stocker ou traiter les données finales du formulaire. Après qu'un utilisateur a modifié et envoyé un formulaire, la prochaine fois qu'un utilisateur ouvre le formulaire après l'avoir modifié et envoyé, Content Server réinitialise les champs et les autres éléments à leur valeur par défaut. Les utilisateurs peuvent activer le mécanisme d'envoi de plusieurs façons :
Si le Formulaire ne dispose d'aucun mécanisme de révision, l'activation s'effectue en cliquant sur le bouton du Formulaire permettant de transférer les données vers le serveur (généralement Enregistrer, Soumettre ou Appliquer).
Si le Formulaire dispose également d'un mécanisme de révision, l'activation s'effectue en cliquant sur le lien Envoyer de la colonne Actions.
Utilisation d'un mécanisme de révision et d'envoi
Si vous sélectionnez un mécanisme de révision et d'envoi, vous pouvez stocker ou traiter les données intermédiaires et finales du formulaire. Les utilisateurs activent le mécanisme de révision en cliquant sur le bouton du formulaire permettant de transférer les données vers le serveur (généralement Enregistrer, Soumettre ou Appliquer).
Note : | |
Sélection des types de mécanisme d'envoi et de révision
Selon vos privilèges et le modèle de formulaire sur lequel se base votre formulaire, vous pouvez sélectionner les types de mécanisme de révision et de stockage suivants :
Utilisation du mécanisme Versions de Content Server
Le mécanisme Versions de Content Server peut être utilisé comme mécanisme de révision pour tout formulaire. Ce mécanisme permet de stocker les données du formulaire sous forme de versions du formulaire dans la base de données Content Server. Vous pouvez accéder aux données enregistrées du formulaire via la page Infos sur les versions du formulaire (tout comme vous accédez aux versions du document), mais vous ne pouvez pas y accéder via des rapports LiveReport ou des applications externes. Content Server indexe les données enregistrées du formulaire ; elles peuvent donc être recherchées en utilisant la recherche Content Server. Cependant, vous devez disposer de l'autorisation Gérer pour le Formulaire afin de voir les données du Formulaire sur la page Résultat de recherche.
Vous trouverez dans les rubriques Exemple de formulaire de demande de déplacement et Exemple de formulaire de note de frais une démonstration du mécanisme Versions.
Utilisation du mécanisme Table SQL
Le mécanisme de révision Table SQL est disponible lorsque les deux conditions suivantes sont remplies :
le formulaire est basé sur un modèle associé à une table de base de données ;
vous disposez du privilège d'utilisation Stockage permettant la révision de formulaires.
Ce mécanisme permet de stocker les données du formulaire sous forme d'enregistrements dans une table de base de données Content Server. La table est associée au modèle de formulaire sur lequel est basé le formulaire. Vous pouvez accéder aux données enregistrées du Formulaire via des rapports LiveReport et des applications externes ainsi que via la page Infos sur les versions du formulaire (tout comme vous accédez aux versions du document). Content Server indexe les données enregistrées du formulaire ; elles peuvent donc être recherchées en utilisant la recherche Content Server. Cependant, vous devez avoir l'autorisation de gestion pour le formulaire pour afficher les données de ce formulaire.
Le mécanisme Table SQL est illustré dans Exemple de formulaire de feuille de présence.
Utilisation du mécanisme Lancer le workflow
Le mécanisme Lancer le workflow peut être utilisé comme mécanisme d'envoi pour tout formulaire. Lorsqu'un utilisateur envoie un formulaire qui utilise le mécanisme Lancer le workflow, Content Server lance une instance de workflow basée sur un schéma de workflow que vous associez au formulaire. Le mécanisme permet de stocker les données du formulaire dans le lot de travail du schéma de workflow. Les données du formulaire sont uniquement accessibles dans le cadre du workflow. Pour plus d'informations sur les schémas de workflow, consultez
Pour que le mécanisme Lancer le workflow fonctionne correctement, vous devez procéder de la façon suivante dans le schéma de workflow :
Pour plus d'informations sur l'activation et l'ajout de formulaires au lot de travail du schéma de workflow, reportez-vous à la rubrique
Par défaut, lorsque les utilisateurs lancent un workflow, ils sont invités à lire les instructions et à compléter les tâches optionnelles avant le début du workflow. Si vous souhaitez que Content Server lance le workflow associé à un formulaire sans demander d'action lorsqu'un utilisateur envoie le formulaire, vous devez procéder de la manière suivante dans l'étape de départ du schéma de workflow :
Pour plus d'informations sur la définition de l'étape de départ, reportez-vous à
Vous pouvez également créer une vue personnalisée de formulaire et la modifier afin de fournir un accès à la page Pièces jointes du workflow. Si le workflow lancé par le formulaire comprend des pièces jointes, vous pouvez autoriser les utilisateurs du formulaire à accéder aux pièces jointes du workflow directement à partir du formulaire. Les utilisateurs du formulaire peuvent effectuer les mêmes tâches à partir de la page Pièces jointes du workflow, par exemple pour visualiser et ajouter des documents, que s'ils avaient navigué dans la page Pièces jointes du workflow. Après que l'utilisateur a rempli le formulaire et l'a renvoyé, les documents modifiés ou ajoutés à la zone Pièces jointes sont copiés sur la page Pièce jointe du workflow et sont accessibles dans le workflow. Pour plus d'informations sur l'ajout d'un bouton personnalisé ou l'affichage des pièces jointes dans un cadre incorporé au formulaire, reportez-vous à la rubrique Utilisation des exemples de Forms.
Vous trouverez dans les rubriques Exemple de formulaire de demande de congés et Exemple de formulaire de note de frais une démonstration du mécanisme Lancer le workflow.
Utilisation du mécanisme Enregistrement révisable par l'utilisateur (Content Server)
Le mécanisme Enregistrement révisable par l'utilisateur (Content Server) peut être utilisé comme mécanisme d'envoi pour tout formulaire. Ce mécanisme permet de stocker les données du formulaire sous forme de versions du formulaire dans la base de données Content Server. Les données de formulaire envoyées sont stockées pour chaque utilisateur qui remplit le formulaire. L'utilisateur peut récupérer les données stockées ultérieurement et ensuite les modifier. Cependant, OpenText recommande d'utiliser l'option Enregistrement révisable par l'utilisateur (SQL) en tant que mécanisme d'envoi car le mécanisme Enregistrement révisable par l'utilisateur (Content Server) risque de renvoyer une erreur si plusieurs utilisateurs tentent d'envoyer le formulaire.
Vous trouverez dans la rubrique Exemple de formulaire de profil de déplacement une illustration du mécanisme Enregistrement révisable par l'utilisateur (Content Server).
Enregistrement révisable par l'utilisateur (SQL)
Le mécanisme d'envoi Table SQL est disponible lorsque les deux conditions suivantes sont remplies :
le formulaire est basé sur un modèle associé à une table de base de données ;
vous disposez du privilège d'utilisation Stockage permettant la révision de formulaires.
Le mécanisme Enregistrement révisable par l'utilisateur (SQL) peut être utilisé comme mécanisme d'envoi pour tout formulaire. Ce mécanisme permet de stocker les données du formulaire sous forme d'enregistrements dans une table de base de données Content Server. La table est associée au modèle de formulaire sur lequel est basé le formulaire.
Les données enregistrées du formulaire sont accessibles via les rapports LiveReport et les applications externes. Content Server indexe les données enregistrées du formulaire ; elles peuvent donc être recherchées en utilisant la recherche Content Server. Cependant, vous devez disposer de l'autorisation Gérer pour le Formulaire afin de voir les données du Formulaire sur la page Résultat de recherche. Les données de formulaire envoyées sont stockées pour chaque utilisateur qui remplit le formulaire. L'utilisateur peut récupérer les données stockées ultérieurement et ensuite les modifier.
Vous trouverez dans les rubriques Exemple de formulaire d'enquête et Exemple de formulaire d'enquête une illustration du mécanisme Enregistrement révisable par l'utilisateur (SQL).
Mécanisme d'envoi de formulaires
WebReports fournit un mécanisme d'envoi de formulaires, Lancer WebReport,similaire à la Table SQL. Leur principale différence réside dans le fait que lorsque les données sont stockées dans la table SQL, la clé primaire, ou SEQ, est identifiée et transmise à un WebReport lancé juste après l'envoi du formulaire.
Les données stockées dans chaque méthode sont interchangeables. En d'autres termes, il est possible de modifier le mécanisme d'envoi de formulaires entre Lancer WebReport et Table SQL sans affecter les données existantes.
Lancer WebReport nécessite uniquement deux options de configuration qui sont définies sur l'onglet Spécifique du formulaire :
Vous devez définir le WebReport à exécuter immédiatement après l'envoi du formulaire.
Vous devez déterminer si le WebReport doit être exécuté de façon transparente ou présenté à l'utilisateur après l'envoi du formulaire.
Dans chaque cas, le SEQ du formulaire venant d'être envoyé est disponible en tant que paramètre [LL_REPTAG_&SEQ /]. Il peut être utilisé dans le WebReport en tant que clé afin de rechercher des données supplémentaires associées au formulaire venant d'être envoyé. Il peut aussi être transmis en tant que paramètre vers un sous-rapport WebReport séparé dont la destination est définie sur Renseigner le formulaire. Des tables relationnelles de base peuvent alors être gérées dans une série de WebReports, car l'utilisation d'un WebReport pour exporter des données vers un formulaire entraîne le lancement d'un autre WebReport lorsque le mécanisme d'envoi est défini correctement.
Le mécanisme d'envoi de formulaires Lancer WebReport n'est pas visible tant que l'option Gérer la table relationnelle n'a pas été utilisée afin de configurer une table SQL associée.
Les balises de formulaire de type [LL_FormTag_1_1_3_1 /] sont prises en charge uniquement lorsque Afficher l'objet WebReport n'est pas sélectionné. Vous pouvez avoir besoin de sélectionner Afficher l'objet WebReport si vous devez par exemple afficher des données venant d'être envoyées. Dans ce cas, vous devez utiliser la balise [LL_REPTAG_&SEQ /] en tant que paramètre d'un sous-rapport WebReport et/ou de sous-rapport LiveReport pour récupérer les données envoyées.