Integration Wizard

The Integration Wizard — the in-app UI under Management → Integrations that generates collector_config.yaml snippets for the integrations the platform recognises.

The Integration Wizard is an in-app UI under Management → Integrations that helps operators bootstrap a collector_config.yaml for the integrations the platform recognises. It is a template generator, not an installer: it does not deploy a collector, write to disk, or talk to any source system. It produces a parameterised YAML snippet that the operator copies into their own collector_config.yaml.

What the wizard does

• Lists every integration the platform's classpath registers (one card per integration; sorted case-insensitively by id).

• For each integration, renders a multi-section wizard panel:

  • Title and description — taken from the integration's manifest (IntegrationPreview model: id, name, description).

  • Content blocks — ordered sections, each with a title, prose content, and zero-or-more code snippets. Use these to walk the operator through prerequisites, snippet selection, and post-deploy verification (whatever the manifest author put there).

  • Code snippets — parameterised templates with form fields. The operator fills in the inputs; the wizard interpolates them; the rendered output is shown ready to copy.

What it does NOT do

• It does not deploy or launch a collector — that is operator-side work, see Deployment Options.

• It does not write collector_config.yaml for you — the file lives on the host running the collector; the wizard only feeds you a snippet.

• It does not validate the snippet against a target source — credentials, hosts, and ports are typed at face value.

• It is not the same surface as the Integrations hub — the hub documents what each integration is, the wizard generates configuration for some of them.

How operators use it

1. Open Management → Integrations in the platform UI.

2. Pick an integration card (PostgreSQL, Snowflake, …).

3. Read the wizard's content blocks (prerequisites, instructions).

4. Fill in the form parameters the wizard prompts for (host, port, credentials, …). The wizard pre-fills any static parameter — see "Static parameters" below.

5. Copy the rendered YAML snippet into the plugins: list of your collector_config.yaml.

6. Run your collector with the updated config — see Build and run ODD Collectors or the chart-based deployment options.

Static parameters

A code-snippet argument has an isStatic flag (and a staticValue field on the wire). When isStatic = true, the platform — not the operator — supplies the value. Today exactly one parameter is wired up this way: platform_url, read from odd.platform-base-url (StaticArgumentMappingContext.java:11-19). The Java field default is the placeholder string http://your.odd.platform, so on a fresh deployment without the key set explicitly the wizard will pre-fill platform_url with that placeholder — see Configure ODD Platform → odd.platform-base-url for the full caveat about this default. Always set odd.platform-base-url to your real deployment URL in any non-local environment, then open the wizard so the snippets carry a working URL out of the box.

All other arguments default to isStatic = false and are entered by the operator.

API surface

The wizard's two backing endpoints — GET /api/integrations (list) and GET /api/integrations/{integration_id} (full overview with content blocks and code snippets) — are documented at API Reference → Integrations. Call them directly to script integration-snippet generation outside the in-app UI.

Integration registry

The wizard is data-driven. Every integration card is one YAML manifest packaged on the platform's classpath at META-INF/wizard/*.yaml. At startup IntegrationRegistryFactory scans classpath*:META-INF/wizard/*.yaml (Spring's PathMatchingResourcePatternResolver), parses each manifest into an IntegrationOverviewDto, and stores them in a case-insensitive TreeMap keyed by id. Adding a new integration to the wizard means dropping a new manifest into a JAR on the platform's classpath; the platform does not currently support hot-reload — a restart is required.

The exact manifest schema is the contract defined by IntegrationOverviewDto and its nested DTOs (IntegrationPreviewDto, IntegrationContentBlockDto, IntegrationCodeSnippetDto, IntegrationCodeSnippetArgumentDto, IntegrationCodeSnippetArgumentTypeEnum).

Wizard vs collector_config.yaml

	Integration Wizard	collector_config.yaml
Where it lives	In the Platform UI (Management → Integrations)	On the host running the collector
What it produces	A YAML snippet for one plugin (one integration)	The full collector configuration: platform_host_url, token, default_pulling_interval, plugins: list
Who reads it	The operator setting up an integration	The collector process at startup
Persistence	None — the wizard re-renders each time	The file you keep under source control

The wizard is a starting point, not a replacement. Operators still maintain collector_config.yaml themselves — combining wizard-generated snippets with hand-authored ones (multiple plugins of the same type, custom filters, secrets backend references, environment-variable overrides). For the full file shape see the Integrations hub → Common configuration and the collector build-and-run guide.

Where to next

• Integrations hub — what each integration is, paired with the wizard cards on the same in-app surface.

• Build and run ODD Collectors — fields the wizard does not surface (filters, secrets, default_pulling_interval, …).

• Configure ODD Platform → odd.platform-base-url — set this before opening the wizard so static platform_url substitution carries a working URL.

• Collector secrets backend — keep wizard-generated credentials out of the YAML you commit.