Sincronizzazione delle Movimentazioni via WS

Nelle interrogazioni al WS per la sincronizzazione delle schede ho notato una cosa (diciamo così) strana: in presenza di numerose Movimentazioni, quando si interroga la "RecuperaIdMovimentazioni" e si indica la sola data di inizio intervallo ("dataEoraMovimentazioneInizio"), il Web Service risponde con un tempo compreso all'incirca fra i 2 e i 4 secondi, limitatamente ai venti elementi massimi restituiti ad ogni invocazione, e con un tempo crescente man mano che lo "startItemPosition" position approssima gli "itemsIndividuati".

Se invece specifico anche la data di fine intervallo ("dataEoraMovimentazioneFine"), valorizzata con la data di sistema, i tempi di risposta variano tra 18 e 34 secondi, in funzione del numero di "itemsIndividuati", ovviamente ottenendo lo stesso output, quindi senza un'apparente ragione per il maggior tempo impiegato (un'idea ce l'ho, ma preferisco tenerla per me).

La cosa negativa è che indicando solo la data di inizio intervallo, se il numero delle movimentazioni da restituire supera i 200 "itemsIndividuati", il WS genera un errore del tipo:

"Errore nei Dati di Input: La ricerca ha prodotto troppi risultati ([206])! Restringere i criteri di ricerca."

Se l'utente SISTRI da sincronizzare non è un produttore, non si ha garanzia che non diventino visibili movimentazioni precedenti all'ultima data di sincronizzazione, per cui è necessario tenere l'intervallo piuttosto largo, e se l'utente ha molte movimentazioni giornaliere si è praticamente obbligati a specificare la data di fine intervallo, generando così tempi di attesa irragionevoli per il completamente del processo di sincronizzazione in interfaccia utente.

Potrei specificare un valore per "movimentazioniDaMostrare" diverso da "TUTTE" per avere ad esempio solo quelle ancora da compilare, ma se l'utente nel frattempo ha completato schede usando la chiavetta, poi queste non riesco a sincronizzarle.

Faccio inoltre notare che specificare la data di fine intervallo con la data di sistema può anche generare il seguente errore:

"Errore nei Dati di Input: non è possibile specificare nel filtro un valore nel futuro per il campo [dataEoraMovimentazioneFine]! Per poter sottomettere una ricerca occorre passare un filtro valido."

Evidentemente esiste un drift di qualche secondo (o anche solo qualche decimo di secondo) nell'ora di sistema tra il server SISTRI e il client che effettua la richiesta, anche al netto della latenza di rete. Il problema è che sulla macchina su cui girano i miei test sono abbastanza sicuro che l'orologio di sistema sia sincronizzato in NTP, e comunque non sono amministratore e non potrei intervenire, quindi al momento sono costretto a sottrarre due secondi (empiricamente sufficienti) alla data di fine intervallo quando questa è impostata all'ora corrente. Ma la domanda vera è per quale ragione sia stato implementato un simile controllo, tanto più che le date delle movimentazioni sono assegnate da SISTRI e non è certo possibile inserirne di postdatate.

Ciao Riccardo,
il problema, come tanti altri è risolvibile solo con la fantasia e un pò di
adattamento.
Io ho creato un eseguibile che esegue la lettura / sincronizzazione
in backend , a intervalli di 15 minuti , indicando solo la data e l'ora di inizio nel
filtro , cosi chè l'utente neanche si accorge dei tempi di attesa.
Chiaramente le movimentazioni sono 'appese' a una tabella temporanea
sul db. Il Programmino può girare sul server db o su un client , e con una opzione
può essere lanciato ad hoc , chiudendosi dopo aver letto i movimenti ( trucco - solo
quelli dall'ultimo letto a 15 minuti dopo ).

Spero di averti dato una buona idea.

Ok, ma in questo modo si è sempre sicuri che non ci sia una nuova movimentazione da sincronizzare precedente all'utlima letta, o anche precedente all'ultima volta che si è effettuata la sincronizzazione?

Se non ho capito male il meccanismo implementato da SISTRI, le movimentazioni effettuate dal produttore vengono rese visibili agli altri soggetti (nel mio caso specifico al trasportatore) solo dopo che il produttore stesso ha apposto la firma alla sua scheda, mentre il filtro che si passa alla "RecuperaElencoIdMovimentazioni" si riferisce alla data della movimentazione, non a quella della firma del produttore, quindi se passa del tempo tra la data di creazione della movimentazione e la data della firma ho comunque un problema:

- se sincronizzo a partire dall'ultima movimentazione letta, rischio di saltarne una creata prima ma firmata (e quindi resasi visibile) successivamente;

- se sincronizzo a intervalli regolari senza lasciare scoperta alcuna finestra temporale e becco il momento fra la creazione della movimentazione del produttore e la firma della scheda, finirò per non riuscire a recuperare la movimentazione, la prima volta perché non era firmata e quindi non ancora visibile, la seconda perché chiederò solo le movimentazioni successive alla data dell'ultima richiesta.

Sbaglio?
(spero di sì...)

mant62 ha scritto:Ciao Riccardo,
il problema, come tanti altri è risolvibile solo con la fantasia e un pò di
adattamento.
Io ho creato un eseguibile che esegue la lettura / sincronizzazione
in backend , a intervalli di 15 minuti , indicando solo la data e l'ora di inizio nel
filtro , cosi chè l'utente neanche si accorge dei tempi di attesa.
Chiaramente le movimentazioni sono 'appese' a una tabella temporanea
sul db. Il Programmino può girare sul server db o su un client , e con una opzione
può essere lanciato ad hoc , chiudendosi dopo aver letto i movimenti ( trucco - solo
quelli dall'ultimo letto a 15 minuti dopo ).

Spero di averti dato una buona idea.

Capisco il problema ,
io sfrutto il fatto che memorizzo sia le Schede che le Movimentazioni
sul Db , e me ne salvo lo stato, collegandole anche con i formulari cosi che anche se non sono state chiuse o non firmate , faccio prima una scansione di quelle memorizzate ancora da sistemare o chiudere.
Inoltre , per i miei clienti , faccio io le registrazioni cronologiche e quindi per quelle
il problema non mi si presenta.
Purtroppo gli strumenti a disposizione per le ricerche sono proprio 'poverelli' ,
speriamo che ci mettano le mani quanto prima.
Ciao , Riccardo , buon Lavoro.

Ah ecco, allora proverò ad aggirare il problema anch'io.
Non sono sicuro di poter fare lo stesso per via di come è progetto il mio client, ma proverò qualcosa di simile.
Grazie mille del suggerimento!

mant62 ha scritto:Capisco il problema ,
io sfrutto il fatto che memorizzo sia le Schede che le Movimentazioni
sul Db , e me ne salvo lo stato, collegandole anche con i formulari cosi che anche se non sono state chiuse o non firmate , faccio prima una scansione di quelle memorizzate ancora da sistemare o chiudere.
Inoltre , per i miei clienti , faccio io le registrazioni cronologiche e quindi per quelle
il problema non mi si presenta.
Purtroppo gli strumenti a disposizione per le ricerche sono proprio 'poverelli' ,
speriamo che ci mettano le mani quanto prima.
Ciao , Riccardo , buon Lavoro.