OSLC access to ressources, how to ?

This OSLC-RM is protected by the OAuth authorization protocol. You have to implement an OAuth client and create an OAuth consumer profile in DOORS to get your API authorized BEFORE you send any REST request, otherwise you will get the unauthorized error. I am not familiar with Java based libraries but i know it is easy to find and use one. Building an OAuth client and understanding the protocol should not take more than half a day to a day. Creating an OAuth provider is another story...

Note that DOORS 9.4 + DWA 1.5 use OAuth 1.0a so this is the logic your OAuth client should adopt. 

See this flow chart : 

http://1.bp.blogspot.com/_nQ8R-170d3c/TGhAm7S5IxI/AAAAAAAABBw/4fj85pULW1U/s1600/twitter-oauth-flow.png

See libraries and examples :

http://oauth.net/code/

See the specification 1.0a in our case :

http://oauth.net/core/1.0a/

See the getting started article :

http://oauth.net/documentation/getting-started/

As for the hierarchy, it is very clear, I even managed to display a tree representation of the database, just pulling data from the OSLC-RM implementation.

Here are a few hints :

once authenticated via OAuth, GET http://localhost:8080/dwa/rm/discovery/catalog.

the xml should display this type of node : 

oslc:serviceProviderCatalog rdf:resource="http://localhost:8080/dwa/rm/discovery/catalog/urn:rational:DATABASEID:1-4fe8345454562e6e-F-00454545"

AND / OR this :

oslc:serviceProvider rdf:resource="http://localhost:8080/dwa/rm/discovery/service/urn:rational:ers-4fe8454545a62e6e:1-4fe839f150a62e6e-M-00454545"

You are here at the root of the database. Make sure you have enough data to play with in your database to have a nice visible structure. So here it means there will be one node like this for each module, project or folder available to you at the root of the database. For each module available there will be a serviceProvider node like above and for each folder/project available there will be a serviceProviderCatalog node available like above.

If you GET the URL in the xml rdf:resource attribute of a serviceProviderCatalog node, you will get another serviceProviderCatalog xml containing the same types of nodes but this time this is the catalog of a new resource, which is identified by the URN contained in the URL you just made a GET on.

If you GET the URL in the xml rdf:resource attribute of a serviceProvider, you will end up with an serviceProvider XML containing the actual endpoints of all the services related to the module you are looking at, which is identified by the URN contained in the URL you just made a GET on.

With all these hints, look at the URLs provided, you will see the URNs of resources available in your usual DOORS client. The OSLC resources follow precisely the hierarchy of your database, given that the modules correspond to an OSLC-RM service provider and folders or projects correspond to OSLC-RM service provider catalogs (in DOORS implementation only of course, this is up to the tool vendor more or less).

Other useful tips : 

- In a URN if you see "-F-" in it, it means you are looking at the URN of a Folder OR Project. From the OSLC point of view no need to make the difference between folders and projects because both can contain modules, folders and projects. 

- In a URN if you see "-M-" in it, it means you are looking at the URN of a Module.

- Only Modules can contain Requirements, and they can only contain Requirements.

- In a URN if you see "-O-" in it, it means you are looking at the URN of a Requirement.

- A DOORS module corresponds to an OSLC service provider. 

- DOORS folders and projects are seen as catalogs only, because they do not provide services and catalogs can list other catalogs.

Useful URLs if you still have trouble navigating (but from an OSLC point of view this should not be hard-coded) :

I hope this helps,

Louis Madeuf

PS : please thumbs up my answers you find useful

Here are a few checkpoints :

- Be sure you have set your accept header to "application/rdf+xml"

- Be sure you have the right query base URL

- Be sure you have specified the right URL to your attributes called in your oslc query

here is a working example of a query to get all the requirements out of a particular module :

http://localhost:8080/dwa/rm/oslc/query/URN_OF_THE_MODULE?oslc.prefix=dcterms=<"http://purl.org/dc/terms/">&oslc.where=dcterms:created<= TODAYS DATE IN YYYY-MM-DD FORMAT

This query for this type of data (requirement) will only work for DOORS 9.4 + DWA 1.5

I hope it helped some of you !

ps : remove the quotes around the purl.org url, I put them here because the forum did not display the url correctly. This url is where the dcterms are defined (dublin core)

Are you using DOORS 9.4 ? Because OSLC-RM is not implemented in older versions of DOORS.

If you are, make sure you add the correct header to ask the server to respond in the right data format.

You need to set a "application/rdf+xml" header in your REST request parameters, otherwise the server will answer you with html by default, asking you to choose between DWA or DOORS.

To me it sounds like this is what is happening.

I hope this helps,

don't hesitate to ask more questions

Best regards,

Louis

Sorry for the delay.

1) The header you need to set is the accept header and not the content type header, as stated in the core specification here : http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#Service_Provider_Resources

2) You are not using OAuth properly. OAuth is working on a very precise workflow. DOORS 9.4 uses the OAuth 1.0a. Please read more about it here : http://oauth.net/

You need to understand the purpose of OAuth before consuming it : OAuth is NOT a normal authentication protocol. Its purpose is to help a third party (your application) getting a limited access to protected resources (DOORS database), this so called access being granted by the owner of the data (DOORS database user). By doing this, your application never knows your credentials to access the database. This is exaclty what happens when you use facebook to connect to another website. Read a very good article about OAuth here : 

http://hueniverse.com/oauth/

The login page you get is the page where the user says to the database "ok I grant access to my data to the user who requested it, here is my identity." You need to go through this step which is part of the OAuth workflow.

I hope this helps,

Best regards,

Louis

Well, I don't think it is a good idea since it is not supposed to work like this, it might cause security problems. As I said, OAuth is not an authentication protocol. You are trying to use it like if it was http basic Auth. The OSLC specification allows the implementation of OAuth, Basic Auth, or both. Because you might need to authenticate yourself to access your data but also grant access to an application that needs your protected data. I really encurage you to read the article about OAuth, it helps a lot to understand it and to find ideas about how to handle any bump on the "OAuth road".

I don't know if what you are trying to achieve is possible, but it should not be because of the protocol. There are many people out there trying to do this because they are not using OAuth properly. I am not sure but I think DWA 1.5 supports Basic http Auth as well, so maybe you should look into it because it will work the way you are trying to make it work right now.

If you still wish to use OAuth, here is how I managed to do it in .NET :

I use an embedded web browser in my winform which disappears when it redirects, so just after the user has logged in (because it redirects you to your callback url if access is granted).

Especially these two:

https://www.youtube.com/watch?v=v_OIghj-FSA

https://www.youtube.com/watch?v=F8KMnuVEqdo

And feel free to search for things such as OAuth within the YouTube channel, we have some very granular tagging of the vids and many more videos around integration.