Forgive me for the wording in this question, because the issue is so specific that I can't think of the terminology to accurately describe the issue.
The model for the virtual service is setup to have a live invocation step. The virtual service is setup for Standin Mode. There are no issues with the virtual service responses. However, when devtest hits the live service an issue arises.
Without using devtest, this is the what can be recreated:
1. Getting the WSDL at URL:
https://{hostname}/somepath/Service.wsdl
2. this is successful as the WSDL is downloaded correctly
3. Determining that {hostname} resolves to an IP: 123.123.123.123
4. getting the WSDL at URL:
https://123.123.123.123:443/somepath/Service.wsdl
5. This request is unsuccessful and the server indicates that the path does not exist.
My Thoughts:
I believe the routing rules in the webserver is looking specifically for calls that come from an unresolved URL. such as: https://{hostname}/
because DevTest resolves the hostname to the IP and then makes the same request, the webserver does not route the call to the desired backend path.
My Question:
Has anyone encountered this issue?
Does there exist a way to force devtest to utilize the unresolved hostname during the call out to the live service for the live invocation step?
Workaround:
Get the organization to accommodate this issue by creating routing rules with IPs (this is highly unlikely due to timelines and how the teams are setup)
It should be noted that the same issue occurs when using the devtest recording engine in the workstation.