DSLCore Orchestrator Documentation
The DSLCore Orchestrator is a separate control-plane application. It registers the applications and connectors in a DSLCore estate, defines the canonical identity that lets those apps refer to the same business things, routes events and records between them with field-level transforms, runs the scheduled jobs, reconciles cross-system state, raises and works governance exceptions, and keeps the delivery, execution and audit history for all of it. It is not the master database for business records — every domain app keeps ownership of its own data and business logic.
This section covers the DSLCore Orchestrator application specifically. For how the interface works in general (lists, forms, navigation, deletion), see the Framework Guides above.
In This Section
- Application Overview — what the app models and why, the operating chain, and the boundary between the control plane and the domain apps
- Quick Reference — menu map, the demo-data codes and their meaning, status vocabularies, and rules of thumb
- System Diagram — the 23-model data model mapped, with an interactive pan/zoom viewer
The Application in One Paragraph
The orchestrator answers one question for a fleet of DSLCore apps — is the right
information moving to the right place, on time, and can we prove it? It starts
with a registry: every application instance (DSLCore, external, legacy or
infrastructure) with its health endpoint and operational status, and the
connectors that know how to talk to each one. On top of that sits canonical
identity — the shared business entities (ExplorationProject, Tenement,
ExplorationTarget, …) each with a canonical key — plus entity ownership
recording which app is authoritative for an entity or a single field, and
entity mappings tying each canonical key to its local key in each app. The
integration core receives an event message against an event
definition, deduplicates it, matches it to route definitions, applies each
route's field mappings (direct, value-map, expression, cast, unit, lookup or
constant), and records a delivery attempt per target; deliveries that exhaust
their retries land in the dead-letter queue. The scheduling engine holds
action and job definitions, their schedules (cron / interval /
one-time), the job-execution history, the sync checkpoints that mark how
far each incremental sync has got, and the retry policies that govern
back-off. Governance is where absence, inconsistency and staleness are caught,
not just emitted events: control definitions (existence, absence,
reconciliation, freshness, timeliness, threshold, completeness, cardinality,
state, sequence) run on a schedule, each control execution passes or fails,
and a failure raises a governance exception that is worked through
Open → Acknowledged → Investigating → Remediation → Resolved → Verified → Closed —
where Verified means the originating control was rerun and passed — with every
step captured as an exception action. Health checks track technical
liveness and an audit record trail records who did what to which object.
Delivery is at-least-once and targets are expected to be idempotent; secrets are
only ever referenced, never stored. This app is the connective tissue for the
Exploration Assurance Suite (eis / epa / elwpm) and any external or legacy system
wired alongside it.