API Management OData & Metadata

[#1]

Hi there,

While developing an OData API in SAP Cloud API Management that is binded and completly in sync with a backend S/4 Hana System, the resources that are exposed are only the entities that are created in the OData service, but we can still call the /$metadata and / for retrieving the metadata of the API. The API works but i need to add a policy for the APIKey that restricts the usage of the API to certain callers.

The problem is when adding the this policy the callers, even when passing a correct API Key, cannot access the /$metadata and / service, and the error says that the APIKey is invalid. Is it possible to bypass this without manually adding those resources in the API?

Thanks,

[dr_vup]

Hi Nuno,

yes, you can do this by using the "Condition" field of your policy.

Example could be:

<Condition>((proxy.pathsuffix MatchesPath "/$metadata") and (request.verb = "GET") != true)</Condition>

Check this for more details.

[Former Member]

Hi Cedric,

Thanks for your response. I was digging in this and i saw that actualy the request for /$metadata is working, only the request / is giving error for the api key.

Since the APIKey validation is in the preflow why the API Management gives the error that API Key is invalid?

While trying to add the condition for the / the editor doesnt give the option to update the policies. Is that beacause / isnt in the resources?

[dr_vup]

Hi!

I feel you! Using APIs with ressources, the root directory isn't accessible that easy. We did set this up by having 2 producs in line. At the first we added all ressources of this proxy, the second product is only having the main / root one (without any ressource). This was solving the issue. I raised that as a bug to SAP - but they told me it's a feature 🙂 Never ending story

[brandonleenaido]

Good day,

Have you been able to resolve this?

I am experiencing the same issue accessing /$metadata when my odata api has a verify api key policy.

I can access the resource with the APIKey no problem.

Regards,

Brandon