MOB Sync nativa document da non sincronizzare

[luca.murzio]

Ciao, avrei l'esigenza di poter dire che un record di una tabella non deve essere preso in considerazione con la sync nativa. Si tratta di uno stato bozza che rimane solo su dispositivo fino a quando non viene confermato.
Ho provato a mettere in errore il document nell'onValidate con reason 10, funziona perchè non mi scrive nulla lato server, però mi sembra di capire che aggiorni la ZZ_SYNC e quando non è più in bozza e sincronizzo mi fa pasticci.

Sapete indicarmi se c'è un modo per dire che un record non deve rientrare nella sincronizzazione?

Grazie

[a.maioli]

Ciao Luca, quello che chiedi non è previsto e la soluzione che ti consigliamo è quella di sincronizzare il documento lato server anche in stato bozza e poi trattarlo diversamente lato server quando esso è in tale stato.

Le regioni sono di natura precauzionale e sono le seguenti:
1) Il database offline è pensato per essere una copia sempre riciclabile. Se succede qualcosa voglio poterlo buttare via e ripartire senza problemi.
2) La struttura dei dati è relazionale: non sincronizzarne alcuni potrebbe causare un'infinità di problemi ovunque, fra l'altro molto difficili da prevedere e trovare.

Se proprio vuoi, esiste la possibilità di mappare nella libreria SyncService la proprietà DontAddVariations (public bool) che impostata nel beforesave e resettata nell'aftersave permette di evitare che il documento venga inserito nel ciclo di sincronizzazione.
Poi puoi mappare il metodo public void SyncService.AddVariation(IDDocument doc, bool force) che permette di aggiungere il documento forzandone la sincronizzazione.

Comunque creiamo un'attività per tenere traccia di questa conversazione.

[a.maioli]

Abbiamo creato l'attività NPQ01621 per tenere conto di questa conversazione. Quando verrà valutata, potrai seguirne l'andamento con Instant Developer Roadmap.

[luca.murzio]

Ciao Andrea, risposta chiarissima. Nel frattempo avevo adottato la soluzione da te proposta, ovvero, le bozze vengono sincronizzate e non considerate poi lato server.

La funzione dontaddvariations l'avevamo già configurata per poter gestire correttamente le entità che devono essere sincronizzate rispetto al sistema di profilazione dell'ERP.

Hai detto che il db lato dispositivo deve poter essere cancellato e riscaricato. Ma cosa avviene se per esempio svuoto totalmente una tabella su dispositivo (senza passare da document) e poi sincronizzo? Mi effettua il download di tutti i record anche se sulla ZZ_SYNC del dispositivo non ha modifiche da sincronizzare?

Grazie

[a.maioli]

Se usi il metodo ResyncClass (lato mobile) puoi resincronizzare completamente una tabella. Nell'esempio MWind viene fatto quando si cambia l'impiegato e si scaricano i suoi ordini.

[luca.murzio]

Perfetto, io ho svuotato la tabella e fatto la resyncClass.
Ancora un'ultimissima domanda a tema.
Se ho una tabella gestita completamente in automatico dal framework di InDe con la sincronizzazione nativa, lato client non è modificabile, lato server sì (es. condizioni di pagamento che lato client vengono solo utilizzate, lato server ogni tanto capita che se ne aggiunga una nuova da gestionale). In questo caso se non forzo la resyncClass, quando sincronizza recepisce le modifiche fatte sulla tabella su server?

Grazie ancora

[a.maioli]

E' così. La sincronizzazione mantiene tutti i dati visibili dal dispositivo opportunamente sincronizzati. Le modifiche lato server devono cmq avvenire non solo a livello di record nella tabella, ma tramite i documenti.

[luca.murzio]

Quindi tutte le tabelle modificabili da gestionale devono essere forzate con la resyncclass, altrimenti non recepisce le modifice su dispositivo....

[a.maioli]

Esatto, in tal caso però usa la LastSync per trasferire solo quelli modificati dopo l'ultima sincronizzazione e non cancellare la tabella offline, che non serve.

[luca.murzio]

Ok, ho già testato questa soluzione con lastsync e resynclass e va bene. L'ho dovuta modificare leggermente perchè da dispositivo è possibile cambiare azienda, quindi il last sync non deve essere quello assoluto che arriva da dispositivo, ma quello relativo all'ultima sincronizzazione per l'azienda selezionata.

Per quanto riguarda la ZZ_SYNC sarebbe ottimo poter avere una vostra stored procedure o qualcosa di simile per scrivere la ZZ_SYNC secondo la vostra sintassi. Da gestionale, chiameremmo la sp a modifica dati e la sync differenziale potrebbe funzionare al meglio senza forzare le resyncclass.