RabbitMQ / FIL bridge
Publish Genesys Cloud operational events and FIL-processed messages to RabbitMQ exchanges for legacy and event-driven consumers — an implemented bridge for estates standardized on a message bus rather than HTTP feeds or polling.
At a glance
Implemented- What it delivers
- Genesys-derived events and FIL-processed messages published to RabbitMQ exchanges.
- Who consumes
- FIL subscribers and legacy event-driven consumers on a message bus.
- Source path
- Service Bus → FIL bridge service → RabbitMQ exchange.
- Status
- Implemented — deployable per integration profile.
- Distinct from
- The full core reactive processing pipeline — optimized for event-bridge scenarios.
Structural KPIs derived from Genesys topics — plus client-specific metrics — are computed once in the Reactive Engine and shared across all sinks.
Embed ingest, reactive processing and storage on infrastructure you own on Azure, AWS or GCP — or consume it as a managed PaaS bridge.
Sub-second, continuous reactive processing from the live Genesys event stream — no nightly batch windows for streaming sinks.
Each destination ships as a Global.Platform.* package; the Reactive Engine is never rewritten.
Overview
A bus bridge for event-driven estates
Some enterprise architectures mandate message-bus consumption. This connector bridges Genesys-derived events onto RabbitMQ for the consumers that expect them.
Genesys events on the bus your services already use
Messages are consumed from Azure Service Bus, processed through FIL-specific processors, and published to RabbitMQ for downstream subscribers — distinct from the reactive processing pipeline and optimized for event-bridge delivery.
- For existing FIL or RabbitMQ subscribers
- When HTTP feeds aren't acceptable downstream
- Exchange and routing mapping defined in discovery

Powered by the Reactive Engine
Every connector is a thin package on one proven core
This connector does not re-implement Genesys integration. It is a focused Global.Platform.* egress package bound to the same Reactive Engine that powers Power BI, operational HTTP feeds and the rest of the catalog. The hard part — correlating the Genesys event stream into trustworthy operational KPIs — is solved once and reused everywhere.
- One ingestion and reactive processing pipeline, many destinations
- Adding a sink is a connector, not a re-architecture
- Consistent KPI semantics across every downstream system
Platform capabilities
The engine guarantees behind every delivery
This connector inherits the correctness, durability and governance of the Reactive Engine — not just a pipe to a destination.
Deterministic reactive processing
The engine computes each KPI from the raw event stream with explicit, reviewable semantics — not opaque aggregates you can't reconcile.
Durable log & replay
An ordered, durable event log lets you recompute, backfill and audit any interval with confidence after a config change.
Idempotent delivery
Keyed envelopes with timestamps let every downstream consumer dedup safely on retry, replay or backfill.
Schema & version governance
Payload contracts are versioned per connector, so consumers upgrade on their own schedule without surprise breakage.
Backpressure & retry
Retry-with-backoff and dead-letter patterns keep transient downstream failures from ever losing a KPI.
Fan-out from one source
Mix real-time streaming and scheduled feeds to many destinations from a single, consistent source of truth.
Integration depth
How deep the integration goes
Integration is a spectrum, not a checkbox. Genesys operational truth is exposed through the Streamvane platform deployed in your Azure — from straightforward egress to a connector embedded in your processing path.
Compute & deliver
The default for most connectors: Genesys operational KPIs are computed once and delivered outward to your destination — streaming or scheduled.
- Read-oriented egress of computed metrics
- Streaming push or scheduled feed cadence
- Same KPI semantics as every other sink
Operational contracts
Schema-controlled, SLA-bound feeds with reconciliation and acceptance criteria — the contract-grade integration WFM and BPO programs depend on.
- Versioned payload schema with acceptance tolerances
- Interval discipline, timezone and latency contracted
- Reconciliation against Genesys source built in
Embedded in your platform
Streamvane is deployed plug-and-play — down to components and code — inside your own cloud subscription on Azure, AWS or GCP, sitting in the Genesys processing path. Genesys operational truth is exposed through our offering, not a brittle hand-built API scrape that drifts on every routing change. Prefer not to operate it? Run the same engine as a managed PaaS bridge instead.
- Deployed into your event mesh and data plane, on Azure, AWS or GCP
- Plug-and-play components, or fully managed as a PaaS
- Extensible with new Global.Platform.* packages
Security
Your data, your tenant, your keys
Security isn't an afterthought bolted onto an export — it's the architecture. Genesys operational data is processed and stored inside your own Azure subscription, under your governance.

Client-owned cloud & data residency
When embedded, Genesys data is ingested, computed and stored inside your own subscription and region — on Azure, AWS or GCP — never transiting or resting in a vendor-controlled cloud.
Encryption in transit & at rest
TLS 1.2+ to every endpoint and Azure storage encryption at rest, with customer-managed keys where your policy requires them.
Secrets in Key Vault, no creds in code
Connection strings, tokens and certificates live in your Key Vault and are read with Managed Identity — never embedded in configuration or source.
RBAC & least privilege
Every component runs with scoped Azure RBAC roles and the minimum permissions needed for its sink — auditable and reviewable.
Network isolation
Private endpoints, VNet integration and IP allow-listing or mTLS keep traffic on private paths where downstream security requires it.
Audit & observability
Diagnostic logs and Application Insights give you a full audit trail of what was produced, when, and to which destination.
DevOps & SecOps
Built to live in your software lifecycle
The connector is engineered, versioned and operated like any other service in your estate — provisioned as code, shipped through your pipelines, governed by your release process.
Infrastructure as Code
The whole footprint — Service Bus, the metrics store, Key Vault, workers and the connector — is provisioned from Bicep or Terraform you can review and own.
CI/CD pipelines
Build, test and deploy through your Azure DevOps or GitHub Actions pipelines, with the connector versioned like any other service.
Environment promotion
Dev, test and production parity with config-driven KPI profiles, so a feed proven in test promotes cleanly to production.
Config & secrets management
KPI profiles, schedules and endpoints are configuration — managed in App Configuration and Key Vault, not hard-coded redeploys.
Observability & SLOs
Health, lag and throughput are surfaced as metrics and alerts so operations teams trust the numbers and catch drift early.
Security in the pipeline (SecOps)
Dependency and static analysis run in the pipeline, with change control and SecOps gates aligned to your release process.

Frequently asked
Is this the same as the Kafka connector?
They share the platform egress philosophy but target different brokers. RabbitMQ is implemented and FIL-aware; Kafka is framework-ready on the same core.
Can some consumers get feeds and others get bus events?
Yes — combine the Reactive Engine with HTTP feeds and the RabbitMQ bridge so each consumer gets the transport it expects.
What's the FIL bridge?
A processing path that handles FIL-specific message shapes for legacy consumers, distinct from the core reactive processing used for feeds and APIs.
See this connector running on your Azure tenant
Book a scoping call and we'll map your KPI families to this destination — with the security, lifecycle and depth of integration your teams require.
Streamvane by Tessovia · Azure · AWS · GCP · Your data, your keys