Transaction Reports Billable APIs for AEM Forms on OSGi
- Topics:
- Transaction Reports
CREATED FOR:
- Admin
- User
- Developer
| Version | Article link |
|---|---|
| AEM as a Cloud Service | Click here |
| AEM 6.5 | This article |
AEM Forms provides several APIs to submit forms, process documents, and render documents. Some APIs are accounted as transactions and others are free to use. This document provides a list of all the APIs that are accounted as transactions in a transaction report. Here are a few common scenarios where a billable API is used:
- Submitting an adaptive form, HTML5 Form, and form set
- Rendering a print or web version of an interactive communication
- Converting a document from one format to another
- Flattening a dynamic PDF document
- Generating a Document of Record
- Merging an interactive PDF document with another PDF document
- Using the assign task step and doc services steps of AEM Workflows
- Using adaptive form within an adaptive form
Billing APIs does not account for the number of pages, the length of a document or form, or final format of the rendered document. A transaction report divides the transactions into two categories: Documents Rendered and Forms Submitted.
-
Forms Submitted: When data is submitted from any type of form created with AEM Forms and the data is submitted to any data storage repository or database is considered form submission. For example, submitting an adaptive form, HTML5 Form, PDF Forms, and form set are accounted as forms submitted. Each form in a form set is considered a submission. For example, if a form set has 5 forms, when the form set is submitted, transaction reporting service counts it as 5 submissions.
-
Documents Rendered: Generating a document by combining a template and data, digitally signing or certifying a document, using a billable document services API for document services, or converting a document from one format to another are accounted as documents rendered.
NOTEBillable Document Services APIs
Generate PDF Service
DocAssurance Service
Distiller Service
Document of Record Service (DoR Service)
Output Service
You can use the getGenerateManyFiles flag to combine multiple renditions to single PDF file. Irrespective of the status of flag, the service counts each record as a separate PDF rendition.
You can use the getGenerateManyFiles flag to combine multiple renditions to single PDF file. Irrespective of the status of flag, the service counts each record as a separate PDF rendition.
Forms Service
Convert PDF Service
Barcoded Forms Service
Assembler Service
The following operations are not accounted as transactions:
- Creating packages or portfolio
- Stitching multiple XDPs
The invoke API’s usage is counted as a transaction, when you perform one or more of the following operations:
- Conversion from non-PDF formats to PDF formats. For instance, the conversion from XDP format to PDF format, catering to both interactive and non-interactive forms of communication, and the conversion from Word to PDF.
- Conversion from PDF format to PDF/A format.
- Conversion from PDF format to non-PDF formats. Examples encompass the transformation from PDF to Image format or the conversion from PDF to Text format.
NOTE- The invoke API of the assembler service can internally call a billable API of another service depending on the input. So, the invoke API can be accounted as none, single, or multiple transactions. The number of transactions counted depends upon the input and the internal APIs invoked.
- A single PDF document produced using assembler service can be accounted as none, single, or multiple transactions. The number of transactions counted depends upon the supplied DDX code.
PDF Utility Service
Billable Data Capture APIs
All the submission events of adaptive forms, HTML5 Forms, and form set are accounted as transactions. By default, submission of a PDF Form is not accounted as a transaction. Use the provided transaction recorder API to record a PDF Forms submission as a transaction.
Adaptive Forms
- Successful submissions account for single or two transactions. The number of transactions counted depends upon the type of submit action used for submission. For example, sending PDF through email submit action accounts for two counts of transactions. One transaction for form submission and another for PDF generated using the Document of Record (DOR) service.
- Using the adaptive form within an adaptive form (Adaptive form formset) accounts only single transaction. You can have any number of adaptive forms within an adaptive form.
HTML5 Forms
Form set
- Using the adaptive form within an adaptive form (Adaptive form formset) accounts only single transaction. You can have any number of adaptive forms within an adaptive form.
- Every form in an HTML5 Forms form set accounts as a separate transaction.
Billable Interactive Communication and Form-centric AEM Workflows on OSGi APIs
Assign task and document services steps of Form-centric AEM Workflows on OSGi and all the renditions of interactive communication and are accounted as transactions. Previewing an interactive communication on the author instance and previewing on the publish instance using Agent UI are not accounted as transactions. If a workflow step accounts a transaction and the workflow fails to complete, the transaction count is not reversed.
Interactive Communication - Web Channel
Interactive Communication - Print Channel
Form-centric AEM Workflows on OSGi
Recording billable APIs as transactions for custom code
Actions like submitting a PDF Form, using Agent UI to preview an interactive communication, using non-standard form submission, and custom implementations are not accounted as transactions. AEM Forms provides an API to record such actions as transactions. You can call the API from your custom implementations to record a transaction.