Unable to match incoming request to an operation.

[webdes03]

I have an OpenAPI definition (Swagger) for an anonymous endpoint (authenticated by providing a licenseId and appId as header values). This OpenAPI definition works with Logic Apps and Nintex Workflow Cloud, but not with Flow. I imported the defintiion, and set security to none (same exact steps as Logic Apps), all of the operations are correctly identified, but when I test it I get odd/incorrect results.

The request url should be https://dev-api.elasticocr.com/v1.0/jobs/{jobid}, but Flow is sending it to msmanaged-na.azure-apim.net

Request

Url:

https://msmanaged-na.azure-apim.net/apim/elasticocr.20.2d.20dev.5fae991b2e953c45e5.5f0447122807b1e5c...[jobid]

Headers:

{
  "Authorization": "Bearer {token}",
  "licenseId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "appId": "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"
}

licenseId/appId removed for security purposes, but I can't figure out why it's sending the request to a different domain, and why it's including a bearer token given that the API is technically anonymous. We do not see these issues in Logic Apps, only in Flow.

Security is correctly configured:

As a result of the wrong request URL, the response is obviously also incorrect:

{
  "error": "{\r\n  \"code\": 404,\r\n  \"message\": \"Unable to match incoming request to an operation.\",\r\n  \"source\": \"msmanaged-na.azure-apim.net\",\r\n  \"path\": \"\",\r\n  \"clientRequestId\": \"53c6068c-9566-4b87-8311-c117-0304008c\"\r\n}"
}

I have seen a few reports that msmanaged-na.azure-apim.net/apim is used as a proxy if the API is protected by OAuth, but in our case it obviously isn't and security is set to none, so I'm baffled as to what's going on here. Any advice or insight is appreciated.

[webdes03]

Follow up: I created a postman collection with just a single one of our endpoints in it, and tried importing that into Flow and get the same behavior. So it's definetely something on the Flow side.

[v-yuazh-msft]

Hi @ webdes03,

Could you please share a screenshot of the configuration of your flow?

Do you mean the flow would send the request to a different domain? tThe request url should be https://dev-api.elasticocr.com/v1.0/jobs/{jobid}, and the Flow is sending it to msmanaged-na.azure-apim.net:https://msmanaged-na.azure-apim.net/apim/elasticocr.20.2d.20dev.5fae991b2e953c45e5.5f0447122807b1e5c...[jobid]?

Could you please share more details and screenshots with us?

We would try to offer you a proper workaround if you could share more details and screenshots with us.

Regards,
Alice Zhang

[webdes03]

@v-yuazh-msft unfortunately I can't even get past testing the connector, so I haven't even gotten to trying to put it into a flow.

At one point the requests randomly started returning 200s and 201s (which is the way it should work). But I have no idea what I did to make it work. I thought maybe Flow had cached an old/bad version of our Swagger definition. Then I deleted the connector and rebuilt it and it's back to not working again.

The simplest endpoint in our Swagger definition is one that validates a license. It takes a header paramater for a License ID and App ID, and returns a license response if the license is valid. This is the endpoint I've been using to test the connector since it basically has no moving parts.

As you can see, if I test the endpoint through Swagger's integrated testing functionality, the endpoint works as expected. It should also be noted that this API works in all of our native apps, as well as with Logic Apps and Nintex Workflow Cloud. Flow is the only platform we're having issues with.

As you can see from the Swagger test, the request URL should be:

https://dev-api.elasticocr.com/v1.0/license

If I now go to Flow and test that endpoint, we see that the Request URL is incorrect, and Flow returns a 404 claiming the request can't be matched to an operation.

If I had to theorize what's going on... Flow is modifying or changing the request that gets send to our API. We don't do any sort of source checking, so even if Flow is sending it through a proxy (which I suspect is what the msmanaged-na.azure-apim.net URL is), it shouldn't matter on our end. Even then though, as I understood it Azure Logic Apps and Flow are incredibly similar under the covers, so I certainly can't explain why everything validates in Logic Apps, but not flow.

I'm really tearing my hair out here... there's no rhyme or reason as to why it shouldn't work. The API is technically anonymous, save for the License ID and App ID headers, so there's no authentication (OAuth, etc.) in play. I've also tried scrapping our Swagger Definition and just creating a Postman collection with only the Get License endpoint in it, and I get the exact same behavior.

[tpalmer]

Hi @webdes03 - could you send me a link to the swagger or attach it in a direct message? The ID of your custom connector in Flow would also be usefuly (found in the URL when you're editing the connector). Unfortunately there's a known issue with users hitting a 404 immediately after creating or updating the operation however that should be temporary (<5mins). If you're continuing to see the issue something else may be wrong. We do route all the requests through our central system before your API, so the "msmanaged-na" URL you're seeing is expected, however the correct parameters etc. should ultimately be forwarded to the API as you described. Once you send it over we'll try to reproduce it on our side and get to the root of the issue.

[webdes03]

@tpalmer - Absolutely... I'll DM you a link to the Swagger and a valid license you can test with. Ironically, it does seem to be working now, so perhaps we were just being bitten by your temporary 404 issue. Nevertheless, if you're willing I'd love to have you try it from your end to confirm.

[DavesTechTips]

Yes them 404 errors are priceless. You are never quite sure if you should continue to troubleshoot, of if you should go and have coffee and hope for the best  

[Anonymous]

I'm getting the same issue with a new Custom Connector for PowerApps. I formed the json and created the new connector without too many dramas though the open api document I created was not supported so I had to implement a number of changes in the json file, but that all works and is added to PA, however, I get a 

{
"error": {
"code": 404,
"message": "Unable to match incoming request to an operation.",
"source": "msmanaged-na.azure-apim.net",
"path": "",
"clientRequestId": "fe82a0f2-49a9-4d10-908d-3974ae08aeaf"
}
}

Session ID: 2e1f8645-0d00-4865-8cf5-92d3ca370f42

Now for any new data sources that I try to add (it will  only want a sharepoint data source or spawn this error), and it has been going on for about an hour (I've used a number of browsers including incognito). The only way I can get the data sources back is to kill the most recent PA session, and restart it but the error keeps coming back.

I am trying to get PA to send back drawing pen doodles to Sharepoint.

Cheers,

Richard

[gmCog]

@tpalmer 

We're currently experiencing this issue with our connector as well. For us, the issue is persistent (weeks). Can you give me some more details on the known issue? Microsoft has indicated that it could be from changing route, but we have not been able to reproduce that issue in our staging connector, and we're seeing the issue for new connections/flows as well. I've added some information in a GitHub issue.

Any help would be appreciated!

---

@tpalmer wrote:

Hi @webdes03 - could you send me a link to the swagger or attach it in a direct message? The ID of your custom connector in Flow would also be usefuly (found in the URL when you're editing the connector). Unfortunately there's a known issue with users hitting a 404 immediately after creating or updating the operation however that should be temporary (<5mins). If you're continuing to see the issue something else may be wrong. We do route all the requests through our central system before your API, so the "msmanaged-na" URL you're seeing is expected, however the correct parameters etc. should ultimately be forwarded to the API as you described. Once you send it over we'll try to reproduce it on our side and get to the root of the issue.

---

[EG040997]

@tpalmer We are experiencing the issue mentioned above as well since a couple of weeks now on two of our flows.

Can you help?

Many thanks in advance