Odata data source to Appgyver

[vinayakgole]

Hello.

I am trying to consume an odata service exposed from S4HANA on premise. However, I continue to get an error "The entered URL is not recognized as a valid odata service metadata". However, the odata is shows the results in the browser as well as postman. Here is the url for the same

https://testserver:44300/sap/opu/odata/sap/C_SUPPLIER_FS_SRV/$metadata

I went on the use the SAP Netweaver Gateway demo system. And it works perfectly. I am unable to understand what and where I am going wrong. Here is the Url for the gateway

https://sapes5.sapdevcenter.com/sap/opu/odata/sap/EPM_REF_APPS_PO_APV_SRV/$metadata

Could anyone please share if you have faced similar issues? And if there is any setting that needs to be done.

Thanks in advnce

Vinayak

[Dan_Wroblewski]

What does it say exactly? Can you provide screenshot?

[Deepan]

I might be wrong but it looks like you will need to expose that test server url as a public url before you can use it as a datasource in Appgyver. If you can share a screenshot of the postman/browser results and the appgyver error screenshot that will help troubleshooting the issue.

[former_member830564]

Vinayak,

I’m going to brainstorm this and just write the first few things coming to mind, hopefully one of those things will prove efficient for you! CORS is a picky beast, so you’ll have to “go down the list” until you find out the exact cause of the error, which I’m sure you know may have nothing to do with the verbiage of the error itself!

First, when you said that you whitelisted CORS, did you (1) add the AppGyver URL, (2) test a wildcard (temporarily, of course), or (3) try both options?

Before anything else, I would try a temporary wildcard to ensure that it’s not a global error, e.g.

• Access-Control-Allow-Origin: *

If you could test a separate instance of OData, meaning separate from AppGyver, now would be the time while using the wildcard temporarily!

Next, why are you leaving Headers blank under Configure OData integration? I’m pretty sure THIS is your problem as you need an Authorization header simply in lieu of an apikey! After all, you are using Basic Authentication! Take a look at this guide as I think it’ll help you a lot:

https://forums.appgyver.com/t/how-to-solve-cors-issues-with-sap-api-management/9752

Though, I’m fairly certain that will be your fix, I will brainstorm a couple more ideas. I also think you should look at the following link that I actually came across last week and remembered it. It’s a great overview of CORS and the necessary headers in general:

https://www.bannerbear.com/blog/what-is-a-cors-error-and-how-to-fix-it-3-ways/

Third, another thought is the version of OData needs to be compatible with the type of data that you are using as some versions don’t play nice with certain datasets. One example would be AppGyver not working with atompub XML and OData v2, however JSON should work just fine with OData v4! (JSON could even be problematic with OData v2.) Just use the latest supported version of OData and you should be fine from that angle! I don’t think that this particular one is your culprit, but it’s worth looking into if the above didn’t already solve it. I still can’t stress it enough how much I think the addition of an “Authorization” header will work for you!

Another thought that I just realized when looking at the URL of the server that you’re using is the non-standard port number for https! If I understand correctly, your gateway worked just fine using the default port 80 (or at least https’ default port 443), so it could be blocked by a firewall rule or similar! The port would also need to be configured to take advantage of OData at your actual test server. Check those Linux logs in detail, especially the firewall logs! It may be as simple as whitelisting the port in the server firewall or ensuring that the port is actually being listened to! I would think this may just be the issue provided the standard ports worked when testing with the gateway, you could always test OData with another method to verify this is the case! By now we’re down to the highly improbable, so this is where I call it a night{

Please do let me know what happens.

Be well and be safe!

[vinayakgole]

Hello Everyone,

I have checked the CORS as well as the whitelisting. CORS is already updated and I have added the whitelist for Appgyver, I still continue to get the CORS error. Any advise?

Thanks and best regards

Vinayak

[yogananda]

vinayakgole78

you should have this in your url to avoid CORS issue or you can develop extension with installing cors to avoid.

Access-Control-Allow-Origin should be *

[former_member830564]

yoganandamuthaiah though technically correct, I would only suggest using the wildcard (*) for testing or troubleshooting purposes as it still leaves a minute chance for certain attack vectors secondary to being open globally. Once tested and proved working with the wildcard, I would immediately change Access-Control-Allow-Origin to the correct associated URL. Imagine the possible repercussions that could result from using the wildcard too liberally when configuring _ALLOW entries in csf.conf (or similar firewall configuration file). They both could yield very similar results! Please don’t take this the wrong way, but the careful way is the only way in this day and age.

I also noticed that Basic Authentication is being used when an apikey would be the preferred methodology. Either way, Headers is blank under Configure OData integration. An “Authorization” Header should resolve this in lieu of an apikey, but since you still need to put a similar “key” in the Headers, you may as well take the safe route and just go apikey.

I’m fairly confident (~95%) that an “Authorization” Header would resolve this where it currently stands (read: using Basic Authentication), but Access-Control-Allow-Origin still needs to relate to the correct associated URL as a best practice.

Please see my earlier comment to vinayakgole78 as I delved a bit into the 5% that I’m not so sure about! There are a couple of other items of interest that could go into the resolution, and though unlikely, they’re not outside of the realm of possibility.

Be well and be safe.

[vinayakgole]

Thank you for your responses. Please find attached the screenshots of the errors.

@deepanshanmugam : The url has already been exposed as Public Api

1. cors.jpg : Error in Appgyver along with Developer Tools