We had a Windows server that was both a web server hosting our web applications as well as the host for our webMethods IS proxy server. We had a web application that instantiated a VB DLL that in turn called an internal webMethods service through our proxy server. The VB DLL code was generated using the “Generate Code” option on the webMethods service from the Developper tool. All we did was fill in the proxy server setttings and let the server settings default.
This worked great until we moved the web server applications to another host server. We now have two physical servers in our DMZ, a dedicated webMethods IS proxy server and a web server. The web application in question was simply moved to the new server along with the VB DLL. The DLL was registered and all that other stuff. The problem is that it is no longer connecting to the webMethods server. It instantiate the object but is unable to connect. (The wc.context is not executing the connect method.)
I believe the problem may reside in the way we have our proxy settings and our server settings set within our VB DLL code.
Can someone please confirm if the following assumption is correct:
1- Proxy server, port, user & password are what we have setup as our external proxy and should not change from one server to another.
2- Server, port, user & password should be for our external IS server located in the DMZ?
Please let me know if additional info is required.
When you moved the webserver to the other box, did you register the webMethods.dll on that machine? In addition you need the java classes as well on that machine and in the classpath.
This should also be in the webMethods documentation (Creating Client Code -> Building a VB Client).
Yes the webMethods.dll was registered on the new box. The classpath and path have also been updated accordingly. My object is instantiating, but it’s not connecting. i.e. the create object is working, but when I try to connect it simply doesn’t connect to the webMethods server.
In regards to the Building a VB Client documentation, that’s what I need clarification on… when you use the generate code from the developer, it also creates a readme file. That readme explains that you need to set the location of the server and proxy server within your VB code. I believe my proxy isn’t the problem, but I believe the server is. Since the server is no longer on the same physical box, it can no longer connect to it. They were being defaulted to localhost and port 5555. What do I set the server values to? Do I refer to my external IS box and port? (Sorry if I’m not being very clear)
Are there any Windows services that need to be enabled to allow a web server to invoke a VB DLL that will invoke an internal webMethods service through a remote proxy server?
Assuming you’re using the reverse invoke proxy server in the DMZ, you’ll need to change your connection settings to point back to that server instance (instead of localhost:5555).
In my VB code, do I need to set both the proxy server and the IS server to the same value?
For example, if my proxy server is www.something.com on port 1234, when I use the context.connect method, do I also specify the server I’m connecting to as www.something.com on port 1234?
Could it be that my VB code is executing on one server and trying to talk to webMethods via a proxy server that resides on another server?
All this code works fine as long as the VB is executing on the same physical machine that also hosts my proxy server.