Orchestration configuration

The orchestration configuration is one versioned document per tenant that tells the order engine how the tenant trades: its channels, purchase moments and markets, the systems it connects, which system executes what, how status events map to statuses, and how payments are allocated. Every change is validated, versioned and audited, and can be rolled back.

The document

Section	Content
trip	anchor_product_types (product types that can anchor a trip) and id_prefix for trip ids.
channels, moments, markets	The codes quotations and purchase orders may use.
systems	The connected systems (see below). The id oms is reserved for the order engine itself.
processes	The processes ownership is decided for. Default create, modify, cancel, payment, fulfilment, billing.
ownership_rules	Which system executes which process for which lines (see below).
feedback	expectations (which status events a system must send after a request) and alert_rules (how long to wait before alerting).
event_catalogue	Additions or changes to the built-in inbound event catalogue.
outbound_events	Optional catalogue of outbound event types.
quotations	required_fields (by default and by channel) and inactivity_days.
line_availability	Product types sold only on certain channels.
payments	Payment scenarios, allocation rules, overpayment handling and passenger split.

The full schema is OrchestrationConfigSchema in the OpenAPI document.

Connected systems

Each entry in systems describes one system the order engine works with:

Field	Meaning
id, label, description	Identity.
domains	What it is responsible for, for example reservation, onboard, excursions, crm, finance.
roles	source, channel and/or target.
route	direct, or integration_layer with via (for example a MuleSoft application).
contract	The interface contract name, version and history.
status, effective_from	active, planned or retired, and from when.
capabilities	What it accepts and emits: outbound requests and inbound events, synchronous or asynchronous, idempotent or not.
master_of, references_kept, field_mappings	Data ownership and how its references and fields map to the order engine's.
owner_team	Who operates it.

Read them with GET /order-orchestration/systems and GET /order-orchestration/systems/{id}; system health is in Monitoring.

Execution-ownership rules

A rule says which system executes a process for the lines it matches:

{ "id": "excursions-onboard", "process": "*", "when": { "product_type": ["excursion"], "moment": ["onboard"] }, "owner": "onboard" }

Field	Meaning
process	A process code, or * for all.
when	Match conditions on product_type, channel, moment and market.
owner	The system id, or oms when the order engine itself executes it.
priority	Tie-breaker between matching rules.
effective_from, effective_until	Time-boxed rules, for example moving drinks packages from the onboard system to the order engine on a cut-over date.
notify	Systems told about the outcome.
on_failure	The team that handles a failure.

GET /order-orchestration/ownership/resolve?process=&productType=&channel=&moment= returns the owner and a trace of every rule considered, which is how to check a rule set before publishing it. Each order line stores the rule that chose its system.

Changing the configuration

Call	Effect
GET /order-orchestration/config	The effective document, its version and where it comes from (command_api once a version has been published through the API, tenant_file before).
POST /order-orchestration/config/validate	Validates a document without publishing it: 200 with no issues, or 422 with every issue and its path.
PUT /order-orchestration/config	Publishes a new version. Send expectedVersion to make it conditional (409 version_conflict otherwise), plus actor and reason.
GET /order-orchestration/config/history	Every version and the audit trail: who, when, why and the field-level changes.
POST /order-orchestration/config/rollback	Publishes a new version equal to an older one.

Validation checks references across the document: unknown systems, processes, channels or event types; duplicate rules; empty effective windows; executors that are not active; payment scenarios on anchors they do not allow. Reads such as systems, rules and ownership/resolve accept version (a number, latest or published) and at (evaluate effective dates at a time), so a draft can be inspected before it applies.

Where the tenant uses governed configuration, a change needs approval before it is published.

See the configuration changes guide and the reference for Orchestration configuration.