PASI Client Performs Synchronization

The following diagram outlines the context in which the previously identified services are utilized for the purpose of retrieving relevant updates from the PASI Core in order to ensure data within the PASI Client and the PASI Core are in sync.

The following scenarios outline the various paths through this business process. They are not intended to highlight every situation. They are intended to provide context to understand when the services should be used.

To double check that nothing has gone awry during the Get PASIUpdates process, the Is Data Available will also be able to identify if the data in the PASI Client and the PASI Core are not in-sync by comparing a hash value calculated by both the PASI Client and the PASI Core. If both the PASI Core and the PASI Client are in-sync, the calculated hash values should be the same.

If the calculated hash values are different, that means that (although the PASI Core has not identified any updates for the PASI Client) the data in the PASI Core and the PASI Client are not in-sync. In this situation, a data resolution process will be required to review the data in the PASI Client against the data in the PASI Core to determine which records need to be updated in order to return to an in-sync state.

It is anticipated that this process could be automated or may require administrator level intervention in order to determine how to resolve the data discrepancies, but also to determine what resulted in the data being out-of-sync.

Primary Scenario #1 - Get Updates


client_performs_sync_ida.vsdx

This scenario begins when a PASI Client has determined that it wants to poll PASI to receive any unseen updates that might have occured.

  1. The PASI Client use the Is Data Available service to check to see if there are any unseen updates using the last known PASI Core Version.
  2. The PASI Core reviews the request and identifies that there are updates for the PASI Client.
  3. The PASI Core returns a list of all records that should be updated.
  4. For each record returned, the following is done:
    1. The PASI Client examines the Id and PASI Core Version and compare that against the local copy to confirm that there is a difference.
    2. Using the appropriate “Get” PASI Core service, the PASI Client requests the updated information from PASI.
    3. The PASI Core returns the details of each record requested.
    4. The PASI Client updates the appropriate records in their local store.
    5. The PASI Client performs the appropriate actions to manage their internal data against what PASI returned.
  5. The PASI Client captures the maximum PASI Core Version that was returned in the results.
  6. Repeat the entire process until Is Data Available returns no changes.

This scenario ends with the PASI Client and the PASI Core being in-sync.

Alternate Scenario #1 - Returned Id/PASI Core Version Matches Local Store

The scenario begins after step 4a of primary scenario #1 when the PASI Client has determined that Id and PASI Core Version match what the client has in their local store.

This scenario skips steps 4b through 4e in the primary scenario #1 and continues with step 4a on the next record.

Alternate Scenario #2 - No Updates

The scenario begins after step 2 of primary scenario #1 when the PASI Core has determined that there are no updates that the PASI Client has not seen.

  1. No updates are necessary.

This scenario ends with confirmation that the PASI Client and the PASI Core being in-sync.

Primary Scenario #2 - Hash Check


client_performs_hash_check_ida.vsdx

This scenario begins when a PASI Client has determined that it wants to ensure that it is in sync with PASI using a calculated hash and the Is Data Available sevice.

  1. The PASI Client calculates a has based on the known record Ids and PASI Core Versions that are in the local copy.
  2. The PASI Client uses the Is Data Available service with the calculated hash.
  3. The PASI Core reviews the request and identifies that the hash matches what PASI calculates.

This scenario ends with the PASI Client and the PASI Core ensured that they are in-sync.

Alternate Scenario #1 - Get Hash Mismatch

The scenario begins after step 2 of primary scenario #1 when the PASI Core has determined that there is a hash mismatch.

  1. Use the Primary Scenario #1 with a PASI Core Version of 0 to get all the updates from PASI Core.
  2. Deal with any of the records that have previously been received from PASI but were not returned as part of Is Data Available. This is usually for records that have been marked as deleted in PASI.

This scenario ends with confirmation that the PASI Client ensured that they are in-sync.

Note: A hash value is a number that has been calculated based on all the data synchronized. For more information about the hash value, refer to the Technical API documentation.