Wildcards

Wildcards are how IBM MQ subscriptions listen to families of events instead of one fixed topic string. The plus sign (+) stands in for exactly one hierarchy level; the hash (#) absorbs the rest of the tree below a prefix. Used well, retail/+/shipped lets one subscription cover every country’s shipped event without listing retail/uk/shipped, retail/de/shipped, and dozens more. Used carelessly, enterprise/# on a powerful service account copies every publication in the company onto one queue—a data exfiltration pattern waiting for an audit finding. Publishers never publish to wildcards; only subscribers declare them in TOPICSTR. This tutorial walks through matching rules with multiple examples, overlapping subscriptions, interaction with authority on topic branches, performance when many subs match one hot topic, testing methodology, and governance templates your integration COE can adopt.

Rules of + and #

Plus requires one segment at its position. Pattern a/+/c does not match a/b/c/d because two levels sit where one plus is allowed—use a/+/+/c or a/# instead. Hash must appear at the end of the subscription pattern in standard IBM MQ usage and matches zero or more additional levels. finance matches finance alone; finance/# also matches finance/payment and finance/payment/completed. Combining literals and wildcards is how you express precise branches.

Overlapping Subscriptions

Publish to retail/uk/order/shipped with Sub1 retail/# and Sub2 retail/uk/#—both match, two copies, possibly to the same DEST if misconfigured twice. Design teams document whether overlap is intentional (audit plus regional) or accidental duplicate processing. Competing consumers on one DEST still share messages; two subs to one DEST doubles puts—do not confuse with competing consumer load balancing.

1
2
3
DEFINE SUB('SUB.REGIONAL') TOPICSTR('retail/+/shipped') DEST('REGIONAL.SHIPPED.Q')
DEFINE SUB('SUB.ALL.RETAIL') TOPICSTR('retail/#') DEST('ALL.RETAIL.Q')
* Publish retail/uk/shipped — both receive — two messages total

Security and Governance

Grant SUB on wildcards only to identities that may read entire branches. Pair with DEST queues encrypted at rest if payloads are sensitive. Deny developers SUB on prod/# in production queue managers—use per-domain subs in test. DISPLAY SUB(*) TOPICSTR should be a monthly audit report reviewed by security.

Performance Considerations

Each matching subscription costs a put at publish time. One publish matching fifty wildcard subs is fifty puts—hot topics need subscription discipline. Prefer narrower patterns (+) over # when possible. Split high-rate streams into dedicated topic branches instead of one giant # listener.

Testing Wildcards

1. Define subs in lab with + and # variants.
2. Publish concrete strings and log which DEST depths increase.
3. Negative test: publish string that should not match.
4. Automate tests in CI with embedded queue manager or testcontainers.

Explainer: TV Channel Packages

Exact topic subscription is one channel. Plus is “any one regional news feed.” Hash is “everything in the sports package.” You still broadcast concrete shows (publish strings); viewers pick packages (wildcard subs).

Explain Like I'm Five: Wildcards

Plus means “any one flavor.” Hash means “every flavor that starts with this name.” You still sell one specific flavor at a time—the wildcard is only on the listening list.

Practice Exercises

Exercise 1

Which subs match publish logistics/eu/road/dispatched?

Exercise 2

Design minimal wildcard set for three regional order consumers.

Exercise 3

Explain why enterprise/# SUB is dangerous on a shared QM.

Frequently Asked Questions

Test Your Knowledge