Considerando le informazioni aggiuntive nei tuoi commenti, opterei per una soluzione come questa:

Poiché le tue applicazioni sono entrambe in esecuzione su una rete Intranet, presumo che la disponibilità del tuo servizio sia più o meno garantita.

App A - Esecuzione locale, utilizzata da un utente per dispositivo

Non sono completamente sicuro di come ottenere i dati dall'App A poiché hai menzionato che non hai accesso diretto a sqlite-db. Presumo che ci sia un modo per accedere ai dati usando qualcosa come un'API, ..?

Dal momento che l'app A memorizza comunque i dati in un db sqlite, non andrei a esportare in file flat. A mio avviso, sarai in grado di estrarre i dati dal Db dell'App A ogni volta che lo desideri. In caso di errore durante l'invio dei dati, è possibile rieseguire nuovamente l'esportazione senza perdere dati in modo specifico.

Ogni volta che viene avviata l'esportazione (attivata da App A saving?), invia i dati direttamente al tuo servizio. Verifica se il servizio ha ricevuto l'intero set di dati utilizzando un checksum o qualcosa di simile.

Cercherò di ridurre al minimo la funzionalità e la complessità del tuo codice sui dispositivi che eseguono l'App A poiché la distribuzione su una quantità incerta o crescente di dispositivi può essere dispendiosa in termini di tempo e di sfide.

App B

L'app B non ha bisogno di conoscere il processo di esportazione / importazione, il servizio o l'app A.

servizio

Dovrebbe accettare i dati inviati da qualsiasi applicazione conoscendo il servizio e avendo il permesso di farlo.

Il servizio accetta i dati e li elabora in uno dei seguenti modi:

Opzione 1

Scrive direttamente i dati ricevuti nel database di App B e conferma la ricezione. La scrittura diretta dei dati potrebbe portare ad alcuni problemi come l'utente X carica i dati relativi al paziente 1, il servizio riceve un nuovo set di dati, l'utente Y riceve successivamente i dati del paziente 1s. Ora avranno uno stato diverso di dati. Dovresti affrontarlo, ad esempio, notificando a ciascun cliente i dati aggiornati e ricaricando tutte le istanze di App B che accedono ai dati caricati prima che il servizio li aggiornasse.

Un altro motivo per non scrivere dati direttamente nel database di App B potrebbe essere la quantità di dispositivi e dati inviati che devono essere scritti dal servizio che blocca il database di App B. mentre lo fa.

Opzione 2

Salva i dati ricevuti nel proprio database, memorizzandoli temporaneamente. Nel caso in cui i dati importati non siano necessari immediatamente, è possibile recuperare i dati nel database di App B ogni notte o così. Ciò garantirebbe agli utenti che utilizzano App B di lavorare con lo stesso stato di dati per tutto il giorno, anche se non utilizzerebbero dati aggiornati.

Opzione 3

Nel caso in cui la quantità di dati inviati al servizio diventi troppo grande per procedere immediatamente, è possibile allegare una coda all'opzione 2 per evitare un servizio bloccato.

Conclusione

Poiché ci sono state alcune ambiguità come l'importanza per i dati nell'app B di essere aggiornati, opterei per l'opzione di servizio 2.