Layer 2: EIP Overview

Layer 2 is the set of Enterprise Integration Pattern (EIP) models in the qubit-core library: package integration, import path ideaswave.com/qubit/core/pkg/integration. You run it inside your own Go service with the SDK's camel runtime (ideaswave.com/qubit/sdk/camel). It is not a hosted Priostack feature: no priostack.com route accepts Layer 2 configuration, and the console deploys none. It sits beside the BPMN execution engine (Layer 1) and talks to it over the REST API.

Architecture Diagram

  External Systems / APIs · Messages (JSON/XML/binary)
         v
  ┌────────────────────────────────────────────────────────┐
  │                    LAYER 2: EIP                        │
  │                                                        │
  │  ┌─────────────┐     ┌─────────────┐                  │
  │  │  Message    │────►│  Message    │                  │
  │  │  Channel A  │     │  Router     │──► Channel B     │
  │  └─────────────┘     │  (FEEL)     │──► Channel C     │
  │                      └─────────────┘──► Channel D     │
  │                                                        │
  │  ┌─────────────┐     ┌─────────────┐                  │
  │  │  Splitter   │────►│  Pipeline   │                  │
  │  │  (fan-out)  │     │  (filter →  │                  │
  │  └─────────────┘     │   translate)│                  │
  │                      └─────────────┘                  │
  │                                                        │
  │  ┌─────────────┐     ┌─────────────┐                  │
  │  │  Aggregator │     │  Correlation│                  │
  │  │  (collect N)│     │  Context    │                  │
  │  └─────────────┘     │  (dedup)    │                  │
  │                      └─────────────┘                  │
  │                           │                           │
  │              ┌────────────▼────────────┐              │
  │              │   Message Endpoint      │              │
  │              │   (bean calls REST API) │              │
  │              └────────────────────────┘              │
  └────────────────────────────────────────────────────────┘
                           │
                           v
              ┌────────────────────────┐
              │    LAYER 1: BPMN       │
              │    Execution Engine    │
              └────────────────────────┘
    

Only the filter and aggregate steps run in the camel runtime today (plus JSON-Schema validate:, log: and your bean: handlers). The router, splitter, translator, endpoint and correlation context are declared in the model and carried out by your own code.

Patterns Reference

Each pattern is a Go struct in ideaswave.com/qubit/core/pkg/integration. The examples show its fields under their JSON names, which are the only names the model reads. In practice you rarely write this JSON: the camel runtime builds the same structs from a Camel Spring-DSL document (see Layer 2 for a complete routes file and its Go wiring).

// A publish-subscribe channel for order events
{
  "id": "order-events",
  "name": "Order events",
  "kind": "publish_subscribe",
  "item_def_id": "order"
}

// Route by order amount
{
  "id": "order-router",
  "name": "Route by amount",
  "source_uri": "direct:order-events",
  "routes": [
    { "channel_id": "high-value-orders", "condition": "amount > 10000", "priority": 2 },
    { "channel_id": "standard-orders",   "condition": "amount > 1000",  "priority": 1 },
    { "channel_id": "small-orders" }
  ]
}

// Aggregate all order lines before processing
{
  "id": "order-lines",
  "name": "Collect order lines",
  "correlation_expr": "orderId",
  "completion_cond": "last = true",
  "output_channel_id": "order-ready"
}

// Resume the instance waiting for this payment transaction
cc := integration.NewCorrelationContext("transactionId")
cc.Register("TX-981", "run_1ce49bbc5260b39423bd", "wait_payment")

entry := cc.MatchVars(map[string]any{"transactionId": "TX-981"}) // the wait, now removed
again := cc.MatchVars(map[string]any{"transactionId": "TX-981"}) // nil

// Filter, translate, filter again
{
  "id": "validated-orders",
  "name": "Validate orders",
  "source_uri": "direct:order-events",
  "steps": [
    { "component_id": "not-test",        "component_kind": "filter" },
    { "component_id": "legacy-to-order", "component_kind": "translator" },
    { "component_id": "positive-amount", "component_kind": "filter" }
  ]
}

// Split an order batch into individual orders
{
  "id": "order-splitter",
  "name": "One message per order",
  "split_expr": "orders",
  "output_channel_id": "individual-orders"
}

// Translate from legacy order format to canonical format
{
  "id": "legacy-to-order",
  "name": "Legacy to canonical order",
  "source_item_def": "legacy-order",
  "target_item_def": "order",
  "mapping_expr": "{ orderId: legacy.order_no, customerId: legacy.cust_id, amount: legacy.amount_cents / 100, currency: upper case(legacy.curr) }",
  "output_channel_id": "orders"
}

// Only pass orders from the EU region
{
  "id": "eu-only",
  "name": "EU orders only",
  "predicate": "region = \"EU\" and currency in (\"EUR\", \"GBP\", \"CHF\")",
  "channel_id": "eu-orders"
}

// Orders leave Layer 2 for the order service
{
  "id": "orders-out",
  "name": "To order processing",
  "channel_id": "validated-orders",
  "direction": "outbound",
  "service_ref": "order-service"
}

Integration with BPMN

Layer 2 and Layer 1 meet over the REST API. A bean in your camel runtime starts an instance with POST /api/v1/process-instances (one credit), or completes a job with POST /api/v1/jobs/{key}/complete. A process waiting at a message catch event is offered to workers as a job of type event:message:<elementId>: the hosted API has no message correlation route, so there is no correlation-key matching.

See the Architecture page for the full two-layer system diagram and how the layers interact.