SYSTEM AND METHOD FOR SYNCHORNISATION OF DATA AND RECOVERY OF FAILURES DURING SYNCHRONIZATION BETWEEN TWO SYSTEMS

• US 20140068328A1
• Filed: 09/03/2013
• Published: 03/06/2014
• Est. Priority Date: 09/04/2012
• Status: Active Grant

• Current Assignee: Opshub, Inc.
• Original Assignee: Opshub, Inc.
• Inventors: JAIN, SANDEEP, TIWARY, PRAKASH CHANDRA, GARG, APARNA
• Granted Patent: US 9,262,282 B2
• Time in Patent Office: Days
• US Class Current: 714/15
• CPC Class Codes: G06F 11/1443 Transmit or communication errors
• CPC Class Codes: G06F 11/1471 involving logging of persistent data for recovery
• CPC Class Codes: G06F 11/2079 Bidirectional techniques
• CPC Class Codes: G06F 11/2082 Data synchronisation
• CPC Class Codes: G06F 11/3676 for coverage analysis

Abstract

The embodiments herein provide a system and method for synchronization of data and recovery of failures during synchronization between two systems. The system for executing synchronization between the source and target systems comprises a connector framework, a process framework, a mapping manager, a recovery manager, a conflict manager and a failure manager. A method for bidirectional data synchronizing and integrating involves keeping information about integration user in integration database for each entity and update along with update time and audit id, only when the system does not keep information about the created and updated entity. A method of synchronizing only the entities qualifying a criterion, a method for failure recovery from a correct point during integration process, a method for handling recovery for changes coming from multiple end points and a method for recovery during server shutdown are also provided.

Claims

1. A system for synchronization of data and recovery of failures during synchronization between two systems, the system comprises:

a connector framework comprising a plurality of poller components for reading a data change from a source system and adapter components for writing a data to a destination system;

a process framework for processing a poll event;

a mapping manager for mapping a plurality of fields of the source system to a corresponding to a plurality of fields of the destination system;

a recovery manager for recovering a data in case of a system failure or any unexpected failure;

a conflict manager for managing all conflict happening during a synchronization process; and

a failure manager for managing an entire field event during the synchronization process.

2. The system according to claim 1, wherein the process framework on successful synchronizing of an event, writes back a data to the source, indicating a successful synchronisation process.

3. The system according to claim 1, wherein the process framework passes a data to a failure management component.

4. The system according to claim 1, wherein the conflict manager further comprises:

a master/slave model, and wherein the master/slave model is adopted to master an entity at one system and to create read only copies of a plurality of entities in other development systems and wherein all changes to the plurality of entities are made in a master system;

a partitioned ownership model, and wherein the partitioned ownership model is adopted to master a plurality of fields of the entity at a plurality of systems, and wherein the plurality of fields are mutually different, and wherein the plurality of systems are mutually different;

a dynamic ownership model, and wherein the dynamic ownership model is adopted to change an ownership of an entity dynamically, and wherein the entity has only one owner at any one time and wherein a current owner of the entity is indicated based on a value of a field in the entity and wherein the current owner is only allowed to pass the ownership to someone else;

a peer to peer model, and wherein the peer to peer model is adopted to allow a plurality of sites to make changes to the plurality entities using a conflict detection process and a conflict resolution process; and

a custom configuration model, and wherein the custom configuration model is adopted to define an actual replication model in a customized manner and mix one or more conflict manager models.

5. The system according to claim 1, wherein the failure manager catches the entire failed events during synchronization and creates a failure queue, and wherein the failure manager retries the synchronization process for a preset attempts, when an event fails, and wherein all the failed events are notified and are processed after a manual intervention.

6. A method for synchronization of data and recovery of failures during a bidirectional synchronization between two systems, the method comprises steps of:

polling a right data during a bidirectional integration between a source system and a target system;

generating a global unique id associated with each entity;

detecting conflicts during the bidirectional synchronization and when a data is moved in one way from a source system to a destination system;

detecting conflicts during a bidirectional synchronization and when a data is moved in two ways from the source system to the destination system and vice versa;

recovering from a system failure; and

recovering from an application failure.

7. The method of claim 6, wherein the step of polling right data during a bidirectional integration between the source system and the target system comprises:

synchronizing a new create from the source system to the target system;

creating an entry in the target system; and

saving the created entry to the integration user;

wherein an entity is filtered out when the entity is created by a same integration user during a polling of the entity.

8. The method of claim 6, wherein the step of generating a global unique id associated with each entity comprises:

generating global id for each entity based on entity type and a system internal id by the integration manager;

searching an associated global ID in the target system by the integration manager;

fetching and writing a target information, when a matching entity is found in the target system based on the generated global ID and the searched associated global ID by the integration manager;

generating a new global id and storing the generated global id in an integration storage, when a matching entity is not found in the target system by the integration manager; and

updating the target information in a table by the integration manager.

9. The method of claim 6, wherein the step of detecting conflicts in the unidirectional synchronization comprises:

creating an event (E) with a state (S1) in the source system;

synchronizing the event from the source system to the destination system, and wherein the event (E) is replicated to the destination system with the state (S1);

updating the event (E) in the destination system and changing the state (S1) to state (S2) after updating;

updating the event (E) in the source system with a state (S3);

synchronizing the event (E) from the source system to the destination system, and wherein the event (E) with state (S3) is written to the destination system; and

detecting a conflict by identifying a change in the state from (S1) to (S3) for the event (E).

10. The method of claim 6, wherein the step of detecting conflicts in the unidirectional synchronization comprises the steps of:

creating an event (E) with state (S1) in the source system;

synchronizing the event (E) from the source system to the destination system, and wherein the event (E) is replicated to the destination system with state (S1);

updating the event (E) in the destination system and changing the state from (S1) changed to (S2);

updating the event (E) in the source system with a state (S3);

synchronizing the event (E) from the destination system to the source system, with the event (E) with state (S2);

detecting a conflict by identifying a change in the state (S3) for the event (E) by an integration, and wherein the conflict occurs in an integration, when old state of the source entity is not same as the current state of the entity at destination system, and wherein the conflict is detected by comparing the old state of the source entity with the current state of the target entity;

synchronizing the event (E) with state (S3) from the source system to the destination system; and

detecting conflict by identifying change in state (S2) for event (E) by the integration;

11. The method of claim 6, wherein the step of recovering from the system failures comprises the steps of:

storing a time stamp of the source system and a step id that are last processed for each entity by the integration system for handling failures;

resuming the synchronization from an exact point of failure; and

allowing updating of further events whose time is greater than or equal to the time of source system and when a step id of the event is greater than 1.

12. The method of claim 6, wherein the step of recovering from the application failures comprises the steps of:

sending the event by the source system pollers;

assigning a constant step number to each sub step in an update process;

getting a last updated time value from the target system for the entity that is updated;

updating the integration storage with the event and a respective last storage time;

checking for changes done by the integration user after a last storage time for the event along with a time of changes, before initiating an update;

updating the time of changes in the integration storage, when the changes are found; and

creating/updating the entity in the integration storage, when the changes are not found.