A web application isn't meant for this sort of "always-on" model. What you're essentially talking about is two applications (which can run on the same web server):
- A Windows Service (or scheduled console application, whichever you want) which does the background work of interfacing with the external system and updating the application's database. This is the "always-on" part. It polls the external system, gets the data it needs from it, updates the application database. Conversely, it can poll the application database, get the data is needs from that, update the external system. Basically, it does the ongoing background stuff.
- A Web Application which handles interaction with the users. This isn't "always-on" in the strictest sense. A web application is designed to receive a request and return a response. After that interaction, it's essentially done. Just waiting for other requests. So this application would just interact with the application database and present the users with the interface they need. From the users' perspective, this application is connecting them to that external system. But from a technical perspective it's just a simple web application connecting to a simple database, something else handles the interaction with the external system.
This provides the added benefit of separating your concerns into distinct modules. If you ever need to build another application to interact with that external system (maybe some kind of system-tray-installed monitoring service on people's workstations) then all that application needs to do is interact with the database, not with the external system.
Conversely, if the external system ever changes then you only have to change that background service, not the application(s) that the users use to interact with it.