- Flexera Community
- App Broker
- App Broker Forum
- App Portal/Remedy Create Default Operations
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Printer Friendly Page
App Portal/Remedy Create Default Operations
We are trying to recreate the Remedy Incident Status Management Service Wrapper and the Service Request Status Management Service Wrapper in our App Portal/Remedy integration. When I test the Third-party integration settings the response is valid, but when I select "Create Default Operations" it returns an error of "Unexpected error occurred on a send".
Has anyone experienced this and know what the solution is?
Full error is below.
<![LOG[Error while connecting to https://<customerdomain>/esd/WS/RemedyWrapper.asmx?wsdl The underlying connection was closed: An unexpected error occurred on a send. Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. at System.Net.HttpWebRequest.GetResponse()
at AppPortal.Business.WebServiceInvoker.Connect(SystemLogoType SystemLogoType)]LOG]!><time="15:05:20.000+240" date="3-27-2020" component="Connect" context="" type="1" thread="2" file="Website">
This thread has been automatically locked due to inactivity.
To continue the discussion, please start a new thread.
Unfortunately, I don't have a Remedy instance to test/validate this against. Is the <customerdomain> pointing either to "localhost" or the App Portal server name? If pointing elsewhere, then some configuration is incorrect somewhere. If pointing to the App Portal server name, is that the actual server name/IP address, or is that an alias that's sitting on a load balancer/VIP? Is this issue the same as this other post? If so, I still highly suggest setting up a hosts/lmhosts file entry on the App Portal server that redirects that alias name to the local server name/IP, localhost, loopback, or 127.0.0.1, as the issue seems to be with traffic that is looping out to some other device on the network and then trying to come back into the server. Forcing it to the loopback connection (127.0.0.1) should prevent that round-tripping.
@jdempsey Thanks for the quick reply. I have added the loopback address into the hostfile. I have tried creating the default operations using both the VIP and the actual server name. The VIP responds with the error in the OP. The actual server name responds with a 403 error.