The invention relates generally to a system and method of synchronizing states in associated data records across different data repositories.
Many computer software applications and development projects store a wide variety of data records in multiple locations commonly referred to as “data repositories”. The data records may be operated on independently but should always be in a compatible state with each other. Consequently, a system and method for synchronizing states in associated data records is needed.
In some aspects, embodiments of the invention relate to a system for synchronizing states in associated data records, comprising: a first data repository (R1) containing a first data record (DR1); a second data repository (R2) containing a second data record (DR2); a synchronizer that initiates synchronization activity between DR1 and DR2; where the system generates a listing of all possible target states for DR2; and where, upon a change in DR1, the system, determines the correct target state of DR2 from the listing of all possible target states, determines if DR2 is in the correct target state, transitions DR2 to the correct target state, and synchronizes the data of DR2 with DR1.
In other aspects, embodiments of the invention relate to a method for synchronizing states in associated data records, comprising: detecting a change in a first data record (DR1) located in a first data repository (R1); initiating synchronization activity between DR1 and a second data record (DR2) located in a second data repository (R2); generating a listing of all possible target states for DR2; determining the correct target state of DR2 from the listing of all possible target states; determining if DR2 is in the correct target state; transitioning DR2 to the correct target state; and synchronizes the data of DR2 with DR1.
Other aspects and advantages of various embodiments of the invention will be apparent from the following description and the appended claims.
It should be noted that identical features in different drawings are shown with the same reference numeral.
A system and method for synchronizing states of data records across multiple data repositories or software applications has been developed. The embodiments of the present invention include multiple data repositories and a synchronizer that serves to synchronize the data links between the repositories.
The data repositories containing data to be synchronized may be on the same computer system or may be spread across different computer systems. The data records could exist in the same data repository or different data repositories.
Independent data repositories may hold two or more similar data records. Each data record has fields that represent the state of the record in a “workflow”, which is a sequence of states, described by a graph, which the records may move through. The repository or application housing the data record typically defines the workflow for a data record based on the type of the data record. As part of one example embodiment of the invention, each data record on each data repository participating in synchronization has one or more fields to represent the state of the data record. All possible legal states of a particular data record type and legal transitions between states are described by a state transition diagram. For a transition to be taken for a data record, there may be other fields on the data record that must be set to literal values for the transition to be legal.
Embodiments of the present invention synchronizes states in similar data records stored in separate data repositories by treating workflow as data. Once states in two systems are detected as incompatible, the synchronizer system will push the data in the second data repository into the correct state.
Referring to
However, if DR2 is not in the proper target state, the system checks to see if a predetermined limit on attempts to transition the state has been exceeded. A limit on transition attempts is set to prevent endless looping errors. Instead, if the limit has been exceeded, an error status is set and the process ends. If the limit on attempts has not been exceeded, the next state for DR2 is set along with any other appropriate fields. As DR2 moves to a new state, a user configuration file can specify that certain fields be set. Finally, DR2 is checked to determine if it has been changed by another process. These other processes could include a change by another workflow synchronizer, another system and/or another user. If it has, the data in fields of DR2 is synchronized with associated data fields of DR1.
One example of a practical application of embodiments of the present invention include a software development team involved in troubleshooting software bugs. The team uses one software system that record bugs that are reported about their software applications. The organization uses a second software system in which to record tests that are used to determine if the applications are executing as desired. To help track tests used to determine if a bug is fixed, the team wants to represent “bugs” in the first system as “defects” in the second system. By synchronizing the bugs to defects, both programmers and testers can work with the same information. This example presumes a correspondence has been determined between bugs and defects in the two systems and that a state transition diagram has been generated for defect artifacts in the second system including any fields that must be set for a given transition to be legal. This example also presumes that it can access a configuration file that describes a target state for a defect for each state of a bug and any constraints on setting other fields in the defect when a transition is taken.
When a change to a state of a bug in the first system is detected, the synchronizer system looks up the target state in the configuration file for a corresponding defect in the second system. For example, a bug may go from an “OPEN” to a “RESOLVED” state. The synchronizer system determines from the configuration file that a corresponding second system should transition from “NEW” to “CLOSED” where a field on the defect is also set to the literal value “Resolved”.
The defect in the second system is in the “NEW” state. The synchronizer system now looks up in the data generated from the defect artifact state transition diagram that a defect can go from “NEW” to “ASSIGNED” but not directly from “NEW” to “CLOSED”. The method asks the second system to transition the defect to “ASSIGNED”. It then checks to see if “ASSIGNED” is the target state. Since it is not, the method asks the second system to transition the defect to the target “CLOSED” state. Since “ASSIGNED” to “CLOSED” is legal in the second system's defect state transition diagram, the second system defect is transitioned. The method also sets the required field to “Resolved”. The transition is taken and the data in each repository is now compatible.
Finally, the synchronizer system also checks, before actually taking the transition for the second system defect, whether there has been any change since the last check of the state (in case another process is changing the record). If so, user-configured conflict detection rules as used to determine how to proceed. Typically, user-configured conflict detection rules are part of a user configuration file that resolves conflicts by either an override instruction or declaring an error.
Embodiments of the present invention can be implemented across a wide variety of applications and uses. For example, embodiments of the present invention could be used with Application Lifecycle Management (ALM) records, project portfolio management (PPM) and tickets in an IT help or support system management (ITSM). Embodiments of the present invention could also be used in Customer Relationship and Sales Management systems that also take data records through various workflow states (e.g., lead, opportunity, etc.). The workflow in these systems might be similar to procedures to handle Application Lifecycle Management (ALM) data. Embodiments of the present invention could then be used to move data simultaneously in two customer relationship or sales management systems into similar or compatible states.
Additionally, the embodiments of the present invention could be used to synchronize data for health records. For instance, a mobile phone app might have a representation of an individual's health record (or part of a health record) and this might be synchronized with a hospital or lab's view of the same record where the workflow could be “stable” to “waiting for lab result” to “waiting for lab interpretation” to “lab results available”, etc.
While embodiments of the present invention have been described with respect to a limited number of embodiments, those skilled in the art, having benefit of this disclosure, will appreciate that other embodiments can be devised which do not depart from the scope of the invention as disclosed here. Accordingly, the scope of the invention should be limited only by the attached claims.
Number | Name | Date | Kind |
---|---|---|---|
5301320 | McAtee et al. | Apr 1994 | A |
5706509 | Man-Hak Tso | Jan 1998 | A |
5970501 | Hunkins et al. | Oct 1999 | A |
6298370 | Tang | Oct 2001 | B1 |
6397192 | Notani et al. | May 2002 | B1 |
6460051 | LaRue et al. | Oct 2002 | B1 |
6505200 | Ims et al. | Jan 2003 | B1 |
7480907 | Marolia et al. | Jan 2009 | B1 |
7496606 | Hind et al. | Feb 2009 | B2 |
7516167 | Selman et al. | Apr 2009 | B2 |
7565381 | Oswalt | Jul 2009 | B2 |
7607130 | Singh et al. | Oct 2009 | B2 |
7693888 | Urscheler et al. | Apr 2010 | B2 |
7962448 | Creamer et al. | Jun 2011 | B2 |
8131672 | Hind et al. | Mar 2012 | B2 |
8315976 | Multer et al. | Nov 2012 | B2 |
20020059299 | Spaey | May 2002 | A1 |
20040148299 | Teegan et al. | Jul 2004 | A1 |
20060069809 | Serlet | Mar 2006 | A1 |
20070083813 | Lui | Apr 2007 | A1 |
20070282802 | Wilhelm | Dec 2007 | A1 |
20080201362 | Multer | Aug 2008 | A1 |
20100011337 | Young et al. | Jan 2010 | A1 |
20100017792 | Young et al. | Jan 2010 | A1 |
20100145910 | Zhao et al. | Jun 2010 | A1 |
20110047126 | Vargas et al. | Feb 2011 | A1 |
20110258160 | Lee | Oct 2011 | A1 |
20140280528 | Brandes | Sep 2014 | A1 |
Number | Date | Country |
---|---|---|
2 160 689 | Mar 2010 | EP |
2169552 | Mar 2010 | EP |
Entry |
---|
Janzen, “System and Method for Repairing Data Synchronization Links,” U.S. Appl. No. 13/834,365, filed Mar. 15, 2013, 16 pages. |
Janzen, “System and Method for Repairing Data Synchronization Links,” Preliminary Amendment filed Apr. 7, 2014, for U.S. Appl. No. 13/834,365, 22 pages. |
Kisynski et al., “Systems and Methods to Synchronize Artifact Relationships Across a Plurality of Repositories,” U.S. Appl. No. 14/571,113, filed Dec. 15, 2014, 63 pages. |