Using the genOSLC Example Application

Using the genOSLC Example Application

The genOSLC Example application provides a fixed set of projects and resources whose domains and resources are configured in the application-local.yml file. The projects include:

image-20250731-153733.png
Example Projects

Select a project, component and configuration to see the available resources:

image-20250731-154036.png
Requirements Resources

Select a resource to view its links in the genOSLC Plugin:

image-20250731-154129.png
Resource Links

The rest of this document describes how the genOSLC Example application is configured to enable link to ELM resources, and then demonstrates creating those links, previewing and navigating to linked resources, and link validation.

Configure for Integration with ELM Servers

For OSLC servers to be able to preview resources in other servers and create links between resources managed in each server, two things are required:

  1. The servers must be configured to authorize incoming and/or outgoing OSLC HTTP asses

  2. The service providers must be associated between the servers to enable OSLC discovery for what resources and links are supported.

OSLC authentication and authorization is often challenging to configure and maintain. A brief explanation of the concepts will be helpful in understanding the configuration settings, and in addressing connection issues. Many of these issues arise from OSLC server implementation variability that has to be carefully documented.

For OSLC discovery and linking to work between OSLC servers, the servers need to be able to authenticate and authorize OSLC requests, and the available resources and link types between the service providers must be established. OSLC server-to-server authentication typically is done with OAuth to avoid requiring or exposing user credentials in these server-to-server requests. OIDC is preferred, but many OSLC servers, including ELM, only support OAuth1.0a. So both are supported in genOSLC.

The OASIS OSLC specifications recommends OIDC or OAuth1.0a for supporting server-to-server communications. ELM OSLC implementations established common practice for server-to-server authentication using OAuth1.0a by defining consumer and friend relationships between the ELM servers. Every OSLC server might make and/or respond to OSLC requests. Each of these incoming and/or outgoing requests must be authenticated. 

To support incoming OSLC requests, an OSLC server registers a Consumer (Inbound) to create an optionally trusted consumer key and secret. Other applications can use these consumer credentials to authenticate their requests.  Trusted consumers will be able to share their authorization with other trusted consumers. Users will not be prompted for approval to access data. Websites and applications external to your organization should be considered untrusted.

To support outgoing OSLC requests, an OSLC server creates a Friend (Outbound) that uses the consumer keys of the target server to authenticate the outgoing requests. ELM supports creating the friend in an OSLC server, and the consumer keys in the target OSLC server in the same operation. In this case, the consumer keys are provisionally created and must be approved for use by an administrator of the target OSLC server.

 You must create the ELM consumer key at the JTS level for the DOORS Next (RM), EWM (CCM) and GC applications. Having done that, Jazz will propagate the consumer information to the application level. This same consumer key can be used for all ELM applications except ETM (QM) to configure genOSLC Example server Outbound Details. A separate consumer key has to be created in the ETM server, it does not propagate the JTS consumer key.

In the ELM JTS, create a Consumers (inbound) consumer key to be used to authenticate access by the genOSLC Example server using an Outbound Details entry.

 

 

genOSLC Example Authentication and Association Configuration

For genOSLC Example to be able to link with ELM resources, consumer/friend relationships and service provider (e.g., project area) associations need to be established.

This authorization and association information is configured in the Example server settings. This configuration is done in the settings in the Plugin UI where the links are created. To access the Example server settings, you have to first select a project, component and configuration, and then select a resource in the configuration. Otherwise the plugin UI is not displayed and the settings button is not visible.

The genOSLC Example server configuration settings consists of four tabs:

  1. Friends: Used to connect to applications using Oauth2.0 (OIDC), and to identify the service provider catalog URLs (e.g., oslc_rm:rmServiceProviders) for creating service provider (i.e., project or project area) associations. 

  2. Inbound Details: OAuth1.0a consumer keys for allowing other applications to make inbound requests to this application. These are the (potentially provisional) OAuth1.0 consumer keys  that are created when you create a Friend in the ELM jts server to the genOSLC Example application. These keys allow the ELM servers to access the genOSLC Example resources. Note: when the friend is created by ELM, the consumer key is provisional. ELM provides a way to approve the key, but this does not work for genOSLC, you need to edit the Inbound Details and approve the key manually. 

  3. Outbound Details: OAuth1.0a consumer keys for allowing this application to make outbound requests to other OSLC applications. Provides the consumer key and secret for OAuth1.0a authentication with an ELM server this genOSLC server can access, and includes the rootservices URL and CORS protected URLs.  

  4. Associations: Provides the service provider (or Project Area) associations and domains that define what resources and link types are available for making links between source and target project areas

 

Setting a Global Configuration

The genOSLC Example server can use ELM GCM global configurations to resolve link references to versioned resources.

Create an ELM global configuration for the JKE Banking lifecycle project that has contribution from the CCM, RM and QM servers: JKE Banking Component Initial Development.

image-20250731-155543.png
Create a Global Configuration

 This requires enabling configuration management for the ELM RM and QM servers and project areas. See Activating configuration management in applications. RM and QM are not config enabled by default. You need to get a key from IBM and set it in the advance properties. Then you can config enable RM and QM project areas.

Then add a genOSLC Example local configuration to the global configuration.