SoR Integration Architecture

How customers connect Systems of Record (ServiceNow, vCenter, Splunk, CMDBs) to the FFO digital twin using Kaoto, Camel-K, and Wanaku — visual integration development that feeds the living knowledge graph.

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: 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: 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: 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

The following integrations demonstrate the pattern and serve as templates for customer deployments:

vCenter Integration (5 Tools)

Tool	Pattern	Purpose
`vcenter.list_vms`	On-Demand	List all VMs with power state and host
`vcenter.get_vm`	On-Demand	Get detailed VM configuration
`vcenter.sync_inventory`	Scout (5min)	Full inventory sync to FFO
`vcenter.list_hosts`	On-Demand	List ESXi hosts with health
`vcenter.get_events`	Event-Driven	Real-time VM lifecycle events

ServiceNow Integration (5 Tools)

Tool	Pattern	Purpose
`servicenow.search_incidents`	On-Demand	Search incidents by CI or severity
`servicenow.get_incident`	On-Demand	Get incident details
`servicenow.create_incident`	On-Demand	Create incident from agent findings
`servicenow.sync_cmdb`	Scout (15min)	Sync CMDB CIs to FFO entities
`servicenow.incident_webhook`	Event-Driven	Real-time incident notifications

Splunk Integration (3 Tools)

Tool	Pattern	Purpose
`splunk.search`	On-Demand	Execute SPL queries
`splunk.get_alerts`	On-Demand	Get triggered alerts
`splunk.sync_findings`	Scout (10min)	Sync notable events as FFO findings

Building a New Integration

Creating a new SoR integration follows a standard workflow:

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
Test locally — run the route in Kaoto’s local mode against a development FFO instance
Deploy to Kubernetes — export the route as a Camel-K IntegrationPlatform CR and apply to the target namespace
Register in Wanaku — add the route’s MCP tool definition to the Wanaku routing configuration
Verify in FFO — confirm entities and relationships appear in the knowledge graph

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