Follow

System: Integration

Required permission

Global Roles: Edit ALM connections

Background: Understand: ALM Integration

SD Element provides integration with common Application Lifecycle Management (ALM) tools. Many of these tools have advanced configuration options. Rather than requiring each project team to setup advanced configuration for each project, administrators can create integration connections that hide connection details from individual project teams.

Refer to Project: Integrations: ALM on how to setup a project integration once these connections are established.

Add/Edit Integration Connection

You can create a new integration connection by clicking on the Add Integration Connection button. You can modify an existing integration connecting by clicking on its name from the System->Integration page.

Common fields include:

  • Credentials:

    • Name: A unique name for this integration connection.
    • Server: The domain of the ALM server. Ensure you select the correct method: HTTPS or HTTP.
    • Username & Password: Credentials for the user in ALM. This user should be able to create and edit stories/issues.
    • Token: The API Token for the user in the ALM. This user should be able to create and edit stories/issues.
  • Synchronization: Details for synchronization.

    • Choose authoritative source: You must select one tool to be the authoritative system of record: your ALM tool or SD Elements. This field is used in case of conflicting statuses between the ALM tool and SD Elements. When you first synchronize a TODO task in SD Elements to your ALM tool, they will have the same status. If you then change the status in one tool, for example by closing the issue in your ALM tool, then they will have conflicting statuses. If you select ALM to be the authoritative source, then the synchronization tool will update SD Elements task to match the status in the ALM tool. If you select SD Elements to be the authoritative source, then SD Elements will change the ALM status to match SD Elements. In most cases, you should leave this as the default: ALM. When you select ALM for this field, you should not modify the task status manually in SD Elements. You should instead change the status in your ALM tool and let the status be reflected in SD Elements by synchronization.

    • Include code sample How-Tos in task descriptions: Whether or not to include detailed code samples / How-Tos in the ALM issue.

    • Tasks to Synchronize: You can limit which tasks actually get synchronized.
    • Tasks having a minimum priority: Synchronize tasks with a minimum priority. For example, 7 or above. This is useful if you want to limit the amount of work for users.
    • Tasks with status: Synchronize only tasks with certain statuses, such as TODO or TODO and Done.
    • Tasks having phases: Synchronize only tasks in certain phases.

Other fields differ for each ALM tool.

CA Agile Central (Rally) (Advanced CA Agile Central Configuration)

  • Issue Type: The name of the type of issue that SD Elements should create when creating the equivalent of a task in the ALM. Supported values are "Story" or "Task".
  • States which map to DONE in SD Elements: A comma-separated list of issue states that map to DONE state in SD Elements. When you synchronize a task in SD Elements to a ticket in CA Agile Central (Rally), and the user changes the ticket state to anything listed in this field, the integration will mark the status of the corresponding SD Elements task as DONE. For example, if task "T1" in SD Elements is currently TODO, and you then synchronize it with Rally, and somebody changes the status of the issue to "Completed", then "T1" will be marked as DONE in SD Elements.
  • Open a CA Agile Central task in the following state: SD Elements sets the state of new issues in CA Agile Central (Rally) to this.
  • Rally workspace: The name of the Workspace in CA Agile Central (Rally).
  • Custom Fields: Any non-default custom fields that are required when creating an artifact in projects. These fields must be provided as a JSON dictionary similar to the following:

         {"custom_field_name": "field_value"}

  • Custom Lookup Fields (version 2.38+): Provide additional fields to use when matching tasks in CA Agile Central (Rally).

By default, tasks in SD Elements are matched with artifacts in CA Agile Central (Rally) using a task's title. Therefore, there can only be one "T21" task in a single CA Agile Central (Rally) project. By filling in "Custom Lookup Fields", additional constraints can be applied to matching. Upon synchronization, the process will look for any CA Agile Central (Rally) artifact sharing a task's title as well has having the field values specified in "Custom Lookup Fields". These fields must be provided as a JSON dictionary similar to the following:

         {"field_name": "field_value"}

Note: There are a few useful substitution values you can use in "Custom Fields" and "Custom Lookup Fields". Field values can use the following dynamic macros. Their values change depending on the project being synced.

  • ${application} - Application name
  • ${project} - Project name
  • ${context} - Value of 'Alm Context' in an integration setup

WARNING: Fields used in the "Custom Lookup Fields" section must be set via the "Custom Fields" section or by the default integration. Failure to provide values can cause the integration process to stop working, and create identical issues each time it is run.

JIRA (Advanced JIRA Configuration)

  • JIRA version: Which version of JIRA you are connecting to.
  • Issue Type: The name of the type of issue that SD Elements should create when creating the equivalent of a task in the ALM.
  • JIRA Reopen Transition: The name of a transition to reopen an issue after it has been closed.
  • JIRA Close Transition: The name of a transition to close an open issue in JIRA.
  • Priorities: If the standard JIRA priorities have been customized, then a mapping is needed between the customized priority names and the SD Elements numeric priorities. This mapping must be provided as a JSON dictionary similar to the following:

         {"10":"Blocker", "7-9":"Critical", "5-6":"Major", "3-4":"Minor", "1-2":"Trivial"}

  • Custom Fields: Any non-default custom fields that are required when creating an issue in projects. These fields must be provided as a JSON dictionary similar to the following:

         {"custom_field_name": "field_value"}

The custom_field_name value is the title of the field you see in the user interface. For example, use "Component/s" for the component field and "Affects Version/s" for the affected version field.

  • Custom Lookup Fields (version 2.38+): Provide additional fields to use when matching tasks in JIRA (version 5/6 only).

By default, tasks in SD Elements are matched with artifacts in JIRA using a task's title. Therefore, there can only be one "T21" task in a single JIRA project. By filling in "Custom Lookup Fields", additional constraints can be applied to matching. Upon synchronization, the process will look for any JIRA artifact sharing a task's title as well as having the field values specified in "Custom Lookup Fields". These fields must be provided as a JSON dictionary similar to the following:

         {"field_name": "field_value"}

The field_name value is the title of the field you see in the user interface. For example, use "Component/s" for the component field and "Affects Version/s" for the affected version field.

Note: There are a few useful substitution values you can use in "Custom Fields" and "Custom Lookup Fields". Field values can use the following dynamic macros. Their values change depending on the project being synced.

  • ${application} - Application name
  • ${project} - Project name
  • ${context} - Value of 'Alm Context' in an integration setup

WARNING: Fields used in the "Custom Lookup Fields" section must be set via the "Custom Fields" section or by the default integration. Failure to provide values can cause the integration process to stop working, and create identical issues each time it is run.

Mingle (Advanced Mingle Configuration)

NOTE: Mingle is a highly configurable tool. It is important to make sure you fill out the correct values for the advanced configuration in Mingle. It is unlikely that the synchronization will work without changing these fields. These fields vary by the template that you use (e.g. Scrum vs. Lean).

  • Card Type: The name of the type of card that SD Elements should create when creating the equivalent of a task in Mingle.
  • States which map to DONE in SD Elements: A list of all Mingle card states that map to DONE in SD Elements.
  • Open a task in Mingle in the following state: The name of the state for new cards in Mingle.

Rational Collaborative Lifecycle Management (CLM)

NOTE: Rational CLM support for syncing "Task" work items is available in the upcoming release 2.27

  • Application context root: The top-level location where the Change and Configuration Management (CCM) component is installed. Normally this is "ccm". For example, the project URL "https://rational-server:9443/ccm/web/projects/ProjectXYZ" would translate to an application context root of "ccm".
  • States which map to DONE in SD Elements: A comma-separated list of issue states that map to DONE state in SD Elements. By default this "Completed,Done".

Github (Advanced Github Configuration)

  • Github duplicate label: This is the label that will be assigned to duplicate tasks.
  • Github issue label: This is the label that will be assigned to new issues raised by SD Elements; this can be used to set a task's issue type.

PivotalTracker (Advanced PivotalTracker Configuration)

  • Story Type: The name of the type of story that SD Elements should create when creating the equivalent of a task in PivotalTracker.
  • States which map to DONE in SD Elements: A list of all PivotalTracker states that map to DONE in SD Elements.
  • Open a task in PivotalTracker in the following state: The name of the state for new tasks in PivotalTracker.
  • PivotalTracker label for issues generated by SD Elements: The label we should assign to new tasks generated by SD Elements when they are created in PivotalTracker.

Microsoft Team Foundation Server

You must use the integration console to use Microsoft Team Foundation Server integration. Please consult the integration console documentation.

ALM integrations page

Individual integration page

 Also refer to Setup ALM-Rally Software and Supported ALM Integrations

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments