I tested an API connection in a desktop app. All it does at this point is request an authorization token. In the desktop app, this works fine. I need to perform this function in a WebApp but it doesn’t work.
I added a log entry to the beginning of my code to mark when it starts:
Var formText As String = RequestData
Session.MainSocket = New URLConnection
AddHandler Session.MainSocket.ContentReceived, AddressOf Extract_token
At the beginning of the Extract_token method is the line:
It appears the ContentReceived Event never fires in the WebApp version. Is there something different about the WebApp that would explain this behavior?
While this isn’t the solution to this problem, you’re headed for another issue…
Web Sessions always run on non-main threads. The events of sockets always run on the main thread. You’re going to need to keep track of which session the request came from and redirect the response to the correct session with a WebSessionContext.
The easiest way to accomplish this is to subclass URLConnection and do the following things:
- Add a private string property, mSession as String
- Add a Public Constructor with this code:
mSession = Session.Identifier
Implement each of the events and create matching Event Definitions. You can right-click on an implemented event and the last item says something like “Create Event Definition”
In each event:
Var ctx as New WebSessionContext(mSession)
RaiseEvent <method name>(<params>)
That is create the context and then call the event definition with the parameters that were passed in.
Have you tried to implement ReceivingProgressed ? That could tell you more.
While this might not be the direct solution, I’ll bet it heads me in the right direction. My fault for thinking moving to a web application after testing in a desktop application would be simple.
The thing to remember is that web apps have multiple simultaneous users whereas desktop has one. That’s the difference you’ll need to wrap your head around to be successful.
I appreciate the heads-up and I have made changes along the lines of your suggestions, however my original problem is still there.
I can run the app in the IDE and the webpage opens and populates with all the expected data.
When I build the windows EXE and execute it on the Windows Server 2012R2 system where I want it to run, the ContentReceived event does not fire.
When I copy it to a Windows Server 2019 system, it works perfectly.
Since Windows Server 2012 is listed as meeting the minimum system requirement I need to consider where to go from here.
Post a simple binary project showing the problem with some simple reproduction steps and I’ll run it on my 2012r2 server vm to see if I can see what the problem is.
Do you get at least part of the page ?
Have you checked to see if any of the other events are firing, like Error, HeadersReceived or AuthenticationRequired. It’s possible that the behavior is different because Windows 2012 is so old, since it uses the underlying framework calls.
Are you able to access the URL without issues from a browser?
I would love to do this, but I need to move forward with this project so I’ll probably try to find a way to implement it on one of the 2019 servers.
If you are curious and want to try to recreate the issue. I created a URLconnection subclass according to Greg’s suggestion, then for my test method I created a property with that subclass called MainSocket and used the basic code above (I moved the MainSocket from a Session Property to a WebPage property) to post form data.
As shown, the method in the AddHandler statement only needs to post a notice to a log, system log, etc., to show that ContentReceived did actually fire. On newer OS it does, on 2012R2 it did not.
OK. We can put this to rest. It is a connectivity issue on the 2012 server and ContentReceived isn’t firing because no Content was Received.
Greg, thanks for the suggestions on dealing with the Session information and my apologies to everyone else for wasting your time.
FWIW I am running all my Web Apps on two Windows 2019 Datacenters with URLconnection ContentReceived holding and returning an encrypted package (to tell it to send emails and convert HTML to PDF) and it is working very well.