I would like to hear opinions/best practices for the following scenario:

I have an application A (C# app from a vendor that does not have an accessible database, it has a sqllite db but we don't have access to it) that needs to export small amounts of data to application B (custom C# homegrown app with a SQL Server Backend) every time a specific button is clicked on application b. Both applications will run on an internal network (intranet).

Options I thought about.

  1. Export data as a text file from application A to File Share and then read/import that text file from application B
  2. Call a Rest Web Service (let's call it application C) from Application A passing the data as JSON to the Rest Web Service and then the Rest Web Service will load the data to the database from application B.
  3. Call a Rest Web Service (let's call it application C) from Application A passing the data as JSON to the Rest Web Service and then the Rest Web Service will push the data to a queue (IBM ESB) and another application (application d) will be reading from the queue and loading the data to the database from application B.

I'm trying to find the best option taking a lot of points/best practices into account (scalability, error handling, simplicity, maintenance, etc.)

Thanks for your thoughts/suggestions.

  • What is your definition of small amounts? How likely is it that the amount of data which you are now describing as small is going to grow? Does application B need the full set of exported (in this case imported) data to work properly?
    – MJumper
    Commented Aug 24, 2016 at 6:29
  • Small amounts means in this case a single record consisting of probably 20-30 fields. It is not likely that the amount of data will grow however one thing to add is that Application A will be running from 10-20 machines and that number will grow so the export will be happening from each of those machines although each machine where application A is installed will be exporting different records. Yes application B needs the full set of exported (in this case imported) data to work properly, it will use the data from Application A for reporting purposes. Thank you for your time. Commented Aug 24, 2016 at 11:07
  • Does the export/import happen on a daily bases or does the data need to be up-to-date all the time (User 1 makes changes in App A, User 4711 need the data in App B immediately)?
    – MJumper
    Commented Aug 24, 2016 at 11:10
  • Good question, we haven't defined the scheduling yet, meaning the export will happen very frequently (maybe 20 times per machine per day) although the import to app b does not need to happen right away. I believe the data does not need to show up immediately. Commented Aug 24, 2016 at 11:20
  • One last question before i'm going to post my answer. :) Does the users in application B only need to know about the last exported set of data from each App A instance or do they need every state of the data exported? For example User 1 using App A sets Value1 to be '4711' and starts the export. He than changes it to be '4712' and exports it again. Does App B need to display both versions or the last one only?
    – MJumper
    Commented Aug 24, 2016 at 11:26

1 Answer 1


Considering the additional information in your comments i'd go for a solution like this:

Since your applications are both running in an intranet i'm assuming the availability of your service is more or less guaranteed.

App A - Running locally, used by one user per device

I'm not completely sure how to get the data from App A since you mentioned that you don't have direct access to the sqlite-db. I assume there is some way of accessing the data using something like an API,..?

Since your App A stores it's data in a sqlite db anyway, i wouldn't go for a local export to flat files. In my understanding you would be able to extract data from App A's Db anytime you want to. In case of a failure during sending the data you could rerun your export again without acctualy losing data.

Every time the export is started (triggered by App A saving?), send the data directly to your service. Verify if the service received your full set of data using a checksum or something similar.

I'd try to shrink the functionality and complexity of your code on the devices running App A to a minimum since the deployment on a uncertain or growing amount of devices can be time consuming and challenging.

App B

The App B doesn't need to know about your export/import process, service or App A.


Should accept data sent from any application knowing about the service and having the permission to do so.

The service accepts the data and processes them in one of the following ways:

Option 1

It directly writes the received data to App B's database and confirms the reception. Writing the data directly could lead to some issues like User X loads data regarding patient 1, the service receives a new set of data, User Y gets patient 1s data afterwards. They'll now get a different state of data. You would have to deal with this for example by notifying each client about updated data and reload every App B instance accessing data loaded before the service updated them.

Another reason for not writing data directly to App B's database could be the amount of devices and sent data which needs to be written by your service blocking your App B's database while doing so.

Option 2

It saves to received data to his own database, storing them temporarily. In case your imported data is not needed immediately you could fetch the data to App B's database every night or so. This would guarantee your users using App B to work with the same state of data the whole day, even though they wouldn't use up-to-date data.

Option 3

In case the amount of data sent to your service gets too big to proceed it immediately you could attach a queue to Option 2 to avoid a blocked service.


Since there has been a few ambiguities like how important it is for the data in App B to be up-do-date i'd go for service option 2.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.