Solved: Re: Remedy Wrapper / AppPortal VIP

dcopher · ‎Feb 25, 2020

We have a customer wherein AppPortal is configured behind a VIP. The routing has worked without issue up until now. When we Create Default Operations for Remedy integration we get the following error back. It looks like we need to allow the web server to talk to itself over the VIP. Can anyone validate this? Are there any other routing considerations beyond this?

Entry in ExternalSystems_Error.log
<![LOG[Error while connecting to https://<VIP_FQDN>/esd/WS/RemedyWrapper.asmx?wsdl Unable to connect to the remote server A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond <VIP_IP>:443 at System.Net.HttpWebRequest.GetResponse()
at AppPortal.Business.WebServiceInvoker.Connect(SystemLogoType SystemLogoType)]LOG]!><time="16:18:34.000+240" date="2-25-2020" component="Connect" context="" type="1" thread="2" file="Website">

jdempsey · ‎Mar 03, 2020

I haven't touched the Remedy integration in about 5 years, so I'm not exactly sure of all the steps happening here, but I believe the reason for the Remedywrapper.asmx is because Remedy includes complex types (embedded objects made up of simple types) in its web service parameters, while App Portal only understands simple types. So the wrapper will convert those complex types to simple types that can be properly displayed in our configuration UI. I'm wondering if it would be possible to create a hosts and/or lmhosts entry on your App Portal servers to redirect any calls bound for <VIP_FQDN> to localhost (127.0.0.1) instead. The issue with pointing to the VIP in that case is that firewalls tend to disallow intranet traffic to traverse through the outbound firewall to hit the public VIP address and then round-trip back through the inbound firewall back to the intranet. If you were able to set up a local hosts entry, then instead of going out and back in using the VIP address, it would simply send the request to the loopback adapter on the local server.

Anything expressed here is my own view and not necessarily that of my employer, Flexera. If my reply answers a question you have raised, please click "ACCEPT AS SOLUTION".

View solution in original post

jdempsey · ‎Mar 03, 2020

I haven't touched the Remedy integration in about 5 years, so I'm not exactly sure of all the steps happening here, but I believe the reason for the Remedywrapper.asmx is because Remedy includes complex types (embedded objects made up of simple types) in its web service parameters, while App Portal only understands simple types. So the wrapper will convert those complex types to simple types that can be properly displayed in our configuration UI. I'm wondering if it would be possible to create a hosts and/or lmhosts entry on your App Portal servers to redirect any calls bound for <VIP_FQDN> to localhost (127.0.0.1) instead. The issue with pointing to the VIP in that case is that firewalls tend to disallow intranet traffic to traverse through the outbound firewall to hit the public VIP address and then round-trip back through the inbound firewall back to the intranet. If you were able to set up a local hosts entry, then instead of going out and back in using the VIP address, it would simply send the request to the loopback adapter on the local server.

Anything expressed here is my own view and not necessarily that of my employer, Flexera. If my reply answers a question you have raised, please click "ACCEPT AS SOLUTION".

dcopher · ‎Mar 06, 2020

I ended up changing the value for Site DNS Address back to the machines FQDN and getting default operations worked. Because of this I've posted https://community.flexera.com/t5/forums/replypage/board-id/App-Portal-Discussion/message-id/831

CharlesW · ‎Mar 06, 2020

I've always been under the impression that the "site DNS address" is only used when building links in notifications.. Based on your observations, I searched the source code to actually see all of the locations where the Site DNS address is actually used. It turns out (not surprisingly now), that the Site DNS address is used when building the path to the remedy wrapper. It's also used in a similar fashion, in a couple of other areas in the code. Unfortunately, I don't see any way to decouple the Rememdy rapper functionality from the Site DNS Alias.

jdempsey · ‎Mar 06, 2020

@dcopher Are you using the VIP to load-balance between 2 or more front-end web servers, or is it just directing to a single server? If just directing to a single server, then using the server FQDN in the site DNS alias setting will effectively get you to the right place but without going through the VIP. So if there are reasons you want traffic going through the VIP, you shouldn't change that site DNS alias. That's why I suggested the hosts/lmhosts file entry, since that would only impact traffic originating from that server and not other inbound traffic. Also, the link in your post goes to the reply page, so I'm not sure what you were intending to link to.

Anything expressed here is my own view and not necessarily that of my employer, Flexera. If my reply answers a question you have raised, please click "ACCEPT AS SOLUTION".

dcopher · ‎Mar 06, 2020

The customer is using the VIP to hide the actual address of the WebServer. You cannot get to the web server outside of using the VIP.

Here is the actual article i was trying to link.
https://community.flexera.com/t5/App-Broker-Forum/App-Portal-Site-DNS-Address-Value/m-p/137399

Ultimately we need to set Site DNS Address so that emails will generate the correct user facing URL but this also changes how App Portal calls the Remedy Wrapper and I'm guessing more internal calls.