Business Event Processing with WebSphere Business Events, Part 3: Using WebSphere Business Events with WebSphere Message Broker

Part 3 of this series shows you how to build WebSphere® Message Broker message flows to interact with WebSphere Business Events, enabling you to use the business event processing power of Business Events in your WebSphere Message Broker application integration and message transformation environment.

Xiaoming Zhang (zhang@uk.ibm.com), Staff Software Engineer, IBM

Xiaoming Zhang photoXiaoming Zhang is a Software Engineer at the IBM Hursley Software Lab. He has done testing, development, and Level 3 service for WebSphere MQ, WebSphere Message Broker, and WebSphere Business Events. Before joining IBM in 1998, Xiaoming was a lecturer in Computer Science at Brunel University in the UK. Xiaoming graduated from Fudan University in China, and received a Ph.D from the University of Wales Swansea, UK. You can reach Xiaoming at zhang@uk.ibm.com.



22 October 2008

Also available in Chinese Spanish

Introduction

Part 1 of this series introduced you to the trade system scenario that is used throughout this series. In Part 2, you built and tested the trade system application. In Part 3, you'll learn how to integrate WebSphere Message Broker (hereafter called Message Broker) into a business event processing solution using the trade system scenario as an example.

What are the benefits of integrating Message Broker with WebSphere Business Events (hereafter called Business Events)? Message Broker provides a smart approach to SOA for business application integration and message transformation. Frequently, however, businesses also require business event processing. For example, although your integrated business applications can freely sending each other messages through Message Broker, your business may also need to detect complex message patterns (for example, one of your applications does not appear to be active for a period of time). WebSphere Business Events (hereafter called Business Events) can detect such patterns, automatically generate a message, and send it to Message Broker so the situation can be corrected.

This article assumes that you are using WebSphere Business Events V6.1. WebSphere Business Events V6.2 or later has introduced two new WebSphere Message Broker nodes -- WBEActionInput and WBEEventOutput -- that greatly simplify the integration of WebSphere Business Events with WebSphere Message Broker. For more information, see the topic Integrating WebSphere Business Events with WebSphere Message Broker in the WebSphere Business Events V6.2.1 information center.


The integration scenario

The scenario used in this article is based on a trade system in which a Business Events application processes buy and sell trade events. If a stock is bought and sold by the same customer within an hour, a SellAfterBuy action is generated by the Business Events system. For every three SellAfterBuy actions that a particular customer performs within a day, regardless of which stocks the actions are performed on, a SpeculativeCustomer action is generated. For more information on the scenario, see Part 1.

In this article, we'll use the trade system application you created in Part 2, and enhance it to include integration with Message Broker using Message Broker touchpoints to send events and consume actions.

Figure 1 shows the high-level architecture of the Message Broker and Business events integration scenario described in this article:

Figure 1. Message Broker and Business Events integration architecture
Integration architecture

In Figure 1, the integration architecture has five key components, three of which are contained in the WebSphere Message Broker "supercomponent":

  • The trading system client is responsible for sending requests to Message Broker and receiving responses from Message Broker. For the purposes of this article, we'll use the rfhutil utility available at IH03: WebSphere Message Broker V6-Message display, test & performance utilities to simulate the client.
  • In Message Broker, the event/action transformation is responsible for mediating messages throughout the system. This component is the focus of this article. Message Broker receives messages from the client and forwards them to Business Events. It also receives action messages from Business Events and forwards them to the client.
  • Business Events detects when a business event has occurred.
  • In Message Broker, the trading system processes the trade sent by the client. The Message Broker trading system component is a logical component of a trading processing system and is presented here for completeness. How it is implemented depends on the actual business environment. Because this article focuses on how to integrate Message Broker and Business Events, that is, how to connect the event/action transformation to Business Events, the details of the trading system component not discussed in this article.
  • The Message Broker action processing system performs the business process when an action has been initiated by Business Events. Because this article is not focused on business processing capabilities, actions received from Business Events are simply examined and passed to relevant WebSphere MQ queues according to the types of the actions received.

Our integration scenario follows these principles:

  • All communication with Business Events is performed using Java Message Service (JMS) message queuing, which is a simple way for Message Broker to connect with Business Events.
  • All events submitted to Business Events are processed by a message flow in Message Broker. This enables the transformation of the specific broker messages into the generic event structure required by Business Events.
  • Similarly any actions generated by Business Events logically flow through a Message Broker flow, where transformation from the generic action structure to the specific broker messages that may be required by the action processing system can take place. However, the flow described in this article doesn't implement this type of transformation logic.

These principles ensure that neither the Message Broker supercomponent or the client do not require any specific knowledge of the Business Event component other than how to interact with its standard interface, so any possible alterations to the implementation of the Business Event component will not affect the WebSphere Message Broker supercomponent.

You can use the procedure described in this article to build your own projects from scratch. The Message Broker project interchange file and Business Events project file for the solution are included for download. You can import these into the Message Broker Toolkit and Business Events respectively. However, you'll still need to do the manual configuration described in Configure WebSphere MQ.


Configure WebSphere MQ

We'll use WebSphere MQ as the JMS provider for messaging between Message Broker and Business Events, and for messaging between Message Broker and the trading system client. In the following sections, you'll configure the WebSphere MQ JMS and create the necessary queue manager and queues.

Configure JMS

JMS queuing is used to pass messages between Message Broker and Business Events. To configure WebSphere MQ JMS, do the following:

  1. Edit the INITIAL_CONTEXT_FACTORY and PROVIDER_URL entries in the WebSphere MQ JMSAdmin.config file, in the Java\bin directory of your WebSphere MQ installation. Update these entries as shown below:
    INITIAL_CONTEXT_FACTORY=com.sun.jndi.fscontext.RefFSContextFactor
    PROVIDER_URL=file:/C:/JNDI-Directory.
  2. Create a separate WebSphere MQ queue connection factory definition file in a location of your choice, containing the following code (assuming the queue manager name is WBRK61_DEFAULT_QUEUE_MANAGER):
    # Define a QueueConnectionFactory
    # Only parameters being overridden from their default values are specified.
    # This sets up a MQ client binding.
    DEF QCF(qcf1) +
    TRANSPORT(CLIENT) +
    QMANAGER(WBRK61_DEFAULT_QUEUE_MANAGER) +
    HOSTNAME(127.0.0.1)+
    PORT(2414)
    
    #
    DEF Q(wbe_input_queue) +
    QUEUE(WBE_INPUT_QUEUE) +
    QMANAGER(WBRK61_DEFAULT_QUEUE_MANAGER)
    
    #
    DEF Q(wbe_output_queue) +
    QUEUE(WBE_OUTPUT_QUEUE) +
    QMANAGER(WBRK61_DEFAULT_QUEUE_MANAGER)
    
    #
    DEF Q(wbe_backout_queue) +
    QUEUE(WBE_BACKOUT_QUEUE) +
    QMANAGER(WBRK61_DEFAULT_QUEUE_MANAGER)
    END

    This file declares that the queue connection factory name is qcf1, and specifies three JMS queues: wbe_input_queue, wbe_output_queue, and wbe_backout_queue. The corresponding WebSphere MQ queues are WBE_INPUT_QUEUE, WBE_OUTPUT_QUEUE, and WBE_BACKOUT_QUEUE, respectively. The wbe_backout_queue is needed by the JMSInput node in the Message Broker output flow, which we'll describe about later, for messages backed out by the flow when they can not be successfully processed.

  3. Create a file directory called C:/JNDI-Directory.
  4. Run the WebSphere MQ jmsadmin command with the queue connection factory definition file you created by entering:
    jmsadmin < your_definition_file

    This creates a .bindings file in the C:/JNDI-Directory directory.

Create WebSphere MQ queue manager and queues

Use the WebSphere MQ Explorer to create a a WebSphere MQ queue manager. You can skip this step if you want to use any existing MQ queue manager, such as WBRK61_DEFAULT_QUEUE_MANAGER, which may have been created for you when you installed Message Broker. Otherwise, start WebSphere MQ Explorer and right-click Queue Managers, then click New => Queue Manager to create a new queue manager.

If you're using WBRK61_DEFAULT_QUEUE_MANAGER, you should see the queues shown in Figure 2.

Figure 2. WBRK61_DEFAULT_QUEUE_MANAGER queues
WBRK61_DEFAULT_QUEUE_MANAGER queues

If you are creating, a new queue manager, you'll need to create the following queues yourself:

  • WBE_INPUT_QUEUE
  • WBE_OUTPUT_QUEUE
  • WBE_BACKOUT_QUEUE
  • wmb_input_queue
  • wmb_unknown_message_type_queue
  • wmb_buy_ack_queue
  • wmb_sell_after_buy_queue
  • wmb_speculative_customer_queue
  • wmb_unknowns_queue

For example, to create WBE_INPUT_QUEUE, right-click Queues under WBRK61_DEFAULT_QUEUE_MANAGER and select New => Local Queue.


Develop the Message Broker flows

Business Events requires that input event and outbound action objects conform to a general XML format, as described here:

  • A connector is the top-level XML element that provides information such as the name of the connector and the timestamp of the submission. The connector element can include one connector-bundle child element.
  • A connector-bundle corresponds to either an action or event. Currently a connector message can contain only one event or action. However, an event or action can contain one or more event or action objects; these objects are represented as connector-objects in the model.
  • A connector-object maps to either an event or action object. It includes the name of the object and an array of fields.
  • The fields are a series of key value pairs in a connector-object.

The Message Broker flows you develop need to interact with Business Events using the message format shown in the following event message example:

<connector name="Trade System" version="2.2">
	<connector-bundle name="Buy" type="event">
		<connector-object name="TradeObject">
			<field name="CustomerID" type="String">
				String_CustomerID
			</field>
			<field name="StockID" type="String">
				StockA
			</field>
			<field name="Date" type="DateTime">
				2008-04-10T14:01:55Z
			</field>
			<field name="Quantity" type="Real">
				9.9
			</field>
			<field name="Price" type="Real">
				9.9
			</field>
		</connector-object>
	</connector-bundle>
</connector>

Develop the input flow

Figure 3 illustrates the input flow, which uses an MQInput node to read MQ messages from an MQ queue. The input messages are passed to the TradeFilter node to check whether the input messages are of certain types which indicates whether they should be passed to Business Events as events. If so, the messages are passed to the CreateEvent node, which transforms them into a format that Business Events can accept. The MQJMSTransform node then transforms the transformed messages from MQ messages into JMS messages, which can be read by Business Events. The JMSOutput node then sends the JMS messages (now Business Events events) to Business Events. For simplicity, irrelevant messages are sent to the UnknownMessageTypeNode node, which stores them in a MQ queue.

Figure 3. Message Broker input flow
input flow

Complete the following steps to create the message flow shown in Figure 3:

  1. In the Message Broker Toolkit Broker Application Development view, as shown in Figure 4, create a message flow project by selecting File => New => Message Flow Project, and give it a name of your choice.
    Figure 4. Message Broker Toolkit Application Development view
    Application Development view
  2. Create a new message flow by right-clicking on the new project and selecting New => Message Flow. Name the flow input.
  3. Drag and drop an MQInput node from the WebSphere MQ drawer in the Palette onto the development canvas.
  4. Click the node and specify in for the Queue name property for the node in Properties tab's Basic folder. Assign a value of XMLNS to the Message domain property in the Input Message Parsing folder.

    The body of the input messages is expected to have a root element <Trade> containing five child elements: <Type>, <CustomerID>, <StockID>, <Quantity>, and <Price>. The following is an example of such an input message:

    <Trade>
    	<Type>Buy</Type>
    	<CustomerID>String_CustomerID</CustomerID>
    	<StockID>StockA</StockID>
    	<Quantity>9.9</Quantity>
    	<Price>9.9</Price>
    </Trade>

    The valid values for the <Type> element are Buy and Sell. We will create Buy and Sell messages at a later stage.

  5. Drag and drop a Filter node from the Routing drawer onto the canvas and rename it TradeFilter. The TradeFilter node routes messages of Buy or Sell types to its True terminal and all other messages to its False terminal.
  6. Double-click the TradeFilter node and define the Function Main() as follows:
    CREATE FUNCTION Main() RETURNS BOOLEAN
    BEGIN
    	DECLARE myref REFERENCE TO Body.Trade.Type;
    	RETURN (myref='Buy') OR (myref='Sell');
    END;
  7. Drag and drop a Compute node from the Transformation drawer into the canvas and rename it to CreateEvent. The CreateEvent node converts the valid input messages to the event message format required by Business Events using the ESQL language.
  8. Double-click the CreateEvent node and define its Main ESQL function as follows:
    CREATE FUNCTION Main() RETURNS BOOLEAN
    BEGIN
    	CALL CopyMessageHeaders();
    	-- create <connector name="Trade System" version="2.2">
    	SET OutputRoot.XML.connector.(XML.Attribute)name = 'Trade System';		
    	SET OutputRoot.XML.connector.(XML.Attribute)version = '2.2';
    	-- create <connector-bundle name="Buy" type="event">
    	SET OutputRoot.XML.connector."connector-bundle".(XML.Attribute)name 
    = CAST (InputRoot.XML.Trade.Type AS CHARACTER);		
    	SET OutputRoot.XML.connector."connector-bundle".(XML.Attribute)type 
    = 'event';
    	-- create <connector-object name="TradeObject">
    	SET OutputRoot.XML.connector."connector-bundle"."connector-object".
    (XML.Attribute)name = 'TradeObject';
    	-- create "CustomerID" field
    	SET OutputRoot.XML.connector."connector-bundle"."connector-object".
    field[1] = InputRoot.XML.Trade.CustomerID;		
    	SET OutputRoot.XML.connector."connector-bundle"."connector-object".
    field[1].(XML.Attribute)name = 'CustomerID';		
    	SET OutputRoot.XML.connector."connector-bundle"."connector-object".
    field[1].(XML.Attribute)type = 'String';
    	-- create "StockID" field
    	SET OutputRoot.XML.connector."connector-bundle"."connector-object".
    field[2] = InputRoot.XML.Trade.StockID;		
    	SET OutputRoot.XML.connector."connector-bundle"."connector-object".
    field[2].(XML.Attribute)name = 'StockID';		
    	SET OutputRoot.XML.connector."connector-bundle"."connector-object".
    field[2].(XML.Attribute)type = 'String';
    	-- create "Date" field
    	SET OutputRoot.XML.connector."connector-bundle"."connector-object".
    field[3] = CAST (CURRENT_DATE AS CHARACTER FORMAT 'IU');
    	SET OutputRoot.XML.connector."connector-bundle"."connector-object".
    field[3].(XML.Attribute)name = 'Date';		
    	SET OutputRoot.XML.connector."connector-bundle"."connector-object".
    field[3].(XML.Attribute)type = 'DateTime';		
    	-- create "Quantity" field
    	SET OutputRoot.XML.connector."connector-bundle"."connector-object".
    field[4] = InputRoot.XML.Trade.Quantity;		
    	SET OutputRoot.XML.connector."connector-bundle"."connector-object".
    field[4].(XML.Attribute)name = 'Quantity';		
    	SET OutputRoot.XML.connector."connector-bundle"."connector-object".
    field[4].(XML.Attribute)type = 'Real';
    	-- create "Price" field		
    	SET OutputRoot.XML.connector."connector-bundle"."connector-object".
    field[5] = InputRoot.XML.Trade.Price;		
    	SET OutputRoot.XML.connector."connector-bundle"."connector-object".
    field[5].(XML.Attribute)name = 'Price';		
    	SET OutputRoot.XML.connector."connector-bundle"."connector-object".
    field[5].(XML.Attribute)type = 'Real';
    		
    	RETURN TRUE;
    END;
  9. Drag and drap an MQJMSTransform node from the JMS drawer onto the canvas.
  10. Drag and drop a MQOutput node from the WebSphere MQ drawer onto the canvas and rename it to UnknownMessageTypeQ. Click the node and specify wmb_unknown_message_type_queue for the Queue name property for the node.
  11. Drag and drop a JMSOutput node from the JMS drawer onto the canvas. Assign the following values to the associated properties of the node:
    • In the Basic folder, Destination queue = wbe_input_queue
    • In the JMS Connection folder, JMS provider name = WebSphere MQ
    • In the JMS Connection folder, Initial context factory = com.sun.jndi.fscontext.RefFSContextFactory
    • In the JMS Connection folder, Location JNDI bindings: file:/C:\JNDI-Directory.
    • In the JMS Connection folder, Connection factory name = qcf1.
  12. Connect all the nodes you just created as shown in Figure 3.

Develop the output flow

Figure 5 shows the Message Broker output flow. The JMSInput node reads actions generated by Business Events. The JMSMQTransform node transform the messages into MQ messages. The RouteReply node then routes the transformed messages to one of the appropriate MQOutput nodes.

Figure 5. Message Broker output flow
output flow

Complete the following steps to create the output message flow shown in Figure 5:

  1. Create a new message flow and name it output.
  2. Drag and drop a JMSInput node from the JMS drawer onto the canvas. Assign the following values to corresponding properties of the node:
    • In the Basic folder, Destination queue = wbe_output_queue
    • In the JMS Connection folder, JMS provider name = Websphere MQ
    • In the JMS Connection folder, Initial context factory = com.sun.jndi.fscontext.RefFSContextFactory
    • In the JMS Connection folder, Location JNDI bindings = file:/C:\JNDI-Directory
    • In the JMS Connection folder, Connection factory name = qcf1
  3. Drag and drop a Route node from the Routing drawer onto the canvas and rename it RouteReply. Right-click RouteReply and select Add Output Terminal twice to create two more output terminals for the node. Name the two new terminals BuyAck and SellAfterBuy and rename the existing Match terminal SpeculativeCustomer.
  4. Click the RouteReply node and configure the Filter table property as shown in Figure 6.
    Figure 6. Settings for the RouteReply node
    RouteReply configration
    This configuration causes the Buy Ack, SellAfterBuy and SpeculativeCustomer actions to be routed to the BuyAck, SellAfterBuy, and SpeculativeCustomer output terminals, respectively, and all other messages to be routed to the Default terminal.
  5. Create four MQOutput nodes and name them UnknownsNode, BuyAckNode, SellAfterBuyNode, and SpeculativeCustomerNode.
  6. Set the Queue name properties for these four nodes to wmb_unknowns_queue, wmb_buy_ack_queue, wmb_sell_after_buy_queue, and wmb_speculative_customer_queue respectively.
  7. Connect all the nodes you just created together as shown in Figure 3. The Default, BuyAck, SellAfterBuy, and SpeculativeCustomer output terminals are connected to the UnknownsNode, BuyAckNode, SellAfterBuyNode, and SpeculativeCustomerNode nodes, respectively.

Specify message queue connection connector parameters

Even though we're using the Business Events application created in Part 2, because the Business Events message queue connection connector is used to connect to Message Broker, you need to modify the connector parameters of the events and actions of the application. To do this, complete the following steps:

  1. Start the Design Data tool by selecting Start => All Programs => IBM WebSphere Business Events v6.1 => Design Data.
  2. Select File => Open Project and then specify the project file name.
  3. Expand the Touchpoints pane, as shown in Figure 7:
    Figure 7. Touchpoints pane
    Touchpoints pane
  4. For each of the Buy and Sell events shown in the Trade System touchpoint, do the following:
    1. Right-click on the event and select Event Properties.
    2. On the Connection tab, select Message Queue Event Connection, and click Configure. Note: You may need to check out the Events first before you can edit them.
    3. Select JMSQueue as the Queue Type and specify wbe_input_queue as theQueue Name.
    4. Click Provider and do the following, as shown in Figure 8:
      1. Select com.sun.jndi.fscontext.RefFSContextFactory for Context Factory Class
      2. Select file:///C:/JNDI-Directory for URL.
      3. Select qcf1 for Factory Name.
      4. Click OK.
        Figure 8. Configure JMS queue parameters for events
        configure JMS queue event parameters
    5. Click OK to save the connector configurations.

Complete the following steps to configure connections for the Buy, Ack, Sell After Buy, and Speculative Customer actions in the Trade System touchpoint:

  1. Right-click the actions and select Action Properties.
  2. On the Connection tab, select Message Queue Event Connection and click Configure. You may need to check out the Actions before you can edit them.
  3. Select JMSQueue as the Queue Type and specify wbe_output_queue as the Queue Name.
  4. Click Provider and do the following, as shown in Figure 9:
    1. Select com.sun.jndi.fscontext.RefFSContextFactory for Context Factory Class.
    2. Select file:///C:/JNDI-Directory for URL.
    3. Select qcf1 for Factory Name.
    4. Click OK.
      Figure 9. Configure JMS queue parameters for actions
      configure JMS queue action parameters
  5. Click OK to save connector configurations.

Install and test the integration

Now you need to test the Message Broker flows you've created. To test the flows, do the following:

  1. Follow the instructions in Part 2 to deploy and start your Business Events project.
  2. Start WebSphere MQ.
  3. If you haven't already done so, create a Message Broker broker using the following command:
    mqsicreatebroker <brokerName> -i <userName> -a
    <password> -q <QManagerName> -n <DBName>
  4. If you haven't already done so, create a Message Broker configuration manager using the following command:
    mqsicreateconfigmgr <configManagerName> -i <userName> 
    -a <password> -q <QueueManagerName>
  5. Start your broker and configration manager using the following commands: mqsistart <brokerName> and mqsistart <configManagerName>.
  6. In the Message Broker Toolkit, create a new Message Broker BAR file by right-clicking the new message flow project you created earlier, and selecting New => Message Broker Archive. Specify a name of your choice for the BAR file.
  7. In the Prepare pane, select the two new input and output message flows and click Build broker archive, as shown in Figure 10.
    Figure 10. Prepare the Broker BAR file
    prepare archive
  8. Switch to the Message Broker Toolkit Broker Administration view and create a domain connection to your configuration manager by selecting File => New => Domain Connection.
  9. Fill in the Queue Manager Name and Port parameters for your configuration manager.
  10. After your configuration manager is connected, click Next then the Finish.
  11. Deploy the BAR file you just created by dragging and dropping it to the default execution group of your broker, as shown in Figure 11.
    Figure 11. Deploy the BAR file
    Deploy the BAR file
  12. Use a text editor to create a text file that represents a Buy message and store it in c:\temp. For example:
    <Trade>
    	<Type>Buy</Type>
    	<CustomerID>String_CustomerID</CustomerID>
    	<StockID>StockA</StockID>
    	<Quantity>9.9</Quantity>
    	<Price>9.9</Price>
    </Trade>
  13. Create another text file that represents a Sell message and store it in c:\temp. For example:
    <Trade>
    	<Type>Sell</Type>
    	<CustomerID>String_CustomerID</CustomerID>
    	<StockID>StockA</StockID>
    	<Quantity>9.9</Quantity>
    	<Price>9.9</Price>
    </Trade>
  14. Use the rfhutil utility to send the Buy or Sell messages to the wmb_input_queue on the queue manager you are using (such as, WBRK61_DEFAULT_QUEUE_MANAGER). This can be achieved by click the Read File button to read the Buy message you have just created from c:\temp directory. You can view the content of the buy message by clicking the Data tab on the rfhutil utility, as shown in Figure 12.
    Figure 12. View content of a buy message
    View content of a Buy message
    Then click Write Q to send the message to the wmb_input_queue, as shown in Figure 13.
    Figure 13. Send a buy message by clicking the Write Q button
    Send a buy message by clicking the Write Q button
    You should see action messages generated by the Business Events flow appear in one of the queues (wmb_buy_ack_queue, wmb_sell_after_buy_queue, and wmb_speculative_customer_queue), depending on the type of the actions.
  15. You can then use the rfhutil utility to read the queues. For example, click Read Q to read the messages in wmb_buy_ack_queue, as shown in Figure 14:
    Figure 14. Click Read Q to read an action message
    Click Read Q to read an action message
  16. Select the Data tab to see the content of the message, as shown in Figure 15:
    Figure 15. Content of a Buy Ack action
    Content of a Buy Ack action
  17. If you send a Sell message immediately after a Buy message, you should see a message in wmb_sell_after_buy_queue, indicating that a Sell After Buy event has occurred.
  18. If you repeat the Buy followed by sell messaging cycle three times, you should see an action message stored in the wmb_speculative_customer_queue queue

Alternative integration methods

For simplicity, the solution described in this article uses the Business Events built-in message queue connection connector to connect Message Broker and Business Events. This means that the Message Broker JMS messages are placed in and read from JMS queues mediating Message Broker and Business Events. In terms of performance, this is not the best solution because the message queue connection connector in the middle incurs extra messaging costs. This is because event messages are forwarded to the Business Events engine by the message queue connection connector rather than directly sent to the engine.

One quick solution is to configure the JMSOutput node in the Message Broker input flow to send events directly to the Message Broker jms/eventTopic or the jms/durableEventTopic topics, and configure the JMSInput node in the Message Broker output flow to receive JMS messages directed from the jms/actionTopic or the jms/durableActionTopic. However, such a configuration does not currently support the Business Events ResultEvent and will, therefore, send all actions to your JMSInput node. You can also use other connection support, such as HTTP/SOAP/File, to connect to other Business Events built-in connectors.


Conclusion

In this article you learned how you can quickly configure Message Broker and Business Events for interoperability. We used example Broker messages to describe how event messages for Business Events can be constructed and sent to Business Events by a Broker message flow, and how action messages from Business Events can be received and processed by a Broker message flow.


Downloads

DescriptionNameSize
Completed WebSphere Message Broker project fileBrokerProject.zip4KB
Completed WebSphere Business Events project fileWBEBrokerProject.zip3KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, SOA and web services
ArticleID=345512
ArticleTitle=Business Event Processing with WebSphere Business Events, Part 3: Using WebSphere Business Events with WebSphere Message Broker
publish-date=10222008