Integrating TIBCO Rendezvous Subjects with AMPS

This page assumes a bridge, adapter, or application republishes TIBCO Rendezvous subjects into AMPS while preserving the original subject name in the AMPS topic name or in a message field. In that architecture, AMPS provides durable current state, query, and derived data for observability and interactive tooling while preserving the subject naming model already used by existing producers and consumers. The same approach also makes direct AMPS adoption simpler when teams later choose to publish those workflows natively.

Where TIBCO Rendezvous and AMPS Overlap

TIBCO Rendezvous uses tokenized subject names separated by .. AMPS can preserve that model with TopicMatchingPolicy set to tibco either as the instance default or as a local override on the imported subject space. Subscriptions and SOW queries can also use topic_matching_policy=tibco, and any TOPIC_MATCH predicate in the same command filter uses TIBCO wildcard rules.

That overlap is useful when a team wants to keep existing RV subject conventions such as MARKETDATA.US.IBM or ORDERS.NY.SEQ while gaining:

• SOW queries over the latest value of each subject or entity
• Atomic initial load plus live updates through sow_and_subscribe
• Derived datasets built with Unions and Views
• UI refresh control through ConflatedTopics
• Reduced client payloads with sow_and_delta_subscribe

TIBCO Subject Patterns Compared to Default AMPS PCRE

Default AMPS topic matching uses pcre. The tibco policy uses TIBCO wildcard semantics instead.

TIBCO Pattern	Meaning	Representative PCRE Equivalent
ORDERS.*	Match exactly one token after ORDERS	^ORDERS\.[^.]+$
ORDERS.>	Match one or more descendant subject tokens below ORDERS	^ORDERS\..+$
>	Match every non-empty subject	^.+$

Under tibco, * and > are token-based wildcards. foo.* does not behave like the PCRE pattern foo.*; it matches foo.bar but not foo.bar.baz.

Recommended AMPS Design

For RV integrations, a practical AMPS design is:

1. Preserve the original RV subject when the integration layer publishes into AMPS.
2. Keep the instance default at pcre unless most of the instance uses TIBCO wildcard semantics. For imported RV namespaces, add TopicMatchingPolicy set to tibco beside each Pattern or UnderlyingTopic that should use TIBCO rules.
3. Capture the subject family into a Pattern SOW topic such as MARKETDATA.> or ORDERS.>.
4. Add a Union whose UnderlyingTopic repeats the same pattern expression so AMPS can expose a single consolidated SOW topic to downstream analytics.
5. Build Views for per-desk, per-region, or per-service summaries and ConflatedTopics for UIs.

This arrangement is often simpler than building a separate subject-tree cache in each client application.

Sample Configuration

The following example keeps the instance default at pcre, preserves an RV order subject hierarchy in AMPS with local TIBCO overrides, and produces a dashboard-ready topic:

<AMPSConfig>
  <Name>tibco-rv-observability</Name>
  <TopicMatchingPolicy>pcre</TopicMatchingPolicy>

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

    <Union>
      <Name>rv-orders-union</Name>
      <MessageType>json</MessageType>
      <UnderlyingTopic>ORDERS.></UnderlyingTopic>
      <TopicMatchingPolicy>tibco</TopicMatchingPolicy>
    </Union>

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

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

To capture an entire RV subject space, use > as the Pattern. Most deployments use a bounded namespace such as ORDERS.> or MARKETDATA.> so SOW storage and entitlement rules follow the operational domain.

Usage Tips

• Use TOPIC_MATCH when a field stores the original RV subject, for example /subject TOPIC_MATCH 'ORDERS.*.PRIORITY.>'.
• Migrating clients can keep RV wildcard syntax on a per-request basis with topic_matching_policy=tibco on commands such as subscribe, sow, and sow_and_subscribe.
• Use LIKE only when you intentionally want full PCRE rather than the resolved TIBCO wildcard rules.
• Choose the SOW key from the business entity, not from the subject alone, when multiple updates for the same entity arrive on the same subject.
• Use a Union before a View when the source is a Pattern topic, and repeat the pattern expression in the Union UnderlyingTopic.
• ConflatedTopics are especially helpful for RV-backed dashboards because market or telemetry subjects often update more quickly than humans need to see.