TOPIC_MATCH Operator

AMPS provides the TOPIC_MATCH operator to compare a string value against a topic pattern using the resolved topic matching policy for the current command or configuration object. This operator is useful when a message field contains a topic name, routing key, subject, or destination and you want to evaluate that field using the same topic matching rules that AMPS uses for subscriptions and topic-based configuration.

The syntax of the operator is:

string_expression TOPIC_MATCH pattern_literal

AMPS also supports the negated form:

string_expression NOT TOPIC_MATCH pattern_literal

The right side of the predicate must be a literal string. As with LIKE, you can use a standard quoted string or a raw string literal when that makes the expression easier to read.

Relationship to LIKE

LIKE and TOPIC_MATCH both compare strings to patterns, but they are intended for different jobs:

Predicate	Pattern Semantics
LIKE	Always uses PCRE syntax, regardless of TopicMatchingPolicy or topic_matching_policy.
TOPIC_MATCH	Uses the resolved topic matching policy.

Use LIKE when you need full regular expression matching on string values. Use TOPIC_MATCH when the string you are matching should be interpreted as a topic or subject according to the AMPS topic matching policy in scope.

How AMPS Resolves the Policy

AMPS resolves the policy for TOPIC_MATCH as follows:

• For commands that support topic expressions, topic_matching_policy=<policy> overrides the global default for that command.
• For configuration-defined filters, a sibling TopicMatchingPolicy on the owning object overrides the global default for that object.
• Otherwise, AMPS uses /AMPSConfig/TopicMatchingPolicy.
• If no TopicMatchingPolicy is configured, AMPS falls back to the legacy RegexTopicSupport behavior: pcre when enabled, exact matching when disabled.

When a command uses topic_matching_policy, AMPS applies that same policy both to the command topic and to any TOPIC_MATCH predicates compiled for that command.

Policy-Specific Behavior

The behavior of TOPIC_MATCH depends on the resolved policy.

Policy	Behavior
pcre	Interprets the pattern literal as a PCRE pattern.
solace	Interprets the pattern literal using Solace topic wildcard syntax. Solace is a registered trademark of Solace Corporation.
tibco	Interprets the pattern literal using TIBCO topic wildcard syntax for TIBCO Rendezvous and TIBCO Enterprise Message Service (EMS). TIBCO is a trademark or registered trademark of Cloud Software Group, Inc.
mqtt	Interprets the pattern literal using MQTT topic wildcard syntax. MQTT is a trademark of OASIS Open.
rabbitmq	Interprets the pattern literal using RabbitMQ topic exchange wildcard syntax, where . separates topic levels, * matches exactly one topic level, and # matches zero or more topic levels.
ibmmq	Interprets the pattern literal using IBM MQ-style wildcard matching, where * matches any sequence of characters, ? matches a single character, and % escapes *, ?, and % so they are treated literally.
nats	Interprets the pattern literal using NATS subject wildcard syntax, where . separates tokens, * matches exactly one token, and > matches one or more trailing tokens.
glob	Interprets the pattern literal as a glob expression, including the Redis-style glob syntax, where * matches any sequence of characters, ? matches a single character, and \ escapes wildcard characters.

When topic pattern matching is disabled by setting RegexTopicSupport to false without setting TopicMatchingPolicy, TOPIC_MATCH behaves like an exact string comparison.

Under the solace, tibco, mqtt, rabbitmq, and nats policies, PCRE-only constructs such as ^, $, and .* are not valid topic patterns.

Under the rabbitmq policy, only * and # have special meaning, and . is the topic level separator.

Under the ibmmq policy, only *, ?, and % have special meaning. Use % to match a literal *, ?, or %.

Under the nats policy, . is the token separator, * matches exactly one token, and > matches one or more trailing tokens. The > wildcard must appear as the last token in the pattern.

Under the glob policy, which follows the same style used by Redis glob matching, only *, ?, and \ have special meaning. Characters such as ^, $, and . are interpreted literally rather than as regular expression metacharacters.

Examples

When the resolved policy is pcre, TOPIC_MATCH uses PCRE:

/destination TOPIC_MATCH '^orders/(na|eu)/.*$'

When the resolved policy is solace, TOPIC_MATCH uses Solace wildcard rules:

/destination TOPIC_MATCH 'orders/*/priority/>'

When the resolved policy is tibco, TOPIC_MATCH uses TIBCO subject matching rules with . as the topic level separator:

/subject TOPIC_MATCH 'ORDERS.*.PRIORITY.>'

When the resolved policy is mqtt, TOPIC_MATCH uses MQTT wildcard rules:

/topic TOPIC_MATCH 'sensors/+/temperature'

When the resolved policy is rabbitmq, TOPIC_MATCH uses RabbitMQ topic exchange wildcard rules:

/routing_key TOPIC_MATCH 'audit.#.user'

When the resolved policy is ibmmq, TOPIC_MATCH uses IBM MQ-style wildcard rules:

/topic TOPIC_MATCH 'Sport/*ware/Results'

To match a literal wildcard character under the ibmmq policy, escape it with %:

/topic TOPIC_MATCH 'orders/%*.json'

When the resolved policy is nats, TOPIC_MATCH uses NATS subject wildcard rules:

/subject TOPIC_MATCH 'time.us.>'

When the resolved policy is glob, TOPIC_MATCH uses glob-style wildcard rules:

/topic TOPIC_MATCH 'orders/*.json'

To match a literal wildcard character under the glob policy, escape it with \. In a filter, use a raw string literal or double the backslash so the glob converter receives the escape:

/topic TOPIC_MATCH r'orders/\*.json'

The negated form returns true when the value does not match the topic pattern:

/topic NOT TOPIC_MATCH 'sensors/+/temperature'

Arrays

TOPIC_MATCH is array-aware, just like LIKE and the other boolean comparison operators.

When the value on the left side is an array, TOPIC_MATCH returns true if any element in the array matches the pattern. NOT TOPIC_MATCH returns true only when no element in the array matches the pattern.