Integrating TIBCO EMS Topics and Queues with AMPS

This page covers two common EMS integration shapes: preserving EMS topic naming in AMPS and modeling EMS-style worker delivery with AMPS queues. In both cases, preserving familiar EMS destination names makes it easier to introduce AMPS for high-performance state, delivery control, and observability while keeping a straightforward path for applications that later publish directly into AMPS.

Where TIBCO EMS and AMPS Overlap

TIBCO EMS topic destinations use the same wildcard family that AMPS supports through TopicMatchingPolicy set to tibco. AMPS can apply that policy as the instance default or as a local override on the imported EMS namespace. 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.

AMPS also provides queue delivery models that map naturally to worker-oriented EMS flows. AMPS queues support:

• at-least-once and at-most-once delivery semantics
• Lease-based redelivery control with LeasePeriod
• Per-queue and per-subscriber backlog limits with MaxBacklog and MaxPerSubscriptionBacklog
• Distributed, local, and bounded-cluster queue topologies through Queue, LocalQueue, and GroupLocalQueue
• Queryable queue state, views over queues, and conflated queue summaries for operator dashboards

That makes AMPS a strong fit when teams want to preserve EMS topic hierarchies such as ORDERS.NA.HIGH or RISK.ALERTS.OPS while adding:

• SOW queries for current state
• Queues for worker delivery with explicit semantics
• Atomic state hydration plus live streaming through sow_and_subscribe
• Derived dashboard datasets using Views and Unions
• Lower-frequency presentation topics with ConflatedTopics
• Efficient browser delivery with sow_and_delta_subscribe

EMS Queue Concerns Mapped to AMPS Queues

For EMS-style worker processing, the closest AMPS building blocks are the queue types documented in the AMPS user guide.

EMS-Oriented Concern	AMPS Queue Capability
One worker should process a message at a time	AMPS queues deliver each message to a single subscriber at a time.
The message should be retried if a worker fails	Use Semantics of at-least-once plus a LeasePeriod so unacknowledged work returns to the queue.
The message should never be redelivered after dispatch	Use Semantics of at-most-once.
Limit how much work is outstanding	Use MaxBacklog and MaxPerSubscriptionBacklog.
Control how long work may remain pending	Use Expiration and ExpirationModel.
Keep work local to one server or one subset of a mesh	Use LocalQueue or GroupLocalQueue.
Build backlog dashboards for operators	Query the queue directly, create a View over the queue, and expose a ConflatedTopic for the UI.

EMS Topic Patterns Compared to Default AMPS PCRE

Default AMPS topic matching uses pcre. The tibco policy uses the token-based wildcard rules familiar from EMS topics.

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

As with TIBCO Rendezvous, * and > are token-aware wildcards rather than regular-expression operators. Use LIKE when you explicitly want PCRE behavior.

Recommended AMPS Design

For EMS integrations, separate the worker-delivery layer from the observability layer:

1. Preserve the original EMS topic name when publishing into AMPS if downstream users already understand that naming.
2. Keep the instance default at pcre unless most of the instance uses EMS semantics. For imported EMS namespaces, add TopicMatchingPolicy set to tibco beside each Pattern, UnderlyingTopic, or transaction-log topic filter that should use TIBCO rules.
3. Capture the topic family into a Pattern SOW topic such as ORDERS.> or RISK.> so AMPS retains current state for the whole namespace.
4. Define an AMPS Queue, LocalQueue, or GroupLocalQueue over the relevant EMS-style work stream, and choose Semantics of at-least-once or at-most-once based on the worker requirement.
5. Set queue controls such as LeasePeriod, MaxBacklog, MaxPerSubscriptionBacklog, Expiration, and FairnessModel to match the worker profile.
6. Add a Union whose UnderlyingTopic repeats that same pattern expression so AMPS can expose one consolidated source to downstream analytics.
7. Add Views and ConflatedTopics for operator summaries and UI workflows, including queue-backlog dashboards.

This pattern lets AMPS serve as the place where teams handle worker delivery, query current state, and build drill-down datasets without forcing every UI or consumer to implement its own cache and backlog logic.

Sample Configuration

The following configuration keeps the instance default at pcre, preserves an EMS order namespace in AMPS with local TIBCO overrides, creates an at-least-once worker queue for that namespace, and exposes a dashboard-oriented queue summary:

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

  <TransactionLog>
    <JournalDirectory>./journals</JournalDirectory>
    <Topic>
      <Name>ems-order-work</Name>
      <MessageType>json</MessageType>
    </Topic>
    <Topic>
      <Name>ORDERS.></Name>
      <TopicMatchingPolicy>tibco</TopicMatchingPolicy>
      <MessageType>json</MessageType>
    </Topic>
  </TransactionLog>

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

    <Queue>
      <Name>ems-order-work</Name>
      <UnderlyingTopic>ORDERS.></UnderlyingTopic>
      <TopicMatchingPolicy>tibco</TopicMatchingPolicy>
      <DefaultPublishTarget>ORDERS.NA.NEW</DefaultPublishTarget>
      <MessageType>json</MessageType>
      <Semantics>at-least-once</Semantics>
      <LeasePeriod>30s</LeasePeriod>
      <MaxPerSubscriptionBacklog>10</MaxPerSubscriptionBacklog>
      <FairnessModel>proportional</FairnessModel>
    </Queue>

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

    <View>
      <Name>ems-queue-backlog-by-status</Name>
      <MessageType>json</MessageType>
      <UnderlyingTopic>ems-order-work</UnderlyingTopic>
      <Projection>
        <Field>/status</Field>
        <Field>COUNT(/orderId) AS /queuedCount</Field>
      </Projection>
      <Grouping>
        <Field>/status</Field>
      </Grouping>
    </View>

    <ConflatedTopic>
      <Name>ems-queue-backlog-by-status-ui</Name>
      <MessageType>json</MessageType>
      <UnderlyingTopic>ems-queue-backlog-by-status</UnderlyingTopic>
      <Interval>1s</Interval>
    </ConflatedTopic>
  </SOW>
</AMPSConfig>

If you truly want to capture an entire EMS topic space, use > as the Pattern. In practice, most teams preserve one functional namespace at a time, such as ORDERS.> or RISK.>. For queue-oriented migrations, start by mapping one workload at a time to an AMPS queue with explicit semantics and backlog controls.

Usage Tips

• Use TOPIC_MATCH when a field stores the original EMS destination, for example /destination TOPIC_MATCH 'ORDERS.*.PRIORITY.>'.
• Migrating clients can keep EMS 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 syntax.
• If the same EMS topic carries repeated updates for the same entity, key the SOW on the entity identifier rather than on the topic name.
• Use at-least-once when the worker must acknowledge successful processing, and at-most-once when avoiding redelivery is more important than retry.
• Use Queue for fully distributed delivery, LocalQueue for single-instance worker flows, and GroupLocalQueue when only a defined subset of a replicated mesh should host the workload.
• Use a Union before a View whenever the source namespace is captured with a Pattern topic, and repeat the pattern expression in the Union UnderlyingTopic.
• Build queue-focused views and conflated topics for operators, and use the Pattern SOW topic plus a Union over the same pattern expression for whole-namespace state and drill-down analytics.