Event Publishing

Event Publishing delivers changes from source tables directly to applications. The changes are translated into messages and sent over IBM® MQ queues or stored in consistent-change data (CCD) tables.

An event is a change to a source table. The following examples show potential uses for Event Publishing:

To update a Web site: Changes to a database or subsystem that records stock prices are captured from the DB2® or Oracle recovery log, and published as XML messages to a JSP (Java™ Server Pages) application that runs on an application server (such as WebSphere® Application Server). The XML messages are then used to update HTML pages that display the up-to-date stock information.
To feed a central integration broker: When a customer updates an address, the transaction is published as an XML message to a central WebSphere Business Integration Message Broker. The broker translates the XML message into formats that can be understood by different applications throughout the business, its partners, and suppliers.
To feed InfoSphere® DataStage®: You can publish changes from a source database to InfoSphere DataStage, a powerful data integration and transformation tool. You can publish to InfoSphere DataStage by using a delimited message.

You can also use a CCD table to store events. A noncomplete CCD table contains only changes to the source table and includes the same information as an XML or delimited message. You can use the replication administration tools to help configure CCD tables to feed data warehouses such as InfoSphere Warehouse.

Event publishing uses only the Q Capture program, not the Q Apply program. The Q Capture program captures changes that you specify when you create an object called a publication. These transactions or row-level changes are then sent to a queue. You specify which queue to use when you create an object called a publishing queue map.

Event publishing gives you the flexibility to use transactional data that is published in the best format for a wide variety of uses. If you want to replicate changes to a target by using the Q Apply program, use Q replication rather than Event Publishing.

Tip: The asnqwxml sample program provides an example of a Web-based application that consumes the XML messages that the Q Capture program publishes. The sample demonstrates how to use publications in a business scenario. You can find the sample program in the \sqllib\samples\repl directory.

Objects for Event Publishing

In Event Publishing that uses XML or delimited messages, the following objects exist between servers:

Publishing queue maps

You must create at least one publishing queue map to transport data from the Q Capture program on each source server.

Publications

For each source table that you want to publish changes from, you must create at least one publication. The publication specifies the table, as well as the rows and columns that you want to publish. You can have multiple publications that specify the same source table. For example, if you wanted to publish changes from the EMPLOYEE table to Application A and Application B, and changes from the DEPARTMENT table to Application A, you create three publications, with two publishing queue maps:

Publication EMPLOYEE0001 from the EMPLOYEE table to Application A by using publishing queue map A.
Publication DEPARTMENT0001 from the DEPARTMENT table to Application A by using publishing queue map A.
Publication EMPLOYEE0002 from the EMPLOYEE table to Application B by using publishing queue map B.

Application A reads the messages that the Q Capture program sends to the send queue in publishing queue map A, and Application B reads the messages that the Q Capture program sends to the send queue in publishing queue map B.

Figure 1 shows Event Publishing for three source tables on the same server. You need three publications and at least one publishing queue map.

Figure 1. Event Publishing. In this example, changes from source tables are published to one or more MQ send queues in XML format so that a user application can retrieve and use those messages.

Controlling message content

You can choose whether the messages that are sent by the Q Capture program contain only a single row change from the source table, or an entire transaction. You make this choice when you create a publishing queue map. The Q Capture program will use the message format that you choose for all publications that specify this publishing queue map.

For example, you might specify that the messages published from the EMPLOYEE table to Application A contain individual row changes, and the messages from the DEPARTMENT table to Application A contain entire transactions. In that case, you use the following configuration:

Publication EMPLOYEE0001 from the EMPLOYEE table to Application A by using publishing queue map A (where publishing queue map A specifies individual row changes for messages).
Publication DEPARTMENT0001 from the DEPARTMENT table to Application A by using publishing queue map C (where publishing queue map C specifies entire transactions for messages).