Jūs skatāties palīdzības saturu versijai:

Introduction

A submit action is triggered when a user click the Submit button. Adaptive forms allows you to configure the submit action on each form. Based on the use case and requirements, you can write and register your own submit action to process data in the submitted form. However, adaptive forms provide a few out of the box submit actions. You can copy and extend the default submit actions to create you own submit action.

You can configure a submit action in the Submission section of the Adaptive Form Container properties, in the sidebar.

Configure Submit Action
Configure Submit Action

The default submit actions available with adaptive forms are:

  • Submit to REST endpoint
  • Store content action (deprecated)
  • Email action
  • Email PDF action
  • Store PDF action (deprecated)
  • Submit to Forms workflow
  • Forms Portal Submit Action

Piezīme.

In a production environment, it is recommended not to store submitted form data in AEM repository. Submit actions such as Store Content (deprecated), Store PDF (deprecated), and Forms Portal store form data in AEM repository. These submit actions are meant only for demonstration purposes. Instead in a production environment, you must write a custom submit action that stores forms data in a more secure storage like your enterprise database. For more information, see Writing custom Submit action for adaptive forms.

Piezīme.

Email PDF action and Store PDF (deprecated) action are applicable only to adaptive forms that use XFA template as form model.

Piezīme.

The store content action (deprecated), file attachments, and eSign services are not supported for anonymous users.

Uzmanību!

If you prefill a form template or schema based adaptive form with XML data complaint to a schema (XML schema or form template) that is data does not contain <afData>, <afBoundData>, and </afUnboundData> tags, then the data of unbounded fields (Unbounded fields are adaptive form fields without bindref property) of the adaptive form is lost.

Configuring the Submit to REST endpoint submit action

The Submit to REST endpoint submit option passes the data filled in the form to a configured confirmation page as part of the HTTP GET request. You can add the name of the fields to request. The format of the request is:

{fieldName}={request parameter name}

As shown in the image below, param1 and param2 are passed as parameters with values copied from the textbox and numericbox fields for the next action.

You can also Enable POST request and provide a URL to post the request. To submit data to the AEM server hosting the form, use a relative path corresponding to the root path of the AEM server. For example, /content/forms/af/SampleForm.html. To submit data to any other server, use absolute path.

Configuring Rest Endpoint Submit Action
Configuring Rest Endpoint Submit Action

Piezīme.

To pass the fields as parameters in a REST URL, all the fields must have different element names, even if the fields are placed on different panels. 

Post submitted data to a resource or external rest end point 

Use the Submit to REST Endpoint action to post the submitted data to a rest URL. The URL can be of an internal (the server on which the form is rendered) or an external server. 

To post data to an internal server, provide path of the resource. The data is posted the path of the resource. For example, /content/restEndPoint. For such post requests, the authentication information of the submit request is used.

To post data to an external server, provide a URL. The format of the URL is http://host:port/path_to_rest_end_point. Ensure that you configure the path to handle the POST request anonymously.  

Mapping for field values passed as Thank You Page parameters

In the example above, user entered information in textbox is captured using parameter param1. Syntax to post data captured using param1 is:

String data=request.getParameter("param1");

Similarly, paramenters that you use for posting XML data and attachments are dataXml and attachments

For example, you use these two parameters in your script to parse data to a rest end point. You use the following syntax to store and parse the data:

String data=request.getParameter("dataXml");
String att=request.getParameter("attachments");

In this example, data stores the XML data, and att stores attachment data.

DEPRECATED - Configuring the Store content action submit action

The Store content action (deprecated) submit option stores the form data in the CRX repository. The form data is stored as properties on the CRX node that gets created on the path provided when configuring the submit action.

For detailed information about Store content action (deprecated), see Submitting and storing content in JCR repository.

Configuring the Email action submit action

The Email action option sends an email to one or more recipients on successful submission of the form. The email generated can contain form data in a predefined format.

Piezīme.

All the form fields must have different element names, even if they are placed on different panels), for including form data in an email.

Configuring the Email PDF action submit action

The Email PDF action option sends an email with a PDF containing form data, to one or more recipients on successful submission of the form.

Note: This submit action is available for XFA-based adaptive forms and XSD-based adaption forms that have the Document of Record template.

DEPRECATED - Configuring the Store PDF action submit action

The Store PDF action (deprecated) option saves form data as a PDF document in CRX on successful submission of the form.

Note: The submit action is also available for XFA-based adaptive forms and XSD-based adaption forms that have the Document of Record template.

For information about how to configure the Store PDF action (deprecated) submit action, see Submitting and storing content in JCR repository.

Configuring the Submit to forms workflow submit action

The Submit to Forms workflow submit option sends a data xml and file attachments (if any) to an existing Adobe LiveCycle process.

For information about how to configure the Submit to forms workflow submit action, see Submitting and processing your form data using forms workflows.

Configuring the Forms Portal submit action

The Forms Portal Submit Action option makes form data available through an AEM Forms portal. 

For more information about the Forms Portal and submit action, see Drafts and submissions component.

Server-Side Revalidation in Adaptive Form

Typically, in any online data capture system, developers place some javascript validations on client side to enforce a few business rules. But in modern browsers, end users have way to bypass those validations and manually do submissions using various techniques, Such as Web Browser DevTools Console. Such techniques are also valida for adaptive forms. A forms developer can create various validation logics, but technically, end users can bypass those validation logics and submit invalid data to the server. Invalid data would break the business rules that a forms author has enforced.

The server-side revalidation feature provides the ability to also run the validations that an adaptive forms author has provided while designing an adaptive form on the server. It prevents any possible compromise of data submissions and business rules violations represented in terms of form validations.

What to validate on Server?

All out of the box (OOTB) field validations of an adaptive form thate are rerun at the server are:

  • Required
  • Validation Picture Clause
  • Validation Expression

Enabling Server-side Validation

Use the Revalidate on server under Adaptive Form Container in the sidebar to enable or disable server-side validation for the current form.  

Enabling Server-Side Validation
Enabling Server-Side Validation

If end-user bypass those validations and submit the forms, the server again performs the validation. If the validation fails at server end, then the submit transaction is stopped. The end user is presented with the orignal form again. The captured data and submitted data are presented to the user as an error.  

Supporting Custom functions in Validation Expressions

At times, in case of complex validation rules, the exact validation script reside in custom functions and author calls these custom functions from field validation expression. To make this custom function library known and available while performing server-side validations, the form author can configure the name of AEM client library under the Basic tab of Adaptive Form Container properties as shown below.

Supporting Custom functions in Validation Expressions
Supporting Custom functions in Validation Expressions

Author can configure custom javascript library per adaptive form. In the library, only keep the reusable functions, which has dependency on jquery and underscore.js third-party libraries.

Error handling on submit action

As a part of AEM security and hardening guidelines, configure custom error pages such as 404.jsp and 500.jsp. These handlers are called, when on submitting a form 404 or 500 errors appear. The handlers are also called when these error codes are triggered on the Publish node. 

For more information, see Customizing Pages shown by the Error Handler.

Šis darbs ir licencēts saskaņā ar Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported licenci  Uz portālā Twitter™ un Facebook izvietotajiem ziņojumiem neattiecas Creative Commons sistēmas noteikumi.

Juridisks paziņojums   |   Tiešsaistes konfidencialitātes politika