Vous consultez actuellement l'aide de la version:

Architecture

AEM Forms est une application déployée dans AEM en tant qu’ensemble de modules pris en charge par un module complémentaire de processus des formulaires basé sur JEE qui offre des fonctionnalités avancées telles que le post-traitement de la correspondance et la gestion des processus. Les packages AEM contiennent des services (fournisseurs d’API), qui sont déployés dans le conteneur AEM OSGI, et les servlets ou JSP (octroi d’entrée et fonctionnalités API REST) gérés par la structure Sling AEM. Le diagramme suivant illustre cette configuration.

Architecture_Small
Cliquez pour ouvrir la vue agrandie dans un nouvel onglet

L’architecture d’AEM Forms comprend les composants suivants :

  • Services AEM principaux : services de base fournis par AEM à une application déployée. Ces services comprennent un référentiel de contenu compatible JCR, un conteneur de service OSGi, un moteur de processus, etc. Ces services sont accessibles par l’application d’AEM Forms mais ne sont pas fournis par les modules d’AEM Forms. Les services font partie intégrante de la pile globale dans la mesure où ils sont utilisés par différents composants d’AEM Forms.
  • Services communs de formulaires : ils proposent des fonctionnalités communes à plusieurs composants d’AEM Forms. A l’exception du Gestionnaire de documents, ces services sont à réservés à un usage interne par les composants Adobe et ne sont pas destinés à des fins d’utilisation ou de personnalisation.
  • Services de formulaires : fournissent des fonctionnalités liées aux formulaires, telles que le rendu de formulaire, la combinaison de documents PDF générés à partir de formulaires, etc. La plupart de ces services sont disponibles publiquement à des fins d’utilisation par le code personnalisé co-déployé dans AEM.
  • Couche Web : JSP ou servlets, reposant sur les services communs et de formulaires, qui fournissent les fonctionnalités suivantes :
    • Interface utilisateur frontale de création : interface utilisateur de création et de gestion de formulaires pour créer et gérer des formulaires.
    • Interface utilisateur frontale de publication de formulaire : interface utilisateur destinée à être utilisée par les utilisateurs finaux d’AEM Forms (par exemple, des citoyens accédant à un site Web gouvernemental). Elle fournit des fonctionnalités de rendu et d’envoi de formulaire.
    • API REST : les JSP et servlets exportent un sous-ensemble de services de formulaires à des fins d’utilisation distante par des clients HTTP appropriés, comme le kit SDK mobile des formulaires.

Outre les composants basés sur AEM, AEM Forms comprend un module complémentaire de processus des formulaires (basé sur JEE) qui fournit des services spécifiques de prise en charge aux composants AEM :

  • Gestion intégrée des utilisateurs : permet aux utilisateurs du module complémentaire de processus des formulaires d’être également reconnus en tant qu’utilisateurs AEM. Ceci est nécessaire dans les cas où une authentification unique entre AEM et le module supplémentaire est requise (dans le cas de l’espace de travail HTML par exemple).
  • Hébergement d’actif : les flux de travaux de formulaires ajoutés peuvent servir certains fichiers (par exemple des formulaires HTML5) rendus sur AEM.
  • Post-traitement de correspondance : pour les utilisateurs de Correspondence Management, les flux de travaux de formulaires ajoutés peuvent éventuellement effectuer un post-traitement des lettres reçues via des flux hébergés sur le moteur de flux.

Outre les services de support, le module complémentaire de processus des formulaires ajoutés peut également être utilisé par les clients de AEM Forms pour des utilisations avancées, impliquant par exemple des flux de travail et des espaces de travail complexes liés aux formulaires, la gestion des tâches, la sécurité des documents, etc.

Tous les formulaires ne peuvent être créés via à l’interface utilisateur de création d’AEM Forms. Les formulaires de ce type doivent être conçus avec l’utilitaire autonome de conception de formulaires, enregistrés sur le disque local, puis téléchargés individuellement ou dans un fichier ZIP dans le gestionnaire d’AEM Forms. Dans les cas où AEM et le module complémentaire de processus des formulaires sont colocalisés en tant qu’applications déployées sur le même serveur JEE, les formulaires peuvent être conçus en tant que ressources d’application déployées dans le module complémentaire, et ainsi être automatiquement synchronisés dans le gestionnaire d’AEM Forms.

Topologie

La topologie de déploiement d’AEM Forms contient des éléments qui facilitent la création de formulaires par les concepteurs de formulaires, l’affichage et l’envoi de formulaires par les utilisateurs finaux et le traitement et le stockage des données de formulaire envoyées. Le diagramme ci-après illustre ces éléments logiques.

Topology_Small
Cliquez pour ouvrir la vue agrandie dans un nouvel onglet

Auteur : instances d’AEM Forms s’exécutant en mode d’exécution Auteur standard destinées à être utilisées par les utilisateurs internes (concepteurs et auteurs de formulaires). L’élément Publier active les fonctionnalités suivantes :

  • Création et gestion de formulaires : les concepteurs de formulaires peuvent créer et modifier des formulaires adaptatifs, télécharger d’autres types de formulaires créés en externe (par exemple dans Adobe LiveCycle Designer) et gérer des formulaires à l’aide de la console du gestionnaire de formulaires.
  • Publication de formulaires : les formulaires hébergés sur l’instance Auteur peuvent être publiés sur d’autres éléments de la topologie (Traitement et Publier) pour effectuer les opérations d’exécution. La publication de formulaires utilise les fonctionnalités de réplication fournies par AEM. Il est recommandé qu’un agent de réplication soit configuré sur l’élément Auteur pour transférer manuellement les formulaires publiés vers l’élément Traitement et qu’un autre agent de réplication soit configuré sur l’élément Traitement avec le déclencheur A réception activé afin de répliquer automatiquement les formulaires reçus sur l’élément Publier.
  • Création/publication de lettres (pour les utilisateurs de Correspondence Management) : similaire à la création/publication de formulaires.

Publier : instances d’AEM Forms s’exécutant en mode d’exécution Publier standard destinées à être utilisées par les utilisateurs finaux des applications de formulaires (par exemple, les utilisateurs accédant au site Web et envoyant des formulaires). L’élément Publier active les fonctionnalités suivantes :

  • rendu et envoi de formulaire pour les utilisateurs finaux ;
  • transmission des données de formulaire brutes envoyées à l’élément Traitement pour un traitement supplémentaire et le stockage dans le système d’enregistrements final. L’implémentation par défaut fournie dans AEM Forms effectue cette opération à l’aide de la fonctionnalité de réplication inverse fournie par AEM. Une implémentation alternative est également disponible pour transférer directement les données du formulaire au Traitement au lieu de l’enregistrer localement d’abord (cette dernière étape constituant pour l’activation par la réplication inverse). Les clients dont les problèmes de stockage des données potentiellement sensibles sur Publish peuvent procéder à cette implémentation alternative, car le traitement se trouve généralement dans une zone plus sécurisé.
  • Rendu et envoi de lettre (pour les utilisateurs de Correspondence Management) : Publish effectue le rendu des lettres pour les utilisateurs finaux, et traite les données dans les lettres envoyées en vue du stockage et du post-traitement. Pour la partie qui concerne le stockage, les données peuvent être enregistrées localement et répliquées inversement vers le Traitement (option par défaut), ou être transférées directement au Traitement (la dernière implémentation est utile pour les clients soucieux de la sécurité). Les données peuvent également être post-traitées par un flux de travail AEM ou un flux hébergé par les flux de travaux de formulaires ajoutés. Dans le cas de les flux de travaux AEM, le flux se déclenche toujours au moment du Traitement indépendamment du mécanisme par lequel les données y arrivent (réplication inverse ou transfert direct).

Traitement : instances d’AEM Forms s’exécutant en mode d’exécution Auteur sans utilisateurs affectés au groupe de gestionnaires de formulaires. Cela permet de s’assurer que les activités de création et de gestion de formulaires ne sont pas exécutées sur l’élément Traitement, mais uniquement sur l’élément Auteur. L’élément Traitement active les fonctionnalités suivantes :

  • Le traitement des données de formulaire brutes issues de Publier: cela s’effectue principalement via des flux de travaux AEM qui se déclenchent lorsque les données arrivent, qui traitent les données puis les enregistre dans mémoire de données appropriée.
  • Stockage sécurisé des données de formulaire : l’élément Traitement fournit un référentiel derrière le pare-feu pour les données de formulaire brutes qui sont également isolées des utilisateurs. Ni les concepteurs de formulaires sur l’élément Auteur, ni les utilisateurs finaux sur l’élément Publier n’ont accès à ce référentiel. Il sert également de référentiel sécurisé pour les données traitées finales au cas où le client choisirait de ne pas utiliser un magasin de données tiers distinct.
  • Le stockage et le post-traitement facultatif des données de correspondance issues de l’élément Publier. Le post-traitement facultatif est effectué par les flux de travaux AEM configurés pour les définitions correspondantes de lettres, et ces flux peuvent choisir d’enregistrer les données finales traitées dans une mémoire externe de données adéquate.
  • Hébergement de Workspace HTML (pour les utilisateurs de Workspace HTML) : le traitement héberge l’espace de travail frontal destiné aux utilisateurs internes et effectue le rendu des formulaires associés aux tâches de l’utilisateur.

L’élément Traitement est configuré pour s’exécuter en mode d’exécution Auteur pour les raisons suivantes :

  • Il assure la réplication inverse des données de formulaire brutes issues de l’élément Publier, qui sont une fonctionnalité requise par le gestionnaire de stockage de données par défaut.
  • Les flux de travaux AEM, qui sont le moyen principal de traiter les données de formulaires brutes provenant de l’élément Publier, sont recommandés pour s’exécuter sur un système de style Auteur pour les déploiements basés sur TarMK.

Module complémentaire de processus d’AEM Forms : un module complémentaire basé sur JEE requis par les éléments spécifiques d’AEM Forms. Peut également être utilisé par les clients pour des utilisations comprenant un traitement plus complexe de données de formulaires :

  • Traitement complémentaire avancé des données de formulaire ou de lettres : le module peut être utilisé pour traiter les données de formulaire brutes (et enregistrer les résultats dans une mémoire de données appropriée) dans les cas d’utilisations complexes où des fonctionnalités avancées de gestion de processus sont requises.
  • Prise en charge de Workspace HTML (pour les utilisateurs de Workspace HTML) : le module complémentaire permet l’authentification unique en mode Traitement, sert à certains actifs générés par le mode Traitement et gère l’envoi de formulaires générés dans Workspace HTML.

Banque de données de formulaire : banque de données tierce utilisée pour stocker les données traitées finales des formulaires ou lettres. Il s’agit aussi d’un élément facultatif dans la topologie Vous pouvez définir le référentiel dans le mode Traitement en tant que système d’enregistrement final.

Nous allons maintenant examiner quelques recommandations pour associer les éléments de la topologie logique aux ordinateurs physiques.

Topologie physique recommandée pour les nouveaux clients n’utilisant pas Workspace

Recommended-physical-topology-for-new-customers-not-using-Workspace_small
Cliquez pour ouvrir la vue agrandie dans un nouvel onglet

Pour les nouveaux clients qui ne prévoient pas d’utiliser l’application de l’espace de travail AEM Forms, il est recommandé que l’Auteur et le Traitement soient exécutés en mode autonome en dehors des serveurs JEE hébergeant les modules complémentaires de processus des formulaires. Un découplage plus fort d’AEM et du module complémentaire de flux de travaux de formulaires présente certains avantages tels que la possibilité de conserver ou de mettre à jour plus facilement chaque flux individuellement, d’éliminer les exigences pour les serveurs JEE si les clients ne font aucune utilisation nécessitant le module complémentaire de flux de travaux de formulaires, etc.

Notez que comme les Formulaires adaptatifs sont généralement des cas d’utilisation en ligne pour utilisateurs finaux et Correspondence Management sur intranet, deux configurations différentes de l’élément Publier sont représentés pour chaque scénario, l’un dans le réseau Extranet (pour les Formulaires adaptatifs) et un autre dans l’Intranet (pour Correspondence Management).

Il convient de noter que dans ce scénario, le module complémentaire de flux de travaux de formulaires est strictement facultatif et que son utilisation dépend uniquement des besoins du client.

Topologie physique recommandée pour les clients Forms de base

Les clients Forms de base qui n’utilisent pas Workspace ou Correspondence Management, mais qui utilisent des mécanismes personnalisés d’envoi et de post-traitement de données de formulaires, peuvent utiliser une topologie simplifiée plus conforme avec un déploiement AEM standard. Ceci est représenté dans le diagramme suivant :

Recommended-physical-topology-for-basic-Forms-customers_small
Cliquez pour ouvrir la vue agrandie dans un nouvel onglet

Notez que ce qui précède constitue à peu près une norme structurée de déploiement AEM auteur-publication. Le serveur de traitement n’est pas obligatoire ici car le client n’utilise pas Workspace ou Correspondence Management, et les données du formulaire sont également envoyées directement à la mémoire de données du client à partir d’un gestionnaire personnalisé d’envoi du formulaire.

Topologie physique recommandée pour les clients LiveCycle effectuant une mise à niveau ou de nouveaux utilisateurs de Workspace

Recommended-physical-topology-for-Livecycle-upgrade-customers-or-new-customers-using-Workspace_small
Cliquez pour ouvrir la vue agrandie dans un nouvel onglet

Il est recommandé que l’Auteur soit co-déployé avec des modules complémentaires de flux de travaux de formulaires sur la même instance de serveur ou de grappe JEE. Suivez le même déploiement pour le Traitement et modules complémentaires de flux de travaux de formulaires de production ajoutés. Pour la mise à niveau des clients de LiveCycle, cela reflète fidèlement ce dont ils disposent déjà. Et pour de nouveaux clients utilisant l’espace de travail HTML/Mobile, le co-déploiement d’AEM et du module complémentaire du flux de travaux de formulaires est nécessaire.

Notez que les clients peuvent également exécuter Publier en mode autonome et dans un serveur JEE, si nécessaire.

Traitement par lots

La version actuelle d’AEM Forms intègre plusieurs nouvelles fonctions, qui accélèrent la tâche de traitement des lots de fichiers importants. Le diagramme suivant illustre comment les clients peuvent générer des relevés PDF d’une longue série de fichiers de données d’entrée, et les imprimer pour les envoyer aux utilisateurs finaux :

Batching
Cliquez pour ouvrir la vue agrandie dans un nouvel onglet

Voici une description plus détaillée du flux d’exécution se produisant sur l’élément Traitement comme l’illustre le schéma ci-dessus :

  • Le lot de fichiers de données d’entrée est copié dans le dossier physique d’entrée.
  • Une tâche planifiée sous le filet de conduite de topologie du cluster de traitement prend les fichiers d’entrée pour le traitement. Cette tâche est activée et configurée pour analyser le dossier d’entrée via la nouvelle fonction du dossier de contrôle.
  • La tâche de numérisation répartit le lot de fichiers pour un traitement ultérieur entre les serveurs disponibles. Le traitement du fichier se produit via un script, un service, ou le flux que le client a spécifié pour ce dossier de contrôle.
  • Dans ce scénario particulier, le code de traitement de fichier utilise les nouvelles API de traitement par lots (et le PDFG sous-jacent) pour générer des fichiers PDF à partir de fichiers de données d’entrée, puis envoie les fichiers PDF générés à l’imprimante.
  • Les informations de mesures et d’échec de performances renvoyée par les API de traitement par lot sont transmises à la structure du dossier de contrôle, qui les enregistre dans le dossier de résultat/d’échecs du dossier de contrôle physique pour analyse manuelle ultérieure.

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne