You're viewing help content for version:

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 functionalities such as correspondence post-processing and process-management. AEM packages contain both services (API providers), which are deployed into the AEM OSGI container, and servlets or JSPs (providing both front-end and REST API functionality) managed by the AEM Sling framework. The following diagram depicts this set-up.

Architecture_Small
Click to open enlarged view in a new tab

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.
  • Forms common services: Provide common functionalities to various AEM Forms components. Except for Document Manager and Watch-Folder support, 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 rendition and submission 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 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 assets (for example, HTML5 forms) rendered on AEM.
  • Correspondence post-processing: For customers using Correspondence Management, the Forms Workflows add-on can optionally post-process submitted letters via workflows hosted on its workflow engine.

In addition, the Forms Workflows add-on can be used by AEM Forms customers for their advanced use-cases, such as complex form-related workflows, workspaces and task management, document security, 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.

Topology_Small
Click to open enlarged view in a new tab

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 Processing for further processing and storage in the final system-of-record. The default implementation provided in AEM Forms achieves this using the reverse-replication capabilities provided by AEM. An alternative implementation is also available for directly pushing the form data to Processing instead of saving it locally first (the latter being a pre-requisite for reverse-replication to activate). Customers having concerns about storage of potentially sensitive data on Publish can go in for this alternative implementation, since Processing typically lies in a more secure zone.
  • Letter rendition and submission (for customers using Correspondence Management): Publish renders letters for end-users, and handles the data in submitted letters for further storage and post-processing. For the storage part, the data can either be saved locally and reverse-replicated to Processing (the default option), or pushed directly to Processing (the latter implementation is useful for security-conscious customers). The data can also be optionally post-processed by an AEM workflow or a workflow hosted by the Forms Workflows add-on. In the case of AEM workflows, the workflow always triggers on Processing regardless of the mechanism by which the data arrives there (reverse-replication or direct push).

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 which trigger when the data arrives, process the data and then save the data to a suitable data-store.
  • 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.
  • Storage and optional post-processing of correspondence data arriving from Publish. The optional post-processing is performed by AEM workflows configured for the corresponding letter definitions, and these workflows may choose to save the final processed data into a suitable external 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, which is a feature required by the default data storage handler.
  • 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 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 additional form/letter data processing: The add-on can be utilized for additionally processing form/letter data (and saving the results to a suitable data store) in complex use-cases where advanced process-management capabilities are required.
  • 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 for new customers not using Workspace

Recommended-physical-topology-for-new-customers-not-using-Workspace_small
Click to open enlarged view in a new tab

For new customers who are not planning on using AEM Forms workspace or AEM Forms workspace app, it is recommended that Author and Processing be run in standalone mode outside the JEE servers hosting the Forms Workflows add-ons. Stronger decoupling of AEM and the Forms Workflows add-on has a few advantages such as the ability to more easily maintain/update each individually going forward, the ability to do away with the requirement for JEE servers if customers have no use-cases requiring the Forms Workflows add-on, etc.

Please note that since Adaptive Forms are typically an internet-based end-user use-case, while Correspondence Management is an intranet-based internal-user use-case, two different Publish setups are depicted for each scenario, one within the extranet (for Adaptive Forms) and one within the intranet (for Correspondence Management).

It should be noted that in this scenario, the Forms Workflows add-on is strictly optional and its usage depends solely on the customer's requirements.

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. This is depicted in the following diagram:

Recommended-physical-topology-for-basic-Forms-customers_small
Click to open enlarged view in a new tab

Note that the above is pretty much a standard author-publish AEM deployment. The Processing server is not required here since the customer is not using Workspace or Correspondence Management, and the form data is also being sent directly to the customer's own data store using a custom form submission handler.

Recommended physical topology for customers upgrading from LiveCycle or new customers using Workspace

Recommended-physical-topology-for-Livecycle-upgrade-customers-or-new-customers-using-Workspace_small
Click to open enlarged view in a new tab

It is recommended that Author is co-deployed with development Forms Workflows add-on on the same JEE server instance/cluster. Follow the same deployment for Processing and the production Forms Workflows add-on. For upgrading Livecycle customers, this closely mirrors what they already have in place. And for new customers using the HTML/Mobile Workspace, co-deployment of AEM and the Forms Workflows add-on is a requirement.

Note that the customers may also run Publish in standalone mode instead of within a JEE server, if needed.

Batching

The current AEM Forms release adds several new features, which ease the task of processing large batches of files. The following diagram depicts how customers may generate PDF statements from a large batch of input data files, and print them for mailing to end-users:

Batching
Click to open enlarged view in a new tab

The following is a more detailed description of the runtime flow occurring on Processing as depicted in the above diagram:

  • The batch of input data files is copied to a physical input folder.
  • A scheduled job running on the topology leader in the Processing cluster picks up the input files for processing. This job is activated and configured to scan the input folder via the new Watched Folder feature.
  • The scan job distributes the batch of files for further processing among the available servers. File processing happens via a script, service, or workflow which the customer has specified for this watch-folder.
  • In this particular scenario, the file-processing code uses the new batching (and underlying PDFG) APIs for generating PDFs from the input data files, and then sends the generated PDF files to the printer.
  • The performance metrics and failure information returned by the batching APIs are propagated back to the watch-folder framework, which saves them in the result/failure folders of the physical watch-folder for further manual analysis.

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