OData Connectivity Errors in IDT

[Former Member]

The OData driver was introduced in SAP BusinessObjects BI 4.1. I need to create a semantic layer for my OData feed, so I'm using IDT to create a connection using the new OData driver in 4.1. Unfortunately, my OData feed does not accept the request from IDT and always returns a 401/Unauthorized error.

When creating the connection in IDT, I enter the Service Root URI, User Name, and Password. No proxy address is used. I get a 'SUCCESSFUL' response when I click the 'Test Connection' button. Furthermore, when I open the 'Show Values' tab, I can see the metadata (i.e. structure) of my OData feed. So far, so good. But when I attempt to run a query or view any of the actual values within a field, my OData feed responds with a 401/Unauthorized error. We looked at some logs on the OData server side and found that BusinessObjects is not sending the User Name and Password and that is why the feed returns a 401/Unauthorized error.

Has anyone successfully used the new OData driver for OData feeds that require User Names and Passwords? Have you seen this same behavior?

I set up connections in IDT for the sample OData feeds below and everything worked perfectly. I successfully ran queries with no errors at all. However, these sample feeds do not require authentication. My fear is that there is a bug in the new OData driver. Thoughts?

http://services.odata.org/V3/Northwind/Northwind.svc/

https://api.datamarket.azure.com/Data.ashx/data.gov/Crimes/

[Former Member]

This was resolved by fixing an oversight in our OData feed. The WWW-Authenticate header was missing the Realm attribute. The 401/Unauthorized error went away after resolving that issue.

The RFC2617 memo on HTTP authentication describes the requirements related to realms.

The realm directive (case-insensitive) is required for all authentication schemes that issue a challenge. The realm value (case-sensitive), in combination with the canonical root URL (the absoluteURI for the server whose abs_path is empty; see section 5.1.2 of [2]) of the server being accessed, defines the protection space. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, which may have additional semantics specific to the authentication scheme. Note that there may be multiple challenges with the same auth-scheme but different realms.

http://www.ietf.org/rfc/rfc2617.txt (Section 1.2)

[Terry_Penner]

Follow-up:  I understand from a colleague that the issue is resolved and there is not a bug in the new OData driver causing it.  Adam, ideally you could post a sentence or two on what the resolution was for future readers of your thread.