In an event-driven architecture (EDA), topics are a means of classifying the information contained in the payload or each event instance. Events are published to a topic and consumers can subscribe to topics to attract all events for that topic from every publisher. When you create an event in Designer, you define a topic address for each event. The topic address is a set of topic levels. Each level in the topic address can have a literal value or can have a variable value that is later substituted for a concrete value that is specific to the event instance. At run time, when an application publishes instances of an event, the topic address is used to construct the topic for each instance. For more information, about how topics work, see Understanding Topics.
Before you start defining topic addresses, it's best practice to define the overall topic hierarchy or taxonomy for your EDA. A good topic hierarchy classifies the topics of events published and consumed within an event mesh. Each topic for an event is expressed as one or more topic levels.
Hierarchical addressing is also used in URLs. When you go to a page on a website, the URL is a hierarchical address with the form:
The scale of the Internet would not work without the hierarchical addressing used by devolved and dynamic global DNS and web servers, which divide up the task of serving portions of the entire domain to end users.
For more information, see Topic Architecture Best Practices.
A topic address is expressed as a series of hierarchical topic address levels. Each topic address level can be a literal value or variable. A variable is a placeholder that is substituted with a concrete value by publishing applications at runtime. A variable topic address level can be an enumeration with a defined value set (bounded), or it can be unbounded.
The topic addresses for events published to Solace event brokers use a forward slash
/ as a delimiter to separate levels. Kafka brokers don't natively support topic hierarchies; however, to support organizing your EDA, you can use topic hierarchies if you specify a character to act as a delimiter to represent level divisions in your Kafka topics.
Each application domain can have one or more topic domains. The topic domain can include one or more topic address levels. It's best practice for each application domain to have unique topic domains. The topic domains should represent the top levels of your topic hierarchy for events within the application domain. You can require new events to use topic addresses that starts with one of the a topic domains of the application domain .
Using Variables in Topic Domains and Topic Addresses
When you add a topic domain to an application domain or a topic address to an event, each level can be specified by a literal value or by a variable. A variable is a placeholder that is replaced with a concrete value by the publishing application at runtime. You can use a literal value when you want a topic address level to be the same for all instances of an event. You must use a variable when you want the topic level to classify an event by a value specific to the event instance. For example, if an event is generated when someone scans a barcode, a variable for the location of the scanner could be one level of the topic address. When a barcode is scanned and an application generates an event instance, the variable in the topic address is replaced with the actual location of the scanner in the topic of the event instance. Other applications can then subscribe only to event instances for scanners in that location and you can track events related to specific locations.
Variables can be unbounded or you can limit a variable to a list of options using enumerations. Enumerations are a type of topic address level variable that define a bounded list of acceptable values. If you use an enumeration for a variable, only values that are part of the enumeration can replace the variable in the topic at runtime. For example, if an event instance could occur in any of six possible locations and you want the topic to include the location, you could create an enumeration that includes the six options. For more information, see Enumerations.
Defining Kafka Topic Addresses
When defining Kafka topic addresses or subscriptions, be aware of the following:
Kafka topic addresses don't support enumerations.
Kafka topic subscriptions don't support wildcards.
Kafka brokers don't recognize level delimiters in topics. If you want to include Kafka events in your EDA, you can specify a delimiter that Event Portal recognizes in Kafka topics. All Kafka topic addresses in your organization's account must use the same delimiter. For more information, see Setting the Kafka Delimiter.
Topic Address Syntax
Topic addresses have a few syntax rules and best practices. Some rules are enforced in Designer.
Topic addresses can't exceed 128 levels.
Topic addresses can't include empty levels. All delimiters must have text or a variable between them.
Topic addresses can't exceed 255 characters.
Topic address level variables must start with a letter or underscore and must contain only alphanumeric and underscore characters.
For Solace topic addresses, don't use /, *, >, or ! within a topic address level. These characters have special meaning.
For more information about topic syntax, refer to SMF Topics.
A topic subscription is a string that consumers use to attract the events published to a topic on an event mesh. Unlike topic addresses, topic subscriptions can contain wildcards to match with multiple topics. The
> characters can be used as wildcards in topic subscriptions.
* appears by itself at a level within a topic subscription it indicates a wildcard match at that level. For example,
animals/*/cats matches the topics
> character is used at the last level of a subscription to indicate a “one or more” wildcard match for any topics. For example,
animals/domestic/> doesn't match the topic
animals/domestic, but it does match