Integration overview
After using SD Elements to understand the risk posture of an application, you can export all tasks or a subset of tasks from your SD Elements project to your Issue Tracker project. Here, the tasks appear as work items, such as tickets, features, or stories. When users "close" or otherwise resolve the work item in the Issue Tracker project, the status of the corresponding task in SD Elements is changed to "DONE" when the two tools are synchronized.
You can select how frequently the Issue Tracker project is synchronized with SD Elements. The more frequent the synchronization, the more accurate the SD Element task statuses will be at any given time. However, be aware that the overhead on the Issue Tracker and SD Elements servers is also increased with frequent synchronization.
| Synchronization occurs as a scheduled “batch process”. |
Process
Synchronization between SD Elements and an Issue Tracker project follows the process below.
-
If the integration does not find the task in the Issue Tracker project, a new Issue Tracker work item is created with the same title as the task. SD Elements changes the Issue Tracker work item’s status, where possible and applicable, to match the task status in SD Elements.
-
If the integration finds the task in the Issue Tracker project, SD Elements checks the status of the work item in the Issue Tracker project. If the statuses do not match, SD Elements is updated to reflect the status of the Issue Tracker project.
For example, if a JIRA ticket is marked as "Fixed", then the corresponding SD Elements task is marked as "DONE". You can configure synchronization in the reverse order, so that updates in SD Elements are reflected in the Issue Tracker project.
-
If the SD Elements task was removed from the project, the integration will attempt to close the issue in the Issue Tracker project.
How changes in SD Elements affect tasks in an Issue Tracker
There are five ways tasks synchronized to an Issue Tracker are affected by changes in SD Elements:
-
Status Change: A task status change in SD Elements can affect the task’s status in a connected Issue Tracker project. The details of this behavior are governed by the status mapping configured for the integration.
-
Risk Policy Change: A risk policy defines the minimum set of tasks needed to satisfy an internal security or policy objective. When a project is subject to a different risk policy or the definition of its current risk policy changes, its minimum set of tasks change accordingly. If an integration is set up to Sync Risk Policy tasks, the list of tasks in a connected Issue Tracker will also change.
-
New tasks applicable to the Risk Policy are added to the Issue Tracker project
-
Tasks no longer in the Risk Policy will be marked as Done or closed in the Issue Tracker (Atlassian Jira, GitLab and Pivotal Tracker integrations do not automatically mark such tasks as Done or closed)
-
-
Project Survey Change: Changes to a project survey can affect the list of tasks. Based on new information, the list of tasks in the SD Elements project can change - newly identified tasks are added and irrelevant tasks are removed. These changes are reflected in the Issue Tracker:
-
New tasks are added to the Issue Tracker if they satisfy the integration’s Tasks to Synchronize criteria
-
Removed tasks are marked as Done or closed in the Issue Tracker
-
-
Task addition: Tasks manually added to SD Elements are also added to an Issue Tracker if they satisfy the integration’s Tasks to Synchronize criteria.
-
Content changes: Tasks are added to or removed from a project when a project administrator accepts content updates.
-
New tasks are added to the Issue Tracker if they satisfy the integration’s Tasks to Synchronize criteria
-
Removed tasks are assigned the configured
closed_status(normally Done or Closed) in the Issue Tracker
-
Integration methods
There are two methods of performing integration, depending on your network setup.
If the SD Elements server can communicate directly with the Issue Tracker server, such as when they are both on the same internal network, or both are Software As A Service (SAAS) deployments, then you can use the normal integration process inside of the SD Elements application.
If the SD Elements and Issue Tracker servers cannot communicate directly, such as when SD Elements is accessed through the Internet and the Issue Tracker tool is located on the internal network, use the Remote Integration Agent. The Remote Integration Agent is an application and must be installed on a server or client machine that can communicate with both SD Elements and the Issue Tracker tool. For more information, see Remote Integration Agent.