Understanding the Standard Batch Syncer
Why This Matters
The batch syncer is one of the most important pieces of SyncApp code. Understanding exactly how it transforms PMS data, generates hashes, and decides which records to send versus skip will make you a much faster debugger when sync issues arise.
What You'll Learn
- The three batch manager types: Initial, Pending, and Standard — and when each is used
- The sync record flow: extract rows from PMS → transform/serialize → clean (trim legacy Unicode) → hash → compare
- How buckets (hashmaps) store entity ID → hash code pairs for comparison
- The three sync scenarios: new record (insert), changed record (re-sync), unchanged record (ignore)
- Validation requirements: records must pass required field checks (patient ID, status) before processing
- What happens when a batch is invalidated (crash/power outage during GOB file write) and how to recover
- The 'selective send' final step: only new or updated records are sent to Data Service
Watch Video
Lesson Summary
The Standard Batch Syncer processes records from PMS one by one. For each record: extract the row, transform it to the Weave schema, clean unnecessary Unicode values, then generate a hash code based on key fields (e.g., name and address for patients). The hash is compared against the bucket — a hashmap of entity ID to hash code. Three outcomes: new ID (insert and send), changed hash (update and send), same hash (skip). Validation checks required fields before processing. If a GOB file (batch storage file) is corrupted due to a crash, a note is added and the SyncApp may need a restart. After all records are processed, only the new/updated set is transmitted to Data Service.