Daily IB Volume/Usage Report

Tailored Operational Context
  • Target Database:
  • Context Type:
  • Alert Severity:
  • Triggered Time:
  • Firing Context:

Daily IB Volume/Usage Report

Report ID: ib-daily-volume Category: Integration Broker

Purpose

This report shows Integration Broker message volume for a configurable date range. It breaks down traffic into four categories:

  1. Async Operations — publication headers (PSAPMSGPUBHDR), the top-level async message record
  2. Publication Contracts — per-subscriber delivery records (PSAPMSGPUBCON)
  3. Subscription Contracts — subscription handler execution records (PSAPMSGSUBCON)
  4. Synchronous Operations — logged sync transactions (PSIBLOGHDR). Only operations with logging enabled appear here

Each category shows counts grouped by operation name and status (Done, Error, New, etc.), sorted by total volume descending.

Parameters

ParameterDefaultDescription
from_dateToday (YYYY-MM-DD)Start of the date range (inclusive)
to_dateToday (YYYY-MM-DD)End of the date range (inclusive)

Leave both parameters blank to report on today’s traffic. Set a range such as from_date=2026-01-01 and to_date=2026-01-31 for a monthly view.

Tables Queried

PSAPMSGPUBHDR — Async Operation Headers

The master record for each async IB message (one row per publication).

FieldDescriptionFilter
IB_OPERATIONNAMEService operation nameGrouped by
STATUSSTRINGMessage status (DONE, ERROR, NEW, etc.)Grouped by
CREATEDTTMWhen the record was createdDate range filter

PSAPMSGPUBCON — Publication Contracts

One row per subscriber for each async publication.

FieldDescriptionFilter
IB_OPERATIONNAMEService operation nameGrouped by
STATUSSTRINGContract statusGrouped by
CREATEDTTMWhen the record was createdDate range filter

PSAPMSGSUBCON — Subscription Contracts

One row per subscription handler execution.

FieldDescriptionFilter
IB_OPERATIONNAMEService operation nameGrouped by
STATUSSTRINGContract statusGrouped by
CREATEDTTMWhen the record was createdDate range filter

PSIBLOGHDR — Sync Operation Log Headers

Logged synchronous transaction records. Only populated when message detail logging is enabled on the routing.

FieldDescriptionFilter
IB_OPERATIONNAMEService operation nameGrouped by
STATUSSTRINGTransaction statusGrouped by
PUBLISHTIMESTAMPWhen the transaction was processedDate range filter

Data Flow

1. Fetch async operation summary (PSAPMSGPUBHDR)
   GROUP BY IB_OPERATIONNAME, STATUSSTRING
        |
        v
2. Fetch publication contract summary (PSAPMSGPUBCON)
   GROUP BY IB_OPERATIONNAME, STATUSSTRING
        |
        v
3. Fetch subscription contract summary (PSAPMSGSUBCON)
   GROUP BY IB_OPERATIONNAME, STATUSSTRING
        |
        v
4. Fetch sync operation summary (PSIBLOGHDR)
   GROUP BY IB_OPERATIONNAME, STATUSSTRING
        |
        v
5. Pivot each dataset into a per-operation table
   with status columns, sorted by total descending

Report Output

The generated report contains:

  • Summary table with total message counts for each of the four categories
  • Async Operations table — one row per operation, columns for each status (Done, Error, New, etc.) plus Total
  • Publication Contracts table — same format
  • Subscription Contracts table — same format
  • Synchronous Operations table — same format, with a note that only logging-enabled operations appear

Interpreting Results

Async Operations

  • Done — successfully processed and delivered
  • Error — failed; check the IB Monitor for details
  • New — queued but not yet processed (may indicate a stuck dispatcher)

A high Error count relative to Done signals a systemic integration problem. A high New count with no decrease over time indicates the IB dispatcher may be stopped.

Publication vs Subscription Contracts

  • Each async publication spawns one publication contract (PSAPMSGPUBCON) per subscribing node
  • Subscription contracts (PSAPMSGSUBCON) represent individual handler executions
  • If pub contract count is much higher than sub contract count, some subscribers may not be processing

Synchronous Operations

  • Only operations with logging enabled on their routing appear here
  • A missing operation does not mean it had no traffic. It may have logging disabled
  • Cross-reference with the Sync Operations Without Logging report to identify gaps

Recommendations

  1. Monitor daily Error rates — set a threshold and investigate any day where errors exceed it
  2. Watch for New status growth — a queue of unprocessed messages indicates a dispatcher or handler problem
  3. Enable sync logging for critical operations to get visibility in this report (see Sync Operations Without Logging)
  4. Compare day-over-day volumes — sudden drops may indicate a sending system stopped, not just low traffic