Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

Starting a web server in OI desktop process

Hi,

We need OI to be able to talk to another process running on each user's computer (the other process is actually a phone). To do this, we want to start a web server on a background thread within the OI process (by calling a c# function defined in a dll). I think it will be fine, but could this cause OI to malfunction in some way?

Comments

  • OI is single threaded, so just make sure you do it in a background thread, as you indicated you plan to do. Other than that, I can't really predict if there will be any conflicts. Indeed, I'd be interested to know if how well it turns out.
  • Does the phone app need to access the state within the running OpenInsight session, i.e. check what record the user has open on their OI form or does it simply need to access the OI database to get information? I'm assuming that since you want to do inter-process communication you are looking to access the state of the running OpenInsight program as opposed to data at rest in the database. If so, then accessing OI through a web server process might not accomplish what you need or it might add another layer of complexity.
  • edited September 2021
    The phone app needs to send some data to OI. The constraint is that the phone app is only capable of making a http request to a url. We can't make it do anything else (as far as i know, but the guy managing the phones probably hasn't tried hard enough).

    So we could do 3 things

    1. Put a http listener (web server) in OI, which will receive the data and then store it in a static variable (c#). Meanwhile, OI will poll this static variable every 5 seconds to retrieve the data.
    2. Create a separate process in which the web server runs, and when it receives data write it to a fie, which OI periodically polls.
    3. Have one web server that the phone app sends data to. This web server will trigger an OI process to run, which will in turn write the data to an OI table where the key of the table is the IP address of the sender. Meanwhile, each OI workstation will poll this table and lookup if its IP has any data. (We are actually currently doing this and it works, but I don't like it because the IP addresses could change, meaning a workstation receives another workstation's data. As we will soon be processing credit card tokens using this method, I want a safer method).

    And no, the phone app does not need to access the state of OI. It just needs to send info to OI.
  • Your original post said this:
    We need OI to be able to talk to another process running on each user's computer (the other process is actually a phone).

    Your last post said this:
    And no, the phone app does not need to access the state of OI. It just needs to send info to OI.

    This seems like two different things. Are both true?
  • Sorry I wasn't clear enough. This is actually all we need:

    We need a certain process running on the user's computer to send data to the OI running on the user's computer. This other process is only capable of making HTTP requests.
  • I think I understand what you are doing. We have a similar situation with at least one client I am aware of. HTTP requests are received through the OECGI (via our HTTP Framework) since that is the easiest way to communicate via HTTP. Then the code that handles the HTTP request will communicate to a running instance of OI using our SRP DirectConnect control.
  • Reading your comment made me realize that there is a simpler way to do this. In our particular scenario, I don't care if OI blocks while waiting to receive data, so I think I can use the sockets_function in OI to listen until a timeout period. I will see if that works.

    Thanks
Sign In or Register to comment.