Use AEM Forms as a Cloud Service Communications

AEM Forms as a Cloud Service Communications feature is in beta.

Communications capability helps you to create brand-oriented, personalized, and standardized documents such as business correspondences, statements, claim processing letters, benefit notices, monthly bills, or welcome kits.

You can generate a document on demand or create a batch job to generate multiple documents at defined intervals. Communication APIs provide:

  • streamlined on-demand and batch documentation generation capabilities

  • HTTP APIs for easier integration with existing systems. Separate APIs for on demand (low-latency) and batch operations (high-throughput operations) are included. It makes document generation an efficient task.

  • a secure access to data. Communications APIs connect to and access data only from customer designated data repositories, makes no local copies of data, making Communications highly secure.

A sample credit card statement
A credit card statement can be created using Communications APIs. This sample statement uses same template but seperate data for each customer depending on their usage of credit card.

How it works?

Communications utilizes PDF and XFA templates with XML data to generate a single document on demand or multiple documents using a batch job at defined interval.

A Communications API helps combine a template (XFA or PDF) with customer data (XML data) to generate documents in PDF and Print Formats like PS, PCL, DPL, IPL, and ZPL formats.

Typically, you create a template using Designer and use Communications APIs to merge data with the template. Your application can send the output document to a network printer, a local printer, or to a storage system for archival. A typical out of the box and custom workflows look like the following:

Communications Workflow

Depending on the use case, you can also make these documents available for download via your Website or a storage server.

Communication APIs

Communications provide HTTP APIs for on-demand and batch document generation:

  • Synchronous APIs are suitable for on-demand, low latency, and single record document generation scenarios. These APIs are more suitable for user-action based use cases. For example, generating a document after a user completes filling a form.

  • Batch APIs (Asynchronous APIs) are suitable for scheduled, high throughput, and multiple document generation scenarios. These APIs generate documents in batches. For example, phone bills, credit card statements, and benefits statements generated every month.


Communications is available as a standalone and add-on module for Forms as a Cloud Service user. You can contact Adobe sales team or your Adobe representative to request access.

Adobe enables access for your organization and provide required privileges to the person designated as administrator in your organization. The administrator can grant access to your AEM Forms developers (users) of your organization to use the APIs.


Before start generating documents using Communication APIs, go through the following considerations:

Form data

Communications APIs accept a form design that is typically created in Designer and XML form data as input. To populate a document with data, an XML element must exist in the XML form data for every form field that you want to populate. The XML element name must match the field name. If an XML element does not correspond to a form field or if the XML element name does not match the field name, the XML element is ignored. It is not necessary to match the order in which the XML elements are displayed. The important factor is that the XML elements are specified with corresponding values.

Consider the following example loan application form:

Loan application Form

To merge data into this form design, create an XML data source that corresponds to the form hierarchy, field naming, and data types. The following XML represents an XML data source that corresponds to the example mortgage application form.

* <xfa:datasets xmlns:xfa="">
* <xfa:data>
* <data>
    * <Layer>
        <city>New York</city>
        <socialSecurityNumber>(555) 555-5555</socialSecurityNumber>
    * <Mortgage>

Supported document types

For complete access to the rendering capabilities of the Communications APIs, it is recommended that you use an XDP file as input. Sometimes, a PDF file can be used. However, using a PDF file as input has the following limitations:

A PDF document that does not contain an XFA stream cannot be rendered as PostScript, PCL, or ZPL. Communications APIs can render PDF documents with XFA streams (that is, forms created in Designer) into laser and label formats. If the PDF document is signed, certified, or contains usage rights (applied using AEM Forms Reader Extensions service), it cannot be rendered to these print formats.

Printable areas

The default 0.25-inch nonprintable margin is not exact for label printers and varies from printer to printer and from label size to label size however, it is recommended that you keep the 0.25-inch margin or reduce it. However, it is recommended that you do not increase the nonprintable margin. Otherwise, information in the printable area does not print properly.

Always ensure that you use the correct XDC file for the printer. For example, avoid choosing an XDC file for a 300-dpi printer and sending the document to a 200-dpi printer.

Scripts for XFA forms (XDP/PDF) only

A form design that is used with the Communications APIs can contain scripts that run on the server. Ensure that a form design does not contain scripts that run on the client. For information about creating form design scripts, see Designer Help.

Font mapping

To design a form that uses printer-resident fonts, choose a typeface name in Designer that matches the fonts that are available on the printer. A list of fonts that are supported for PCL or PostScript are located in the corresponding device profiles (XDC files). Alternatively, font mapping can be created to map nonprinter-resident fonts to printer-resident fonts of a different typeface name. For example, in a PostScript scenario, references to the Arial® font can be mapped to the printer-resident Helvetica® typeface.

If a font is installed on a client computer, it is available in the drop-down list in Designer. If the font is not installed, it is necessary to specify the font name manually. The “Permanently replace unavailable fonts” option in Designer can be off. Otherwise, when the XDP file is saved in Designer, the substitution font name is written to the XDP file. It means that the printer-resident font is not used.

Two types of OpenType® fonts exist. One type is a TrueType OpenType® font that PCL supports. The other is CFF OpenType®. PDF and PostScript output supports embedded Type-1, TrueType, and OpenType® fonts. PCL output supports embedded TrueType fonts.

Type-1 and OpenType® fonts are not embedded in PCL output. Content that is formatted with Type-1 and OpenType® fonts is rasterized and generated as a bitmap image that can be large and slower to generate.

Downloaded or embedded fonts are automatically substituted when generating PostScript, PCL, or PDF output. It means that only the subset of the font glyphs that are required to properly render the generated document is included in the generated output.

Working with device profile files (XDC file)

A device profile (XDC file) is a printer description file in XML format. This file enables the Communications APIs to output documents as laser or label printer formats. Communications APIs use the XDC files including the following:

  • hppcl5c.xdc

  • hppcl5e.xdc

  • ps_plain_level3.xdc

  • ps_plain.xdc

  • zpl300.xdc

  • zpl600.xdc

  • zpl300.xdc

  • ipl300.xdc

  • ipl400.xdc

  • tpcl600.xdc

  • dpl300.xdc

  • dpl406.xdc

  • dpl600.xdc

You may use the provided XDC files to generate print documents or modify them as per your requirement.

These files are reference XDC files that support the features of specific printers, such as resident fonts, paper trays, and stapler. The purpose of these reference is to help you understand how to set up your own printers by using device profiles. The reference are also a starting point for similar printers in the same product line.

Working with the XCI configuration file

Communications APIs use an XCI configuration file to perform tasks, such as controlling whether the output is a single panel or paginated. Although this file contains settings that can be set, it is not typical to modify this value.

You can pass a modified XCI file while using a Communications API. When doing so, create a copy of the default file, change only the values that requires modification to meet your business requirements, and use the modified XCI file.

Communications APIs start with the default XCI file (or the modified file). Then it applies values that are specified using the Communications APIs. These values override XCI settings.

The following table specifies XCI options.

XCI option Description
config/present/pdf/creator Identifies the document creator using the Creator entry in the Document Information dictionary. For information about this dictionary, see the PDF Reference guide.
config/present/pdf/producer Identifies the document producer using the Producer entry in the Document Information dictionary. For information about this dictionary, see the PDF Reference guide.
config/present/layout Controls whether the output is a single panel or paginated.
config/present/pdf/compression/level Specifies the degree of compression to use when generating a PDF document.
config/present/pdf/scriptModel Controls whether XFA-specific information is included in the output PDF document.
config/present/common/data/adjustData Controls whether the XFA application adjusts the data after merging.
config/present/pdf/renderPolicy Controls whether the generation of page content is done on the server or deferred to the client.
config/present/common/locale Specifies the default locale used in the output document.
config/present/destination When contained by a present element, specifies the output format. When contained by an openAction element, specifies the action to perform upon opening the document in an interactive client.
config/present/output/type Specifies either the type of compression to apply to a file or the type of output to produce.
config/present/common/temp/uri Specifies the Form URI.
config/present/common/template/base Supplies a base location for URIs in the form design. When this element is absent or empty, the location of the form design is used as the base.
config/present/common/log/to Controls the location that log data or output data is written to.
config/present/output/to Controls the location that log data or output data is written to.
config/present/script/currentPage Specifies the initial page when the document is opened.
config/present/script/exclude Informs to AEM Forms server/Communications APIs which events to ignore.
config/present/pdf/linearized Controls whether the output PDF document is linearized.
config/present/script/runScripts Controls which set of scripts AEM Forms executes.
config/present/pdf/tagged Controls the inclusion of tags into the output PDF document. Tags, in the context of PDF, are additional information included in a document to expose the logical structure of the document. Tags assist accessibility aids and reformatting. For example, a page number may be tagged as an artifact so that a screen reader does not enunciate it in the middle of the text. Although tags make a document more useful, they also increase the size of the document and the processing time to create it.
config/present/pdf/version Specifies the version of PDF document to generate.

On this page