Azione di invio di moduli adattivi

Un’azione di invio viene attivata quando un utente fa clic sul pulsante Invia su un modulo adattivo. Adaptive Forms fornisce alcune azioni di invio pronte all'uso. Le azioni di invio disponibili sono:

È inoltre possibile estendere le azioni di invio predefinite per creare un’azione di invio personalizzata.

Puoi configurare un’azione di invio nella Invio della sezione delle proprietà del contenitore di moduli adattivi, nella barra laterale.

Configurare l’azione Invia

Invia all’endpoint REST

Utilizza la 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 dati a un server interno, fornisci il percorso della risorsa. I dati vengono inviati nel percorso della risorsa. Ad esempio, /content/restEndPoint. Per tali richieste post, vengono utilizzate le informazioni di autenticazione della richiesta di invio.

Per inviare dati a un server esterno, specifica 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.

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

Nell’esempio precedente, l’utente ha immesso informazioni in textbox viene acquisito utilizzando il parametro param1. Sintassi per la registrazione dei dati acquisiti tramite param1 è:

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

Analogamente, i parametri utilizzati per la registrazione di dati XML e allegati sono dataXml e attachments.

Ad esempio, è possibile utilizzare questi due parametri nello script per analizzare i dati in un punto finale residuo. Utilizza 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.

La Invia all’endpoint REST Invia azione invia 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 i valori copiati dal casella di testo e casella numerica campi per l’azione successiva.

Configurazione dell'azione di invio dell'endpoint rimanente

È inoltre possibile Abilita richiesta POST e fornire un URL per inviare la richiesta. Per inviare dati al server AEM che ospita il modulo, utilizzare un percorso relativo corrispondente al percorso principale del server AEM. Esempio, /content/forms/af/SampleForm.html. Per inviare dati a qualsiasi altro server, utilizzare un percorso assoluto.

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 su pannelli diversi.

Invia e-mail

È possibile utilizzare Invia e-mail Invia azione per inviare un’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. Ad esempio, nel modello seguente, il nome del cliente, l’indirizzo di spedizione, il nome dello stato e il codice postale vengono recuperati dai dati del modulo inviati.

"

Hi ${customer_Name},

Il seguente è impostato come indirizzo di spedizione predefinito:
${customer_Name},
${customer_Shipping_Address},
${customer_State},
${customer_ZIPCode}

Cordiali saluti,
WKND

"
NOTA
  • Tutti i campi del modulo devono avere nomi di elementi diversi, anche se si trovano su pannelli diversi di un modulo adattivo.
  • AEM as a Cloud Service richiede che la posta in uscita sia crittografata. Per impostazione predefinita, le e-mail in uscita sono disabilitate. Per attivarlo, invia un ticket di supporto a Richiesta di accesso.

È inoltre possibile includere allegati e un documento di record (DoR) nell’e-mail. Per abilitare Allega documento di registrazione configurare il modulo adattivo per generare un documento di record (DoR). È possibile abilitare l’opzione per generare un documento di record dalle proprietà Modulo adattivo.

Invia usando il modello dati modulo

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

Inoltre, è possibile inviare all’origine dati un allegato del modulo utilizzando un modello dati modulo e un documento di record. Per informazioni sul modello dati del modulo, consultare AEM Forms Integrazione dei dati.

Richiamare un flusso di lavoro AEM

La Richiamare un flusso di lavoro AEM Invia azione 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 di authoring. È possibile salvare il file di dati, gli allegati e il documento di record nella posizione di payload del flusso di lavoro o in una variabile. Se il flusso di lavoro è contrassegnato per l’archiviazione di dati esterni e configurato per un archivio dati esterno, è disponibile solo l’opzione variabile . Puoi selezionare dall’elenco delle variabili disponibili per il modello di flusso di lavoro. Se il flusso di lavoro è contrassegnato per l’archiviazione dei dati esterni in una fase successiva e non al momento della creazione del flusso di lavoro, assicurati che siano presenti le configurazioni delle variabili richieste.

L’azione Invia inserisce quanto segue nel percorso di payload del flusso di lavoro o nella variabile se il flusso di lavoro è contrassegnato per l’archiviazione dei dati esterni:

  • File di dati: Contiene i dati inviati al modulo adattivo. È possibile utilizzare Percorso file dati per specificare il nome del file e il percorso del file relativo al payload. Ad esempio, il /addresschange/data.xml crea una cartella denominata addresschange e lo posiziona rispetto al carico utile. Puoi anche specificare solo data.xml per inviare solo i dati inviati senza creare una gerarchia di cartelle. Se il flusso di lavoro è contrassegnato per l’archiviazione dei dati esterni, utilizza l’opzione variabile e seleziona la variabile dall’elenco delle variabili disponibili per il modello di flusso di lavoro.

  • Allegati: È possibile utilizzare Percorso allegato opzione per specificare il nome della cartella in cui memorizzare gli allegati caricati nel modulo adattivo. La cartella viene creata in relazione al payload. Se il flusso di lavoro è contrassegnato per l’archiviazione dei dati esterni, utilizza l’opzione variabile e seleziona la variabile dall’elenco delle variabili disponibili per il modello di flusso di lavoro.

  • Documento di registrazione: Contiene il documento di record generato per il modulo adattivo. È possibile utilizzare Percorso del documento di registrazione per specificare il nome del file del documento di record e il percorso del file relativo al payload. Ad esempio, il /addresschange/DoR.pdf crea una cartella denominata addresschange relativo al payload e inserisce il DoR.pdf relativo al payload. Puoi anche specificare solo DoR.pdf per salvare solo il documento di record senza creare una gerarchia di cartelle. Se il flusso di lavoro è contrassegnato per l’archiviazione dei dati esterni, utilizza l’opzione variabile e seleziona la variabile dall’elenco delle variabili disponibili per il modello di flusso di lavoro.

Prima di utilizzare Richiamare un flusso di lavoro AEM Invia azione configura quanto segue per Servizio impostazioni di DS AEM configurazione:

  • URL server di elaborazione: Il server di elaborazione è il server in cui viene attivato il flusso di lavoro Forms o AEM. Può essere lo stesso dell’URL dell’istanza di authoring AEM o di un altro server.

  • Nome utente del server di elaborazione: Nome utente dell’utente del flusso di lavoro

  • Password server di elaborazione: Password dell’utente del flusso di lavoro

Per impostare i valori di una configurazione, Generare configurazioni OSGi utilizzando l’SDK AEMe distribuire la configurazione all'istanza di Cloud Service.

Utilizzare l’invio sincrono o asincrono

Un’azione di invio può utilizzare l’invio sincrono o asincrono.

Invio sincrono: In genere, i moduli web sono configurati per l’invio in modo sincrono. In un invio sincrono, quando gli utenti inviano un modulo, vengono reindirizzati a una pagina di conferma, a una pagina di ringraziamento o in caso di errore di invio, a una pagina di errore. È possibile selezionare la Utilizzare l’invio asincrono per reindirizzare gli utenti a una pagina web o mostrare un messaggio all’invio.

Configurare l’azione Invia

Invio asincrono: Le esperienze web moderne, come le applicazioni a pagina singola, stanno guadagnando popolarità laddove la pagina web rimane statica mentre l'interazione client-server avviene in background. È ora possibile fornire questa esperienza con Adaptive Forms tramite configurazione dell’invio asincrono.

Rivalutazione lato server in forma adattiva

In genere, in qualsiasi sistema di acquisizione dati online, gli sviluppatori inseriscono alcune convalide JavaScript sul lato client per applicare alcune regole business. Ma nei browser moderni, gli utenti finali hanno modo di bypassare tali convalide e fare manualmente gli invii utilizzando varie tecniche, come ad esempio Web Browser DevTools Console. Tali tecniche sono valide anche per Adaptive Forms. Uno sviluppatore di moduli può creare diversi logici di convalida, ma tecnicamente, gli utenti finali possono ignorare tali logici di convalida e inviare dati non validi al server. Dati non validi potrebbero interrompere le regole business applicate da un autore di moduli.

La funzione di riconvalida lato server consente di eseguire anche le convalide fornite da un autore di Forms adattivo durante la progettazione di un modulo adattivo sul server. Impedisce qualsiasi possibile compromesso tra l’invio dei dati e le violazioni delle regole aziendali rappresentate in termini di convalida dei moduli.

Cosa convalidare sul server?

Tutte le convalide predefinite (OOTB) di un modulo adattivo che vengono ripetute sul server sono:

  • Obbligatorio
  • Clausola di convalida dell'immagine
  • Espressione di convalida

Abilitazione della convalida lato server

Utilizza la Rivelare sul server in Contenitore di moduli adattivi nella barra laterale per abilitare o disabilitare 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 nuovamente la convalida. Se la convalida ha esito negativo al server, la transazione di invio viene arrestata. All’utente finale viene presentato nuovamente il modulo originale. I dati acquisiti e inviati vengono presentati all’utente come un errore.

NOTA

La convalida lato server convalida il modello di modulo. È consigliabile creare una libreria client separata per le convalide e non combinarla con altri elementi come lo stile di HTML e la manipolazione DOM nella stessa libreria client.

Supporto di funzioni personalizzate nelle espressioni di convalida

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

Supporto di funzioni personalizzate nelle espressioni di convalida

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 dipendono dalle librerie di terze parti jquery e underscore.js.

Gestione degli errori nell’azione di invio

Come parte delle linee guida per la protezione e l’indurimento AEM, configura pagine di errore personalizzate come 400.jsp, 404.jsp e 500.jsp. Quando si invia un modulo 400, 404 o 500 vengono visualizzati errori di questi gestori. I gestori vengono chiamati anche quando questi codici di errore vengono attivati sul nodo Publish . Puoi anche creare pagine JSP per altri codici di errore HTTP.

Quando si precompila un modello dati del modulo o un modulo adattivo basato su schema con dati XML o JSON in uno schema che non contiene dati <afData>, <afBoundData>e </afUnboundData> quindi i dati dei campi non associati del modulo adattivo vengono persi. Lo schema può essere uno schema XML, uno schema JSON o un modello dati modulo. I campi non collegati sono campi Modulo adattivo senza bindref proprietà.

In questa pagina