AEM Forms is an application deployed into AEM as a set of packages. It is supported by JEE-based Forms Workflows add-on. The Forms Workflow add-on provides advanced functionalities such as advanced process management and document security.
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:
The architecture for AEM Forms includes the following components:
- Core AEM services: Basic services that AEM provides to a deployed application. These include a JCR-compliant content repository, an OSGI service container, a workflow engine, a trust store, a key store, and so on. These services are available to AEM Forms application but are not provided by AEM Forms packages. The services are an integral part of the overall AEM stack and various AEM Forms components use these services.
- Forms common services: Provide common functionalities to various AEM Forms components. Except for Document Manager and Watch-Folder support, these services are only for internal Adobe components. These services are not intended for external 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.
AEM Forms Workflows add-on: AEM Forms Workflows add-on is AEM Forms server running on JEE stack. A few specific components of AEM Forms and customers for use cases involving more complex processing of form data, workspaces and task management and document security use the AEM Forms Workflows add-on:
- Advanced additional form/intreactive communication data processing: The add-on can be utilized for additionally processing form/intreactive communication 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.
AEM Forms includes a (JEE-based Forms Workflows add-on) also 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 Forms Workflows 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.
AEM Forms authoring user interface does not support creating every type of forms, for example, PDF forms. Such forms are designed using the stand-alone Forms Designer application, saved to a local disk, and 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.
AEM and Forms workflow add-on both have workflow capabilities. You can rapidly build and deploy basic workflows for various tasks on the AEM stack, without having to install the full-fledged Process Management capability of Forms workflow add-on stack. There is some difference in the features of workflow on AEM stack and Process Management capability of Forms workflow add-on stack. The development and management of Form-centric workflows on AEM stack uses the familiar AEM Workflow and AEM Inbox capabilities.
The following image displays various AEM Form server configurations and their components that are used in a typical AEM Forms deployment:
Author: An author instance is an AEM Forms server running in the standard Author run mode. It can be AEM Forms on JEE or AEM Forms on OSGi environment. It is intended for internal users, forms and interactive communication designers, and developers. It enables the following functionalities:
- Authoring and managing forms and interactive communications: Designers and developer can create and edit adaptive forms and interactive communications, upload other types of forms created externally, for example, forms created in Adobe Forms Designer, and manage these assets using the Forms Manager console.
- Form and interactive communication publishing: Assets hosted on an author instance can be published to a publish instance to perform runtime operations. Asset publishing uses AEM’s replication features. Adobe recommends that a replication agent is configured on all the author instances to manually push published forms to processing instances, and another replication agent is configured on processing instances with the On Receive trigger enabled to automatically replicate the received forms to publish instances. Are we keeping the concept of processing instances?
Publish: A publish instance is an AEM Forms server running in the standard Publish run mode. Publish instances are intended for end users of form-based applications, for example, users accessing a public website and submitting forms. It enables the following functionalities:
- Rendering and submitting Forms for end users.
- Transporting of raw submitted form data to processing instances 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 of AEM. An alternative implementation is also available for directly pushing the form data to processing servers 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 instances can go in for this alternative implementation, since processing instances typically lie in a more secure zone.
- Rendering and submitting interactive communication: The letters are rendered on a publish instances and corresponding data is submitted to processing instances for storage and post-processing. The data can either be saved locally on a publish instance and reverse-replicated to a processing instance (the default option) later, or pushed directly to processing instance without saving on the publish instance. The latter implementation is useful for security-conscious customers. Optionally, Form-centric workflows on AEM or a workflow hosted on the Forms Workflows add-on can post-process the data. For Form-centric workflows on AEM, 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 the users are not assigned to ensure that form authoring and management activities are not perfomed on the Processing instance, and occur only on the Author instance. A Processing instance enables the following functionalities:
- Processing of raw form data arriving from a Publish instance: This is achieved primarily via AEM workflows which trigger when the data arrives. The workflows process and 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 the Author instnace nor end users on the Publish instance can access this repository. It also serves as a secure repository for the final processed data, if the customer chooses not to use a separate third-party data store.
- Storage and post-processing of correspondence data arriving from a Publish instance: AEM workflows perform the the optional post-processing of the corresponding letter definitions. These workflows can save the final processed data into a suitable external data stores.
- HTML Workspace hosting (for customers using HTML Workspace): A processing instnce hosts the frontend for HTML Workspace. Internal users use the frontend to render the forms associated with a user tasks.
A Processing instance is configured to run in the Author run mode for the following reasons:
- It enables reverse-replication of raw form data from a Publish instance. The default data storage handler requires the reverse-replication feature.
- AEM Workflows, which are the primary means of processing raw form data arriving from a Publish instance, are recommended to run on an Author-style system for TarMK-based deployments.
AEM Forms on JEE: An AEM Forms on JEE environment is AEM Author and Forms Workflow add-on capabilities co-deployed on a single JEE stack running on an application server. You can also choose to run only Forms Workflow add-on capability, if required. You can run AEM Forms on JEE in single server and clustered setups.
AEM Forms on OSGi: An AEM Forms on OSGi environment is standard AEM Author or AEM Publish. with AEM Forms package deployed on it. You can run AEM Forms on OSGi in single server environment, Farm, and clustered setups. Cluster steup is available only for AEM Author instances.
AEM Forms customers planning to use only document services or document security capabilities can have a topology similar to the one displayed below. This topology recommends using single instance of AEM Forms on JEE server. You can also create a cluster of AEM Forms on JEE servers, if required. This topology is recommneded when most users programatically access capabilities of AEM Forms server and intervention through user interface is minimum. The topology is quite helpful in batch processing operations of document services. For example, using output service to create hundreds of non-editable PDF documents on daily basis.
Although, AEM Forms allows you to set up and run all the functionalities from a single server, you should do capacity planning, load balancing, and set up dedicated servers for specific capabilities in a production environment. For example, for an environment using the PDF Generator service to convert thousands of pages a day and multiple adaptive forms to capture data, set up separate AEM Forms servers for the PDF Generator service and adaptive forms capabilities. It helps provide optimum performance and scale the servers independent of each other.
AEM Forms customers planning to use AEM Forms process management features, for example, HTML Workspace, AEM Forms App can have a topology similar to the one displayed below. This topology recommends that Forms Workflows add-on and AEM author are co-deployed on the same JEE server. The JEE sever can be in single server or cluster configuration.
If you are upgrading from LiveCycle ES4, this topology closely mirrors with what you already have in LiveCycle except addition of AEM Author built-in to AEM Forms on JEE. Moreover, there is no change in the clustering requirements for customers performing an upgrade. If you were using AEM Forms in clusterered environment, you can continue with same in AEM 6.4 Forms. For fresh installation of AEM Forms of JEE for using HTML Workspace and AEM Forms App, co-deployment of Forms Workflows add-on and AEM author is an additional requirement.
Form data store is a third-party data store used for storing final processed data of forms and intreactive communications. This is an optional element in the topology. You can also choose to setup a processing instance and use its repository as the final system-of-record system, if required.
AEM Forms customers planning to use AEM Forms data capture capabilities, for example, adaptive forms, HTML5 Forms, PDF Forms, can have a topology similar to the one displayed below. This topology is also recommended for using interactive communication capablities of AEM Forms.
You can make the following changes/customizations to above suggested topology:
- Using HTML Wowkspace and Adaptive Forms app requires an AEM author instance. You can use the AEM author instance built-in to AEM Forms on JEE server instead of setting up an additional external AEM author server.
- A publish server is required only for Forms-centric workflows on OSGi, adaptive forms, forms portal, and intreactive communication.
- Intreactive communication Agent UI is generally run within the organization. So, you can keep a publish server for Agent UI within private network.
- AEM author instance built-in to AEM Forms on JEE server can also run Forms-centric workflows on OSGi and Watched folders.
AEM Forms customers planning to use AEM Forms data capture capabilities, for example, adaptive forms, HTML5 Forms, PDF Forms, can have a topology similar to the one displayed below. This topology is also recommended for using interactive communications and Forms-Centric Workflows on OSGi capability, for example, for using AEM Inbox and AEM Forms App for business process workflows.
AEM Forms customers planning to use Watched Folders for batch processing can have a topology similar to the one displayed below. The topology displays a clustered environment but you decide to use a single instance of AEM Forms server depending on the load. The third-party data source is your own system-of-record. It acts as an input source for Watched Folders. The topology also displays output in the form of a printed file. You can also store the output content to a file-system, send via email, and use other custom methods to consume output.
AEM Forms customers planning to use only document services capability can have a topology similar to the one displayed below. This topology recommends using a cluster of AEM Forms on OSGi servers. This topology is recommended when most users programmatically (Using APIs) access capabilities of AEM Forms server and intervention through the user interface is minimum. The topology is quite helpful in multiple software client scenarios. For example, multiple clients using PDF Generator service to create PDF documents on demand.
Although AEM Forms allows you to set up and run all the functionalities from a single server, you should do capacity planning, load balancing, and set up dedicated servers for specific capabilities in a production environment .For example, for an environment using the PDF Generator service to convert thousands of pages a day and multiple adaptive forms to capture data, set up separate AEM Forms servers for the PDF Generator service and adaptive forms capabilities. It helps provide optimum performance and scale the servers independent of each other.