Skip to main content

Component Manifest Examples

This page collects two end-to-end Component Manifest examples for SDK developers. Each is a complete JSON payload of the kind you embed in a Java component class to declare its identity, its configuration form, and its operational metadata to the platform.

Component Manifest versus Adapter Definition

Two related but distinct artifacts exist on the platform. They are not authored by the same person, and this page is only about the first.

ArtifactAuthored byPurposeWhere it lives
Component ManifestPlugin Developer (SDK)Declares a single reusable component (Connector, Processor, Transformer, Condition, ErrorProcessor) to the platform. Drives the form the Portal renders for that component and the operational metadata the platform relies on.Embedded in a Java class via the SDK's component annotation.
Adapter DefinitionOperations / DevOpsDeclares an adapter instance: which connector to use, which routes the pipeline runs, and which target each route delivers to. Packaged into Custom Bundles and deployed via Helm.A .json file inside a Custom Bundle.

This page focuses exclusively on Component Manifests. For the operations-side Adapter Definition workflow, see Custom Bundles & Extensibility.

The structural rules each example follows are documented in full in Component Manifest Schema. Read that page first if you have not already; this page assumes the schema reference and shows two complete realisations of it.

Example 1: A Connector with a network listener​

This manifest declares a Connector that opens a network listener and optionally authenticates inbound clients. It demonstrates the layout extensions, widget overrides, and the operational marker the platform needs to surface a network port.

{
  "id": "gateway-listener-connector",
  "pluginId": "acme-gateway",
  "functionalType": "GATEWAY_LISTENER",
  "displayName": "Gateway Listener",
  "category": "CONNECTOR",
  "configuration": {
    "$schema": "http://json-schema.org/draft-07/schema#",
    "type": "object",
    "title": "Gateway Listener Settings",
    "x-order": [
      "listenPort",
      "tlsEnabled",
      "requireAuth",
      "username",
      "password"
    ],
    "required": ["listenPort"],
    "properties": {
      "listenPort": {
        "type": "integer",
        "title": "Listen Port",
        "description": "TCP port the connector binds to for inbound traffic.",
        "minimum": 1,
        "maximum": 65535,
        "default": 9100,
        "x-section-title": "Network",
        "x-is-port": true
      },
      "tlsEnabled": {
        "type": "boolean",
        "title": "Require TLS",
        "description": "When enabled, the listener accepts TLS-terminated connections only.",
        "default": false,
        "x-widget": "switch"
      },
      "requireAuth": {
        "type": "boolean",
        "title": "Require Authentication",
        "description": "When enabled, the listener challenges every inbound client for credentials.",
        "default": false,
        "x-section-title": "Authentication",
        "x-widget": "switch"
      },
      "username": {
        "type": "string",
        "title": "Username"
      },
      "password": {
        "type": "string",
        "title": "Password",
        "x-widget": "password"
      }
    }
  }
}

Why the schema is structured this way:

  • The top-level keys (id, pluginId, functionalType, displayName, category) carry the component's identity to the platform's component registry. category: "CONNECTOR" puts the component in the connector pickers in the Portal.
  • x-order enumerates the field render order. A property not listed is appended after the ordered ones rather than hidden, so listing every property simply makes the order explicit.
  • x-section-title on listenPort and requireAuth opens two visible sections: Network and Authentication. Properties between section titles cluster under the most recent heading.
  • x-is-port: true on listenPort tells the platform this value is a network port. The platform reads every port-marked field at deploy time and surfaces the value as a Kubernetes Service port. Skipping this leaves the listener unreachable.
  • password uses x-widget: "password", which masks the input box and nothing else. It is a display choice, not a security control: the value is stored, exported, and displayed like any other. Keep credentials out of the configuration entirely by holding an ${env:VAR_NAME} reference, which the adapter resolves at runtime.

Example 2: A Processor with dynamic artifact selection​

This manifest declares a Processor that validates each in-flight message against a schema chosen at adapter-configuration time. It demonstrates dynamic resource lookup and the advanced-area pattern for niche tuning.

{
  "id": "schema-validator-processor",
  "pluginId": "acme-validation",
  "functionalType": "SCHEMA_VALIDATOR",
  "displayName": "Schema Validator",
  "category": "PROCESSOR",
  "configuration": {
    "$schema": "http://json-schema.org/draft-07/schema#",
    "type": "object",
    "title": "Schema Validator Settings",
    "x-order": [
      "schemaArtifactId",
      "failOnError",
      "validationTimeoutMs"
    ],
    "required": ["schemaArtifactId"],
    "properties": {
      "schemaArtifactId": {
        "type": "string",
        "title": "Schema Artifact",
        "description": "Schema document the processor validates each inbound message against.",
        "x-widget": "dynamic-select",
        "x-resource": "artifacts",
        "x-filter": { "type": "json-schema" },
        "x-label-key": "name",
        "x-value-key": "id",
        "x-placeholder": "Select an uploaded schema"
      },
      "failOnError": {
        "type": "boolean",
        "title": "Fail Route on Validation Error",
        "description": "When enabled, a validation failure routes the message into the error handler chain instead of acknowledging it.",
        "default": true,
        "x-widget": "switch"
      },
      "validationTimeoutMs": {
        "type": "integer",
        "title": "Validation Timeout (ms)",
        "description": "Maximum wall time the processor will spend validating a single message before giving up.",
        "minimum": 1,
        "maximum": 60000,
        "default": 250,
        "x-advanced": true,
        "x-tooltip": "Increase only when validating very large payloads against deeply nested schemas. The default is sufficient for almost every workload."
      }
    }
  }
}

Why the schema is structured this way:

  • category: "PROCESSOR" puts the component in the processor pickers in the Pipeline Designer.
  • schemaArtifactId is the central choice the operator makes for this processor. It uses x-widget: "dynamic-select" with x-resource: "artifacts" and a json-schema filter, so the dropdown lists every uploaded JSON Schema artifact and nothing else. Operators choose by name, while the persisted value is the artifact's stable identifier.
  • Marking the field as required and giving it the first slot in x-order makes the operator's primary decision the first thing they see.
  • failOnError is a boolean rendered as a switch because it is a binary policy choice that reads more naturally as on/off than as a checkbox.
  • validationTimeoutMs is a niche tuning knob. Putting it under x-advanced: true keeps it out of the primary form for the common case while still letting operators reach it when needed. Its description explains when changing the default is appropriate, so a reader does not have to guess. The field also carries an x-tooltip, but when a field has both, the description is the text shown on hover.
  • Every field carries default, description, and the validators (minimum, maximum, required) the platform needs to reject bad input before the configuration is saved.

See also​