Integrating Solace Topics with AMPS

This page assumes a bridge, adapter, or application republishes Solace messages into AMPS while preserving the original destination topic in the AMPS topic name or in a message field. That model lets teams preserve familiar Solace naming while AMPS becomes the current-state, query, and analytics layer for observability and interactivity. The same naming approach also makes a later shift to direct AMPS publish simpler because the topic space seen by applications remains familiar.

Where Solace and AMPS Overlap

Solace and AMPS both rely on hierarchical topics. AMPS can preserve Solace wildcard patterns by using TopicMatchingPolicy set to solace as the instance default or as a local override on the imported Solace namespace. Subscriptions and SOW queries can also use topic_matching_policy=solace, and any TOPIC_MATCH predicate in the same command filter uses Solace wildcard rules.

That makes AMPS a good fit when teams want to preserve an existing Solace topic hierarchy but add:

• Current-state snapshots for every destination in a namespace through the SOW
• Atomic cache hydration and live updates through sow_and_subscribe
• Lighter payloads for browser clients through sow_and_delta_subscribe
• Aggregated dashboard datasets with Views and Unions
• Lower-frequency presentation topics with ConflatedTopics

Solace Patterns Compared to Default AMPS PCRE

The default AMPS policy, pcre, uses regular expressions. Solace topic syntax is wildcard-based and is easier to preserve directly when migrating existing subscriptions.

Solace Pattern	Meaning	Representative PCRE Equivalent
orders/>	Match one or more topic levels below orders	`^orders(/(?!#P2P(?:/
orders/*/priority/>	Match one topic level between orders and priority, then one or more levels below priority	`^orders/(?!#P2P(?:/
>	Match every topic eligible for Solace wildcard delivery with at least one level	`^(?![$])(?:(?!#P2P(?:/

Under solace, wildcard characters only have special meaning when used as Solace wildcard levels. PCRE anchors and operators such as ^, $, and .* are not valid Solace topic patterns.

Recommended AMPS Design

For a Solace-backed observability architecture:

1. Preserve the original Solace topic name when the integration layer publishes into AMPS.
2. Keep the instance default at pcre unless most of the instance uses Solace semantics. For imported Solace namespaces, add TopicMatchingPolicy set to solace beside each Pattern or UnderlyingTopic that should use Solace rules.
3. Capture the Solace namespace into a Pattern SOW topic such as orders/>.
4. Create a Union whose UnderlyingTopic repeats that same pattern expression so dashboards can treat the namespace as one consolidated SOW source.
5. Create Views for aggregations and a ConflatedTopic for UI refresh intervals.

This structure works both when AMPS is introduced alongside an existing Solace estate and when teams later standardize new application flows directly on AMPS topics.

info

Pattern topics are ideal for wide topic spaces where each logical topic holds a small number of records. When a single logical topic carries many records, individual SOW topics may be a better fit.

Sample Configuration

The following configuration keeps the instance default at pcre, preserves a Solace order namespace with local Solace overrides, creates a consolidated AMPS dataset from it, and produces a topic intended for dashboards:

<AMPSConfig>
  <Name>solace-observability</Name>
  <TopicMatchingPolicy>pcre</TopicMatchingPolicy>

  <SOW>
    <Topic>
      <Name>solace-orders-space</Name>
      <Pattern>orders/></Pattern>
      <TopicMatchingPolicy>solace</TopicMatchingPolicy>
      <MessageType>json</MessageType>
      <Key>/orderId</Key>
      <FileName>./sow/%n.sow</FileName>
    </Topic>

    <Union>
      <Name>solace-orders-union</Name>
      <MessageType>json</MessageType>
      <UnderlyingTopic>orders/></UnderlyingTopic>
      <TopicMatchingPolicy>solace</TopicMatchingPolicy>
    </Union>

    <View>
      <Name>solace-orders-by-desk</Name>
      <MessageType>json</MessageType>
      <UnderlyingTopic>solace-orders-union</UnderlyingTopic>
      <Projection>
        <Field>/desk</Field>
        <Field>COUNT(/orderId) AS /orderCount</Field>
      </Projection>
      <Grouping>
        <Field>/desk</Field>
      </Grouping>
    </View>

    <ConflatedTopic>
      <Name>solace-orders-by-desk-ui</Name>
      <MessageType>json</MessageType>
      <UnderlyingTopic>solace-orders-by-desk</UnderlyingTopic>
      <Interval>1s</Interval>
    </ConflatedTopic>
  </SOW>
</AMPSConfig>

To capture the full Solace topic space, use > as the Pattern. Many teams instead start with a bounded domain such as orders/> or telemetry/> so the SOW reflects a coherent functional area.

Usage Tips

• Use TOPIC_MATCH when a message field stores the original Solace topic, for example /destination TOPIC_MATCH 'orders/>'.
• Migrating clients can keep Solace wildcard syntax on a per-request basis with topic_matching_policy=solace on commands such as subscribe, sow, and sow_and_subscribe.
• Remember that LIKE stays PCRE even when the resolved topic policy is solace.
• Solace-style wildcards should be preserved in topic names only when that compatibility is useful to subscribers. If the UI does not need Solace-native topic syntax, normalize names during ingest.
• Use a Union before a View whenever the source is a Pattern topic, and repeat the pattern expression in the Union UnderlyingTopic.
• Conflate dashboard topics when update rates are faster than the browser or operator needs to process.
• Decide explicitly whether to ingest administrative or system topics into the same namespace as business topics. Keeping those domains separate usually makes entitlements and UI logic simpler.