0

Greetings.

I was working on a project which will consume a REST API located at a server say www.this-server.com and there will be a Windows Forms Application using C#, let's call this application X.

This X will be installed on several machines at different locations across the globe, and they would be utilizing the application. Suppose there are 90 stations or machines where X is installed but internet is connected only to say 85 of the stations.

What I want is that remaining 5 stations should not stop working, I mean CRUD operations take place offline in the local database of the application X.

As soon as there is a network available, 5 remaining stations should sync their changes to main API at www.this-server.com and get any changes happend to the server in the meantime.

I know it would require something like this, the so called smart client: https://www.codeproject.com/Articles/1134703/Net-application-that-works-online-and-offline-Sma

But what I am having problem is that suppose, there is a auto-increment field in several tables in the API, how would those be generated at all and would there be any conflict.

Something kind of this: https://dba.stackexchange.com/questions/104700/sync-many-client-database-to-one-central-database

I mean is that thing even possible, it could have been possible if the application X had single instance running at once, but in my case there are 90 simultaneous utilization of the API.

Any help, teachings, advice would be highly appreciated. Regards Jayant

PS: I am a newbie developer and still learning, so a lot to go and see, don't get angry over me :-D.

Coder Marine
  • 73
  • 10
  • 2
    This is too broad as written. Just search for offline app synchronization patterns. If you're worried about IDs, then use dummy IDs on the offline client until the data is sent to the server and replaced with real IDs. – Dan Wilson Jul 12 '18 at 19:25

2 Answers2

0

Are you completely locked into using REST?

I'm assuming you are using this as the transport mechanism to send data from X to the server. If X doesn't have connectivity to the server then maintaining a local copy of any changes that have been made is going to be really cumbersome.

You can considere the possibility of using a different transport mechanism, such as MSMQ. This seems like it might be a better fit for this type of application as MSMQ would store the message locally until such a time as it can connect to the remote system. If there is connectivity then the message can be sent immediately. just as if you were making a REST call. MSMQ can even be configured to send over HTTP ports if that is a requirement. Possibly you could utilize an approach of using REST to retrieve data from the server and using something like MSMQ to send data to the server.

Bhargav Rao
  • 50,140
  • 28
  • 121
  • 140
kooch
  • 107
  • 1
  • 5
0

If you cannot change the server you will have to write a client (X) that can differ between synchronised records and not synchronised records.
I would either create a second store for unsynchronised stuff or create extra fields marking a record as unsynchronised. When connecting I would then do some magic to update the local ID. The local ID cannot be autoincrement.

Preferably, if you can change the server, I would instead opt for not using the autoincrement in the REST API. Instead I would use a Guid which can be created globally unique by anyone.
For performance reason you can use the integer autoincrement ID locally. But for any communication with an external system, hide the ID and use the Guid instead.

LosManos
  • 7,195
  • 6
  • 56
  • 107
  • Thanks! However, your approach shall help me in implementing this thing better, but whatever @kooch suggested regarding using MSMQ would drastically improve performance since that mechanism is designed for something like this. – Coder Marine Aug 12 '19 at 10:50