ImportMulti è il protocollo per leggere più tipi di dato in una sola chiamata e, nella stessa chiamata, confermare i record ricevuti al giro precedente. Riduce di molto il numero di chiamate di una sincronizzazione completa. È di sola lettura: per scrivere si usa il protocollo normale.
IndirizzoPOST https://<tuo-dominio>/webservice.aspx?Key=<chiave>&serialize=json&operationmulti=importmulti
Trasporto, compressione e formato sono gli stessi del protocollo normale; cambia l'oggetto inviato.
WebServiceMultiRequest
| Campo | Tipo | Obbligatorio | A cosa serve |
|---|
ProtocolVersion | Intero | Sì | Versione del protocollo: deve essere 1. |
GuidPC | Testo | Sì | Identificativo della postazione, da 1 a 256 caratteri. Vale per tutte le letture e tutte le conferme. |
Requests | Elenco di WebServiceMultiItemRequest | Sì | Le letture: una per tipo di dato. |
ReceivedRecords | Elenco di WebServiceMultiReceipt | No | Le conferme dei record ricevuti al giro precedente. |
WebServiceMultiItemRequest
| Campo | Tipo | A cosa serve |
|---|
TypeObject | DataType | Il tipo da leggere. |
QueryParameter | QueryParameter | Parametri della lettura. Counting viene ignorato; LimitRecord a 0 diventa 1000 (20 per immagini e file); senza IgnoreImportRecord la lettura parte sempre dal primo record. SQLFilter qui non è disponibile. |
WebServiceMultiReceipt
| Campo | Tipo | A cosa serve |
|---|
TypeObject | DataType | Il tipo del record confermato. |
Key | Testo | La chiave del record, al massimo 4096 caratteri, composta come per le conferme. |
I limiti
| Limite | Valore |
|---|
| Tipi per richiesta | al massimo 64, senza ripetizioni |
| Record per tipo | al massimo 1000 |
| Record per tipo con file | al massimo 20 per PRODUCTIMAGE, PRODUCTFILE, DHMANIMALIIMAGE, DHMANIMALIFILE, DHMUSERFILEALLEGATI |
| Record richiesti in totale | al massimo 10.000 (somma dei LimitRecord) |
| Conferme per richiesta | al massimo 10.000 |
Permessi e ordine di esecuzione
- Il server controlla l'intera richiesta prima di fare qualsiasi cosa: limiti, permesso di lettura su ogni tipo, permesso di scrittura su
RECEVEIDCLASS e di lettura sul tipo di ogni conferma. - Registra tutte le conferme in una sola transazione. Se anche una sola non riesce, non esegue nessuna lettura e risponde
ALERT: così non perdi record. - Esegue le letture nell'ordine richiesto e mette ogni risposta in
Responses.
WebServiceMultiResponse
| Campo | Tipo | A cosa serve |
|---|
ProtocolVersion | Intero | Versione del protocollo. |
Status | Testo | OK; WARNING se una lettura ha avuto problemi; ALERT se le conferme non sono state registrate; FAILED se la richiesta non è valida; keyinvalid o ko per chiave e errori generali. |
ResponseString | Testo | Messaggio del server. |
LastSQLExecute | Testo | Ultima istruzione eseguita. |
ErrorList | Elenco di WebServiceError | Errori della richiesta nel suo insieme. |
Responses | Elenco di WebServiceResponse | Una risposta per ogni lettura, nello stesso ordine, con i record nella lista del tipo. |
ReceiptResponse | WebServiceResponse | Esito della registrazione delle conferme. |
Il ciclo completo
JSON · articoli, prezzi, giacenze e immagini con le conferme del giro prima{
"ProtocolVersion": 1,
"GuidPC": "app-magazzino-01",
"Requests": [
{ "TypeObject": 19, "QueryParameter": { "LimitRecord": 500 } },
{ "TypeObject": 20, "QueryParameter": { "LimitRecord": 1000 } },
{ "TypeObject": 32, "QueryParameter": { "LimitRecord": 1000 } },
{ "TypeObject": 21, "QueryParameter": { "LimitRecord": 20 } }
],
"ReceivedRecords": [
{ "TypeObject": 19, "Key": "A0001" },
{ "TypeObject": 20, "Key": "A0001|1" }
]
}
- Primo giro:
ReceivedRecords vuoto. - Salvi i record ricevuti e prepari le loro chiavi.
- Giro successivo: le stesse
Requests con le conferme in ReceivedRecords. - Ti fermi quando tutte le
Responses tornano vuote, e mandi un'ultima chiamata con le sole conferme rimaste e Requests vuoto.