Read the Agile product record out whole. Items, revisions, structures, manufacturer parts, AML, change orders, redlines and the file vault, extracted to CSV, Parquet or JSON with checksums, row counts and lineage recorded as the data lands.
Anyone can select from an Agile table. The value is in coming out the other side with a product record whose parts still reference each other correctly, including the files.
SyntraETL reads Agile through its own relationships. An item pulls its revisions; each revision pulls the attribute state, structure, AML and attachments that applied at that revision; change orders pull their affected objects and redlines; attachments pull both the metadata row and the physical file from the vault. What lands in staging is a navigable record, not a pile of disconnected exports.
Extraction is read-only against the source. Agile keeps running, and where the window matters the extract can run in delta mode against a previous baseline so only what changed is re-read. Each run records row counts per object, checksums per file, start and end times, and the exact query set used, so the extract itself is auditable.
Output goes wherever the programme needs it: CSV or Parquet for a warehouse, JSON for an API-driven target, or straight into the transformation layer when the extract is the first stage of a migration rather than a deliverable in its own right.
Built for programmes where someone will later ask how a number was produced.
No writes, no triggers, no schema changes on the Agile instance. Extraction runs against a replica where one is available.
A signed full baseline, then delta runs against it, so a long programme does not re-read terabytes every cycle.
Physical files pulled with checksums recorded on landing, and the association to item, revision or change preserved as metadata.
CSV for handover, Parquet for analytics at volume, JSON where the downstream target is API-driven.
Row counts per object, file counts and sizes, checksums, timings and the query set, recorded per run in DataVault.
An extract is a configuration, not a script someone wrote once. The same definition re-runs months later and produces a comparable result.
From first connection to a signed baseline, typically inside three weeks.
Read-only connection to the Agile database and vault, then an inventory of classes, subclasses, populated attributes and object counts.
Agree object families, revision depth, date ranges and whether the vault is in scope in full or by attachment category.
Volumes, cardinality, orphan and duplicate detection, vault size and file-type distribution, so the run time is predictable.
Full extract with checksums and counts, signed and held as the reference every later delta compares against.
Incremental runs on the agreed cadence, each reconciled against the baseline so drift is visible rather than assumed away.
An extract is only as useful as the evidence that comes with it. Without counts and checksums, a partial run and a complete one look identical, and the difference surfaces much later.
Every run writes the following to DataVault alongside the data, so a question asked months afterwards about what was extracted has an answer that does not depend on anyone’s memory.
What teams try first, and where each one runs out of road.
Fine for a one-off list. No file vault handling, no revision-level history, and no evidence that the export was complete.
Fast for a single table. Rebuilding the relationships between items, revisions, AML, changes and files in SQL is where the effort quietly goes.
Relationship-aware extraction across objects and vault together, with checksums, counts and lineage produced as a by-product of the run.
Through a read-only connection to the Agile database and file vault, driven by the object model rather than a table list. The extractor walks items to their revisions, revisions to the attribute, structure, AML and attachment state that applied at that revision, and change orders to their affected objects and redlines. Vault files are pulled alongside their metadata with a checksum recorded per file. Nothing is written back to the source, and where a database replica exists the extract runs against that instead of production.
Yes, and this is usually the part that determines the schedule. The extractor pulls the physical file and its metadata together, records a checksum as each file lands, and preserves the association to the item, revision or change order that carries it. Vaults commonly run to terabytes, so file extraction is planned with a measured throughput figure from profiling rather than started and hoped about.
CSV for handover to another team or supplier, Apache Parquet where the destination is a warehouse or lake and the volumes justify columnar compression, and JSON where the downstream target is API-driven. Where the extract is the first stage of a migration rather than a deliverable in its own right, it feeds the transformation layer directly and no intermediate file is produced at all.
It is read-only, so there are no writes, no triggers fired and no schema changes. The practical impact is query load, which is managed by scheduling extraction outside business hours, throttling concurrency, or pointing the extract at a database replica where one exists. Vault file reads are sequential and rate-limited so file-server throughput stays predictable.
Yes. Scope can be narrowed by object family, by item class or subclass, by lifecycle phase, by date range, by product line, or by attachment category. Selective extraction is common when the goal is a specific downstream need such as a data lake feed or a supplier handover rather than a full migration. The same profiling and reconciliation apply to a partial extract as to a complete one.
Every run produces its own evidence: row counts per object family, file counts and total bytes for the vault, per-file checksums, run timings and the query set used. Those numbers become the baseline. Delta runs reconcile against it, so a gap shows up as a reconciliation difference rather than as a missing record somebody notices months later.
Tell us the objects, the revision depth and whether the vault is in scope. We will size the extract, estimate the run window and tell you what profiling is likely to find.