Webservice call from an external partner through Reverse proxy

Team,

We have setup two IS, one designated as our Reverse Proxy IS and the other our Internal IS. We have also configured simple http ports (as a POC) on the Reeverse Proxy for both as follows:

  1. Gateway External Port: 8733
  2. Gateway Registration Port: 8732

Protocol: HTTP and all other settings are default.

Port Configuration for Internal IS: Protocol: HTTP and Port as “reverseproxyIS:8732”.

The challenge here is, the webservice descriptor (provider) which is hosted on our Internal IS, is still not available to be accessed by external partners.

Steps taken so far:

  1. Changed protocol to HTTP from HTTPS
  2. Ensure all the ports are changed to “Allow by Default”
  3. Gave the reverseproxy IS and port number in the WSDL port address…

but still unable to access the simple webservice from external environment. Please let me know if I am missing out any silly thing.

Hi
2. Ensure all the ports are changed to “Allow by Default”
==> you mean, you already set internal registration port’s access mode allow by default?

Can you able to at least a ping service from RG external URL as a test invoke from your browser?

invoke/wm.server/ping

Does it respond any thing or no?

ow great, some of them will known as the most wanted here

Yes, I have already done that. Thanks for your response though.

Please stop your spams. This is not the forum for that.

Hello RMG,

Thanks for your response. We are testing the web-service using SOAP UI tool. My Idea is, when we give the webservice WSDL to the external partner, we give the host-name and port of the Reverse invoke IS, right?

Not sure, somewhere I am making a silly mistake.

Yes you would give them the URL with external port on the RG server (if you want it route thru DMZ/proxy layer) for additional security measures.

HTH,
RMG

Have tried all the possible combinations to get this to work. But I keep getting this error message:

“HTTP Error 400 Bad request”

Which means the request from external client is hitting the internal server, but some error in data flow.

Did you check with your extenal client what data are they sending in the correct syntax?

Is that XML data?