Known Issue: Data Virtualization API docs don't load with IIS Reverse Proxy

Issue

When a reverse proxy is set up using IIS and ARR, Data Virtualization API's docs don't load when accessed over HTTPS.

The error "No API definition provided" is shown, as is a yellow "INVALID" button.

This error message is different from when the docs of an API with no endpoints are viewed. In this case, the error message "No operations defined in spec!" is shown alongside the API's base URL.

Cause

When redirecting requests through URL rewrites, IIS doesn't preserve headers. Instead, it changes the Host header to the new domain, while keeping the Origin header as the old domain. Since these are different, CORS blocks the /export POST request which fetches the API definition from Flow, responding with 403 Forbidden. 

Workaround

Another URL Rewrite rule can be added to redirect /export to a new endpoint that accepts GET requests. This new endpoint is from a new Data Virtualization API, which must be imported. 

GET requests are not blocked by CORS in this instance, so the API docs can load correctly.

To implement the workaround:

1. Import the Project

Download api_spec.fsproject from the attachments section.

In the Flow UI, head to Projects > Import, and upload the attached .fsproject file. If not doing the import from an admin account, an admin might have to manually grant permissions.

Check that the project was imported correctly. First, navigate to Data Virtualization and looking for the API with title "api-spec". Next, navigate to Connections & Parameters > Deployment Parameters and check that the frontend_hostname parameter is shown. 

2. Set the Frontend Hostname

Select the frontend_hostname Deployment Parameter and set its value to the URL users will see in the docs. Use the format https://myfme.com/.

This value will be displayed in the API docs:

3. Verify the Imported Endpoint Works Correctly

Edit, then open the following links:

http://<backend Flow host>/api/api-spec/get?id=invalid

https://<frontend Flow host>/api/api-spec/get?id=invalid

Both should display the message:

{"message":"Unable to parse value \"invalid\" for parameter \"apiID\""}

If you see this message for the backend hostname but a 404 page for the frontend hostname, ensure your main proxy Inbound Rule > Match URL > Pattern is (^(api|fme).*). If using a version earlier than 2025.1, your pattern could be (^fme.*). The pattern (^(api|fme).*) includes URLs used by Data Virtualization APIs.

4. Add a New URL Rewrite Rule

Add a new URL Rewrite rule under the Default Web Site. The rule should be configured as follows:

Name: API Redirect
 
Under Match URL:

• Requested URL: Matches the Pattern
• Using: Regular Expressions
• Pattern: fmeapiv4\/datavirtualization\/([a-z0-9-]+)\/export

Under the Action heading: 

• Action type: Redirect
• Redirect URL: https://<frontend hostname>/api/api-spec/get?id={R:1}
• Append query string: [unchecked]
• Redirect type: Permanent (301)

Ensure the Rule is Enabled and Above Any Others 

4. The Docs Should Now Load as Expected!
Try to open the API-spec docs and check if the /get endpoint is displayed.

Verifying HTTPS Certificates

By default, the workspace does not verify HTTPS certificates when requesting the API docs from the backend Flow server. To change this:

1. Open the Endpoint Workspace in Workbench

2. Set the Default Value of the User Parameter to Selected

3. Save and Publish to Flow

Troubleshooting

The best way to troubleshoot is to use Developer Tools. In your browser, open Developer Tools (F12 for Chrome on Windows), navigate to the Network tab, and refresh the page. The expected behaviour is for the /export endpoint to return a 301 response, and the /get endpoint to return a 200 response. 

• If the /export endpoint returns a response other than 301, check your IIS configuration.
• This is likely expected behavior if the /get endpoint has a 404 or a 422 response. Click the endpoint, navigate to Response, and check the error message. 

• If the /get endpoint has a 500 response, something went wrong in the workspace. Locate the job log on the host Flow server and troubleshoot in the workspace. The workspace referenced in the job log will be 
  api-spec-GET.fmw, and it will have a successful status, but will have runtime errors. This can be debugged in Workbench as usual. If problems persist, please contact support.