Artifacts Types list from OSLC model
Accepted answer
The most mature API to get the type model of a project (or to be more precise, it's component), is to use their private API.
Therefore, use the following endpint:
https://<domain>/rm/types?resourceContext=https://<domain>/rm/rm-projects/<project_id>/components/<component_id>
The response will be self-explaining. In general, it contains all attribute-, resource-, and link types.
2 other answers
Have you looked at the OSLC workshop? There you can quickly see how to get to the artifact types defined for a project or component, looking at the creation factory for a service provider. And yes you could use the private API, but usage at your own risk.
For completeness, the DNG public API's that are available are:
RRC Reportable API - creating custom reports to be run from DNG or RPE, read only.
OSLC RM V2 API - the open standard way to programmatically integrate with DOORS Next Generation, there is an elaborate workshop to get you started; here the OSLC Workshop article. These programs can be from any language that support HTTP REST calls, e.g. Java, C# etc. Hence these are more flexible to run and can read and update DNG data, as part of a web server, or standalone, but have some limitations set by the current OSLC standard, for example module support. In release 6.0.5 extension have been added for modules.
DNG Server API's - starting with version 6.x, various public RM server API's have been added, also REST API's, for configuration management, task tracker, modules, ReqIF, and type import.
TRS 2.0 - the OSLC Tracked Resource Set open standard REST API to hook into the stream of low level changes done to resources in the DNG application (and other Jazz apps as well); read only.
Client extension capability - these are Javascript extension that are added as widgets you can run from the dashboard, and can be used to view and edit DNG data. It's more tailored to DNG, so has better module support, but is limited to run in a browser/javascript environment.
RRC Reportable API - creating custom reports to be run from DNG or RPE, read only.
OSLC RM V2 API - the open standard way to programmatically integrate with DOORS Next Generation, there is an elaborate workshop to get you started; here the OSLC Workshop article. These programs can be from any language that support HTTP REST calls, e.g. Java, C# etc. Hence these are more flexible to run and can read and update DNG data, as part of a web server, or standalone, but have some limitations set by the current OSLC standard, for example module support. In release 6.0.5 extension have been added for modules.
DNG Server API's - starting with version 6.x, various public RM server API's have been added, also REST API's, for configuration management, task tracker, modules, ReqIF, and type import.
TRS 2.0 - the OSLC Tracked Resource Set open standard REST API to hook into the stream of low level changes done to resources in the DNG application (and other Jazz apps as well); read only.
Client extension capability - these are Javascript extension that are added as widgets you can run from the dashboard, and can be used to view and edit DNG data. It's more tailored to DNG, so has better module support, but is limited to run in a browser/javascript environment.
And as I mentioned above, there is the private REST API, which you could reverse engineer looking at the requests/responses, but it isn't documented and supported, and can change over time, so usage at your own risk.
Comments
Yes, I did and I know this workshop well.
My concern is that I do not want to create any new artifact, but I need to download all artifact types available in the project.
I am aware of those APIs, but mixing those is making your application a one mess which is impossible to maintain.
I need to get artifact type URL server/rm/type/_TypeID for sepecific artifact name (Term), and I do not see any possiblity to do it using creation factory.
Just do a GET on the service provider catalog, then iterate over the service providers (correspond to project areas for the jazz-apps) and that will tell you the supported domain and vocabulary and the specific services that are provided will likely have resource shapes that constrain and describe the resource types supported by the service.
Comments
Jim,
Yes, you can iterate through all the oslc:resourceTypes under service catalog. Only concern is that you do not see artifact types names associated with those url links, so you are not able to figure out what is what.
I've had the same issue as well, for a different reason.
I'm working on a huge program of work with 30+ Project Areas that all need to be consistent with each other, and I've built a JavaScript app that walks through all the project areas service catalogs, extracting the metadata for Artefacts, Attributes, Data Types, Links, Workflows, etc., compares them with a master schema and each other and displays inconsistencies
The problem I'm facing is that there seems to be no way to relate resourceType (which contains the Artefact URIs we have assigned) with resourceShape (which contains the actual definition and metadata, but not the URI)
resourceShape is the only one that seems to not have the URI anywhere - Properties and their enumerated values, link types etc all have the propertyDefinition containing the URI