We are having problems with our setup of the reverse invoke server. The setup involves using SOCK connection protocol between the RIS and Internal server. We can see http request of connection being made from the client to the external proxy port 5557 on the RIS. But we have no evidence of the request occurring on the internal integration server. We have a registration port setup on the reverse invoke server of 5556 which the internal server appears to successfully connect to. We have opened up the access of IP addresses and ACL to Allow by default for both the ports on the RIS. We have done the same for the Internal Server Access mode. We are also just requesting certificates. When the client sends a http request they get the error unable to connect to peer.

I would like to rule out that the problem is not on the webMethods RIS translation of ports from proxy port 5557 to 5556. We currently have the logs set on 10 with logging occurring for all facilities. We have not noticed anything on the logs indicating that the reverse invoke server has successfully translated the ports. Are there any other methods of monitoring the ports to ensure that the translation of ports is successful?

In the area of the admin where you registered the reverse invoke connections you should be able to see how many connections are registered. If there was a problem they will not have registered.
Also: you might want to check out a description I wrote a while back of reverse invoke to make sure you’ve got the right ports linked etc etc… (see [url=“Best Online Casino in Australia | Top Licensed Casinos for Gamblers”]Best Online Casino in Australia | Top Licensed Casinos for Gamblers).

If the RI proxy goes down (via restart or flakey network) the internal IS will not reconnect. In the past I’ve written a scheduled service that performs the admin functionality that registers the connections. There’s now a set of services under the WmPublic/pub.security/reverseInvoke folder to play around with this stuff… listRegisteredConnections might be the one you’re after.

You should try to get things working with the minimum of potential moving parts, so that means:

1. on the RI proxy open up a normal HTTP listener port (allow all services) on the rigistration port and attempt to connect from the internal IS to that port using telnet or lynx or a browser. This verifies that the firewall is at least letting you get from internal to the registration port.
2. Open a normal http listener on the RI machine on the externally available port (the one the other party will be connecting to). Verify you can connect and invoke a service like pub.math:addInts on the RI machine.
3. Blow both those ports away and attempt to get simple HTTP RI proxy setup going first using the Administrator account, try to invoke debugLog and verify it pops out on the internal IS’s logs.
4. Start locking things down by swapping over to using HTTPS. Sort out the CA certificates and all that mess as you go.

You should be able to track down what the issue is there. Like I said: keep it simple and one little step at a time, leave the SSL stuff til a few steps in as it usually complicates things if you jump in too early.

Anyhow, that’s the usual sort of process I go through.
Hope that helps.

regards,
Nathan Lee
http://www.customware.net/wmunit - WmUnit The webMethods testing framework