Contents

Flow of PMQ messages in Interaction Dialer

Agents collect information during the course of a campaign. Each ODS uses PMQ to deliver these database updates to the Central Campaign server for processing. PMQ guarantees delivery of data across machine, network, and process boundaries.

To understand how PMQ works in the Dialer environment, let's step through the messaging process. The diagram below illustrates the flow of PMQ messages between Outbound Dialer servers and the Central Campaign server.

Each Outbound Dialer server creates a PMQ object in memory. The object knows how to communicate with the Central Campaign server to deliver PMQ messages. Each message is a chunk of binary data that represents an item of work. PMQ doesn't care what a message contains—its only role is to store and forward messages efficiently.

The PMQ object creates an I3 persistent file to store messages in FIFO order. FIFO ensures that transactions arrive in order.
The object invokes a method that attempts to send data to the UpdateServer process on the Central Campaign server. If the server cannot be contacted using Notifier protocol, if the UpdateServer subsystem is not running, or if the transaction cannot be completed quickly enough, the method returns an error code. When errors occur, the message stays in the FIFO queue until PMQ can successfully send it. Under typical conditions, PMQ messages cross network and machine boundaries in near real-time.
Next, PMQ sends messages between processes on the Central Campaign server. Messages received by the UpdateServer process are in turn passed to the DialerTranServer process, which starts database operations. Messages that cannot be delivered to the DialerTranServer are retained in the UpdateServer's input queue.
When messages arrive at the DialerTranServer, they are prepared for submission to the database management system (DBMS). DialerTranServer uses a UDL connection to send an update notification to the DBMS. The notification contains the message data. Most messages are written to database tables without incident. When this happens, a successful return code is passed back to PMQ, and it removes the processed message from the input queue.
If the DBMS rejects the data for some reason, it doesn't stay in the input queue. Instead, rejected messages are written to an error queue. A database may reject messages for a variety of reasons. For example, a message may refer to a field that has been removed or renamed from a table, or the format of the data may be inappropriate for the data type defined in the table.