SoR Integration Architecture

Design for bringing system-of-record data into the FFO digital twin with Kaoto, Camel-K, and Wanaku. Connectors to specific systems of record are not implemented yet.

Status: connectors to vCenter, ServiceNow, Splunk, CMDBs, and other systems of record are not implemented yet. The verified HyperSync routes are timer routes with one log step; see Building a first HyperSync integration. The patterns below describe the design, not running integrations.

The Problem

Enterprise customers have operational data spread across multiple Systems of Record — ServiceNow for ITSM, vCenter for virtualization, Splunk for log analytics, legacy CMDBs for asset inventory, and dozens of others. InfrastructureAI’s autonomous agents need a unified view of this infrastructure to reason about problems and plan remediations. But asking customers to rewrite their data pipelines or migrate to a new data store is a non-starter.

The solution: a visual integration framework that lets operators connect any System of Record to the FFO knowledge graph without writing code. Data flows in, the digital twin stays current, and agents get real-time situational awareness from the customer’s actual infrastructure — not from stale documentation or manual imports.

Architecture

The integration stack has four layers:

Layer Component Role
Development Kaoto (VS Code Extension) Visual route designer — drag-and-drop integration flows
Runtime Camel-K (Kubernetes) Lightweight integration runtime — runs routes as pods
Bridge Wanaku MCP routing layer — exposes Camel routes as MCP tools
Knowledge FFO (TypeDB) Living digital twin — receives entity state from integrations 
Source System (vCenter, ServiceNow, Splunk, ...)
  │
  ▼
Kaoto (visual design) → Camel-K Route (runtime)
  │
  ├── Writes to FFO via FFO MCP Server
  │     (entity state, relationships, findings)
  │
  └── Exposed as MCP Tool via Wanaku
        (agents can invoke the integration on demand)

Three Integration Patterns

1. Scout Pattern (Polling)

Timer-driven routes that periodically poll a source system and write current state to FFO. Used for Systems of Record that don’t support webhooks or event streams.

  • Trigger: Cron schedule (e.g., every 5 minutes)
  • Data flow: Poll source API → Transform → Write to FFO
  • Example (not implemented): vCenter VM inventory sync — polls vCenter API, writes VM entity state (name, power state, host, resource pool) to FFO

2. Event-Driven Pattern (Webhooks)

Routes triggered by real-time events from source systems. Used when the SoR supports webhooks, change notifications, or event streams.

  • Trigger: HTTP webhook endpoint exposed by the Camel-K route
  • Data flow: Receive event → Validate → Transform → Write to FFO
  • Example (not implemented): ServiceNow incident webhook — fires when a new incident is created, writes the incident entity and its relationship to the affected CI in FFO

3. On-Demand Pattern (MCP Tool Invocation)

Routes exposed as MCP tools via Wanaku. Agents or operators invoke them when they need fresh data from a source system — lazy hydration rather than continuous sync.

  • Trigger: MCP tool call from an agent or operator
  • Data flow: Agent calls tool → Camel route fetches from source → Returns result to agent → Optionally writes to FFO
  • Example (not implemented): Splunk log search — agent calls splunk.search MCP tool during an investigation, Camel route executes the SPL query and returns results

Classification-Aware Routing

Integration routes are deployed to classification-specific namespaces. Each classification level (IL2, IL4, IL5, IL6) has its own Wanaku instance that enforces scope boundaries:

  • Routes in the IL4 namespace can only write to IL4-scoped FFO entities
  • Wanaku enforces OPA policies that prevent cross-classification data flow
  • Credentials for source systems are stored as Kubernetes Secrets in the appropriate namespace
  • An IL6 air-gapped deployment has its own Camel-K operator and Wanaku instance with no external network access

Security

Concern Mechanism
Authentication OIDC tokens for MCP tool access; source system credentials as Kubernetes Secrets
Authorization OPA policies at the Wanaku layer — tool-level and entity-level access control
Credential Management No credentials in route definitions; all secrets mounted from Kubernetes
Audit Every MCP tool invocation logged; FFO write-back creates an audit trail in the knowledge graph
Network Isolation Namespace-scoped NetworkPolicies; classification-level Wanaku instances

Reference Integrations

No vCenter, ServiceNow, or Splunk integration is implemented yet. No tools for those systems are registered.

Building a New Integration

Creating a new SoR integration follows a standard workflow:

  1. Design in Kaoto — open the Kaoto VS Code extension, create a new route, configure the source component (HTTP, timer, webhook), add transformation steps, and configure the FFO MCP write destination
  2. Test locally — run the route in Kaoto’s local mode against a development FFO instance
  3. Deploy to Kubernetes — export the route as a Camel-K IntegrationPlatform CR and apply to the target namespace
  4. Register in Wanaku — add the route’s MCP tool definition to the Wanaku routing configuration
  5. Verify in FFO — confirm entities and relationships appear in the knowledge graph

See the MCP Server development guide for additional patterns and conventions.