SOLUTION · REPLICATE TO SOLACE PUBSUB+

Real-time data replication to Solace PubSub+ event meshes

Every committed change in your systems of record is published onto your Solace event mesh as it happens, with one topic per entity and action, instead of waiting for a batch export.

Gluesync by MOLO17 captures changes from Oracle, IBM i, SQL Server, PostgreSQL, MongoDB, and other heterogeneous sources with a dedicated agent per database. The Solace target agent publishes each change over SMF with Solace's official Java SDK, either as direct or persisted messages, after a snapshot loads every entity. Core Hub, the Gluesync control plane, runs every pipeline from one web UI and REST API.

Start a Gluesync trial Talk to us

WHO THIS IS FOR

Teams feeding a Solace event mesh from systems of record

Integration architects who route business events across sites and clouds on PubSub+ and need the database layer to publish into the mesh without custom bridge code
Application teams that subscribe to topic namespaces such as orders/insert and orders/update and want consumers to react to real row changes
Platform leads running PubSub+ on premises or on PubSub+ Cloud who want one Core Hub for every source, backed by best-in-class enterprise support, rated 4.9/5 by customers
Teams replacing a homegrown publisher, a Kafka bridge, or nightly files that feed the mesh, who want every source delivered by one product

THE PROBLEM

Event meshes fed by batch files react hours late

Solace event meshes carry the events that day-to-day operations run on, but the database side often feeds them through nightly files, polling services, or hand-written publishers inside applications. Subscribers then react to a snapshot of the business instead of to each change, polling adds load to production, and every bridge is one more component to monitor. Buyers weighing a fix usually compare a Kafka bridge with a source connector, custom publishers their teams maintain, and commercial replication products with their own target lists.

Gluesync addresses that with per-agent CDC into PubSub+. A source agent reads each database's native change mechanism, Core Hub routes each change, and the Solace target agent publishes it to a topic built from the entity and the action. Every source uses the same topic pattern, so subscribers keep working as you add databases.

HOW IT WORKS

How Gluesync publishes to Solace PubSub+

The write path: Solace's Java SDK over SMF

The Solace target agent publishes through Solace's official Java SDK over SMF, the protocol PubSub+ uses natively. It is a target agent: it receives changes from any Gluesync source agent and publishes each one to the topic for its entity and action, with no bridge, staging layer, or Kafka hop in between.

Optimized batches, never row by row: Core Hub hands the agent changes in grouped batches, and the agent publishes them through publishers it keeps open per entity and delivery mode, so there is no per-message connection setup on the broker.
One messaging service per agent serves every entity that agent publishes, which keeps the number of client connections on the Message VPN small and predictable.
JSON payloads: every message body is JSON, whichever database the change came from. Solace PubSub+ agent overview ↗

Topics by entity and action

Topic pattern: each change publishes to collection/insert, collection/update, or collection/delete, so subscribers can follow one action or the whole namespace with a wildcard.
Entity key: each message carries the entity key as a message property, built from the fields you choose with the document key builder, so subscribers match every event to its record.
Deletes: a delete publishes to the delete topic with the key of the removed row, so subscribers receive removals as explicit events.
Snapshot, then stream: a snapshot publishes each entity's current rows, then changes follow in real time on the same topics, and an interrupted snapshot resumes from its last saved state.
Shaping before publish: Custom Field Functions and UDFs reshape each payload, and Allowed Operations chooses which actions reach the mesh, for example inserts and updates only. See data transformation.

Direct or persisted delivery, per entity

Direct publishing is the default for every entity.
Persisted publishing is switched on per entity. Those messages go through Solace's persistent publisher, the guaranteed messaging path, for entities whose events subscribers must not miss.
Priority and expiry: each entity can set a message priority and a time to live for its messages.
Routing: the Solace routing for persisted messages is prepared on the broker before the pipeline starts.

Message VPN, credentials, and TLS

Each pipeline publishes into one Message VPN with a broker account that can publish to its topics. The full field list and REST calls are in the target setup guide ↗.

Create a broker account with publish permission on the topics for your entities, in the Message VPN you will use.
On premises, connect to the broker host on port 55555. On PubSub+ Cloud, enter the host with its protocol, such as tcps:// followed by the cloud hostname, and the secured SMF port of your service.
Enter the username, the password, and the Message VPN name.
For production, turn on TLS and upload the trust store with its password.
Choose the SASL mechanism and security protocol for the broker. On PubSub+ Cloud the usual choice is SCRAM-SHA-256 with SASL_SSL.

Architecture around Core Hub

Lightweight agents sit close to each source. Core Hub orchestrates them through its web UI and REST APIs and routes every change to the Solace agent. A pipeline groups the source agents, the Solace agent, and the entities they replicate, and Core Hub and the agents deploy with Docker, Docker Compose, or Kubernetes, on-premises or in any cloud. See CDC streaming.

Agents can run in the data center beside an IBM i or Oracle system while the broker runs on PubSub+ Cloud, so the mesh receives database events from sites that have no other route onto it. Solace is also a MOLO17 technology alliance partner.

Explore the general CDC streaming architecture →

WRITE OPTIONS

The Solace PubSub+ target agent: one agent, two delivery modes

PubSub+ has one Gluesync target agent. Delivery is chosen per entity: direct publishing for most topics, and persisted publishing where the broker should store each message on the persisted path.

Agent	Write technique	Versions	Best for
Solace PubSub+ agent ↗	Solace Java SDK over SMF, grouped publishing through per-entity publishers, direct by default and persisted per entity	PubSub+ on premises and PubSub+ Cloud, through a Message VPN	Event meshes that route business events to many consumers. Pick it when subscribers need topics by entity and action, and use persisted publishing on the entities that the broker should store.

SOURCES AND TOPOLOGIES

Put database changes on the mesh from the systems you run

Any Gluesync source agent can publish to PubSub+, each with its own native capture technique. Open the integrations finder with Solace PubSub+ pre-selected to see every source you can pair with it, from IBM i and Oracle to MongoDB and Couchbase.

One Core Hub can run Oracle to PubSub+, IBM i to PubSub+, and SQL Server to PubSub+ side by side, with one set of snapshot and monitoring controls. Gluesync keeps pace with your change volume at any scale, and the delivery mode is yours to choose per entity; MOLO17 Professional Services can help design the topic taxonomy with your integration team.

IBM i (AS/400) to PubSub+ through the native journal APIs: see IBM i CDC
Oracle to PubSub+ from the redo logs through LogMiner or XStream: see Oracle CDC
SQL Server to PubSub+ through Change Data Capture or Change Tracking: see SQL Server CDC
PostgreSQL, MySQL, and MongoDB to PubSub+ from the WAL, the binlog, and change streams: see PostgreSQL CDC, MySQL CDC, and MongoDB CDC

FAIR, HIGH-LEVEL COMPARISON

Where Gluesync fits among event mesh feeding approaches

Approach	What buyers usually get	Where Gluesync fits
Kafka as the bridge	Kafka topics carry the changes, and a bridge or connector moves them onto PubSub+. Each hop runs, upgrades, and scales on your team's side	One Core Hub from source to PubSub+, with the same topic pattern for every source and no Kafka cluster in the path. Read the Debezium alternative comparison
Custom publishers in applications	Full control over topics and payloads. Your team writes and maintains each publish call, and handles retries and schema changes	Changes come from the database log, so writes made outside the application are published too, and the topic pattern stays the same as sources change; see CDC streaming
Batch files and scheduled extracts	Simple to schedule, and the mesh reacts to whatever the last file contained	Changes are published as they arrive, after a snapshot loads each entity, so the mesh reflects each change rather than each batch; see cloud migration for the initial load pattern
Commercial replication suites	Mature replication products with broad target lists. PubSub+ support and setup differ by product	A commercial product with a dedicated agent per source, Core Hub operations, and MOLO17 enterprise support behind every pipeline
Cloud-managed replication services	Managed replication into their own cloud's services, with destination lists that follow each provider's catalog	Agents that run on premises or in any cloud, writing to PubSub+ on premises or in PubSub+ Cloud; see migrating to Gluesync

Solace PubSub+ background and implementation detail

What does replicating to Solace PubSub+ with Gluesync involve?

A source agent captures committed changes from your database through its native change mechanism, Core Hub routes them, and the Solace agent publishes each change to the topic for its entity and action, after a snapshot loads the entity.

How are topics named?

Each change publishes to a topic built from the entity collection and the action: collection/insert, collection/update, or collection/delete. The entity key travels as a message property.

What is the difference between direct and persisted publishing?

Direct publishing is the default. Switching on persisted publishing for an entity sends its messages through Solace's persistent publisher, the guaranteed messaging path, with the routing prepared on the broker beforehand.

Does the agent work with PubSub+ Cloud as well as on-premises brokers?

Yes. The agent connects to PubSub+ on premises on port 55555, and to PubSub+ Cloud with the host entered with its tcps protocol, using a Message VPN in both cases.

How does the connection get authenticated and secured?

With a username and password that has publish rights in the Message VPN, and TLS with a trust store, which we recommend for production.

Which sources can publish to PubSub+?

Any Gluesync source agent, including Oracle, IBM i, SQL Server, PostgreSQL, MySQL, MongoDB, and Couchbase. The integrations finder shows every pairing with Solace PubSub+.

How are message priority and expiry set?

Each entity can set a message priority and a time to live for its messages, or leave them without expiry.

REPLICATE TO A TARGET