v5.0 - v5.5 Data Sync Documentation
  • Overview
  • Release Notes
    • V4.5
    • V4.6
    • v4.7
    • v4.8
    • v4.9
    • v4.10
    • v4.12
    • v4.13
  • v4 Connections Installation Guide
    • v5 Connections and CLI Installation Guide
  • v4 Worker/Listener Installation Guide
    • v5 Worker/Listener Installation Guide
  • Upgrades & Config Changes
  • Builder Guide
    • Overview
    • Types of Data Syncs
    • Subscribing to Event Streams
      • Supported Stream Sources
        • Amazon Simple Queue Service (SQS)
        • Cinchy Change Data Capture
        • Data Polling
        • Kafka Topic
        • MongoDB
        • Salesforce
          • Push Topic
          • Platform Event
    • Configuring a Data Sync
      • Connections Experience & XML Config Reference
        • Info
          • Parameters
            • String Escape
        • Source Config Reference
          • Schema Columns
            • Calculated Column Examples
          • Auth Requests
          • Request Headers
          • Pagination
          • Source Filter
        • Target Destination Config Reference
          • Column Mappings
          • Target Destination Filter
        • Sync Behaviour
        • Post Sync
        • Permissions
        • Jobs
        • Connections Usage Example
      • Data Validation
      • Transformations
        • StringReplacement
      • Supported Data Sources
        • File Based Source
          • Binary File
            • Binary File Data Source Example
          • Delimited File
            • Delimited File Data Source XML Example
          • Fixed Width File
          • Excel
            • Excel Source XML Example
        • Cinchy Event Broker/CDC
          • Cinchy Event Broker/CDC XML Config Example
        • Cinchy Table
          • Cinchy Table XML Config Example
        • Cinchy Query
          • Cinchy Query Data Source Example
        • Copper
        • DB2
        • Dynamics 2015
        • Dynamics
        • DynamoDB
        • Kafka Topic
          • Apache AVRO Data Format
          • Kafka Topic Source Example
        • LDAP
        • MongoDB Collection
          • MongoDB Collection Source XML Example
        • MongoDB Collection (Cinchy Event Triggered)
        • MS SQL Server Query
        • MS SQL Server Table
        • ODBC Table
        • ODBC Query
        • Oracle Table
        • Oracle Query
        • Parquet
        • Polling Event
          • Polling Event Example
        • REST API (Cinchy Event Triggered)
        • REST API
          • REST API XML Example
        • SAP SuccessFactors
        • Salesforce Object (Bulk API)
        • Salesforce Platform Event
        • Salesforce Push Topic
        • Snowflake
          • Snowflake Source XML Example
        • SOAP 1.2 Web Service
      • Supported Sync Targets
        • Cinchy Table
        • DB2 Table
        • Dynamics
        • Kafka Topic
        • MongoDB Collection (Column Based)
        • MS SQL Server Table
        • Oracle Table
        • REST API
        • Salesforce
        • Salesforce Object
        • Snowflake Table
          • Snowflake Table Target XML Example
        • SOAP 1.2 Web Service
    • Common Design Patterns
    • Testing a Data Sync
    • Promoting a Data Sync
    • Scheduling a Data Sync
    • CLI Command List
    • Connections Functions
    • Monitoring
  • Cinchy Platform Documentation
Powered by GitBook
On this page
  • 1. Batch Syncs
  • 1.1 Execution Flow
  • 2. Real-Time Data Sync
  • 2.1 Execution Flow

Was this helpful?

  1. Builder Guide

Types of Data Syncs

This page helps to define the different types of data syncs available in Cinchy.

PreviousOverviewNextSubscribing to Event Streams

Last updated 2 years ago

Was this helpful?

1. Batch Syncs

Batch sync works by processing a group or a ‘batch’ of data all together rather than each piece of data individually. When the data sync is triggered it will compare the contents of the source to the target. The Cinchy Worker will decide if data needs to be added, deleted or updated. Batch sync can either be run as a one-time data load operation, or it can be scheduled to run periodically using an external Enterprise Scheduler.

Batch Sync is ideally used in situations where the results and updates don’t need to occur immediately but they can occur periodically.

For example, a document that will only be reviewed once a month doesn’t necessarily need to be updated every single time a change is made

1.1 Execution Flow

At a high level, running a batch data sync operation performs these steps (Image 1):

  1. The sync connects to Cinchy and creates a log entry in the Execution Log table with a status of running.

  2. It streams the source and target into the CLI. Any malformed records or duplicate sync keys are written to source and target errors csvs (based on the temp directory)

  3. It compares the sync keys to match up source and target records

  4. The sync checks if there are changes between the matched records

  5. For the records where there are changes, groups them into insert, update, and delete batches.

  6. It sends the batches to the target, records failures in sync errors csv and Execution Errors table.

  7. Once complete, it updates Execution Log entry with final status and execution output.

Image 1: Batch Syncs

2. Real-Time Data Sync

In real-time syncs, the Cinchy Listener picks up changes in the source immediately as they occur. These syncs do not need to be manually triggered or scheduled using an external scheduler. Setting up a real-time sync does require an extra step of defining a listener configuration in order to execute properly.

Real-time sync is ideally used in situations where results and responses must be immediate.

For example, a document that is constantly checked and referred to should have the most up-to-date and recent information.

The following sources can be used in real-time syncs:

  • Cinchy Event Broker/CDC

  • MongoDB Collection (Event Triggered)

  • Polling Event

  • REST API (Event Triggered)

  • Salesforce Platform Event

2.1 Execution Flow

At a high level, running a real-time data sync operation performs these steps (Image 2):

  1. The Listener is successfully subscribed and waiting for events from streaming source

  2. The Listener receives a message from a streaming source and pushes it to SQL Server Broker.

  3. The Worker picks up message from SQL Server Broker

  4. The Worker fetches the matching record from the target based on the sync key

  5. If there are changes detected, the worker pushes them to the target system. Logs successes and failures in the worker's log file.

Image 2: Real-time Syncs