Since version 2022x Refresh2, Teamwork Cloud OSLC API implementation has been moved to the Web Application Platform, resulting in a change of port and API URI patterns:
- OSLC API no longer uses port 8111 but relies on port 8443, as well as other Web Application Platform applications.
- OSLC root services document URI can be found using the following pattern - http(s)://WEBAPP_IP:PORT/oslc/api/rootservices.
- Each of the model elements is exposed using the following URI pattern - http(s)://WEBAPP_IP:PORT/oslc/api/oslc/am/{projectID}/{elementID}.
Note that the elementID here is an Element Server ID.
Note regarding migration
The old pre-2022x Refresh2 root services URI and element URIs will be automatically redirected to the new URIs via HTTP 301 redirect. After migrating to 2022x Refresh2, you must set the WAP URI value in the server field of the Teamwork Cloud esi.oslc configuration block in the application.conf file.
Teamwork Cloud has OSLC support and exposes model element data following OSLC Architecture Management (AM) and OSLC Configuration Management vocabularies. Along with core OSLC services provided in Teamwork Cloud, this enables smooth integration with other OSLC-compatible tools by linking resources in Linked Data fashion.
We expose the following model element properties:
- rdf:type (http://www.w3.org/1999/02/22-rdf-syntax-ns#type) - represents architecture resource type, which according to OSLC AM vocabulary is always a Resource (http://open-services.net/ns/am#Resource).
- dcterms:modified (http://purl.org/dc/terms/modified) - stands for the last element modification date.
- dcterms:identifier (http://purl.org/dc/terms/identifier) - the Element Server ID as used in element's URI pattern.
- dcterms:title (http://purl.org/dc/terms/title) - the name of the element
<?xml version="1.0" encoding="UTF-8"?> <rdf:RDF xmlns:oslc="http://open-services.net/ns/core#" xmlns:oslc_am="http://open-services.net/ns/am#" xmlns:dc="http://purl.org/dc/terms/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> <rdf:Description rdf:about="https://localhost:8443/oslc/api/oslc/am/b1acff2d-4396-4314-9dba-477d573ede16/50775427-bce2-4de4-b747-8ab82d294237"> <rdf:type rdf:resource="http://open-services.net/ns/am#Resource"/> <oslc:serviceProvider rdf:resource="https://localhost:8443/oslc/api/oslc/am/b1acff2d-4396-4314-9dba-477d573ede16/services"/> <dcterms:modified rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">May 16, 2018 2:08:52 PM</dcterms:modified> <dcterms:identifier rdf:datatype="http://www.w3.org/2001/XMLSchema#string">50775427-bce2-4de4-b747-8ab82d294237</dcterms:identifier> <dcterms:title rdf:parseType="Literal">Engine</dcterms:title> </rdf:Description> </rdf:RDF>
Currently, querying services are not supported. Model data can only be read through OSLC services and editing capabilities are not supported.
- We offer OSLC UI previews through integration with Cameo Collaborator for Teamwork Cloud. For this, you need to publish an OSLC resource.
- We provide OSLC delegated dialog support via Selection Dialog service for navigating the model tree and linking to AM resources from external tools.
OSLC Configuration Management Support
OSLC Configuration Management support makes Teamwork Cloud OSLC services configuration-aware. This enables Teamwork Cloud resource discovery at the branch or tagged commit levels. The entry point for discovery of OSLC Configuration Management services is via the <oslc_config:cmServiceProviders> property. Teamwork Cloud concepts map to OSLC Configuration Management concepts in the following way:
Teamwork Cloud concept | OSLC Configuration Management concept |
---|---|
Cameo Model (.Master Resource) | Component |
Branch | Stream |
Tagged Commit | Baseline |
Used Project (Branch) | Contribution of a Stream to a Stream |
OAuth 1.0a authentication
To ensure secure access to server resources via OSLC, OAuth 1.0a authentication protocol is used.
OAuth 1.0a requires consumer key and secret to be known before starting the authentication process flow. These can be created through Teamwork Cloud Admin as described in Managing OAuth client keys.
Alternatively, a pair of consumer key and secret can be generated manually via a service exposed in the root services document. The following HTTP POST request should be made to a consumer key generation service (jfs:oauthRequestConsumerKeyUrl):
{ "name": "consumerNameGoesHere", "secret": "OAuthSecretGoesHere" }
{ "key": "generatedConsumerKeyShouldBeHere" }
Note, that keys generated following this approach will still need to be approved by an administrator through Teamwork Cloud Admin.