Che cos'è una buona architettura software per POS con modalità offline?

Question

Che cos'è una buona architettura software per POS con modalità offline?

#1 da (10 voti)

5

Ho un software per piccoli negozi di consegna (pizzeria, giapponese, ecc.) qui in Brasile che girano su alcune decine di clienti e ho la possibilità di estenderlo a molti altri clienti dopo averlo evoluto in un POS completo (Punto di vendita ).

Tuttavia, c'è una funzione critica che abbiamo faticato a sviluppare: una modalità offline. Internet in Brasile non è affidabile per l'uso commerciale, quindi è normale in alcune regioni avere problemi da alcune disconnessioni a settimana fino a disconnessioni per 0-90 minuti a giorni alterni.

Il software è realizzato in C # / Windows Form e il database MySQL è ospitato su Azure. I clienti si connettono allo stesso database e ogni tabella ha un CompanyId. È strategico avere un database online piuttosto che un server MySQL nella rete locale dei clienti.

Ho svolto una buona quantità di ricerche ma finora non ho trovato una soluzione o una direzione.

Abbiamo adottato un approccio: considerare l'installazione anche installare un MySQL e scaricare (se presente) i dati dell'azienda, il software si collegherebbe al database locale e ogni pochi secondi apporterebbe le modifiche dal database locale a quello cloud . Ma si è rivelato impegnativo e ha avuto un impatto sul design del codice (non può fare da zero a causa degli attuali clienti).

In questo momento considereremmo questa modalità da zero e la migrazione precedente.

design offline software-as-a-service

posta Talles Santana 12.01.2017 - 12:46

fonte

1 risposta

Leggi altre domande sui tag design offline software-as-a-service

Come uscire dal supportare le vendite di deadend? In caso di chiusura di una struttura di sondaggio

score 10 · Accepted Answer

L'opzione predefinita che vedo un sacco di persone è di avere un database locale con la stessa struttura e sincronizzarlo con il server. Questo è veloce da configurare e ci sono vari strumenti e librerie che puoi usare per implementarlo.

Tuttavia, non penso che questo sia un buon approccio.

Vorrei utilizzare un'architettura basata su queue / event store in cui le azioni sono archiviate localmente fino a quando una connessione è disponibile e quindi elaborata. Ad esempio, diciamo che ogni volta che effettui una vendita devi aggiornare il livello di scorte, che deve essere fatto sul server.

Una volta completata la vendita, crei un'attività "Aggiorna livello stock", con tutte le informazioni richieste e inseriscile in una coda (che potrebbe essere una semplice tabella di database)

Hai quindi un processo in background che monitora la coda e, se è disponibile una connessione Internet, rimuove gli elementi dalla coda uno alla volta e li invia al server per l'elaborazione.

Ciò consente all'utente di mostrare quali e quante attività sono in attesa di essere eseguite e consente di controllare la logica utilizzata quando si verifica un conflitto. vale a dire non ci sono scorte disponibili, ma la vendita è stata completata qualche tempo fa.

Inoltre, consente una migliore separazione delle preoccupazioni. Il database locale può essere una struttura completamente diversa da quella basata sul server.