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:

Sample RDF/XML representation of element data
<?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 more information, check Publishing 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 (Technology Preview)

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 conceptOSLC Configuration Management concept
Cameo Model (.Master Resource)Component
BranchStream
Tagged CommitBaseline
Used Project (Branch)Contribution of a Stream to a Stream
For technology preview, OSLC Configuration Management support is read-only. This means that you can retrieve Streams, Baselines, and Components but not create them via the OSLC API.

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 consumer 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):

HTTP request body
{
  "name": "consumerNameGoesHere",
  "secret": "OAuthSecretGoesHere"
}


HTTP response body
{
  "key": "generatedConsumerKeyShouldBeHere"
}

Note, that keys generated following this approach will still need to be approved by an administrator through Teamwork Cloud Admin.