Xamarin multi platform background database sync - sqlite

I am developing an application which collects data into a local sqlite database, and (when the Internet is available) synchronises the data with a server.
I understand roughly how to create a background task (in different ways for each platform, unfortunately), but I read in Xamarin Background Tasks...
As a word of caution, be aware of what service or application is accessing an application, for example a SQLite DB. Two processes can not access a file at the same time, unless read-only. Hence ensure only one process is performing actions on file’s or locked resources.
This worries me - I need both the background task and the app to be able to update a single database. Is it in fact possible for the background task and the main app to access the same database? If so, how does one go about avoiding "Database is locked" messages?

Related

Firebase messaging's spawned isolate and main app - how to pass data(Web)?

According to https://firebase.flutter.dev/docs/messaging/usage/
onBackgroundMessage(...) is running on its own isolate.
How do I pass data from that isolate (which automatically spawns and runs a top level function) to the main app without using persistent storage (sqlite/files) which isn't supported on the web platform?
Flutter Web does not support isolates. You are likely looking in the wrong documentation tab. Still, what you are looking for may just not be supported yet.
Web requires you to register a JavaScript Service Worker which runs in the background.
Unfortunately we haven't yet been able to establish a proper way of communicating with the Service Worker and Flutter applications. Right now, all web background code must be executed in the JavaScript Service Worker file.
EDIT:
In order to share data between WebWorkers and the app, you can try using the awesome Drift library (formerly Moor).
https://pub.dev/packages/drift
https://drift.simonbinder.eu/web/
You can offload the database to a background thread by using Web Workers. Drift also supports shared workers, which allows you to seamlessly synchronize query-streams and updates across multiple tabs!
You should be able to communicate with the background database web worker and save your data. If correctly setup, this will in turn update your frontend.
Maybe checkout this example: https://github.com/simolus3/moor/tree/develop/extras/web_worker_example

Synchronise users from PeopleSoft HRMS to an external application

I have an enterprise application which needs to synchronise user information from the centralised source. We have been so far been integrating using LDAP with AD using a daemon process.
However, In our next deployment we need to integrate with PeopleSoft HRMS (9.1). The application needs to periodically synchronise users with the PeopleSoft HRMS.
I wanted to check how to proceed on implementing this?
Is there a standard module which would expose these details or does it allow LDAP communication?
Any direction on how to consume user records will be helpful.
Webservices can be implemented with Integration Broker: https://docs.oracle.com/cd/E41633_01/pt853pbh1/eng/pt/tibr/concept_IntroductiontoPeopleSoftIntegrationBroker-076593.html
A more low-level approach could be done with an Application Engine.
Your enterprise application could generate an XML/csv.
You would make a record in peopletools that corresponds with the fields in the XML/csv file. Then you make a fileLayout. If you drag this fileLayout into the Application Engine peoplecode window, you get a template of what your code should be and you'd have to complete it with some paths to files and minimal logic to process and import the data into your user tables.
Remember you can schedule Application Engines with reccurence, so after setting this up all you need to worry about is that the file gets updated.
If you require validation you should also look into feeding the data to a Component Interface after reading it in via Application Engine.

Local and synchronized usage

After online registration, my mobile app must be able to be used without a network. It consists of a service and a UI, both accessing the same data.
I do not understand how to organize my application.
I known how to record data remotely (on my ROS) and locally but what about the synchronization between the two .realm?
This is should my app manage synchronization between these two db or is there another way?
When I create the user on my ROS, I get a .realm file on the device.
But it is unusable without User.LoginAsync (Incompatible histories exception).

Send data to DynamoDb over intermittent connection

I have an application that needs to send data to a cloud database (DynamoDb).
The app runs on a computer that can lose internet connectivity or be switched off at any time, but I must ensure that all data eventually gets to the cloud database.
I can assume the application will eventually be switched on, and will eventually get internet access back.
The app is written in VB .NET
What are some schemes for achieving this, and are there any ready-made products that already achieve this?
You could implement a write-through cache using a local DynamoDB instance (or even using SQLite). But without getting specific details about what kind of data you'd be storing into the database, and what data should be made available "offline" it's hard to say exactly how you should structure your application. You'll definitely want to not keep everything local, unless the volume of data is really small overall.
Then there is the problem of resolving conflicts that may occur during network partitions (ie. a client goes offline and makes some database modifications, while other clients also make modifications to the database; these need to be reconciled and it's up to you, and your users to determine how)
It's not a simple problem to solve.

how to sync data between company's internal database and externally hosted application's database

My organisation (a small non-profit) currently has an internal production .NET system with SQL Server database. The customers (all local to our area) submit requests manually that our office staff then input into the system.
We are now gearing up towards online public access, so that the customers will be able to see the status of their existing requests online, and in future also be able to create new requests online. A new asp.net application will be developed for the same.
We are trying to decide whether to host this application on-site on our servers(with direct access to the existing database) or use an external hosting service provider.
Hosting externally would mean keeping a copy of Requests database on the hosting provider's server. What would be the recommended way to then keep the requests data synced real-time between the hosted database and our existing production database?
Trying to sync back and forth between two in-use databases will be a constant headache. The question that I would have to ask you is if you have the means to host the application on-site, why wouldn't you go that route?
If you have a good reason not to host on site but you do have some web infrastructure available to you, you may want to consider creating a web service which provides access to your database via a set of well-defined methods. Or, on the flip side, you could make the database hosted remotely with your website your production database and use a webservice to access it from your office system.
In either case, providing access to a single database will be much easier than trying to keep two different ones constantly and flawlessly in sync.
If a webservice is not practical (or you have concerns about availability) you may want to consider a queuing system for synchronization. Any change to the db (local or hosted) is also added to a messaging queue. Each side monitors the queue for changes that need to be made and then apply the changes. This would account for one of the databases not being available at any given time.
That being said, I agree with #LeviBotelho, syncing two db's is a nightmare and should probably be avoided if you can. If you must, you can also look into SQL Server replication.
Ultimately the data is the same, customer submitted data. Currently it is being entered by them through you, ultimately it will be entered directly by them, I see no need in having two different databases with the same data. The replication errors alone when they will pop-up (and they will), will be a headache for your team for nothing.

Resources