Build a connector that publishes events

Learn how to build a custom connector from the Grand Central connector template that publishes events to Sync Hub. Use this pattern when a source system produces data changes that downstream systems need to receive, for example account updates or payment status changes. For the concepts behind this pattern, see Event streaming. For field-level detail on envelopes, headers, and properties, see Sync Hub events and files reference.

​

Prerequisites

Before you start, make sure you have:

• A connector repository scaffolded from the connector template. For more information, see Set up the project.
• Sync Hub deployed in your target runtime, with a topic for your events. For more information, see Sync Hub deployment and configuration.
• Java and Maven installed for local builds.

​

Build the connector

The template includes an event publish route that posts to the Sync Hub producer through the gc-http-caller Kamelet. You configure the route with properties instead of writing HTTP calls by hand.

1. Define the event contract. Decide the topic name, the event source domain, the schema version, and the payload shape inside the data object. Align these with the teams that consume the event.
2. Set the Sync Hub properties in the connector’s application.properties file:
   asb.event.type=com.backbase.party.event.spec.v1.PartyUpdateEvent
   asb.event.source=com.backbase.party
   asb.event.version=1.0.0
   asb.event.topic=party-updates
   asb.producer.apiUri=http://asb-producer.synchub-producer.svc.cluster.local
   
   The template route builds the publish endpoint as ${asb.producer.apiUri}/${asb.event.topic}/publish and sets the bbEventType header from asb.event.type. The template hardcodes the eventSource header and derives eventVersion from the payload schema. In a production connector, set these headers from your own configuration, for example with the asb.event.source and asb.event.version properties. The asb.event.type value shown is an example. Use the event spec class that matches your event contract. Confirm the producer release name in the Application manifest for your runtime. Some runtimes deploy a versioned release name such as asb-producer-v0. For property descriptions, see Connector properties.
3. Implement the route logic: read from the source system, transform the payload into your event contract, and set the per-request values identifier and traceParent on the outgoing message. These values change for each event, so the connector sets them per request rather than in configuration. For route structure guidance, see Anatomy of a connector.
4. Add the Sync Hub pod labels to the connector’s values.yaml file so the runtime network policy allows the call to the producer:
   connector:
     customLabels:
       app.gcservices.io/synchub-enabled: "true"
       app.gcservices.io/synchub-type: "producer"
   
5. Build and run the connector locally:
   mvn clean verify
   mvn quarkus:dev
   

​

Verify the connector

To confirm the connector publishes events:

1. Trigger the route in your local or development environment.
2. Check the connector logs for a successful publish to the producer.
3. Check the producer logs in Grafana for the matching publish activity. For queries, see Logs.
4. Confirm the message arrives on the topic with Azure Service Bus tooling. For more information, see Service Bus explorer.

​

Next steps

• Configure a custom connector: Secrets, properties, and traits for deployment.
• Test and validate: Add automated tests for your route.
• Sync Hub go-live checklist: Verify your setup before production.