Un’azione di invio viene attivata quando un utente fa clic sul pulsante Invia in un modulo adattivo. Puoi configurare l’azione di invio per il modulo adattivo. I moduli adattivi forniscono alcune azioni di invio pronte all’uso. Puoi copiare ed estendere le azioni di invio predefinite per creare un’azione di invio personalizzata. Tuttavia, in base alle tue esigenze, puoi scrivere e registrare la tua azione di invio per elaborare i dati nel modulo inviato. L’azione di invio può utilizzare invio sincrono o asincrono.
Puoi configurare un’azione di invio in Invio nella barra laterale, nella sezione delle proprietà Contenitore modulo adattivo.
Configura azione di invio
Le azioni di invio predefinite disponibili con i moduli adattivi sono:
L’azione Invia PDF tramite e-mail è applicabile solo ai moduli adattivi che utilizzano il modello XFA come modello di modulo.
Assicurati che [Directory_installazione_AEM]Cartella \crx-quickstart\temp\datamanager\ASM
esiste. La directory è necessaria per archiviare temporaneamente gli allegati. Se la directory non esiste, creala.
Se preriempimento un modello di modulo, un modello di dati modulo 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 modulo) che è dati non contiene <afdata>, <afbounddata>, e </afunbounddata> , quindi i dati dei campi non limitati (i campi non limitati sono campi modulo adattivo senza bindref del modulo adattivo.
Per soddisfare il tuo caso d’uso, puoi scrivere un’azione di invio personalizzata per i moduli adattivi. Per ulteriori informazioni, consulta Scrittura dell’azione di invio personalizzata per i moduli adattivi.
Il Invia all’endpoint REST l’opzione di invio trasmette i dati compilati nel modulo a una pagina di conferma configurata come parte della richiesta HTTP GET. Puoi 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 da casella di testo e casella numerica campi per l’azione successiva.
È inoltre possibile Abilita richiesta POST e fornisci un URL per pubblicare la richiesta. Per inviare i dati al server Experience Manager che ospita il modulo, utilizzare un percorso relativo corrispondente al percorso principale del server Experience Manager. Ad esempio, /content/forms/af/SampleForm.html. Per inviare dati a qualsiasi altro server, utilizzare il percorso assoluto.
Configurazione dell’azione di invio endpoint REST
Per passare i campi come parametri in un URL REST, tutti i campi devono avere nomi di elementi diversi, anche se i campi sono posizionati su pannelli diversi.
Utilizza il Invia all’endpoint REST azione per pubblicare i dati inviati su un URL rest. L’URL può essere interno (il server sul quale viene eseguito il rendering del modulo) o esterno.
Per pubblicare i dati su un server interno, specifica il percorso della risorsa. I dati vengono inseriti nel percorso della risorsa. Ad esempio, /content/restEndPoint. Per tali richieste successive, vengono utilizzate le informazioni di autenticazione della richiesta di invio.
Per pubblicare dati su un server esterno, fornisci un URL. Il formato dell’URL è https://host:port/path_to_rest_end_point. Assicurati di configurare il percorso per gestire la richiesta POST in modo anonimo.
Nell’esempio precedente, l’utente ha inserito le informazioni in textbox
viene acquisito tramite il parametro param1
. Sintassi per pubblicare i dati acquisiti tramite param1
è:
String data=request.getParameter("param1");
Analogamente, i parametri utilizzati per la registrazione di dati e allegati XML sono dataXml
e attachments
.
Ad esempio, questi due parametri vengono utilizzati nello script per analizzare i dati in un punto finale rest. Utilizza la sintassi seguente per archiviare 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 dell'allegato.
Il Invia e-mail azione di invio invia un messaggio e-mail a uno o più destinatari in seguito all’invio corretto del modulo. L’e-mail generata può contenere dati del modulo in un formato predefinito.
Tutti i campi modulo devono avere nomi di elementi diversi, anche se sono inseriti in pannelli diversi), ad esempio per includere i dati del modulo in un messaggio e-mail.
Il Invia PDF tramite e-mail azione di invio invia un messaggio e-mail con un PDF contenente i dati del modulo a uno o più destinatari non appena il modulo viene inviato correttamente.
Questa azione di invio è disponibile per i moduli adattivi basati su XFA e per i moduli di adattamento basati su XSD che dispongono del modello del documento di record.
Il Invia al Forms Workflow opzione submit invia un xml dati e gli eventuali allegati a un LiveCycle Adobe o AEM Forms in JEE esistente.
Per informazioni su come configurare l’azione Invia al Forms Workflow, consulta Invio ed elaborazione dei dati del modulo tramite flussi di lavoro per moduli.
Il Invia utilizzando il modello dati modulo l’azione submit scrive i dati del modulo adattivo inviati per l’oggetto modello dati specificato in un modello dati del modulo nella relativa origine dati. Durante la configurazione dell’azione di invio, puoi scegliere un oggetto modello dati di cui desideri riscrivere i dati inviati nella relativa origine dati.
Inoltre, è possibile inviare un allegato del modulo utilizzando un modello di dati del modulo e un documento di record (DoR) all’origine dati.
Per informazioni sul modello dati del modulo, consulta Integrazione dei dati di AEM Forms.
Il Azione di invio Forms Portal rende i dati del modulo disponibili tramite un portale AEM Forms.
Per ulteriori informazioni sul portale Forms e sull’azione di invio, consulta Componente Bozze e invii.
Il Richiama un flusso di lavoro AEM Azione di invio associa un modulo adattivo a un Flusso di lavoro AEM. Quando un modulo viene inviato, il flusso di lavoro associato viene avviato automaticamente nell’istanza Autore. Puoi salvare il file di dati, gli allegati e il documento di record nella cartella relativa o sotto il payload del flusso di lavoro o in una variabile. Se il flusso di lavoro è contrassegnato per l’archiviazione dati esterna, l’opzione della variabile è disponibile e non l’opzione payload. Puoi effettuare una selezione dall’elenco di variabili disponibili per il modello di flusso di lavoro. Se il flusso di lavoro è contrassegnato per l’archiviazione di dati esterni in una fase successiva e non al momento della creazione del flusso di lavoro, assicurati che siano presenti le configurazioni di variabili richieste.
Prima di utilizzare Richiama un flusso di lavoro AEM invia azione, configurare le impostazioni di Experience Manager DS. Per informazioni sulla creazione di un flusso di lavoro AEM, consulta Flussi di lavoro incentrati sul modulo su OSGi.
L’azione Invia inserisce quanto segue nella posizione del payload del flusso di lavoro. Tuttavia, se il modello di flusso di lavoro è contrassegnato per l’archiviazione dei dati esterni e non per l’opzione payload, viene visualizzata solo l’opzione Variabile.
/addresschange/data.xml
percorso crea una cartella denominata addresschange
e lo posiziona in relazione al payload. È inoltre possibile specificare solo data.xml
per inviare solo i dati inviati senza creare una gerarchia di cartelle. Utilizza l’opzione variabile e seleziona la variabile dall’elenco di variabili disponibili per il modello di flusso di lavoro.Le variabili possono essere utilizzate indipendentemente dal fatto che il modello di flusso di lavoro sia contrassegnato o meno per l’archiviazione dati esterna.
Allegati: puoi utilizzare la Percorso allegato per specificare il nome della cartella in cui archiviare gli allegati caricati nel modulo adattivo. La cartella viene creata in relazione al payload. Se il flusso di lavoro è contrassegnato per l’archiviazione di dati esterni, utilizza l’opzione della variabile e seleziona la variabile dall’elenco di variabili disponibili per il modello di flusso di lavoro.
Documento record: contiene il documento di record generato per il modulo adattivo. È possibile utilizzare Percorso del documento record per specificare il nome del file del documento di record e il percorso del file relativo al payload. Ad esempio, il /addresschange/DoR.pdf
percorso crea una cartella denominata addresschange
relativo al payload e posiziona il DoR.pdf
relativo al payload. È inoltre possibile specificare solo DoR.pdf
per salvare solo un documento di record senza creare una gerarchia di cartelle. Se il flusso di lavoro è contrassegnato per l’archiviazione di dati esterni, utilizza l’opzione della variabile e seleziona la variabile dall’elenco di variabili disponibili per il modello di flusso di lavoro.
In genere, in qualsiasi sistema di acquisizione dati online, gli sviluppatori inseriscono alcune convalide JavaScript sul lato client per applicare alcune regole di business. Tuttavia, nei browser moderni, gli utenti finali possono ignorare tali convalide ed effettuare manualmente gli invii utilizzando varie tecniche, ad esempio la Console per la creazione di strumenti di browser Web. Tali tecniche sono valide anche per i moduli adattivi. Uno sviluppatore di moduli può creare diverse logiche di convalida, ma tecnicamente gli utenti finali possono ignorarle e inviare dati non validi al server. I dati non validi violano le regole business applicate da un autore di moduli.
La funzione di riconvalida 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 possibile compromissione dell’invio dei dati e delle violazioni delle regole aziendali rappresentate in termini di convalide dei moduli.
Tutte le convalide pronte per l’uso di un modulo adattivo rieseguite sul server sono:
Utilizza il Riconvalida sul server in Contenitore modulo adattivo nella barra laterale per abilitare o disabilitare la convalida lato server per il modulo corrente.
Abilitazione della convalida lato server
Se l'utente finale ignora tali convalide e invia i moduli, il server esegue nuovamente la convalida. Se la convalida non riesce alla fine del server, la transazione di invio viene interrotta. All’utente finale viene nuovamente presentato il modulo originale. I dati acquisiti e inviati vengono presentati all’utente come un errore.
La convalida lato server convalida il modello del modulo. Si consiglia di creare una libreria client separata per le convalide e non combinarla con altri elementi come lo stile HTML e la manipolazione DOM nella stessa libreria client.
Talvolta, in presenza di regole di convalida complesse, lo script di convalida esatto risiede in funzioni personalizzate e l’autore chiama tali funzioni personalizzate dall’espressione di convalida del campo. Per rendere nota e disponibile questa libreria di funzioni personalizzata durante l’esecuzione delle convalide lato server, l’autore del modulo può configurare il nome della libreria client AEM in Base delle proprietà del Contenitore modulo adattivo, come illustrato di seguito.
Supporto di funzioni personalizzate nelle espressioni di convalida
L’autore può configurare una libreria JavaScript personalizzata per modulo adattivo. Nella libreria, mantieni solo le funzioni riutilizzabili, che hanno dipendenza da librerie di terze parti jquery e underscore.js.
Come parte delle linee guida sulla sicurezza e l’irrigidimento di Experience Manager, configura pagine di errore personalizzate come 404.jsp e 500.jsp. Questi gestori vengono chiamati quando all’invio di un modulo vengono visualizzati errori 404 o 500. Gli handler vengono chiamati anche quando questi codici di errore vengono attivati sul nodo Publish.
Per ulteriori informazioni, consulta Personalizzazione delle pagine visualizzate dal gestore degli errori.