Introduction

This article describes a best practice for monitoring non-BPEL Enterprise Information Systems (EIS) processes that use an Oracle database. This best practice leverages the Oracle Emitter tool, provided for download with this article, to transform and even augment your event data if needed, before forwarding it on for consumption. The Oracle Emitter is easily installed into your existing WebSphere Business Monitor (hereafter called Monitor) platform or into WebSphere Application Server (Application Server) with minimal customization.

Common Base Events (CBE) is the data format used to package and send events to be consumed by Monitor. As long as the business data that flows into your business system can be captured and transformed into CBE events, Monitor provides a near real-time capability to monitor your business activities and thus capture any performance implications. The scenario we'll use in this article demonstrates an end-to-end solution using the Oracle Emitter to emit and transform business events to Monitor for monitoring. The resulting metrics reflecting the measures of the business activities are then rendered to the Business Space dashboard of Monitor for reporting.

In the following sections, we'll describe:

• The scenario
• How to use the Oracle Emitter
• How the Oracle Emitter works

Back to top

The scenario

Figure 1 illustrates the scenario we'll use in this article.

The principle of business monitoring is that your implemented business processes are designed to generate events at defined data points. Those events can then be defined and augmented to carry data and metrics reflective of the business activities that took place, such as variable state and value changes. Those change activities and their relevant data are recorded into an event table. The event records are then used to trigger the emission of events for monitoring. The major stages of this process are summarized below:

• The business process interacts with the underlying Oracle database and stores or modifies the data in the application tables.
• The Oracle Emitter captures those operations (such as insert, update and delete) from the database, retrieves the pertinent data, converts the data to CBEs, and emits it as events.
• The Monitor model receives the CBEs from the Common Event Infrastructure (CEI) and calculates the business measures.
• The business measures and KPIs are shown in Business Space

Back to top

How to use the Oracle Emitter

This section explains how to use the Oracle Emitter in an existing Monitor installation. We'll use the Clips and Tacks Order Handling Future 1 Process as an example.

The Clips and Tacks Order Handling Future 1 Process is a public sample delivered with the IBM BPM product suite. The sample features detailed process models for generic customer order handling processes that include order processing and verification, and shipment handling. The process has three activities: Place Order, Review Order, and Ship Order. The order information is stored in four tables: Customer, Product, Order and OrderItem.

To get started, download the Clips And Tacks sample and the Oracle Emitter package. Follow the instructions in the Clips And Tacks sample to set up the Clips And Tacks process.

Complete the steps in the following sections to set up the Oracle Emitter.

• Configure the environment for Oracle Emitter.
• Develop the monitor model.

Configure the environment for Oracle Emitter

Before you install the Oracle Emitter application, you need to configure the data source, scheduler and system tables. To do this, complete the following steps:

1. Create an authentication alias for the Emitter Scheduler and Oracle Emitter:
   1. Launch the Monitor server administrative console.
   2. Select Security => Secure administration, applications, and infrastructure => Java Authentication and Authorization Service => J2C authentication data.
   3. Click New to create a new authentication alias with the following properties:
      • Alias: DBEmitterAlias
      • User ID: WBMEMIT
      • Password: (Specify the password for user WBMEMIT to connect to the database.)
      • Description: Authentication Alias for Scheduler and DB Emitter to Connect to database
2. Create a JDBC Provider for the Emitter Scheduler and Oracle Emitter:
   1. Launch the administrative console.
   2. Select Resources => JDBC Providers, and set the scope to Server.
   3. Create a JDBC provider named Oracle JDBC Driver (XA) For DBEmitter.
   4. Specify the directory where you put the Oracle JDBC driver (ojdbc14.jar) for Oracle_JDBC_DRIVER_PATH. For example in Windows: <oracle\product\version>\db1\jdbc\lib\ojdbc14.jar
3. Create a data source for the Emitter Scheduler:
   1. Select the newly created provider, then select Data sources in the Additional Properties section.
   2. Click New a new data source with the following properties:
      • Name: SKDLR Datasource
      • JNDI name: jdbc/skdlr
      • Component-managed authentication alias: <Node Name>/DBEmitterAlias
      • Description: JDBC data source for SKDLR database
      • URL: URL to the Monitor database. For example, jdbc:oracle:thin:@localhost:1521:orcl
      • Data store helper class name: Oracle 10g data store helper
      • Check Use this Data Source in container managed persistence (CMP)
4. Create a scheduler for the Oracle Emitter:
   1. Launch the administrative console.
   2. Select Resources => Schedulers and set the scope to Server.
   3. Click New to create a new scheduler with the following properties:
      • Name: Poller for DB Emitter
      • JNDI name: sched/Poller. (This is the default specified as an environment entry in the EJB deployment descriptor)
      • Description: Scheduler for DB Emitter's Event Table Poller
      • Data source JNDI name: jdbc/skdlr
      • Data source alias: <Node Name>/DBEmitterAlias
      • Table prefix: DBEMTR_
      • Poll interval: 30
      • Work managers: wm/default
   4. Click OK, then Save.
   5. On the Schedulers page, select the newly created Poller scheduler and click Create tables.
5. Create the event and log tables to be used for Oracle Emitter:
   1. Open sqlplus with the user id system.
   2. Run the createEventAndLogTable.ddl script shipped with this article. This creates the event table, log table, and necessary procedures used for Oracle Emitter.
6. Create a data source for Oracle Emitter:
   1. On the JDBC providers page, click the newly created Oracle JDBC Driver (XA) For DBEmitter, then click Data sources in the Additional Properties section.
   2. Click New to create a new data source with the following properties:
      • Name: DB Emitter Datasource
      • JNDI name: jdbc/DBEmitter (This is the default specified as an environment entry in the EJB deployment descriptor)
      • Component-managed authentication alias: <Node Name>/DBEmitterAlias
      • Description: DBC Datasource for DBEmitter
      • URL: The URL to connect to the monitor database. For example, jdbc:oracle:thin:@localhost:1521:orcl
      • Data store helper class name: Oracle 10g data store helper
      • Check Use this Data Source in container managed persistence (CMP).
7. Create the necessary directories. The table below lists the default directories on a Windows™ system.
   
   

   Name	Directory	Notes
   EventConfDir	C:/DBEmitter/EventConfiguration	Directory to store event configuration files
   EventSchemaDir	C:/DBEmitter/EventSchema	Directory to store generated event schema

   
   
   
8. Deploy the Oracle Emitter enterprise application (DBEmitterEAR.ear) using the administrative console. Accept all default values and save the configuration after the deployment is completed.
9. Copy the event configuration files shipped with this article to <EventConfDir>. There are three event configuration files for the order handling process: OrderCreate.xml, OrderItemAdd.xml and OrderUpdate.xml.
10. Restart the Monitor server to run the scheduler.
11. Point your browser to http://<hostname>:<WC_defaulthost port>/DBEmitterWeb/CreateTriggerServlet. This creates the trigger in the database for all the events defined in the <EventConfDir> directory. Every time the event definition files are changed, new event definition files are added, or the structure of the application tables is changed, you'll need to restart the Oracle Emitter and point your browser to the link above to create or update the triggers.

Develop the monitor model

In this article, we won't address common monitor model development tasks, such as creating metrics, triggers, stopwatches, measures, dimensions and KPIs. Refer to the Clips and Tacks sample for the complete steps for monitor model creation. In this article, we'll only cover the steps needed to extend the monitoring capabilities using the Oracle Emitter.

1. To create the event schema for all events according the configurations, point your browser to http://<hostname>:<WC_defaulthost port>/DBEmitterWeb/CreateSchemaServlet. The event schemas are generated in the <EventSchemaDir> directory, and can be imported into the monitor model as event definitions when creating the monitor model. Every time the event definition files are changed, new event definition files are added, or the structure of the application tables is changed, you'll need to restart the Oracle Emitter and point your browser to the link above to create or update the schema.
2. Import the event schemas shown in Figure 2 into the monitor model as event definitions.
   
   Figure 2. The event schemas for the order handling process
   
   
   
3. Create a monitor model with the imported event schemas. Because CBEs sent by Oracle Emitter don’t contain any BPEL data, such as ECSParentID, ECSCurrentID and so on, you can only use business logic to correlate all the events. In the Order Handling process monitor model, there are two monitor contexts: OrderMM MC and OrderItemMC.
4. Next you need to create inbound events. Refer to the Clips And Tacks sample documentation for instructions on how to create inbound events. Figure 3 shows an example of an inbound event used in this model. Pay particular attention to the filter condition and correlation expression, which are related to the business logic. The filter condition ensures that only related events are accepted by specific models and the correlation expression ensures that events are applied to the right instance.
   
   Figure 3. OrderCreate inbound event
   
   
   
5. Specify the key for monitor context. Refer to the Clips And Tacks sample documentaton for detailed instructions on how to do this. As stated, we'll use business logic and its pertinent payload data to correlate the event with the monitoring context instance. In the sample model, Order Number is set as the key of the OrderMM MC. Product Number is set as the key of OrderItemMC. Events in the child monitor context (MC) should correlate with the key in the parent MC as well. As a result, Order Number and Product Number are used to correlate the three events in this model. The key relationship is consistent with the primary and foreign key relationship in the database. Order Number is the primary key of OrderMain table, while Order Number and Product Number are the primary keys of OrderItem table. Order Number is the foreign key in the OrderItem table, which references the Order table. Figure 4 shows the key of the OrderMM MC.
   
   Figure 4. Key definition of OrderMM MC
   
   
   
6. You also need to define triggers to terminate the monitor context when the order handling process finishes. When the order is declined or shipped, the order handling process instance is terminated, so you need to define two triggers to terminate OrderMM MC: OrderShipTr and OrderDeclinedTr. Figure 5 shows the OrderShipTr.
   
   Figure 5. OrderShipTr trigger
   
   
   
7. After you finish creating inbound events, key settings and triggers, you can continue augmenting the monitor model. For more information, look at the OrderMM model shipped with this article.
8. Now you're ready to use the model to consume events emitted from the order handling process via the Oracle database emitter. For simplicity, execute insertData.ddl in sqlplus to simulate the running of the Order Handling process, then check the business space to see the monitoring results, as shown in Figures 6, 7, and 8.
   
   Figure 6. Instance view
   
   
   
   
   Figure 7. Dimension view
   
   
   
   
   Figure 8. KPI view
   
   
   

Back to top

How the Oracle Emitter works

The Oracle Emitter tool enables the monitoring of your business activities via business events emitted from your non-BPEL processes running on Oracle databases. The Oracle Emitter is a J2EE application running on WebSphere Application Server. Figure 9 depicts the processing flow of Oracle Emitter.

The event table and log table are the system tables used by Oracle Emitter. Oracle Emitter itself is composed of two parts: an event configuration loader and an emitter. The event configuration loader (on the left in Figure 9) is responsible for reading in event configuration information from files, fetching metadata for the application tables from the database, and creating triggers to insert event records, as well as event definition (schema) files used by the monitor model. The event configuration loader is invoked and initialized only once during application start-up. The emitter (on the right in Figure 9) is implemented by extending some classes and specific interfaces from the Event Framework API. Its task list covers: polling data from the event table, fetching application data from application tables, converting business data to V6.1 xsd format for CBE event payload, sending the events to CEI, deleting event records and logging the results. We'll explain each of these components in detail in the following sections.

Event configuration file

The user defined event configuration files specify to the Oracle Emitter which source table is to be monitored, which tables are referenced by the source table, and which columns are of interest. The event configuration files enhance the flexibility of the Oracle Emitter, and mean that users do not have to implement the retriever and formatter class. The event configuration files are in XML format and follow the schema structure below.

				
<xsd:schema>
  
  <xsd:element name="emitter_event">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="source_table" minOccurs="1" maxOccurs="1"/>
        <xsd:element ref="related_table" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>	
      <!-- event name, which should be unique -->
      <xsd:attribute name="name" type="xsd:string" use="required"/>
	  <!-- operation: C – insert; U– update; D - Delete. -->
	  <xsd:attribute name="operation" use="required">
	    <xsd:simpleType>
	      <xsd:restriction base="xsd:string">
	        <xsd:enumeration value="C"/>
	        <xsd:enumeration value="U"/>
	        <xsd:enumeration value="D"/>
          </xsd:restriction>
        </xsd:simpleType>
      </xsd:attribute>
    </xsd:complexType>
  </xsd:element>
	
  <!--Define the table which business process has modified. -->
  <!--Triggers will be invoked if there are modifications to this table.-->
  <!-- The schema and table name should be provided -->
  <xsd:element name="source_table">
    <xsd:complexType>
      <xsd:sequence>
        <!-- If the occurs = 0, all the columns will be included in the CBE -->
        <xsd:element ref="selected_column" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attribute name="name" type="xsd:string" use="required"/>
      <xsd:attribute name="schema" type="xsd:string" use="required"/>
    </xsd:complexType>
  </xsd:element>

  <!--Define the table that will provide detail information for some columns in the 
   source table -->
  <xsd:element name="related_table">
    <xsd:complexType>
      <xsd:sequence>
        <!--If the occurs = 0, all the columns will be included in the CBE -->
        <xsd:element ref="selected_column" minOccurs="0" maxOccurs="unbounded"/>
        <xsd:element ref="correlation" minOccurs="1" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attribute name="name" type="xsd:string" use="required"/>
      <xsd:attribute name="schema" type="xsd:string" use="required"/>
    </xsd:complexType>
  </xsd:element>
	
  <!--Define the columns in the table need to be included in the CBE -->
  <xsd:element name="selected_column">
    <xsd:complexType>
      <xsd:sequence>
      </xsd:sequence>
      <xsd:attribute name="name" type="xsd:string" use="required"/>
    </xsd:complexType>
  </xsd:element>

  <!--Define the conditions that can uniquely determine which record is related to the 
  source table-->
  <xsd:element name="correlation">
    <xsd:complexType>
      <xsd:sequence>
      </xsd:sequence>
      <xsd:attribute name="column" type="xsd:string" use="required"/>
      <xsd:attribute name="ref_schema" type="xsd:string" use="required"/>
      <xsd:attribute name="ref_table" type="xsd:string" use="required"/>
      <xsd:attribute name="ref_column" type="xsd:string" use="required"/>
    </xsd:complexType>
  </xsd:element>
  
</xsd:schema>

Event configuration files should include the following information:

• Event Name (required): This name should be unique in the system. The Emitter uses the event name as the key to look for corresponding event configuration information for each event record.
• The operation to be performed on the table (required): It will be one of the three values: C stands for insert a record; U stands for update a record; D stands for delete a record.
• Source table (required): This is the table that the business process interacts with. Both the table name and schema should be provided.
• Related table (optional): If the source table can't provide enough information for monitoring, you can specify additional tables that are referenced by the source table. For example, the customer information table may be a related table for the order table.
• Selected Column of source table or related table (optional): You can include only the columns to be transformed into CBE by specifying the selected column. This will reduce the payload of CBE and improve performance. If no selected column is specified, all the columns in the table are included in the generated CBE. For a delete operation, only the primary key can be set as selected columns.
• Correlation (required for each related table): This defines the foreign key relationship between tables. The attributes ref_schema and ref_table refer to the schema name and table name of the referencing table. The ref_column is the foreign key of the referencing table. The attribute column refers to the primary key in the referenced table.

Listing 2 shows a sample event configuration file.

	
<?xml version="1.0" encoding="UTF-8"?>

<!-- event name, which should be unique -->
<!-- operation: C – insert U– update D -- Delete  -->
<emitter_event name="OrderItemAdd" operation="C"> 
   
     <!-- source table: the table which business process has modified. The schema and 
     table name should be provided -->
     <source_table name="OrderItem" schema="CT“>
        <!-- selected column: the columns in the table need to be included in the CBE-->
        <selected_column name="OrderNumber"/>
        <selected_column name="Quantity"/>
     </source_table>
           
     <!-- related table: table that will provide detail information for some items 
     in the source table-->
     <related_table name="Product" schema="CT">
         <!--If no selected column is specified, all the columns will be included in 
         the CBE-->
        
         <!-- correlation: conditions that can uniquely determine which record is 
         related to the source table-->
         <!-- correlation: minOccur = 1, maxOccur = unbounded-->
         <correlation column="Productnumber" ref_schema="CT" ref_table="OrderItem" 
         ref_column="ProductNumber"/>
     </related_table> 

</emitter_event>

Event and log tables

In order to log and capture all operations being performed on the application tables, an event table is needed to record an operation each time it happens. The Oracle Emitter queries the event table and retrieves the specifics about that operation. The record in the event table contains the summary information regarding the event that occurs in the application table. It also stores the primary key to the application table record, which can be used to retrieve full information for the event. Table 1 lists the schema for the event table used by the Oracle Emitter.

Note: Because ";" is used to delimit the compound primary key, ";" must not be included in any primary key value. Otherwise the Oracle Emitter can not work properly.

Figure 10 depicts the source of the information stored in the event table records.

Whenever the emitter tries to handle an event record, the emitter deletes the event record and logs the result in the log table, regardless of whether the operation was successful or not. The structure of the log table, shown in Table 2, is the same as event table except that the Result and LOGTIMESTAMP columns are added.

Trigger

The application table must be configured with appropriate triggers that will create a record in the event table when an operation of interest has occurred on the source table. Listing 3 shows the template for a trigger.

    
CREATE OR REPLACE TRIGGER <Schema Name>.<Event Name>
 AFTER INSERT/UPDATE/DELETE
 ON <Schema Name>.<Table Name>
 REFERENCING NEW AS NEWROW/ REFERENCING OLD AS OLDROW
 FOR EACH ROW
 BEGIN
    INSERT INTO EVENTTABLE(KEYVALUE, EVENTNAME, CREATETIMESTAMP) 
    VALUES(:TRIM(NEWROW/OLDROW.<Primary Key Name>), <Event Name>, SYSDATE);
 END;

Note: For an insert operation, you should use REFERENCING NEW AS NEWROW, while using REFERENCING OLD AS OLDROW for update or delete operations.

Listing 4 shows a trigger sample. This trigger inserts an event record if there is a record inserted into orderitem table. Notice that orderitem table uses a compound primary key and the key value is split by ";".

   
-- CREATE TRIGGERS FOR ORDERITEM TABLE
CREATE OR REPLACE TRIGGER OrderItemAdd
 AFTER INSERT
 ON CT.OrderItem
 REFERENCING NEW AS NEWROW
 FOR EACH ROW
 BEGIN
   INSERT INTO EVENTTABLE(KEYVALUE, EVENTNAME, CREATETIMESTAMP) 
   VALUES(TRIM(:NEWROW.ORDERNUMBER)||';'||TRIM(:NEWROW.PRODUCTNUMBER), 'OrderItemAdd', 
   SYSDATE);
 END;

Data type to XSD type mapping

The Oracle Emitter also creates event schema, which are imported into the Monitor Model editor as event definitions for model creation. Data types in the database are different from types in XSD schema. To generate the event schema, we need to solve the data type mapping problem. Table 3 summarizes the mapping between common data types and XSD types used in Oracle Emitter.

Mapping database data to CBEs

Before generating the CBE schema, we also need to determine the conversion rule from database data to CBE elements. The header of CBEs emitted by Oracle Emitter is set with common values, and the data in the source table and related tables (if there are any) is converted as the sub-elements of the wbi:any element. The detailed mapping is shown in Table 4.

CBE event schema sample

After resolving the data type and data mapping, the emitter can create the event schema using the metadata of the tables. The event schema for the OrderItemAdd event is shown in Listing 5.

   
<xsd:complexType name="OrderItemAdd">
         <xsd:sequence>
                   <xsd:element name="SID" type="xsd:int"/>	
                   <xsd:element name="Trigger" type="xsd:string"/>
                   <xsd:element name="OrderItem" type="tns:OrderItem"/>
                   <xsd:element name="Product" type="tns:Product"/>
          </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="OrderItem">
         <xsd:sequence>
                  <xsd:element name="OrderNumber" type="xsd:integer"/>
                  <xsd:element name="Quantity" type="xsd:integer"/>
          </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="Product">
          <xsd:sequence>
                   <xsd:element name="ProductNumber" type="xsd:string"/>
                   <xsd:element name="ProductName" type="xsd:string"/>
                   <xsd:element name="Price" type="xsd:decimal"/>
                   <xsd:element name="Description" type="xsd:string"/>
          </xsd:sequence>
</xsd:complexType>

</xsd:schema>

CBE sample

The Oracle Emitter also extends the event framework by implementing the retriever and formatter interface. For more details on the event framework, refer to the DB2 Event Emitter Sample for WebSphere Business Monitor V6.0.2.

At runtime, the emitter is invoked by a scheduler in WebSphere Application Server at regular intervals. At each invocation, it polls the event table to see if there is any new record to be transformed. If there is, it retrieves the corresponding application data and formats it into CBE. The CBE is then be emitted to CEI to be forwarded on to Monitor. The Oracle Emitter deletes the record in the event table and logs the result in the log table.

Listing 6 shows a CBE sample (OrderItemAdd) generated by the Oracle Emitter.

   
<CommonBaseEvent creationTime="2008-04-02T08:08:32.562Z" extensionName="OrderItemAdd" 
globalInstanceId="CE82A47FFCF8908C05A1DD008BFC608120" sequenceNumber="1" version="1.0.1">
<sourceComponentId application="IBM_WBM_DB_EMITTER_SAMPLE" component="EventFormatter" 
componentIdType="n/a" executionEnvironment="null null null" location="9.186.116.195" 
locationType="IPV4" subComponent="n/a" threadId="189" 
componentType="com.ibm.wbimonitor.dbemitter.formatter.xsd.DBEmitterEventFormatterImpl"/>
<situation categoryName="AvailableSituation">
      <situationType xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xsi:type="AvailableSituation" reasoningScope="EXTERNAL" 
      operationDisposition="STARTABLE" processingDisposition="FUNCTION_PROCESS" 
      availabilityDisposition="NOT AVAILABLE"/>
</situation>
<tns:OrderItemAdd xmlns:tns="http:///DBEmitter/EmitterEvent.xsd">
      <tns:TRIGGER>CREATE</tns:TRIGGER>
      <tns:SID>60</tns:SID>
      <tns:OrderItem>
         <tns:OrderNumber>6632</tns:OrderNumber>
         <tns:Quantity>2</tns:Quantity>
      </tns:OrderItem>
      <tns:Product>
         <tns:ProductNumber>RB-0003</tns:ProductNumber>
         <tns:ProductName>5 MP Digital Camera</tns:ProductName>
         <tns:Price>499</tns:Price>
         <tns:Description>This digital camera takes MPEG4 movies</tns:Description>
      </tns:Product>
</tns:OrderItemAdd>
</CommonBaseEvent>

Back to top

Summary

In this article you learned about the Oracle Emitter, a tool that enables you to monitor business process events generated via the intermediary of Oracle databases. You learned about the necessary steps to set up your existing Monitor installation to incorporate this tool. The article also described the design of the components that make up the framework for the Oracle Emitter.

Back to top

Disclaimer

The opinions, solutions, and advice in this article are from the authors' experiences and are not intended to represent official communication from IBM. Neither the authors nor IBM is liable for any of the contents in this article. The accuracy of the information in this article is based on the authors' knowledge at the time of writing. Also the sample code within this document have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability or function of the examples.

Back to top

Download

Information about download methods

Resources

Learn

• DB2 event emitter sample: Learn more about the event framework.
  
  
• Clips and Tacks Order Handling Future 1 Process: Learn about the Clips and Tacks Order Handling Process used in this article.
  
  
• Clips and Tacks: Getting started with the IBM BPM suite of products : This tutorial describes in detail how to develop a monitor model.
  
  
• Canonical Situation Data Format: The Common Base Event V1.0.1 : This document defines the Common Base Event and supporting technologies that define the structure of an event in a consistent and a common format.
  
  
• Common Base Event best practices: Getting it right the first time (developerWorks, 2006): Take a look at how IBM is getting the basics to autonomic computing technology right the first time as developerWorks highlights the recently released manual, "Best Practices for the Common Base Event and Common Event Infrastructure," taking you through the interesting and the cool.
  
  
• WebSphere Business Monitor V6.2 Information Center : Get complete product documentation.
  
  
• developerWorks BPM zone: Get the latest technical resources on IBM BPM solutions, including downloads, demos, articles, tutorials, events, webcasts, and more.
  
  

Get products and technologies

• Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2 ®, Lotus ®, Rational ®, Tivoli ®, and WebSphere ® .
  
  

About the authors

Jing Jing Wei currently works on the WebSphere Business Monitor SWAT and L3 team in the China Development Lab. She has been building business activity monitoring solution for customers worldwide. You can reach her at weijingj@cn.ibm.com.

Kiet Nguyen is a software engineer with the IBM WebSphere Business Monitor Lab SWAT team in Raleigh, NC.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• The scenario
• How to use the Oracle Emitter
• How the Oracle Emitter works
• Summary
• Disclaimer
• Download
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers