Configurazione dell'azione Invia

Introduzione all'invio di azioni

Un'azione di invio viene attivata quando l'utente fa clic sul pulsante Invia di un modulo adattivo. È possibile configurare l'azione di invio sul modulo adattivo. I moduli adattivi forniscono alcune delle azioni di invio previste. È possibile copiare ed estendere le azioni di invio predefinite per creare una propria azione di invio. Tuttavia, in base alle esigenze dell'utente, è possibile scrivere e registrare una propria azione di invio per elaborare i dati nel modulo inviato. L'azione di invio può utilizzare invio sincrono o asincrono.

È possibile configurare un'azione di invio nella sezione Invio delle proprietà Contenitore modulo adattivo, nella barra laterale.

Configura azione di invio

Configura azione di invio

Le azioni di invio predefinite disponibili con i moduli adattivi sono:

  • Invia a endpoint REST
  • Invia e-mail
  • Invia PDF tramite e-mail
  • Richiamo di un Forms Workflow
  • Invia usando il modello dati modulo
  • Azione di invio Forms Portal
  • Richiama un flusso di lavoro AEM
NOTA

L'azione Invia PDF tramite e-mail è applicabile solo ai moduli adattivi che utilizzano il modello XFA come modello di modulo.

NOTA

Assicurarsi che [AEM_Installation_Directory]\crx-quickstart\temp\datamanager\ASM folder
esiste. La directory è necessaria per memorizzare temporaneamente gli allegati. Se la directory non esiste, createla.

ATTENZIONE

Se si precompila un modello di modulo, un modello di dati o un modulo adattivo basato su schema con un reclamo di dati XML o JSON a uno schema (schema XML, schema JSON, modello di modulo o modello di dati di modulo) che non contiene i tag <afData>, <afBoundData> e </afUnboundData>, i dati dei campi non associati (campi non associati) sono campi modulo adattivi senza la proprietà bindref del modulo adattivo.

È possibile scrivere un'azione di invio personalizzata per i moduli adattivi per soddisfare le esigenze d'uso. Per ulteriori informazioni, vedere Scrittura di un'azione di invio personalizzata per i moduli adattivi.

Invia all'endpoint REST

L'opzione di invio Invia all'endpoint REST passa i dati compilati nel modulo a una pagina di conferma configurata come parte della richiesta di GET HTTP. Potete aggiungere il nome dei campi da richiedere. Il formato della richiesta è:

{fieldName}={request parameter name}

Come mostrato nell'immagine seguente, param1 e param2 vengono passati come parametri con valori copiati dai campi textbox e numericbox per l'azione successiva.

Potete inoltre Abilitare la richiesta di POST e fornire un URL per inviare la richiesta. Per inviare i dati al server AEM che ospita il modulo, utilizzare un percorso relativo corrispondente al percorso principale del server di AEM. Ad esempio, /content/forms/af/SampleForm.html. Per inviare dati a qualsiasi altro server, utilizzare il percorso assoluto.

Configurazione dell'azione di invio dell'endpoint rimanente

Configurazione dell'azione di invio dell'endpoint rimanente

NOTA

Per trasmettere i campi come parametri in un URL REST, tutti i campi devono avere nomi di elementi diversi, anche se i campi sono posizionati in pannelli diversi.

Invia i dati inviati a una risorsa o a un punto finale di riposo esterno 

Utilizzare l'azione Invia a endpoint REST per inviare i dati inviati a un URL rimanente. L'URL può essere di un server interno (il server su cui viene eseguito il rendering del modulo) o di un server esterno.

Per inviare i dati a un server interno, fornire il percorso della risorsa. I dati vengono inviati nel percorso della risorsa. Ad esempio, /content/restEndPoint. Per tali richieste di post, vengono utilizzate le informazioni di autenticazione della richiesta di invio.

Per inviare dati a un server esterno, immetti un URL. Il formato dell’URL è https://host:port/path_to_rest_end_point. Accertatevi di configurare il percorso per gestire la richiesta di POST in modo anonimo.

Mapping dei valori dei campi passati come parametri della pagina di ringraziamento

Nell'esempio precedente, le informazioni immesse dall'utente in textbox vengono acquisite utilizzando il parametro param1. La sintassi per il post dei dati acquisiti con param1 è la seguente:

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

Analogamente, i membri utilizzati per inviare dati e allegati XML sono dataXml e attachments.

Ad esempio, è possibile utilizzare questi due parametri nello script per analizzare i dati in un punto finale rimanente. È possibile utilizzare la sintassi seguente per memorizzare e analizzare i dati:

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

In questo esempio, data memorizza i dati XML e att memorizza i dati degli allegati.

Invia e-mail

L'azione di invio Invia e-mail invia un messaggio e-mail a uno o più destinatari dopo l'invio corretto del modulo. L'e-mail generata può contenere dati del modulo in un formato predefinito.

NOTA

Tutti i campi modulo devono avere nomi di elementi diversi, anche se si trovano in pannelli diversi), per l’inclusione dei dati del modulo in un messaggio e-mail.

Invia PDF tramite e-mail

L'azione di invio Invia PDF tramite e-mail invia un messaggio e-mail contenente un PDF contenente dati del modulo a uno o più destinatari dopo l'invio corretto del modulo.

NOTA

Questa azione di invio è disponibile per i moduli adattivi basati su XFA e per i moduli di adattamento basati su XSD con modello Documento di record.

Richiamo di un flusso di lavoro moduli

L'opzione Invia a flusso di lavoro Forms invia un file xml di dati ed eventuali allegati a un LiveCycle di Adobe esistente o AEM Forms su JEE.

Per informazioni su come configurare l'azione di invio del flusso di lavoro Invia ai moduli, vedere Invio ed elaborazione dei dati del modulo mediante i flussi di lavoro dei moduli.

Invia usando il modello dati modulo

L'azione di invio Invia utilizzando il modello dati del modulo scrive i dati del modulo adattivo inviati per l'oggetto modello dati specificato in un modello dati del modulo alla relativa origine dati. Durante la configurazione dell'azione di invio, è possibile scegliere un oggetto modello dati di cui si desidera riscrivere i dati inviati nell'origine dati.

È inoltre possibile inviare all'origine dati un allegato del modulo utilizzando un modello dati del modulo e un documento record (DoR).

Per informazioni sul modello di dati del modulo, vedere Integrazione dei dati AEM Forms.

Azione di invio Forms Portal

L'opzione Forms Portal Submit Action rende i dati del modulo disponibili tramite un portale AEM Forms.

Per ulteriori informazioni su Forms Portal e per l'invio di azioni, vedere Componente Bozze e invii.

Richiama un flusso di lavoro AEM

L'azione di invio Richiama un flusso di lavoro AEM consente di associare un modulo adattivo a un flusso di lavoro AEM. Quando un modulo viene inviato, il flusso di lavoro associato viene avviato automaticamente sul nodo di elaborazione. Inoltre, posiziona il file di dati, gli allegati e il documento di registrazione, se applicabile, nel percorso di payload del flusso di lavoro.

Prima di utilizzare l'azione di invio Richiama un flusso di lavoro AEM, configurare le impostazioni AEM DS. Per informazioni sulla creazione di un flusso di lavoro AEM, vedere Flussi di lavoro incentrati sui moduli in OSGi.

Ripristino lato server nel modulo adattivo

In genere, in qualsiasi sistema di acquisizione dei dati online, gli sviluppatori inseriscono alcune convalide JavaScript sul lato client per applicare alcune regole aziendali. Tuttavia, nei browser più recenti, gli utenti finali hanno modo di bypassare tali convalide e di effettuare manualmente gli invii utilizzando varie tecniche, come ad esempio Web Browser DevTools Console. Tali tecniche sono valida anche per i moduli adattivi. Gli sviluppatori di moduli possono creare diversi logici di convalida, ma tecnicamente gli utenti finali possono ignorare tali logici di convalida e inviare al server dati non validi. Dati non validi potrebbero interrompere le regole aziendali applicate dall'autore di un modulo.

La funzione di ripristino lato server consente inoltre di eseguire le convalide fornite da un autore di moduli adattivi durante la progettazione di un modulo adattivo sul server. Impedisce qualsiasi compromesso nell'invio di dati e nelle violazioni delle regole aziendali rappresentate in termini di convalida dei moduli.

Cosa convalidare sul server?

Tutte le convalide dei campi (OOTB) di un modulo adattivo eseguite nuovamente sul server sono:

  • Obbligatorio
  • Convalida dell'immagine
  • Espressione di convalida

Abilitazione della convalida lato server

Utilizzare la funzione Revoca sul server in Contenitore modulo adattivo nella barra laterale per attivare o disattivare la convalida lato server per il modulo corrente.

Abilitazione della convalida lato server

Abilitazione della convalida lato server

Se l'utente finale bypassa tali convalide e invia i moduli, il server esegue di nuovo la convalida. Se la convalida ha esito negativo alla fine del server, la transazione di invio viene arrestata. All'utente finale viene nuovamente presentato il modulo originale. I dati acquisiti e inviati vengono presentati all'utente come un errore.

Supporto delle funzioni personalizzate nelle espressioni di convalida

A volte, nel caso di complesse regole di convalida, lo script di convalida esatto risiede in funzioni personalizzate e l'autore chiama queste funzioni personalizzate dall'espressione di convalida del campo. Per rendere la libreria di funzioni personalizzate nota e disponibile durante l'esecuzione di convalide sul lato server, l'autore del modulo può configurare il nome AEM libreria client nella scheda Base delle proprietà Contenitore di moduli adattivi, come illustrato di seguito.

Supporto delle funzioni personalizzate nelle espressioni di convalida

Supporto delle funzioni personalizzate nelle espressioni di convalida

L'autore può configurare la libreria JavaScript personalizzata per ciascun modulo adattivo. Nella libreria, mantenere solo le funzioni riutilizzabili, che dipendono dalle librerie di terze parti jquery e underscore.js.

Gestione degli errori nell'azione di invio

Come parte delle AEM linee guida sulla protezione e l'indurimento, configurate pagine di errore personalizzate come 404.jsp e 500.jsp. Questi gestori vengono chiamati quando si invia un modulo 404 o 500 errori. I gestori vengono chiamati anche quando questi codici di errore vengono attivati sul nodo Pubblica.

Per ulteriori informazioni, vedere Personalizzazione delle pagine mostrate dal gestore errori.

In questa pagina