Business Event Processing with WebSphere Business Events, Part 4: Integrating Business Events with WebSphere Enterprise Service Bus and WebSphere Process Server

Document options Document options requiring JavaScript are not displayed Sample code My developerWorks needs you! Connect to your technical community Rate this page Help us improve this content

Level: Introductory

Eric Erpenbach (eerpenb@us.ibm.com), Senior Software Engineer, IBM
Doina Klinger (dklinger@uk.ibm.com), Advisory Software Engineer, IBM
Callum Jackson (callumj@uk.ibm.com), Software Engineer, IBM

19 Nov 2008

Part 4 of this series shows you how to build an IBM® WebSphere® ESB mediation module to interact with WebSphere Business Events, IBM®'s premier product for business event processing.

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 this article, you'll learn how to integrate WebSphere Enterprise Service Bus (hereafter called ESB) V6.1.0.1 and WebSphere Process Server (hereafter called Process Server) V6.1.0.1 with a business event processing solution. This article doesn't provide detailed background information on Business Events, ESB, or Process Server. Instead it focuses on the integration patterns between the products.

The target audience for this article is the ESB, Process Server and WebSphere Integration Developer (hereafter called Integration Developer) user who wants to exploit the capabilities of Business Events as part of a mediation or business processing solution.

WebSphere Enterprise Service Bus

WebSphere ESB V6.1.0.1 is an IBM product for the integration of service-oriented, message-oriented, and event-driven technologies. You can build and deploy mediation integration solutions to connect new and existing software applications within and across enterprises. ESB enables service virtualization and loose coupling between service requesters and service providers. To take a message from one service interface to another, it is often necessary to perform a number of operations on the message, such as message enrichment and transformation, as well as routing based on message content.

WebSphere Process Server

WebSphere Process Server V6.1 is a comprehensive service-oriented architecture (SOA) integration platform that is the core runtime environment of a business process management (BPM) solution. BPM and Process Server enable you to develop applications that satisfy your business requirements and quickly adapt them to changes in the marketplace. BPM solutions that involve automation of business processes and human tasks leverage standards such as BPEL, SCA, Web services, and JMS.

Back to top

The integration scenario

As described in previous parts in this series, the scenario is based on a trading system in which a Business Events application processes buy and sell 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. If one customer completes three sells after buys within a day for the same stock, a SpeculativeCustomer action is generated. We'll use the same Business Events application created in Part 2. The only change we'll make to the Business Events project is to specify new connector information for the events and actions.

We'll enhance the scenario to include integration with ESB and discuss where Process Server would normally fit within the solution. Figure 1 shows the high-level architecture of the integration scenario described in this article:

As you can see in Figure 1, the integration architecture has five key components:

• The trading system client is responsible for send requests into the trading system. Since this article is focusing on the ESB and Business Events integration, this component is implemented using the Web Service Explorer in Integration Developer.
• WebSphere ESB is responsible for the mediation of messages throughout the system. This component is the focus of this article. ESB will receive the message from the client and forwarding to the Business Events system. We will discuss the implementation of the mediation module in more detail later in this article.
• Business Events is responsible for detecting when a business rule has occurred. We'll use the application we built in Part 2.
• The ESB trading system is responsible for executing the trade sent by the client. This component is outside the scope of this article and is not covered in the implementation section.
• The Action processing system is responsible for performing the business process when an action has been initiated by the Business Events system. Because this article is not focused on the vast business processing capabilities of Process Server, we''ll implement this component as a Java™ component, and describe how Process Server is integrated.

The integration scenario follows these design principles:

• All communication between ESB and Business Events is done via JMS to achieve optimum performance. The integration at JMS level is achieved by using a JMS import and JMS export for the ESB flow to interact with Business Events and using the Message Queue Connector for events and actions in Business Events.
• All events published to Business Events flow logically through a mediation module in ESB, which transforms the specific business object into the generic event structure required by Business Events.
• Similarly any actions generated from Business Events flow logically through a mediation module, which transforms the generic action structure to the specific business object required by the action processing system.
• A generic schema is used for Business Events events and actions to illustrate how the mapping can be achieved in ESB regardless of the structure of the events.

These principles ensure that the trading system and client have no knowledge of the business event processing that is occurring, so that no modifications are required.

Note that Business Events plays two different roles in its interaction with ESB. For the requests coming into ESB flow from the trading system client, Business Events is an external service, or more precisely, an observer detecting patterns of events without influencing the flow. Once the patterns are identified and Business Events generates actions, Business Events acts as a client sending requests to the ESB flow that processes the actions.

Terminology

The use of inbound and outbound terms is relative to the product it refers to. The outbound flow from an ESB point of view (that is, trading requests from the client that are transformed and sent to Business Events) is inbound for Business Events and vice versa. In this article, we'll use the terminology relative to ESB.

The integration with Business Events demonstrated in this article uses the Message Queue Connector. The connector acts as a bridge between the messaging provider in the ESB and the internal messaging provider of Business Events. This approach simplifies the set-up required when either ESB or Business Events is already installed. As outlined in other articles in this series, Business Events uses JMS topics internally between the connector framework and the core Business Events engine. Therefore, ESB can place a message directly onto a Business Events internal topic for processing. This would improve overall performance, but raises the question of deployment topologies, which is outside the scope of this article.

Building the solution

We'll use the Business Events application created in Part 2 to illustrate how you can use ESB as a touchpoint to send events and consuming actions.

You can import the project Interchange file of the solution into Integration Developer (see Downloads), or follow the instructions in this article to build the project from scratch. As we walk through the steps to build the application, we'll discuss the key design points.

Notes:

1. The instructions and project interchange file apply to V6.1.01 of ESB, Process Server and Integration Developer.
2. The instructions assume that you have started Integration Developer and created a new mediation module called WESBtoWBEIntegration.

Back to top

Create the interfaces and business objects

Business Events requires that input event and outbound action objects conform to a general XML format. The ESB runtime and Integration Developer tools require an XSD representation of this format so that transformations can be created and the JMS bindings can successfully understand the inbound and outbound XML. These objects have already been modeled and are provided for download in the Director.xsd file. To import these objects into your application, complete the following steps:

1. Select the WESBtoWBEIntegration project in the Business Integration navigator.
2. Select File => Import => General => File System.
3. Specify the location of the downloaded Director.xsd file and check the corresponding box.
4. Click Finish.

As shown in Figure 2, four new business objects are created in your application: connector, connector-bundle, connector-object, and field.

These business objects are abstract representations of any action or event inbound and outbound from Business Events. Let's look at the structure in a little more detail:

• 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.

Figure 3 shows the hierarchical structure of the business objects:

Now that you've imported the generic business objects for Business Events, the next step is to create the specific business objects for the application. There are four business objects that are required either for the Trading System or to model the specific actions that will be received from Business Events. Complete the following steps to the SellAfterBuyProcess business object:

1. To create a new business object, select the WESBtoWBEIntegration project from the Business Integration navigator.
2. Select File => New => Business Object.
3. Specify SellAfterBuyProcess as the Name, and click Finish.
4. Click on the icon to add an element.
5. On the Description tab of the Properties pane, specify the Name as CustomerID and select string for Type.
6. Click the icon to add another element.
7. On the Description tab of the Properties pane, specify the Name as Dateand select dateTime for Type.
8. Select File => Save to save the business object.

Repeat the above steps for the following two business objects, using the information provided below:

• TradeObject represents the trade that the end user has submitted to the trading system. The following table shows the TradeObject fields.

• BuyAcknowledgementProcess is the ESB representation of the BuyAck Business Events event. It has the following fields:

The final business object, SpeculativeCustomerProcess, is a superset of SellAfterBuyProcess. To create this business object, do the following:

1. To create a new business object, select the WESBtoWBEIntegration project from the Business Integration navigator.
2. Click File => New => Business Object.
3. Specify SpeculativeCustomerProcess for the Name.
4. Select SellAfterBuyProcess for Inherit from.
5. Click Finish.
6. Select File => Save to save the business object.

Figure 4 shows the structure of the four business objects.

Now that you've defined the business objects for the application, the next step is to create the required interfaces. You'll need to create four interfaces for communication of the Trade System application and integration with Business Events.

First you need to create an interface that can receive requests from the client. Complete the following steps to create a Trading interface.

1. To create a new interface, select the WESBtoWBEIntegration project from the Business Integration navigator.
2. Select File => New = > Interface.
3. Specify Trading for the Name, and click Finish.
4. Click the Add one-way operation icon .
5. Change the name of the operation from operation1 to sendTradeEvent.
6. Change the type of the input from string to TradeObject.
7. Select File => Save to save the interface.

Repeat these steps to create the remaining three interfaces using the information provided below:

• The WESB_to_WBE interfacbe allows events to be sent to Business Events for processing. The interface has a single one-way method called event_emission with a single parameter with a type of connector.
• WBE_to_WESB interface allows ESB to consume actions generated by Business Events. The interface has a single one-way method called processAction with a single parameter with a type of connector.
• CustomerProcess is the business interface to the back-end system that will process the actions generated by the Business Events system once they've been transformed using the ESB mediation. This interface has three one-way methods for each type of action defined in the system. The following tables shows the details of the CustomerProcess interface.

Figure 5 shows the interfaces for the application:

Back to top

Define the assembly diagram

Now you've defined all of the business objects and Interfaces for the application, so you're ready to define the high-level interactions between the components in the assembly diagram.

As we mentioned earlier, since the focus of this article is on the integration of ESB and Business Events, the TradingSystem itself is omitted from the implementation. The application provides an interface for clients to submit trading requests that will be transformed and forwarded to Business Events for processing. Another interface receives actions from Business Events. These actions are then transformed into a specific business object and sent to a stub component for processing. This component simply logs the request into standard output.

Complete the following steps to create the assembly diagram:

1. Double-click on the assembly diagram in the WESBtoWBEIntegration project in the Business Integration navigator. A mediation module has already been created, but it doesn't include any interfaces or references. You'll add those later.
2. Drag and drop the CustomerProcess interface onto the assembly diagram, and select Component with no Implementation Type in the context menu, as shown in Figure 6.
   
   Figure 6. Create the BackEndSystem
   
   
   This component is used as the back-end system to process the actions derived by Business Events. Rename the component BackEndSystem.
3. Drag and drop the Trading interface onto the assembly diagram, and select Export with Web Service Binding, then soap/http in the Transport context menu. This export will be used by trade clients to access the Trading System.
4. Drag and drop the WESB_to_WBE interface onto the assembly diagram, and select Import with no Binding from the context menu. This interface will be used to submit events to Business Events for processing. Rename the interface WBEEvent.
5. Drag and drop the WBE_to_WESB interface onto the assembly diagram, and select Export with no Binding in the context menu. This interface is used to receive actions from Business Events for processing. Rename the interface WBEAction.
6. When an Action is sent from Business Events to ESB via the JMS export there is no contextual information to determine the method that should be invoked on the interface. To work around this issue, we've created a custom function selector that hard-codes the method to processAction, as shown in Listing 1. If the WBE_to_WESB interface is defined as described in the previous steps, the attached function selector will work without modifications.

   Import WBEFunctionSelect.jar into your project by selecting WESBtoWBEIntegration => File => Import. In the Import window, select General => Archive File and click Next. Select the JAR file and click Finish.

   Listing 1 shows the function selector code.

public class WBEFunctionSelector implements FunctionSelector {
	/**
	 * The function selector is hardcoded to always select 
	 * a method called 'processAction.' If this is incorrect, the value
                * MUST be modified.
	 */
	public String generateEISFunctionName(Object[] arg0)
			throws SelectorException {
		return "processAction";
	}
}

7. Now that you've created the WBE_to_WESB export and the Business Events function selector, you need to define the binding for the export.
   1. Right-click the newly created WBEAction export and select Generate Binding => Messaging Binding => JMS Binding.
   2. In the Configure JMS Export Service dialog, specify the following information, as shown in Figure 7:
      • JMS messaging domain: Select Point-to-Point.
      • End-point configuration: Select Configure new messaging provider resources.
      • Security configuration: Check Specify a Java Authentication and Authorization Services (JAAS) alias security credential when server security is enabled.
      • Data binding configuration: Specify com.ibm.websphere.sca.jms.data.impl.JMSDataBindingImplXM. (The business object XML using JMSTextMessage or JMSByteMessage.
      • Function selector configuration: Specify com.ibm.wbe.WBEFunctionSelector.
      
      
      Figure 7. Create WBE_to_WESB binding
      
      
      
8. To define the binding for the WESB_to_WBE import, do the following:
   1. Right-click the WBEEvent import and select Generate Binding => Messaging Binding => JMS Binding.
   2. In the Configure JMS Export Service dialog, specify the following information, as shown in Figure 8:
      • JMS messaging domain: Select Point-to-Point.
      • End-point configuration: Select Configure new messaging provider resources.
      • Security configuration: Check Specify a Java Authentication and Authorization Services (JAAS) alias security credential when server security is enabled.
      • J2C Authentication data entry: Specify SCA_Auth_Alias.
      • Data binding configuration: Specify com.ibm.websphere.sca.jms.data.impl.JMSDataBindingImplXM. (The business object XML using JMSTextMessage or JMSByteMessage.
      • Function selector configuration: Specify com.ibm.wbe.WBEFunctionSelector.
      • Check Generate "TargetFunctioName" message header property for default JMS Function Selector.
      
      
      Figure 8. Create WESB_to_WBE binding
      
      
      
9. Create a stub implementation for the BackEndSystem that consumes the Business Events actions after transformation by the mediation module as follows:
   1. Right-click BackEndSystem and select Generate Implementation => Java.
   2. In the Generate Implementation dialog, click OK. The stub Java class will automatically be generated.
   3. Replace the generated methods with the following code:

public void showSellAfterBuyAction(DataObject input1) {
		System.out.println("Sell After Buy action");
		XMLSerialisationHelper helper = new XMLSerialisationHelper();
		try {
			System.out.println(helper.writeString(input1));
		} catch (Exception e) {
		}
	}

	public void showSpeculativeCustomerAction(DataObject input1) {
		System.out.println("Speculative Customer action");
		XMLSerialisationHelper helper = new XMLSerialisationHelper();
		try {
			System.out.println(helper.writeString(input1));
		} catch (Exception e) {
		}
	}

	public void showBuyAcknowledgementAction(DataObject input1) {
		System.out.println("Buy Acknowledgement action");
		XMLSerialisationHelper helper = new XMLSerialisationHelper();
		try {
			System.out.println(helper.writeString(input1));
		} catch (Exception e) {
		}
		}
            

10. Finally, create the following wires between the exports, imports and the SCA component:
    • TradingExport1 => WESBtoWBEIntegration
    • WBEAction => WESBtoWBEIntegration
    • WESBtoWBEIntegration => BackEndSystem
    • WESBtoWBEIntegration => WBEEvent

You've now finished configuring the assembly diagram. The completed diagram should be similar to Figure 9.

Back to top

Define the mediation module

In this section, we'll walk through the process of creating the mediation flows for converting the inbound business object (in specific format) into the Business Events generic format, and then back into the specific business object format.

1. When you created the assembly diagram, you added interfaces and references to the mediation module, therefore you need to regenerate the implementation. Right-click WESBtoWBEIntegration and select Regenerate Implementation, then click OK.
2. To map the possible flow logic at the operation level, create the following wiring:
   • sendTradeObject => eventEmission
   • processAction => showSellAfterBuyAction
   • processAction => showSpeculativeCustomerAction
   • processAction => showBuyAcknowledgementAction

   Figure 10 illustrates this configuration.

   
   
   Figure 10. Mediation module operation mapping
   
   
   
3. Now let's define the request flow of the sendTradeObject operation, which is invoked when the client sends a request to the trading system for processing. Two possible types of event can be sent, either buy or sell. The mediation flow has to filter the inbound message, creating a path to transform the message into a Sell Business Events event structure and another for a Buy Business Events event Structure. It's important to note that we've removed the trading system at this stage. In a real world scenario there would be branching logic to the callout of the trading system, but since we're focused on the ESB and Business Events integration we've omitted this stage. Select the sendTradeObject operation and complete the following steps to create and configure the primitives:
   1. Add a MessageFilter primitive to the canvas by doing the following:
      1. Rename the primitive to SellOrBuyFilter.
      2. This primitive is going to route the inbound message to one of two possible transformations. As such we need to add two new terminals to the primitive to represent these paths. Select the primitive and in the Terminal section of the Properties pane, right-click in the Output terminal section and select Add Output Terminal. In the Terminal configuration dialog, specify Buy as the terminal name and click OK.
      3. Repeat this process to add another terminal called Sell.
      4. Now that you've defined the terminals, you need to specify the routing logic. In the Details section of the Properties pane, select Add. In the Add/Edit dialog enter /body/sendTradeObject/input1/tradeType="BUY" for the Pattern, ensure that the Buy terminal is selected for Terminal name field, and click OK.
      5. Repeat the previous step to create another pattern with /body/sendTradeObject/input1/tradeType="SELL" for the Pattern and Sell for the terminal.

      Once complete, the configuration of the primitive should be similar to Figure 11.

      
      
      Figure 11. Message filter properties for trade event
      
      
      
   2. Now add two XSL transformation primitives and rename them ToWBESell and ToWBEBuy. We won't complete the configuration of the stylesheet until we've finished the wiring.
4. Now that all the primitives have been added to the canvas, you need to implement the wire shown in the table below:

Your mediation flow should look similar to Figure 12.

Now that the wiring of the flow has been defined, you can configure the XSLT. Listing 3 is a copy of the inbound XML. Listing 4 is the expected outbound XML.

<input1>
    <StockID>IBM</StockID>
    <CustomerID>1234</CustomerID>
    <Price>123.50</Price>
    <Quantity>1000</Quantity>
    <Date>2008-04-26T21:32:52</Date>
    <tradeType>BUY</tradeType>
</input1>

<connector version="2.2">
    <connector-bundle type="event"  name="Buy">
        <connector-object name="Trade">
            <field name="StockID" type="String">IBM</field>
            <field name="CustomerID" type="String">1234</field>
            <field name="Price" type="Real">123.50</field>
            <field name="Quantity" type="Real">1000</field>
            <field name="Date" type="dateTime">2008-04-26T21:32:52</field>
        </connector-object>
 </connector-bundle>
</connector>
                    

The outbound XML can be separated into two sections: standard template values that remain the same for the submitted event type (highlighted in bold), and the field elements that are populated from the inbound message.

5. Select the ToWBEBuy primitive. In the Details view of the Properties pane, select New. In the New XML Mapping dialog, select Finish to accept all the default values.
6. The XSLT mapping tool displays with the source map on the left and the target map on the right. Expand the structure on the left and the right so that you can see all the elements.
7. Right-click the version attribute of the connector element in the target body and Create Transformation in the context menu. This automatically creates an Assign box to the left of the version attribute, as shown in Figure 13.
   
   Figure 13. Assign version value
   
   
   
8. The Properties pane should automatically show the General tab. Enter 3.0 for the Value, as shown in Figure 14.
   
   Figure 14. Set the version value
   
   
   
9. Repeat this process for the type and name attributes of the connector-bundle element, setting the values to event and Buy respectively.
10. Repeat the process once more for the name attribute of the connector-object, setting the value to Trade. Your transformation should now look similar to Figure 15.
    
    Figure 15. Static values set for the event transformation
    
    
    
11. The second phase of the transformation is to copy the relevant information from the source to the target map of value pairs. Start by selecting the StockID element of the source and wiring this to the field element of the target. This automatically creates an Inline map transformation as shown in Figure 16.
    
    Figure 16. Create wire to field element
    
    
    
12. You will notice a red explanation mark on the Inline map. This is due to the array structure within the target map. As there is only a single connector-object in our target, its array index will always be 1, and because this is the first field element, its array index will be 1. To enter the array index information select the Inline map and select the Cardinality tab in the Properties pane. Enter 1 for the connector-object array index and 1 for the field array index as shown in Figure 17.
    
    Figure 17. Set the cardinality of the Inline map
    
    
    
13. Now that you've resolved the array structure, you need to implement the mapping of the inline map. Click on the yellow down arrow associated with the inline map. This moves the transformation editor into the inline map.
14. Now move the value stored in the StockID source element to the value of the field element. Create a wire between the StockID and the value of the field as shown in Figure 18.
    
    Figure 18. Store the StockID in the value
    
    
    
15. Next you need to assign static values to the name and type attributes of the field element. Similar to the process used before, right-click the name attribute of the field element and select Create Transformation. This creates an Assign box to the left of the name attribute, as shown in Figure 19.
    
    Figure 19. Store static value in name attribute
    
    
    
16. The Properties pane should automatically show the General section. Enter StockID for the Value.
17. Repeat this process for the type attribute using String as the value. You should now have a completed inline map like that shown in Figure 20.
    
    Figure 20. Completed Inline map
    
    
    
18. Use the yellow up arrow to return to the top-level transformation.
19. You've now completed one out of five inline maps. Using the same process, create four more inline maps using the following information:
    • Create an inline map between the source CustomerID and the target Field array index 2, using CustomerID for the name attribute and String for the type attribute.
    • Create an inline map between the source Price and the target Field array index 3, using Price for the name attribute and Real for the type attribute.
    • Create an inline map between the source Quantity and the target Field array index 4, using Quantity for the name attribute and Real for the type attribute.
    • Create an inline map between the source Date and the target Field array index 5, using Date for the name attribute and dateTime for the type attribute.

    The transformation for ToWBEBuy is now complete and should look like Figure 21.

    
    
    Figure 21. Completed ToWBEBuy transformation
    
    
    
20. Repeat the same process for the ToWBESell transformation. The only modification is to change the name attribute of the connector-bundle to Sell instead of Buy.

The mediation flow for events into Business Events is complete. Now we need to turn our attention to the mediation flow of the processAction operation. Select processAction to display the empty mediation flow. As with the previous flow, we'll add the required primitives to the canvas as follows:

1. Add a MessageFilter mediation primitive to the canvas by doing the following:
   1. This primitive is going to route the inbound action from Business Events to one of three possible transformations. As such we need to add three new terminals to the primitive. Select the primitive and in the Terminal section of the Properties pane select the Output terminal section, right click and select Add Output Terminal.
   2. The terminal configuration window will appear, fill in speculativeCustomer as the terminal name and click OK.
   3. Repeat this process to add two other terminals called sellAfterBuy and buyAck.
   4. Now that all the terminals have been defined, you can specify the routing logic. In the Details section of the Properties pane, select Add.
   5. In the Add/Edit dialog enter /body/processAction/input1/connector-bundle/@name='Speculative Customer' in the Pattern field, ensure that speculativeCustomer is selected for Terminal name field, and click OK.
   6. Repeat this process to add another pattern with /body/processAction/input1/connector-bundle/@name='Sell After Buy' as the pattern and sellAfterBuy as the terminal.
   7. Repeat this process to add a pattern with /body/processAction/input1/connector-bundle/@name='Buy Ack' as the pattern and buyAck as the terminal.

   The configuration of the primitive should be similar to Figure 22.

   
   
   Figure 22. Message filter configuration for action
   
   
   
2. Add three XSL transformation primitives named speculativeCustomerAction, buyAction and sellAfterBuyAction.

Now that all the primitives have been added to the canvas, create the following wires:

Your mediation flow should look similar to Figure 23.

Now that the wiring of the flow has been defined, you can configure the XSLT. Listing 5 is a copy of the inbound XML. Listing 6 is the expected outbound XML.

<connector version="3.0">
    <connector-bundle type="action" name="Sell After Buy">
        <connector-object name="Trade Out">
            <field name="CustomerID" type="String">1234</field>
            <field name="StockID" type="String">IBM</field>
            <field name="Date" type="dateTime">2008-04-26T21:32:52</field>
            <field name="Quantity" type="Real">9</field>
            <field name="Price" type="Real">130.00</field>
            <field name="Key" type="String">Key1</field>
        </connector-object>
 </connector-bundle>
</connector>

<input1>
    <CustomerID>1234</CustomerID>
    <Date>2008-04-26T21:32:52</Date>
</input1>

The outbound XML is a decoding of the field elements from the inbound XML.

1. Select the SellAfterBuyAction primitive.
2. In the Details view of the Properties pane, select New.
3. In the New XML Mapping dialog, select Finish to accept all the default values.
4. The XSLT mapping tool appears with the source map on the left and the target map on the right. Expand the structure on the left and the right so you can see all the fields. The Business Events structure on the left is a generic structure for all event and action instances. You need to map from this generic structure into the specific Action business object. You need to map two transformations. First select the field element and wire it to the target CustomerID element.
5. A submap transformation is generated. Select the blue down arrow associated with the submap and select Custom. The XSLT editor should display as shown in Figure 24.
   
   Figure 24. Action XSLT mapping
   
   
   
6. Because this is a custom transformation, you need to add a custom XPath expression. On the General tab of the Properties pane, add $field[@name='CustomerID'] as a custom XPath expression as shown in Figure 25.
   
   Figure 25. Custom XPath for field element
   
   
   
7. Repeat this process to add a wire between the source field element and the target Date element with a custom XPath of $field[@name='Date'].
8. You've completed the XSLT configuration for the SellAfterBuyAction primitive. Repeat this process for the remaining two XSLT primitives. The custom XPath expression is in the same format as shown above: $field[@name='<ELEMENT_NAME>'].
9. You've finished developing the mediation flow for the application. Select File => Save to save the mediation flow.

Back to top

Possible Process Server integration points

As mentioned earlier, a Java component (BackEndSystem) was used to simulate a system (SpeculativeCustomer) that will react to the business events identified by Business Events. This Java component could easily be replaced with an import that is bound to a module with an export wired to a business process, human task, or other service.

Figure 26 shows the SCA import that would replace the Java component. The mediation component would be wired to in order to call the business process, as shown in Figure 27.

As previously described, the generic event format used by Business Events must be transformed into application-specific business objects. ESB provides this capability and is a key part of the integration between Businebss Events and Process Server. With ESB transforming event data into application-specific data, business events identified in Business Events can drive any amount of processing in applications running on Process Server.

Back to top

Install and test the scenario

The ESB and Business Events integration solution is based on the use of a message queue connector for the Business Events events and actions. The connector process essentially links between the ESB instance and the WebSphere Application Sever on which the Business Events run-time executes, passing messages from one queue to another.

This section describes how to test the mediation module you created earlier. The process can be separated into four sections:

• Install the ESB application
• Configure the ESB messaging provider
• Modify and install the Business Events application
• Test the scenario

Install the ESB application

The following steps assume you have either followed the steps in this article to create the application in the previous section or imported the completed project interchange file.

1. In Integration Developer start WebSphere ESB Server v6.1 from the Servers pane.
2. Add the WESBtoWBEIntegration project to the server by right-clicking WebSphere ESB Server v6.1 in the Servers pane and selecting Add and Remove Projects.
3. In the Add and Remove Projects dialog, select WESBtoWBEIntegration and click Add, then click Finish.
4. On the Servers tab, you should be able to see that the application has been deployed to the server, as shown in Figure 28.
   
   Figure 28. ESB application deployed to the server
   
   
   

Configure the ESB messaging provider

Unfortunately the connection factory generated during the installation of the ESB application is not a queue connection factory as required by Business Events. Therefore, you need to manually create a Queue Connection Factory for access.

1. Point your browser to the ESB administration console, for example: http://localhost:9060/admin
2. Enter the username and password (the default for both is admin), and click Log in.
3. Select Resources => JMS => Queue connection factories, as shown in Figure 29.
   
   Figure 29. Select Queue Connection Factories
   
   
   
4. In the Scope field, select server level and click New.
5. Select Default messaging provider and click OK.
6. Specify the following values:
   • Name: Business Events Connection Factory
   • JNDI name: jms/WESBtoBusiness Eventscf
   • Bus name: SCA.APPLICATION.xxxCell.Bus
   • Component-managed authentication alias: SCA_Auth_Alias
   • You may need to enter a Provider endpoint if you aren't using the default port configuration, however this will be dependent on your set-up. See the WebSphere Application Server Information Center for more information.
   • Click OK.

   Figure 30 shows the created queue connection factory.

   
   
   Figure 30. Created Queue Connection Factory
   
   
   
7. Click Save.
8. Restart the ESB server for the changes to take effect.

Modify and install the Business Events application

Before testing the scenario, you need to make a few modifications to the Business Events application to enable it to receive events and send actions to the JMS queues on which ESB will be listening, and then deploy the application.

1. Start WebSphere Business Events Director Data.
2. Select File > Open Project and specify the location of the Trading.xml application provided in the Downloads section.
3. Under Touchpoints, expand Trade System to show the associated events and actions, as shown in Figure 31.
   
   Figure 31. Trade system events and actions
   
   
   
4. Right-click the Buy event and select Event Properties.
5. In the Event Buy Properties dialog, select the Connection tab.
6. Uncheck File System Connection, if checked, and check Message Queue Connection, then click Configure.
7. In the Message Queue Event Connection dialog, specify WESBtoWBEIntegration/WBEEvent_SEND_D as the Queue Name. (If you named the mediation module or JMS exports/imports differently, this name will be incorrect and you'll need to find the JNDI JMS Queue value in the ESB or Process Server administration console by selecting Resources => JMS => Queues.)
8. Click Provider.
9. In the Provider dialog, specify the following, as shown in Figure 32:
   1. Select com.ibm.websphere.naming.WsnInitialContextFactory as the Context Factory Class.
   2. Specify the URL for the JMS provider. If ESB is the only server on the machine, this will be the default value iiop://localhost:2809, depending on your ESB and Process Server configuration, you may need to customize this setting.
   3. In the Factory Name field, enter jms/WESBtoWBEcf .
   4. If security is enabled on your ESB or Process Server system, configure the Username and Password to allow the connector to establish a connection. The default value for both is Admin.
   5. Click OK.
   
   
   Figure 32. Configure JMS provider
   
   
   
10. In the Message Queue Event Connection dialog, click Apply and then OK.
11. In the Event Buy Properties dialog, click OK.
12. Repeat the same process to configure the Sell event.
13. Repeat the same process to configure the Buy Ack, Sell After Buy, and Speculative Customer actions, but set the JNDI JMS Queue name to WESBtoWBEIntegration/WBEAction_RECEIVE_D.
14. If not already started, start your Business Events run-time environment and any associated database servers.
15. To deploy the application to the server, select Tools => Repositories.
16. Select all the assets and click Add In.
17. In the Repository Properties dialog, fill in the connection details for the Business Events server ((for example, localhost and 9080) and click OK.
18. Enter the User name and Password (the default for both is admin) and click Login.
19. Close the Repository window, and close Director Data.
20. Point your browser to the Business Events administration console, for example: http://localhost:9060/admin. (If multiple Application Server instances are installed, the port information may be different.)
21. Select Applications => Enterprise Applications.
22. Check WBERuntimeEAR and click Stop, as shown in Figure 33.
    
    Figure 33. Stop the Business Events application
    
    
    
23. Check WBERuntimeEAR again and Start.
24. Open a command prompt and navigate to <WBE_INSTALL>\director\bin.
25. Start the connector framework by entering the command: connector.bat.

The Business Events application has been successfully installed and the connector started. You're now ready to test the ESB integration.

Test the scenario

You'll use the Integration Developer Web Service Explorer to test the solution.

1. In the Business Integration perspective, click the Physical Resources tab.
2. Expand the WESBtoWBEIntegration project, right-click WESBtoWBEIntegration_TradingExport1.wsdl and select Web Services => Test with Web Service Explorer.
3. In the Web Service Explorer, click sendTradeObject.
4. Specify the following information:
   • StockID: IBM
   • CustomerID: 12345
   • Price: 130.00
   • Quantity: 100
   • Date: 2008-06-06T10:58:45.651Z
   • tradeType: Buy
5. Click Go.
6. Repeat the process but select Sell as the tradeType instead of Buy.
7. Click the Console tab. You should see a Buy Acknowledgement and Sell After Buy action, as shown in Figure 34.

Back to top

Summary

In this article, you learned how to create an application that demonstrates the integration points between ESB and Business Events for events and actions. Using a mediation flow component, you created XSLT transformations to transform the application-specific messages into the format supported by Business Events. You also created a mediation flow containing XSLT transformations to process the actions sent by Business Events. Next you set up the JMS resources for ESB to send the events to Business Events and for Business Events to send the actions to ESB. Finally you tested the solution with events sent to ESB and then onto Business Events and saw actions generated by Business Events consumed by ESB.

Back to top

Downloads

	Information about download methods

Resources

• Business event processing with WebSphere Business Events, Part 1: An introduction (developerWorks 2008): Part 1 of this series introduces you to key WebSphere Business Events concepts and tools.
  
  
• Business event processing with WebSphere Business Events, Part 2: Building a business events application (developerWorks 2008): Part 2 of this series describes how to build and test a simple Business Events application.
  
  
• Business event processing with WebSphere Business Events, Part 3: Integrating WebSphere Business Events with WebSphere Message Broker (developerWorks 2008): 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.
  
  
• WebSphere Business Events: Get product information, including features, benefits, demos and trial downloads.
  
  
• WebSphere Business Events V6.1 Information Center: Get complete product documentation.
  
  
• WebSphere Business Events V6.1 forum: Share your experiences and questions with other WebSphere Business Events users.
  
  
• Business Event Processing from IBM: A Smart SOA Solution: Get more information on IBM business event processing products.
  
  
• developerWorks WebSphere Enterprise Service Bus zone: Get the latest techical resources for WebSphere ESB, including downloads, demos, articles, tutorials, events, webcasts, and more.
  
  
• developerWorks BPM zone: Get the latest technical resources on IBM BPM solutions, including downloads, demos, articles, tutorials, events, webcasts, and more.
  
  
• Business Process Management enabled by SOA: Get product information, including features and benefits.

About the authors

		Eric Erpenbach is a software engineer at IBM in Rochester, MN. While he has worked with many areas of the WebSphere family of products since 2000, he is currently spending his time around business rule technologies, metadata-driven architectures, and aspects of governance for these two areas. If Eric has any spare time, he enjoys the outdoor activities that all four of Minnesota's seasons offer. You can reach Eric at eerpenb@us.ibm.com.

		Doina Klinger is an Advisory Software Engineer at the IBM Hursley Software Laboratory. She is a developer for WebSphere Business Events. She has worked previously as a developer and development lead on a number of WebSphere products and components, most recently, WebSphere Enterprise Service Bus and WebSphere Integration Developer. She has an interest in Eclipse and messaging and event processing technologies. Doina joined IBM in 2000, having received an MSc in Computer Science from Purdue University. You can reach Doina at dklinger@uk.ibm.com.

		Callum Jackson is a software engineer for WebSphere Enterprise Service Bus based in Hursley, United Kingdom, and has worked in the product area since 2005. Prior to this he worked in ISSW on SOA applications for the telecommunication industry. You can reach Callum at callumj@uk.ibm.com.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!