Engineered HDL bundle assembly, validated payload submission, ESS job tracking, failure routing. Purpose-built for Oracle Fusion HCM Data Loader — not adapted from generic ETL load tooling.
Oracle Fusion HCM Data Loader has its own rules, dependencies, and error patterns. Generic ETL load tools don't know any of them — which is why so many Sage People migrations stall in the load phase.
HCM Data Loader (HDL) is Oracle Fusion's strategic bulk-load framework. It's the primary supported path for migrating workers, assignments, salaries, and absence data into Fusion HCM. But HDL is not a generic database load — it has Fusion-specific file format rules (tab-delimited .dat files with prescribed METADATA headers and MERGE keywords per business object), strict dependency rules (Worker must load before WorkRelationship, which must load before Assignment, which must load before Salary), per-release schema evolution (26A introduces fields that 25D didn't have, 26B deprecates fields), and per-business-object validation rules that aren't documented in any single place.
Generic ETL tools (Informatica, Talend, custom Python with pandas) don't know any of this. They emit data files that the developer hopes are HDL-compliant, submit them via the HDL UI (manual upload, no programmatic submission), wait for ESS to process them (6 hours later — discovering a schema violation that could have been caught in 6 seconds locally), interpret the Fusion error log manually (HCM domain expertise required), and start the cycle again. A typical bulk load using generic tooling takes 4-6 weeks of iterative fix-and-resubmit. With HDL-native load automation, it takes 18-30 hours of compute time and a single round of remediation.
Syntra ETL's Sage People load automation is HDL-native end-to-end. Bundle assembly respects dependency rules. Payload validation runs locally against the current Fusion release schema (catches 95%+ of errors before submission). ESS job submission via LoaderIntegrationService SOAP. Status tracking via ScheduledProcessesService. Failure parsing extracts per-record errors with business-rule context. Remediation library handles common patterns automatically. The result is a load phase that doesn't dominate the project timeline.
A repeatable, pre-built pipeline for every Sage People HCM business object. Same engine for bulk load and incremental delta replay.
Transformed Sage People data assembled into HDL .dat files per business object with current-release METADATA headers, MERGE keywords, and column ordering. Output zipped as HDL bundle.
Bundle validated against the current Fusion release HDL schema (26A, 25D, etc.). Format errors, missing required fields, invalid lookup codes, business-rule violations caught locally.
Bundle submitted to Fusion HCM via LoaderIntegrationService SOAP API. Process ID captured. Operator identity logged. Submission audit trail recorded for SOX evidence.
ESS status polled every 30 seconds via ScheduledProcessesService. Dashboard shows live progress per bundle. Webhook/Slack/email notifications on terminal status.
On terminal status (SUCCESS / ERROR / WARNING), full ESS log automatically retrieved from Fusion. Per-record error detail parsed. Diagnostics presented in human-readable form.
Errored records routed back to transformation layer with full Fusion error context. Remediation library applies common-pattern fixes. Re-emitted as delta bundle. Re-submitted automatically.
The actual sequence for a representative mid-market Sage People migration. Wave dependencies determine sequencing.
Department.dat, Location.dat, Position.dat, Job.dat, Grade.dat, SalaryBasis.dat bundles. ~50k records per hour. Foundation for everything downstream — must succeed before Wave 2.
Worker.dat (5,000 workers with PersonName/Address/Phone/Email/NationalID), WorkRelationship.dat, WorkTerms.dat. ~15k workers per hour throughput. Reconciliation between waves.
Assignment.dat with full 7-year effective-dated history per worker — ~25,000 historical assignment records. ~8k records per hour. Dependency-aware, fails fast if Wave 2 incomplete.
Salary.dat with full historical chain — ~30,000 historical salary records across 7 years. ~12k records per hour. Compensation Workbench eligibility validated post-load.
AbsenceCase.dat + AbsenceEntry.dat for current and historical absences. Opening AbsenceEntitlement balances loaded. UK statutory leave preserved.
Open performance reviews via PerformanceDocument.dat, open goals via GoalPlan.dat, open onboarding workflows via REST API. Final reconciliation kickoff at hour 30.
A curated library of common Fusion HDL error patterns with pre-built remediation logic. New patterns added with each migration; library grows with the platform.
Sage People date fields with non-ISO formats (DD/MM/YYYY) reformatted to YYYY-MM-DD HDL standard. Time zones normalized to UTC.
Non-printable characters in name fields, smart quotes in address fields, UTF-8 edge cases stripped or normalized to HDL-compliant ASCII subset.
Reference data (Department, Location, Position) loaded in dependency order. Forward references caught locally; downstream loads held until references resolved.
Salary currency mismatches between worker and assignment caught and routed. FX-conversion logic applied per Fusion currency-of-record rules.
Worker history with effective-date gaps (Sage People legacy artifacts) reconciled or held for HR review. Continuous chain produced for Fusion.
Circular manager assignments (rare but real) detected before submission. Cycle broken with HR notification; clean hierarchy submitted to Fusion.
Sage People picklist values not aligned to Fusion lookup codes caught by local validation. Value mapping applied from signed crosswalk.
Duplicate Worker__c records (M&A artifacts) detected by fuzzy match. Merge decision applied per remediation library; manager chains preserved.
Bundle headers automatically aligned to current Fusion release schema (26A, 25D). Deprecated fields stripped, new required fields populated from source.
Sage People load automation is the engineered, repeatable pipeline that takes transformed Sage People data and submits it to Oracle Fusion HCM via HCM Data Loader (HDL) bundles — without manual file uploads, without bespoke ESS job submissions, and without per-load surprises. The automation layer handles HDL bundle assembly (worker.dat, workrelationship.dat, workterms.dat, assignment.dat, salary.dat, absencecase.dat in the correct dependency order), validated payload submission (catching schema and business-rule violations locally before submission, not after a 6-hour Fusion ESS run), ESS job tracking (real-time status, completion notifications, failure log retrieval), and failure routing (errored records routed back through the transformation layer for fix-and-resubmit). It's the difference between a 14-week Sage People migration and a 14-month one.
Because Oracle Fusion HCM Data Loader has its own ecosystem that doesn't look like generic database loads. HDL is a Fusion-specific framework with strict file format rules (.dat tab-delimited, specific column header conventions, METADATA vs MERGE keywords per business object), strict dependency rules (Worker before WorkRelationship before Assignment before Salary), HCM business-object schemas that evolve per Fusion release (26A vs 25D vs 25C have material schema differences), ESS job submission via the LoaderIntegrationService SOAP API or HDL UI bulk upload, and Fusion-specific error reporting that requires HCM domain knowledge to interpret. Generic ETL load automation tools don't know any of this. Syntra ETL's HCM load automation is purpose-built for Fusion HDL — pre-validated against current Fusion release schemas, dependency-aware, error-aware.
An HDL (HCM Data Loader) bundle is a .zip file containing one or more .dat files plus metadata. Each .dat file targets a specific HCM business object (Worker, WorkRelationship, Assignment, Salary, AbsenceCase, etc.) with tab-delimited records and prescribed column headers. For Sage People migration, the bundle composition depends on the load wave: Wave 1 bundle has Reference Data (Department, Location, Position, Job, Grade, Salary Basis), Wave 2 bundle has Worker + WorkRelationship + WorkTerms, Wave 3 bundle has Assignment + Salary, Wave 4 bundle has AbsenceCase + AbsenceEntry. Each bundle is loaded as a single ESS job submission, processed by HCM in dependency order. Syntra ETL's automation emits bundles with the right structure, the right METADATA headers, and the right MERGE keywords — pre-validated before submission to eliminate the most common cause of ESS failure (malformed bundles).
ESS (Enterprise Scheduler Service) is Fusion's job submission and tracking framework. When an HDL bundle is submitted, ESS assigns a Process ID, schedules execution, runs the load, and produces a status (SUCCESS, ERROR, WARNING, BLOCKED) with detailed error logs. Sage People load automation uses the Fusion LoaderIntegrationService SOAP API for programmatic bundle submission, polls ESS via the ScheduledProcessesService for status updates every 30 seconds, retrieves completion logs automatically on terminal status, and notifies the migration team via webhook/Slack/email. For a typical Sage People migration with 8-12 HDL bundles, the automation tracks all bundles in parallel where dependencies allow, sequentially where they don't, and produces a real-time dashboard of load progress. No manual ESS UI navigation, no spreadsheet tracking of bundle status.
Failure routing is the difference between weeks of rework and same-day fix-and-resubmit. When an HDL bundle completes with ERROR or WARNING status, the automation retrieves the detailed error log from ESS, parses per-record errors (which can be hundreds in a bad bundle), and routes errors back to the transformation layer with full context: original source record, transformed payload, exact Fusion error message, business-rule violated. The transformation engine applies fixes (per a curated remediation library of common Fusion HDL errors), re-emits a corrected delta bundle, and re-submits. Customers see typical first-pass HDL success rates of 95-98% on the initial bulk load, climbing to 100% by the second or third remediation cycle. Common failure patterns (date format issues, missing reference data, business-rule violations) have pre-built remediations; novel failures get added to the library.
Throughput depends on the Fusion HCM environment sizing, the load type, and the dependency graph. Reference data (Department, Location, Position): ~50,000 records per hour per bundle. Worker + WorkRelationship + WorkTerms: ~15,000 workers per hour for a clean load (no business-rule violations). Assignment (with effective-dated history): ~8,000 worker-assignments per hour. Salary (with full history chain): ~12,000 salary events per hour. AbsenceCase + AbsenceEntry: ~20,000 absence records per hour. For a 5,000-worker Sage People migration with 7 years of history, full bulk load takes 18-30 hours of ESS processing time, with most spent on Assignment and Salary historical chains. Customers running staged bulk-then-delta patterns spread this across the migration window rather than concentrating in cutover weekend.
Yes — incremental load is the primary use case after initial bulk. Once Fusion HCM is live, Syntra ETL's load automation continues to operate for: parallel-run delta loads (Sage People still operational, deltas pushed to Fusion for reconciliation), late-discovered Sage People history (additional historical periods loaded post-go-live), Sage People archive replays (a Sage People legacy data access query that needs to materialise in Fusion for compliance reasons), and post-go-live cleanup loads (corrections discovered in hypercare). The same HDL bundle assembly + validation + submission + ESS tracking + failure routing pipeline supports incremental flows; only the source data scope changes. Some customers continue using the load automation for non-Sage-People Fusion HCM loads (Concur expense data, Workday merger acquisitions, etc.) after the primary migration completes.
Two integration patterns. Pattern 1 (recommended for production): Syntra ETL load automation pushes HDL bundles directly to Fusion via LoaderIntegrationService SOAP. OIC is bypassed for the bulk migration phase — adds complexity without value. Pattern 2 (post-migration steady-state): Once Fusion HCM is live, ongoing integrations (Sage People archive replays, third-party feeds, post-migration cleanups) route through OIC for governance, monitoring, and orchestration alignment with the customer's broader Fusion integration estate. Syntra ETL's load automation provides OIC-compatible REST endpoints for this. Customers running OIC-first architectures can use Pattern 2 from day one with a small throughput trade-off; customers prioritising speed-to-go-live use Pattern 1 then add OIC orchestration in steady-state.
HDL-native bundle assembly, local payload validation, ESS tracking, failure routing — purpose-built for Fusion HCM Data Loader. Book a 30-minute walkthrough and we'll show you the load automation on real Sage People data.