Campi mancanti e in più
Due regole che rendono l'integrazione tollerante, e una conseguenza che è bene conoscere.
Un campo che il modello si aspetta ma che il tuo payload omette viene reso vuoto. Non è un errore. Un campo che il tuo payload contiene ma che il modello non legge mai viene semplicemente ignorato. Un payload troppo scarso o troppo ricco produce comunque un documento.
Quindi {{ vendor.price }} senza price nei
dati lascia uno spazio vuoto dove andrebbe il numero, e la richiesta risponde comunque
200.
La conseguenza: un campo scritto male non è un errore. Invia
vendro invece di vendor e ottieni un documento
con un buco, non un rifiuto — ma non in silenzio: la risposta porta
l'avviso TEMPLATE_FIELDS_MISSING (2104), che indica ciò che il modello
si aspettava e non ha ricevuto.
Il payload di ogni richiesta viene inoltre conservato così come è arrivato (per 12 mesi, e
mai per una chiamata dataless). Apri Documenti nella console,
fai clic su Dettagli sulla generazione, e la pagina mostra affiancati attesi dal modello ma assenti e
inviati ma mai letti: un refuso compare subito nel secondo
elenco.
Maiuscole e minuscole non contano
Tag e payload non devono concordare su maiuscole e minuscole. Questi sono tutti lo stesso campo:
template: {{ VendoR.Price }} {{ vendor.price }} {{ VENDOR.PRICE }}
payload: {"Vendor": {"PRICE": …}} {"vendor": {"price": …}}Entrambi i lati vengono portati in minuscolo prima dell'unione, nomi dei cicli compresi:
{% for R in Forniture %} legge
l'array forniture e {{ r.SITE }} legge
site su ogni elemento. I valori non vengono mai toccati: una ragione sociale conserva
le sue maiuscole.
L'unica cosa da evitare è un payload che contiene lo stesso campo in due
grafie (Vendor e vendor insieme): è
ambiguo, e vince quello valorizzato, non quello arrivato per primo.