Connecting Lifecycle Query Engine or Link Index Provider to applications that use a different Jazz Team Server

If you installed Lifecycle Query Engine (LQE) or Link Index Provider (LDX) on a separate Jazz Team Server (JTS) from the lifecycle management applications, first you add the client access licence for LQE or LDX on the JTS where the lifecycle tools are registered, then you create a functional LQE or LDX user that can run background tasks, you create an inbound consumer key for LQE or LDX on each lifecycle management application, and finally you add the data providers by using root services documents or URLs. This configuration ensures that LQE or LDX can access the IBM® Engineering Lifecycle Management (ELM) data.

Procedure

  1. In a web browser, open the JTS administration page: https://server:port/jts/admin.
  2. On the Server page, under Licensing, click License Key Management > Client Access License Types > Add.
  3. When prompted for a license, browse to the WEB-INF/classes/META-INF/licenses/TRS_Consumer_Internal.jar file in the lqe.war file. Follow the prompts in the wizard to accept the license agreement, and finish.

Creating the functional user that is required by LQE or LDX

Procedure

  1. On the JTS administration page, at https://server:port/jts/admin, in the Users menu, select Create user.
  2. Create the functional LQE user (for example, lqe_user) and assign the User ID and Email Address.
  3. Assign the TRS Consumer-Internal client access license.
    Note: If IBM Engineering Lifecycle Optimization - Engineering Insights (ENI) is installed on the same JTS, you must assign the TRS Consumer-Internal license to the lqe_user.
  4. Return to the Active Users page. Click the jts_user link. On the jts_user page, go to the Client Access License area, and select TRS Consumer-Internal.

Creating an inbound consumer key for LQE or LDX on each lifecycle management application

Before you begin

Start the server for each application that you want to configure.
Important: If the lifecycle management applications are deployed to the same JTS as LQE or LDX, it is not necessary to create inbound consumers. Complete these steps only if the applications that you add as data providers for LQE or LDX, such as IBM Engineering Workflow Management (EWM), IBM Engineering Requirements Management DOORS® Next (DOORS Next), and IBM Engineering Test Management (ETM), run on a separate JTS.

Procedure

  1. Create the inbound consumer key for LQE or LDX in each lifecycle management application.
    Open the application administration page:
    • EWM: https://host_name:port/ccm/admin
    • DOORS Next: https://host_name:port/rm/admin
    • ETM: https://host_name:port/qm/admin
  2. On the Application page, select Communication >Consumers (Inbound) and create a new OAuth Consumer key for LQE or LDX.
    Enter the consumer name LQE, a secret, and select Trusted. Then click Register.
  3. In the Authorized Keys list, edit the LQE entry by clicking the pencil icon.
    Note: The functional user lqe_user can be used for LQE as well as LDX.
  4. In the Edit Consumer Key Properties dialog box, click the Select User... link.
  5. Enter lqe in the filter field, and select lqe_user from the list of matching users. Click Add and Close, and then Finish.

What to do next

Now you can add your data providers by using one of the following procedures: For details about which TRS feeds to configure for ELM, see Choosing TRS feeds for Lifecycle Query Engine.

Correcting failed data providers

For LDX, some data providers are added automatically by JTS. And if the applications whose data providers are added in LDX are not local to LDX (registered with a different JTS) then those data providers can end up in a failed state.

Procedure

To correct the error, you can perform one of the following steps:
  • Remove the data providers and again add them.
  • Update the authentication properties for the failed data providers.
    • Enter the OAuth Consumer Key and OAuth Consumer Secret that was created in the earlier application.
    • You can obtain the OAuth URL from the root services document of the remote application.