webMethods Universal Messaging & Event-Driven Architecture

Channels vs Queues in Universal Messaging

graph LR
    subgraph Publisher["Event Publisher"]
        IS1["Integration Server A<br/>(Publishes OrderCreatedEvent)"]
    end

    subgraph UM_Realm["Universal Messaging Realm (nsp://host:9000)"]
        Channel["Channel: /finance/orders<br/>(Publish / Subscribe)"]
        Queue["Queue: /billing/tasks<br/>(Point-to-Point)"]
    end

    subgraph Subscribers["Subscribers / Consumers"]
        IS_Sub1["Trigger 1 (Inventory Service)"]
        IS_Sub2["Trigger 2 (Billing Service)"]
        Worker1["Worker Node 1"]
        Worker2["Worker Node 2"]
    end

    IS1 -->|Publishes Event| Channel
    Channel -->|Broadcasts Copy| IS_Sub1
    Channel -->|Broadcasts Copy| IS_Sub2

    IS1 -->|Pushes Work Item| Queue
    Queue -->|Consumed by exactly ONE worker| Worker1
    Queue -.->|If Worker 1 busy| Worker2

IS Messaging Trigger Execution Modes

• Concurrent Execution Mode:
  • Uses a pool of worker threads to process multiple published messages simultaneously.
  • Maximum throughput; order of execution is not guaranteed. Ideal for independent notifications.
• Serial Execution Mode:
  • Processes messages strictly one-at-a-time in exact FIFO order per trigger or per partition key.
  • Essential for financial ledger updates or state machine events (e.g.,
    CODE / PROMPTCopy

    OrderCreated

    must execute before
    CODE / PROMPTCopy

    OrderPaid

    ).

Exactly-Once Processing Architecture

When network hiccups cause publishers to retry:

1. Publisher embeds a unique Document UUID (
   CODE / PROMPTCopy

   _env/uuid

   ).
2. The receiving Trigger checks the Document History Database / Terracotta Cache.
3. If the UUID was processed within the configured Time-To-Live (TTL) window:
   • The trigger marks the document as duplicate and automatically discards it without executing the target Flow service twice.