Browse Prior Art Database

The Method of Collision detection for bidirectional synchronization between change request management systems

IP.com Disclosure Number: IPCOM000199657D
Publication Date: 2010-Sep-14
Document File: 21 page(s) / 1M

Publishing Venue

The IP.com Prior Art Database

Abstract

Change request management (CRM) systems (ClearQuest, CMVC, Bugzilla, PTR etc) are widely used in today’s software development. More and more teams become globally and across geographically. In this situation, change request management systems be installed in multiple location per usage and performance. So this raise a request to synchronize change request object among multiple change request management systems, which can make user get same change request object by access change request management system located anywhere, and global team can work together on distributed projects smoothly. We know ClearQuest MultiSite® provide a synchronization method between multiple ClearQuest installations, it is a exclusive-right-to-modify mechanism, so user can just modify object in replica with mastership, for other replicas, user can not modify object in them. That’s inconvenient and will cause lower performance. In this case, ClearQuest MultiSite use unidirectional synchronization in fact, but to provide user more convenient and better performance, bidirectional synchronization is needed instead. By using bidirectional synchronization, user can login any change request management system to do the changes, and the changes can be synchronized between change request management systems quickly. But collision detection and avoidance is a very big problem for bidirectional synchronization, currently there’s no good method for collision detection in bidirectional synchronization between change request management systems. Our invention will provide a solution to detect collision in bidirectional synchronization between change request management systems.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 49% of the total text.

Page 1 of 21

The Method of Collision detection for bidirectional synchronization between change request management systems

   Our invention is provide a method to detect collision for bidirectional synchronization between change request management systems:
1. The foundation is bidirectional synchronization between change request management systems, we'll describe a simple method at below.
2. Based on bidirectional synchronization, our core idea is to use change request object change history to detect collision.

Our invention include below important points:
1. We make sure change request management system can store the change history, for example, change history can include a field has been changed from one value to the other, the time when changes happened, and who did the changes

   See Figure 1 as example for ClearQuest to support the history information, ClearQuest can not provide this function as default, but we can use ClearQuest API to implement this function, the other CRM system can support this history in many different ways.

1

Page 2 of 21

Fig 1 Change History

2. There's sync-agent which is used to bidirectional synchronize change request object between change request

2

[This page contains 1 picture or other non-text object]

Page 3 of 21

management systems. Sync-agent will use a DB to store last synchronization time of each object. See Figure 2 for architecture of sync-agent, DB and change request management systems

3

Page 4 of 21

4

[This page contains 1 picture or other non-text object]

Page 5 of 21

Fig 2 Architecture of sync-agent, DB and change request management systems

   Sync-agent work flow for bidirectional synchronize change request object between change request management systems as below:
1. Sync-agent pick up one change request management as source.

5

[This page contains 1 picture or other non-text object]

Page 6 of 21

   2. Sync-agent query out modified change request data at specified interval. Each fields value will extracted and saved into "source fields value list".
3. Sync-agent find out "source changed fields list" through change history and last-sync-time stored in DB
4. Sync-agent pick up one change request management as destination according to configuration
5. Sync-agent extract destination change request object fields value, store them into "destination fields value list"
6. Sync-agent find out "destination changed fields list" through change history and last-sync-time stored in DB for destination change request object.
7. Sync-agent compare source "source fields value list" with "destination fields value list", get "different fields list" which value is different in source and destination.
8. Sync-agent check collision by compare "different fields list" with "destination changed fields list" and "source changed fields list"

   It will check "different fields list" with "destination changed fields list" firstly, if there are notsame field existed in two list, which means there are no collision, sync-agent can update destination cha...