Architecture

AEM forms is an application deployed into AEM as a set of packages, supported by a JEE-based Forms Workflows add-on that provides advanced functionality, such as correspondence handling and process-management. AEM packages contain services (API providers) and servlets or JSPs (providing front-end and REST API functionality). While services are deployed into the AEM OSGI container, servlets/JSPs are managed by the AEM Sling framework.

The following diagram depicts the architecture AEM forms. 


View Full Size

The architecture for AEM forms includes the following components:

  • Core AEM services: Basic services provided by AEM to a deployed application. These include a JCR-compliant content repository, an OSGI service container, a workflow engine, and so on. These services are available to AEM forms application but they are not provided by AEM forms packages. The services are an integral part of the overall stack as they are used by various AEM forms components.
  • Digital Asset Management (DAM): An AEM application that serves as a foundation for AEM forms because forms and other related resources are modeled as DAM assets. As with core AEM services, DAM is not provided with AEM forms packages.
  • Forms common services: Provide common functionalities to various AEM forms components. Except for Document Manager, these services are for internal use by Adobe components and are not intended for use or customization.
  • Forms services: Provide forms-related functionality, such as form rendition, combining PDF documents generated from forms, and so on. Many of these services are publicly available for consumption by custom code co-deployed in AEM.
  • Web layer: JSPs or servlets, built over common and forms services, which provide the following functionalities:
    • Authoring frontend: A forms authoring and forms management user interface for authoring and managing forms.
    • Form publishing frontend: An end user facing interface for use by the end users of the AEM forms (for example, citizens accessing a government website). This provides form rendition and submission functionalities.
    • REST APIs: JSPs and servlets export a subset of forms services for remote consumption by HTTP-based clients, such as the forms mobile SDK.

Apart from the AEM-based components, AEM forms includes a (JEE-based) Forms Workflows add-on which provides specific supporting services to the AEM-based components:

  • Integrated user management: Allows users of the Forms Workflows add-on to be recognized as AEM users as well. This is required for scenarios where single sign-on between AEM and the add-on is required (For example, HTML workspace).
  • Asset hosting: The Forms Workflows add-on can serve certain assets (For example, HTML5 forms) rendered on AEM.
  • Correspondence handling: For Correspondence Management, the Forms Workflows add-on provides services for letter rendering, and workflows hosted by its workflow engine for handling letter submission.

In addition to the supporting services, the Forms Workflows add-on can also be used by AEM forms customers for their advanced use-cases, such as complex form-related workflows, workspaces and task management, and so on.

Not all forms can be authored using the AEM Forms authoring user interface. Such forms need to be designed using the stand-alone Forms Designer utility, saved to local disk, and then uploaded individually or as a zip file to AEM Forms Manager. Alternatively, for scenarios where AEM and the Forms Workflows add-on are co-located as applications deployed within the same JEE server, forms can be designed as application assets deployed into the add-on, and from there be automatically synchronized to AEM Forms Manager.

Topology

The deployment topology for AEM forms includes elements that facilitate authoring of forms by form designers, viewing and submission of forms by end users, and processing and storage of submitted form data. The following diagram depicts these logical elements.

Author: Instance(s) of AEM forms running in standard Author run mode intended for use by internal users (form and letter designers). It enables the following functionalities:

  • Form authoring and management: Form designers can create and edit adaptive forms, upload other types of forms created externally (for example, forms created in Adobe LiveCycle Designer), and manage forms using the Forms Manager console.
  • Form publishing: Forms hosted on Author instance can be published to other elements in the topology (Processing and Publish) to perform runtime operations. Form publishing uses replication features provided by AEM. It is recommended that a replication agent is configured on Author for pushing manually published forms to Processing, and another replication agent is configured on Processing with the On Receive trigger enabled to automatically replicate the received forms to Publish.
  • Letter authoring/publishing (for customers using Correspondence Management): Similar to form authoring/publishing.

Publish: Instance(s) AEM forms running in the standard Publish run mode for use by end users of form-based applications (for example, users accessing the website and submitting forms). It enables the following functionalities:

  • Form rendition and submission for end users.
  • Transport of raw, submitted form data to the Processing element for further processing and storage in the final system-of-record. The default implementation provided in AEM forms achieves this using reverse-replication capability provided by AEM.
  • Letter rendition and submission (for customers using Correspondence Management): Publish renders letters for end users, and sends the data submitted by the users to the Forms Workflows add-on for processing.

Processing: Instance(s) of AEM forms running in Author run mode with no users assigned to the forms-manager group. The latter is to ensure that form authoring and management activities are not done on Processing, and occur only on Author. Processing enables the following functionalities:

  • Processing of raw form data arriving from Publish: This is achieved primarily via AEM workflows that trigger when the data arrives. The workflows may choose to process the data entirely within themselves and then save results to a suitable data store, or may delegate some or all of the processing to AEM forms Workflows add-on in complex scenarios where advanced process management capabilities are required during data processing.
  • Secure storage of form data: Processing provides a behind-the-firewall repository for raw form data which is isolated from users. Neither form designers on Author nor end users on Publish can access this repository. It also serves as a secure repository for the final processed data in case the customer chooses not to use a separate third-party data store.
  • HTML Workspace hosting (for customers using HTML Workspace): Processing hosts the workspace frontend for use by internal users and renders the forms associated with the user tasks.

Processing is configured to run in the Author run mode for the following reasons:

  • It enables reverse-replication of raw form data from Publish.
  • AEM Workflows, which are the primary means of processing raw form data arriving from Publish, are recommended to run on an Author-style system for older TarMK-based deployments.

AEM forms Workflows add-on: A JEE-based add-on which is required by specific components of AEM Forms, and can also be used by customers for use cases involving more complex processing of form data:

  • Advanced form data processing: The add-on can be utilized for processing raw form data (and saving the results to a suitable data store) in complex use-cases where advanced process-management capabilities are required. It can be invoked from Processing using the LiveCycle-AEM connector component. This is only relevant for use-cases where AEM workflows running on Processing are not fully capable of processing raw form data entirely.
  • Correspondence handling (for customers using Correspondence Management): The add-on handles rendering of letters and processing of data in submitted letters.
  • HTML workspace support (for customers using HTML workspace): The add-on enables single sign-on with Processing, serves certain assets rendered on Processing and handles submission of forms rendered within the HTML workspace.

Form Data Store: A third-party data store used for storing the final processed form/letter data. This is also an optional element in the topology, and you may choose to use the repository on Processing as the final system-of-record.

Next, let us look at some recommendations for mapping logical topology elements onto physical machines.

Recommended physical topology when upgrading from Livecycle ES4

It is recommended that Author is co-deployed with the development Forms Workflows add-on on the same JEE server instance/cluster, and the same should be done for Processing and production Forms Workflows add-on. It closely mirrors most existing LiveCycle ES4 deployments. Also, if you are using HTML Workspace, co-deployment of AEM and the Forms Workflows add-on is a requirement.

If you are upgrading from LiveCycle ES4, you may also run Publish in stand-alone mode instead of running it within a JEE server.

Recommended physical topology for new or existing AEM customers

Customers not using HTML Workspace

For new or existing AEM customers who are not planning to use HTML Workspace, it is recommended that Author and Processing are run in stand-alone mode outside the JEE servers hosting the Forms Workflows add-ons. Most existing AEM customers run AEM in stand-alone mode. Stronger decoupling of AEM and the Forms Workflows add-on also has a few other advantages, such as easy maintenance of stand-alone units and the ability to do away with the requirement of JEE servers if customers have no use case requiring the Forms Workflows add-on.

Customers using HTML workspace

HTML Workspace currently requires AEM and the Forms Workflows add-on to be co-deployed on the same JEE server. Hence, for new or existing AEM customers planning to use HTML workspace, the topology needs to be enhanced by adding a JEE-based Author co-located with the development Forms Workflows add-on (for testing HTML Workspace), and a JEE-based Processing co-located with the production Forms Workflows add-on (for production HTML Workspace operation). Assets such as adaptive forms rendered within HTML Workspace need to be authored on the JEE-based Author and sent to the JEE-based Processing using a separate replication agent.

Recommended physical topology for basic Forms customers

Basic forms customers who are not using Workspace or Correspondence Management, and who have custom form data submission and post-processing mechanisms in place, can utilize a simplified topology which is more in line with a standard AEM deployment.

Note:

The recommended topology for basic forms customers is a standard author-publish AEM deployment. The Processing server is not required as they are not using Workspace or Correspondence Management. Also, the form data is being sent directly to customer's own data store using a custom form submission handler.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License  Twitter™ and Facebook posts are not covered under the terms of Creative Commons.

Legal Notices   |   Online Privacy Policy