2

Currently, my thoughts are that GET requests would be feasible by using the concept of screen scraping combined with a cron job that runs at a set interval to scrape data from the GUI and sync to my own database.

However, I'm not quite sure how I would handle actions that seek to mutate the database that sits behind the GUI. I am quite certain I would need to interface directly with the GUI, but what tools are available that could help automate this by programmatically controlling the GUI?

Also, since an overall architecture such as this is far from conventional, I'm curious what strategies might be utilized to help scale a system such as this.

Note: It is acceptable for data returned from a GET request to be stale for at least as long as the cron job interval, and for POSTs and PUTs and the like to complete sometime in the future, let's say half an hour.

Note: Maybe my train of thought is completely idiotic and there's a better angle. I'd love to know.

J. Munson
  • 137
  • 3
  • Why are you trying to put a web based front end over a desktop app? Just use remote desktop like a normal person. – whatsisname Jan 04 '19 at 01:58
  • 1
    Why not talk to the DB directly? – candied_orange Jan 04 '19 at 02:07
  • @whatsisname because the desktop application must be accessed/driven programmatically – J. Munson Jan 04 '19 at 02:38
  • @candied_orange because no API is available. All interactions with the DB must go through the GUI. This is 3rd party legacy enterprise software I’m dealing with. – J. Munson Jan 04 '19 at 02:40
  • 4
    All interactions with a DB must go through the GUI WHY? I seriously don't care how legacy, how 3rd party, how closed source, or even proprietary, unless you would actually be breaking the law to reverse engineer your own API (see Google vs Oracle) to talk to the DB I honestly think it's unprofessional not to. – candied_orange Jan 04 '19 at 03:44
  • @candied_orange what do you mean “your own API”? It’s a 3rd party closed source desktop application, not “my own API”. As far as reverse engineering goes, perhaps there is a way to inspect the network traffic entering and exiting the application that I am unaware of? I don’t know what communication protocols are being used so I wouldn’t know where to start – J. Munson Jan 04 '19 at 04:03
  • 2
    @J.Munson If the desktop app has a database, there's a reasonably good chance that it uses one of the well known embedded database systems (SQLite, local MSSQL, Berkeley DB, the old Jet engine from VB, dbase files, etc). The first thing I'd do is inspect the files and try to figure out what it is using. – GrandmasterB Jan 04 '19 at 08:19
  • There are several ways to inspect the network traffic ([see wikipedia](https://en.wikipedia.org/wiki/Packet_analyzer)). There is also directly accessing the DB itself. You can also use hex editors and disassemblers to understand what the app is doing even without source. Don't let this application own you if you own it. – candied_orange Jan 04 '19 at 08:23
  • 2
    Are we down-voting this question, because it is a bad question, or because it is a bad idea? Bad ideas don't necessarily make bad questions. – Greg Burghardt Jan 04 '19 at 17:56
  • Thanks Greg. It's only a bad idea if there are obviously better alternatives. Currently, the two proposed ideas have been... 1. GUI automation (aka robotic process automation) 2. Reverse engineer the desktop application to understand how it is communicating with the remote database – J. Munson Jan 04 '19 at 18:13
  • @J.Munson: How to solve this best depends very much on the kind of application. For example if it is a .net GUI app, it is might be possible to bypass the GUI using reflection. If the app has a database it might be possible the extract the data. – JacquesB Jan 04 '19 at 22:51
  • 1
    The original GUI application developer probably never thought that the database may be used by another application in the future or that the database may outlive the original application. Perhaps he or she completely encapsulated all database access behind a dozen layers, possibly using some fancy ORM library, so that "you can easily change the database in the future", ending up with all business logic and all integrity constraints in the application. If that's the case, then reverse engineering becomes very hard, and programmatically controlling the GUI may not be such a bad idea, after all. – Christian Hackl Jan 30 '20 at 06:51

1 Answers1

1

If you can programmatically click buttons and retrieve data from the GUI application then you can wrap that program in a REST service.

I have been in a similar situation and wrote a web service which entered a code and clicked a button to automate a program which required a user use a code card on the machine.

In my case I used IIS .net (or vb6? cant remember) and wrapped windows api calls.

https://www.codeproject.com/Articles/14519/Using-Windows-APIs-from-C-again

Ewan
  • 70,664
  • 5
  • 76
  • 161