Architecture

AEM Forms on JEE constitue 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 la gestion de la correspondance et des processus. Les modules AEM contiennent des services (fournisseurs d’API) et des servlets ou JSP (qui fournissent des fonctionnalités frontales et d’API REST). Les services sont déployés dans le conteneur AEM OSGI, mais les servlets/JSP sont gérés par la structure Sling AEM.

Le diagramme suivant illustre l'achitecture d’AEM Forms on JEE. 


Vue plein écran

L’architecture d’AEM Forms on JEE 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. Ils 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.
  • Gestion des actifs numériques (DAM) : application AEM qui sert de base pour AEM Forms, car les formulaires et les autres ressources associées sont modélisés en tant que ressources de gestion des actifs numériques. A l’instar des services AEM principaux, la gestion des actifs numériques n’est pas fournie dans les modules d’AEM Forms.
  • Services communs de formulaires : fournissent 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 basés sur 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 Workspace HTML par exemple).
  • Hébergement de ressources : Les modules complémentaires de processus des formulaires peuvent servir à certaines ressources (les formulaires HTML5 par exemple) générés sur AEM.
  • Gestion de la correspondance : Pour Correspondence Management, le module complémentaire de processus des formulaires fournit des services pour le rendu des lettres ainsi que des flux de travail hébergés par le moteur de processus pour gérer l’envoi des lettres.

En plus d’offrir des services de prise en charge, le module complémentaire de processus des formulaires peut également être utilisé par les clients d’AEM Forms pour des utilisations avancées, impliquant par exemple des flux de travail, des espaces de travail et une gestion des tâches complexes liés aux formulaires.

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 on JEE 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.

Auteur : instances d’AEM Forms on JEE 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 Auteur 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 on JEE 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 on JEE effectue cette opération à l’aide de la fonctionnalité de réplication inverse fournie par AEM.
  • Rendu et envoi de lettres (pour les utilisateurs de Correspondence Management) : la publication effectue le rendu des lettres pour les utilisateurs finaux et envoie les données envoyées par les utilisateurs au module complémentaire de processus des formulaires pour traitement.

Traitement : instances d’AEM Forms on JEE 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 :

  • Traitement des données de formulaire brutes en provenance de l’élément Publier : cela est effectué principalement par le biais de processus AEM qui se déclenchent lors de l’arrivée des données. Les processus peuvent choisir de traiter les données entièrement entre eux puis d’enregistrer les résultats dans un magasin de données approprié. Ils peuvent également choisir de déléguer une partie ou la totalité du traitement au module externe Processus d’AEM Forms dans des cas complexes où des fonctionnalités avancées de gestion de processus sont requises lors du traitement des données.
  • 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.
  • 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 active la réplication inverse des données de formulaire brutes de l’élément Publier.
  • Les processus 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 anciens déploiements TarMK.

Module complémentaire de processus d’AEM Forms : 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 formulaire :

  • Traitement avancé des données de formulaire : le module complémentaire peut être utilisé pour traiter les données de formulaire brutes (et enregistrer les résultats dans une banque de données adaptée) dans les cas d’utilisation complexes où des fonctionnalités avancées de gestion de processus sont requises. Il peut être appelé par l’élément Traitement à l’aide du composant connecteur LiveCycle-AEM. Ceci ne s’applique qu’aux utilisations où les processus AEM exécutés en mode Traitement ne sont pas complètement capables de gérer toutes les données de formulaire brutes.
  • Gestion de correspondance (pour les utilisateurs de Correspondence Management) : le module complémentaire effectue le rendu des lettres et le traitement des données dans les lettres envoyées.
  • Prise en charge de Workspace HTML (pour les utilisateurs de Workspace HTML) : le module complémentaire permet l’authentification unique en mode Traitement, sert à certaines ressources générées 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 lors de la mise à niveau de LiveCycle ES4

Il est recommandé de co-déployer le mode Auteur et le module complémentaire de processus des formulaires de développement sur la même instance/grappe de serveur JEE. Il en va de même pour le mode Traitement et le module complémentaire de processus des formulaires de production. Cela reflète fidèlement la plupart des déploiements existants de LiveCycle ES4. En outre, si vous utilisez Workspace HTML, le co-déploiement d’AEM et du module complémentaire de processus des formulaires est requis.

Si vous effectuez une mise à niveau de LiveCycle ES4, vous pouvez également exécuter Publier en mode autonome au lieu de l’exécuter dans un serveur JEE.

Topologie physique recommandée pour les nouveaux clients ou clients existants AEM

Clients n’utilisant pas Workspace HTML

Pour les nouveaux clients ou clients existants AEM n’ayant pas prévu d’utiliser Workspace HTML, il est recommandé d’exécuter Auteur et Traitement en mode autonome en dehors des serveurs JEE hébergeant les modules complémentaires de processus des formulaires. La plupart des clients AEM existants exécutent AEM en mode autonome. Un découplage plus fort d’AEM et du module complémentaire de processus des formulaires comporte également quelques autres avantages, tels que l’entretien facile des unités autonomes et la possibilité d’éliminer les exigences des serveurs JEE si les clients n’ont aucune utilisation nécessitant le module complémentaire de processus des formulaires.

Clients utilisant Workspace HTML

Workspace HTML requiert actuellement le co-déploiement d’AEM et du module complémentaire de processus des formulaires sur le même serveur JEE Par conséquent, pour les nouveaux clients ou clients existants AEM ayant prévu d’utiliser Workspace HTML, la topologie doit être améliorée en ajoutant un mode Auteur basé sur JEE colocalisé avec le module complémentaire de processus des formulaires de développement (pour tester Workspace HTML) et en ajoutant un mode Traitement basé sur JEE colocalisé avec le module complémentaire de processus des formulaires de production (pour les opérations de production de Workspace HTML). Les ressources telles que les formulaires adaptatifs générés dans Workspace HTML doivent être créées en mode Auteur basé sur JEE et envoyées en mode Traitement basé sur JEE via un agent de réplication distinct.

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