For organizations needing to connect development, QA, and project management, Tasktop Sync provides the only enterprise-scale ALM middleware solution, built on the industry-standard Eclipse Mylyn ALM integration framework. Tasktop Sync provides two distinct capabilities: Task Linking and Task Synchronizing. In addition, Tasktop Sync also provides a Quick Start to help configure repositories.

Unlike previous approaches to ALM synchronization, Tasktop Sync provides real-time synchronization, automated conflict resolution, and support for over two dozen ALM tools. Building on Tasktop’s Task Federation™ technology, Tasktop Sync’s synchronization component ensures that each stakeholder has access to the data that they need within their tool of choice, even if the data resides across requirements management, Agile development, and traditional quality management systems. The Task Synchronization Configuration section explains in detail how to configure the Task Synchronization feature.

For those who want a lighter-weight solution, Tasktop Sync’s Task Linking enables traceability by letting you find and link related tasks across repositories with minimal configuration. Task Linking is built on top of Open Services for Lifecycle Collaboration (OSLC) protocols, an industry-standard means for communicating between ALM components. Tasktop Sync supports the service provider, picker, links, and preview features of the OSLC Core 2.0 standard. This means that Task Linking allows users to select, link to, and preview related tasks in a foreign repository from a OSLC consumer’s system. Not only can Task Linking easily communicate with OSLC consumers (like IBM® Rational Team Concert™ Rational DOORS Next Gen and IBM Rational Team Concert Change and Configuration Management), Tasktop Sync connectors can turn HPE QC / ALM, JIRA, and TFS repositories into OSLC producers. The Task Linking Configuration section explains how to configure the Task Linking feature.

Tasktop Sync Dashboard


Tasktop connects to many different products, and different vendors and products have very different terms for similar concepts. It is important to understand these terms to make sense of the rest of this manual.

Task — A task is an item of work that someone needs to act upon. In other products, what we call “tasks” may be called “tasks”, “defects”, “bugs,” “feature requests”, “work items”, “test cases”, “trouble tickets”, “records”, etc. This can be confusing. For example, IBM Rational Team Concert manages “tasks”, “work items”, and “defects”, all of which we call “tasks” in this document.

Repository — A repository (or task repository) is a collection of tasks. In other products, what we call “repositories” or “task repositories” are also called “bug databases”, “bug trackers”, “issue tracking systems”, “incident tracking systems”, etc.

Proxy Task — When Tasktop Sync synchronizes tasks between repositories, a proxy relationship between synchronized tasks is defined. A proxy task is the task (say, Task O) in the other repository that is synchronized to the current task (say Task C). Conversely, Task C is the proxy task of Task O.

Task attribute — A task attribute is an aspect of a task that is stored in a repository. “Date” and “Priority” are common task attributes. In other products, what we call “task attributes” are also called “fields”, “columns”, etc.

Task attribute values — A task attribute value is the specific value that a task attribute may have. For example, “March 14, 1:59am 2011” might be a task attribute value for the task attribute of “Date”. “P1” might be a task attribute value for the task attribute of “Priority”.

Connector — A connector is the software that connects Tasktop Sync to a repository. Different vendors' repositories use different connectors.

Workflow — In some Repositories, a task’s status represents a stage in the task’s workflow lifecycle. This workflow is configured within the repository, and links together statuses that a Task may transition between. For example, a Task with the status “To Do” may only be allowed to transition to the “In Progress” or “Rejected” status, and not the “Done” status.

Transitions — In workflow management, a task’s status cannot be updated directly, but must be changed using a transition. This transition is a repository operation that must be executed to perform the change to the task. Transitions are defined when configuring the workflow in the repository, and normally include the starting status and the ending status. Examples of transitions might include “Complete Task”, or “Start Working”.

Transition attributes — When executing a transition, some task attributes can, or must, be updated at the same time. For instance, it is common to include a Resolution value when executing a “Complete Task” transition. The transition attributes are defined in the repository workflow, and can be configured in Sync using the Transition Attribute Mappings Table.

Repository back-off — When defining repository connections, you must provide authentication credentials which will be used by Sync when communicating with the repository. If these credentials become incorrect, the communication will start failing. Some repositories will disable users that perform too many actions with invalid credentials. To prevent this, when Sync detects authentication errors it will institute a back-off, freezing all activity with the repository for a period of time.


Integration Visualizer

The integration visualizer provides the user with a broad overview of the ALM architecture configured in Tasktop Sync. This view not only allows the overall ALM architecture to be understood quickly, but it also provides an easily understood snapshot of the health of the architecture by tracking and display synchronization history and highlighting problems between different parts of the architecture.

Integration Visualizer

Task Mapping Editor

Tasktop Sync provides a comprehensive UI for configuring synchronization mappings between pairs of repositories and tasks. The task mapping editor allows users to quickly define new mappings, as well as add to and modify existing mappings.

Attribute Mapping Editor

Automated Conflict Resolution

Tasktop Sync automatically handles conflicts in an intelligent fashion.

Conflicts can occur when two synchronized tasks are updated at the same time in each repository. If two users are collaborating on the same task and both decide to update it at the same time, they might submit incompatible changes. For example, one user could change the priority of the task to “High” while the other user changes it to “Medium”. Most repositories provide built-in support for handling this case, but this support only works for tasks being accessed on the same repository. In a synchronized environment, the tasks can exist in different repositories; Tasktop Sync is in a position to handle conflicts that occur across repositories.

Person Mappings

Heterogeneous ALM repositories are often accessed by different groups, with varying degrees of overlap. Even in the cases where the same user is accessing both systems being synchronized, the user might have different user IDs in each system. For example, a user might be called janesmith in one repository and jsmith in another. Synchronizing data between repositories involves translating these IDs between repositories so that identities are preserved.

Tasktop Sync provides a pluggable system for mapping person IDs. For simple person ID mappings, Tasktop Sync can be pointed at a file containing the mappings between person IDs. This mapping may contain direct ID-to-ID mappings as well as configuration for more sophisticated person mapping, including mapping using person metadata, and mapping using scripts. Additionally a default person ID can be provided on each repository that is used if a user exists in one system but not the other. For further details see person mapping configuration

No Local State Lock-in

Tasktop Sync stores all important task-related data in your existing task repositories. There is no information stored in Tasktop Sync that is not retrievable from one of the repositories participating in synchronization. This means that utilizing Tasktop Sync does not cause your data to be stored in a new proprietary format, nor do you need to back up task data from the machine running Tasktop Sync.

Copied Task Handling

Tasktop Sync handles synchronizing copied tasks in a way that eliminates the problematic scenario with multiple tasks having the same proxy link. Copied tasks will be treated as if they were new tasks; their incorrect proxy association will be removed, and then a new proxy task will be created.

Automatic Proxy Link Repair

When enabled, Tasktop Sync supports the recovery of deleted or missing proxy links during synchronization. Tasktop Sync keeps a database of past synchronizations and will recover and rewrite the previous proxy associations. For example, this allows successful synchronizations of HPE ALM tasks that have reverted to a version before their proxy associations were stored.

Configuration Templates

Configuration templates allow administrators of Tasktop Sync to easily expand and manage the use of Tasktop Sync at their organization by allowing them to apply the same configurations to multiple workspaces and projects. With this feature, administrators can:

Task Relationship Management

ALM repositories can store relationships between their tasks. Normally, these relationships reflect a link between two different types of tasks, such as a test case linked with a defect found during execution of the test. Relationships may also exist amongst tasks of the same type, such as parent and child requirements. Tasktop Sync can synchronize these relationships, maintaining the links and hierarchy in two synchronized repositories.

Synchronizing External Associations

Tasktop Sync handles synchronizing references to related tasks as web URLs. For example, when a defect is synchronized between your quality assurance repository and your engineering repository, a reference to a test can be synchronized as a URL, enabling your engineers to see the test in its original repository with a simple mouse click.

Synchronizing Attachments

When enabled, Tasktop Sync can synchronize attachments between ALM repositories. Along with the attachment, certain attachment metadata may also be synchronized, including its description, author and title.

To synchronize attachments efficiently, Tasktop Sync must be able to compare attachments between repositories without downloading the entire binary. To do this, Tasktop Sync will use the filename and/or file size to identify the attachment. Since not all repositories provide access to both a filename and file size, Tasktop Sync will use the fields that are supported by both repositories to compare. So, for example, if one repository provides both filename and file size, yet the second provides only filename, Tasktop Sync will be forced to only use filename when comparing the attachments. If there are no overlapping fields provided, then Tasktop Sync cannot synchronize attachments between the repositories.

For details on configuring Attachment synchronization, see Mapping Preferences.

Synchronizing Comment and Attachment Authors

Tasktop Sync attempts to synchronize the authors of comments and attachments. If a person mapping is defined, it will be used to determine the author of the comment or attachment in the target repository. Tasktop Sync can optionally validate whether the authors of comments and attachments exist in the target repository before submission.

Not all systems support synchronization of comment or attachment authors. When synchronizing comments and attachments to systems which do not support synchronization of authors, the author will appear as the user defined in the repository connection. Tasktop Sync can also be configured to add the comment author’s name to the synchronized comment’s text. This feature can be useful to enable dialog across tasks in separate repositories.

Status Workflow Management

Many ALM repositories support the notion of a task’s status or state. For instance, a Defect task may have a set of predefined statuses: New, In Progress and Done. In some ALM repositories, changing a task’s status cannot be done directly, but must be changed through executing a transition. This is commonly referred to as Workflow Management, and can be configured within the ALM repository.

Tasktop Sync can execute transitions using a Status Transition Caster. Details on how to configure the caster are here.


This section describes the overall architecture of Tasktop Sync. Understanding the fundamentals section makes Tasktop Sync configuration easier. The following sections are more advanced discussions of the architecture of some of the critical features of Tasktop Sync.


At its core, Tasktop Sync maintains synchronization between a task in one repository, say Task A, with a task in another repository, say Task 1. In this case, Task 1 is called the “proxy task” of Task A, and vice versa.

The architecture of Tasktop Sync involves pairs of connectors to task repositories. These connectors provide a common interface to Tasktop Sync for accessing tasks from each repository. Tasktop Sync then uses these connectors in its core to synchronize tasks between the two connectors. This modular architecture is what enables Tasktop Sync to easily work with many different vendors' repositories and create general mappings between any pairs of these supported repositories.

The tasks which are synchronized between pairs of repositories are scoped first by queries, and then by matching a set of field values. The queries allow Tasktop Sync to bound the set of tasks which should be synchronized between repositories, but they also allow Tasktop Sync to build a local cache of task data to improve both throughput and latency of task synchronization, and to resolve conflicts between tasks at a fine-grained level.

Tasktop Sync uses these queries to issue requests to each repository in order to identify tasks which have changed and require synchronization. Synchronizations can be batched by varying the delay which Tasktop Sync uses between checking its queries for changed tasks.

Tasktop Sync is optimized to minimize latency, maximize throughput, and minimize load on your repositories.

Together, this means that the synchronization speed does not depend upon the size of your repository or the number of users, only on the frequency of meaningful changes.

Synchronization Conflict Handling

Conflict Detection

The first step in handling conflicts is to detect them. Note that there’s a difference between two tasks being out of sync with each other and being in conflict with each other. If an attribute of the two tasks is different because one of the tasks has been updated while the other wasn’t, that is not a conflict. If the attributes are different because they have both been updated at the same time, that’s a conflict. Furthermore, if an attribute of both tasks has been updated at the same time with the same change then they have in effect been synchronized by the users, and there is no conflict; a synchronization action would be redundant. If two tasks have changed, but the attributes which changed were different in the two tasks, again, there is not actually a conflict. For example, if one person changed the Severity of a task to “BLOCKER”, while another person changed the owner to “mgarcia”, this would not be a conflict.

If a synchronizer only has the information that two tasks were updated at the same time, but not information about which attributes caused the tasks to conflict, then that synchronizer will not be able to recognize non-conflicting attribute changes. Tasktop Sync, however, can detect which attributes have changed, and thus provides built-in support for attribute-level conflict detection.

Conflict Resolution

Once a conflict has been detected, the next step is to decide what to do about the conflict. This involves selecting one of the changes as the new value of the attribute, thus overwriting the other value, or deciding that the sync is not allowed to go through at all, thus leaving both values in place. Note that with attribute-level conflict detection, only changes to the same attribute are declared as conflicts and chosen to be resolved. Non-conflicting changes to different attributes are merged and both tasks are updated with the other’s changes.

Tasktop Sync has the following policies available for resolving conflicts:

Conflict resolution policies can be defined at both the task level and the attribute level in the configuration file. Defining a conflict resolution policy at the task level applies that policy to every attribute mapping defined in that task’s mapping that does not have its own resolution policy. Conflict resolution policies specified in an individual attribute mapping apply only to that attribute and override the policy specified in the containing task mapping.

Conflict Notification

Once a conflict has been detected and resolved, it’s often useful for users to be notified of the conflict and what action was taken to resolve it. At a minimum, Tasktop Sync reports all conflicts in a log file available to Tasktop Sync administrators. However, Tasktop Sync administrators are often not in the best position to act on this information, as they may not be involved in the task on which the conflict occurred. It’s often desirable for the users who are subscribed to the task to be notified of the conflict so they can confirm that the action taken was appropriate, or at least be aware that two users were posting conflicting data to a task.

Tasktop Sync provides a conflict notification policy whereby the conflicts can be logged in the comment stream of the task in question. The comment indicates which attributes were involved in the conflict and which values were overwritten according to the conflict resolution policy.

Synchronization States

A synchronization is defined as process of propagating a set of changes between two tasks. Each time Tasktop Sync detects changes on a mapped task, a new synchronization is scheduled.

The synchronization process runs through a set of states as changes are propagated between repositories. Many of these states are visible through the Tasktop Sync Dashboard. The synchronization will progress through each state, and depending on the results accrued during processing, move onto another until the Done state is reached. Each state is described below.


When a change is detected in a mapped repository task, or a new task that should be mapped is detected, a new synchronization is created and placed in the queue. At this stage, the synchronization is in Queued state, waiting to be processed.

A synchronization can remain in Queued state due to a number of restrictions, such as:

The synchronization will remain in Queued state until no more restrictions exist. From Queued state, a synchronization can enter Error state, if an error is encountered, or Processing state. If Tasktop Sync is stopped, any synchronization in queued state will remain there until Tasktop Sync is restarted.


A synchronization is in Processing state while the actual synchronization of tasks is being performed. During Processing, both repositories are contacted, and changes to the tasks are propagated.

Normally, at the end of the Processing state, the synchronization enters Done state and is complete. If an error occurs, it will enter Error state.

A synchronization can also enter Pending state if there are more changes to synchronize. See Pending for details. If Tasktop Sync is stopped, any synchronizations in Processing state will be completed.


When a synchronization encounters an error it cannot automatically recover from, it moves the synchronization to Error state. These synchronizations are visible under the Tasktop Sync Dashboard.

The synchronization will remain in Error state until either a new change is detected in the task(s), returning the synchronization to Queued state, or the Tasktop Sync administrator manual forces the state to change. This can be done by right-clicking on the synchronization in the Tasktop Sync Dashboard, and choosing one of the following:

More details in these steps are located under the Tasktop Sync Dashboard.

A synchronization in Error state will remain in this state even when Tasktop Sync is stopped.


During Processing state, if there are more changes known to be propagated, the synchronization is moved to Pending state. This condition can happen for a number of reasons:

The synchronization will remain in Pending state for approximately one minute, and then moved back to Queued state to start the synchronization again. If the condition(s) that triggered the original Pending state still exists, the synchronization will then re-enter Pending State. This can happen up to 60 times, at which point the synchronization will enter Error state.

If Tasktop Sync is stopped, any synchronizations in Pending state will be returned to Queued state when Tasktop Sync is restarted.


When a synchronization has finished propagating all the mapped changes across repositories, the synchronization is Done. At this stage, the synchronization will no longer appear in the Tasktop Sync Dashboard, and no more work will be scheduled.