Integrating WebSphere Business Events V6.2 with WebSphere ESB and WebSphere Process Server

In an earlier developerWorks article, I showed you how WebSphere Business Events V 6.1 can interoperate out of the box with WebSphere Process Server and WebSphere Enterprise Server Bus V6.1. In this article, you'll learn how this interoperability has improved in V6.2.

Doina Klinger, Advisory Software Engineer, IBM

Doina Klinger photoDoina 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.



16 September 2009

Also available in Chinese Russian

Introduction

Interoperability between WebSphere Business Events (Business Events), WebSphere Process Server (Process Server) and WebSphere Enterprise Server Bus (ESB) has improved in V6.2. Some of the changes are:

  • Events and actions have specific, rather than generic, schemas, which makes mapping easier.
  • A new event emitter primitive, Business Event Emitter, encapsulates the ESB-to-Business Events part of the integration.
  • New sample scripts are provided that show how to establish communication between the products at the messaging level.
  • For the Business Events actions processing in ESB, support has been added for the pattern where specific processing is defined for each type of action.
  • Support for formatting result events to send to Business Events has been added in the form of two new primitives. These primitives, Business Events Send Success and Business Events Send Failure, can be used in a mediation flow to indicate to Business Events when the processing of an action has been succesful or has failed. Note: This is a new topic, which was not covered in in the V6.1 article.

As in V6.1, ESB is a key part of the integration between Business Events and Process Server. With ESB transforming event data into application-specific data, actions identified in Business Events can drive any amount of processing in applications running on Process Server.

The rest of the article describes the integration between Business Events and ESB. You can use the same steps to integrate Business Events with Process Server, using the mediation module described here as the key component for the integration. The mediation module can be combined with other Process Server artifacts as required, but the integration is achieved using the mediation module.

The focus of this article is V6.2 ESB-to-Business Events integration. We'll define a sample (and very simple!) Business Events project. Only the definition of events and actions really matters for the integration. A real Business Events application is likely to have various filters to determine patterns, but this won't change the shape of the integration solution.

Event processing is typically added to an existing ESB integration solution. This part of the solution, including typical mediation functions like service invocations, message transformations or filtering is omitted here for reasons of brevity. Only Business Events-specific processing is shown.

In this article, you'll learn:

  1. How to create the connectivity that eliminates the need for the Business Events connectors to be running, effectively making ESB act as a Business Events connector.
  2. How to configure the event emitter primitive to an ESB flow and add the V6.2-specific mapping
  3. How to add the processing of Business Events actions in a flow using the pattern of one method per action
  4. How to add ESB-specific information to result events and how to send result events from an ESB flow into Business Events.

Overview of the scenario

Figure 1 shows a representation of the integration solution that we'll build in this article. The scenario is built using Integration Developer V6.2 IFix and Business Events V6.2 Fixpack 1.

Figure 1. The scenario
The big picture

For Business Events, we'll use a very simple project, in which MyEvent always triggers MyAction. The action has an associated result event called ResultEventForMyAction that triggers a new action ActionForResultEvent.

In ESB, we'll have two types of flow: one that emits events into Business Events and one that processes actions and sends result events into Business Events.

In the execution flow:

  • A message arrives from an external source and triggers processing in a ESB flow. As part of the flow, the message is transformed and is sent into Business Events using the primitive (1) .
  • Business Events receives the event which triggers processing that, in this example, means an action will always be generated (2)
  • The action is processed by ESB. As part of the action flow, a result event is sent to Business Events. The result event generates the new action in Business Events. (3)
  • The new action is received and processed by an ESB flow.

Note: The event generation, action processing, and action processing followed by result event generation are three independent aspects of the ESB-to-Business Events integration. The example from this article illustrates all of those aspects, but a particular integration solution could have only of them.


Download the project

Before you begin, you need to download the Business Events project. This very simple project defines one event, one action, one result event and the action it generates. There are two simple rules with no filters, as shown in Figure 2:

Figure 2. Interaction sets
Interaction sets

Business Event Processing with WebSphere Business Events, Part 4: Integrating Business Events with WebSphere Enterprise Service Bus and WebSphere Process Server describes in great detail how to create events and actions, as well as intermediate objects and the mappings. We won't go over that again in this article.

Load the project file in the Business Events Design Data tool, then open the repository and add everything to the repository, as described in Moving assets into production in the Business Events Information Center.


Enable connectivity

In Business Events V6.2, you can establish connectivity between ESB and Business Events at the JMS level. There are various ways to achieve this. Business Events V6.2 provides sample scripts to support this. The scripts define interbus links between the Service Component Architecture (SCA) application bus in ESB and the Business Events bus. In addition, the ESB script defines the JMS resources that enable the Business Events related artifacts to run out-of-the-box.

Achieving connectivity at JMS levels eliminates the need for the Message Queue connector to be running (as described in the V6.1 integration article), thus significantly improving performance.

You can run the scripts that come with Business Events V6.2 to create and modify the necessary bus and JMS resources without requiring any user intervention. This approach is recommended for development and testing scenarios and small deployments. The sample scripts are in <WBE>\integration\WESB\features\runtime\samples. Comprehensive comments and help for running the scripts is provided in the scripts themselves and as comments.

The scripts take as parameters machine, server, node and cell names, as well as SIB port numbers. Therefore, it's recommended that you collect these values before running the scripts.

  1. Start the servers and check the following values in administrative console and fill them in as follows:
    Machine Server Node Cell Port
    ESB PUTNA server1 PUTNANode01 PUTNANode01Cell 7276
    Business Events COZIA server COZIANode01 7276
  2. From WESB\bin, the general syntax of the wsadmin command is:
    wsadmin.bat -lang jython -f /path/to/configure_WESB_SIB_JMS_messaging.py 
    scope local_host_name local_SIB_messaging_port local_server_name remote_
    host_name remote_SIB_messaging_port remote_node_name remote_server_name

    Assuming that the script has been copied locally, with these values, run the scripts as follows:

    wsadmin.bat -lang jython -f  configure_WESB_SIB_JMS_messaging.py 
    server PUTNA 7276 server1 COZIA 7276  COZIANode01 server1

    The script creates a foreign bus link with the ESB's SCA application bus.

  3. From WBE\WAS\bin, the general syntax of the wsadmin command is:
    wsadmin.bat -lang jython -f configure_WBE_SIB_JMS_messaging.py 
    local_host_name  local_SIB_messaging_port local_server_name
    remote_host_name remote_SIB_messaging_port remote_cell_name
    remote_node_name remote_server_name

    Assuming that the script has been copied locally, with these values, run the scripts as follows:

    wsadmin.bat -lang jython -f configure_WBE_SIB_JMS_messaging.py 
    PUTNA 7276 server1 COZIA 7276 COZIANode01Cell COZIANode01 server1

    The script creates a foreign bus link with the Business Events bus and creates the JMS resources (topic connection factory, topics, activation specification) that enable the ESB artifacts to run out of the box.


Build the integration solution

As mentioned earlier, this article focuses on the ESB integration for Business Events. It includes a Project Interchange file of the final solution that you can import into WebSphere Integration Developer (Integration Developer), or you can follow the instructions below to build the project from scratch.

The instructions assume that you have started Integration Developer and created a new mediation module called WESBtoWBEIntegration62.

We'll show you how to send events into Business Events, how to process actions and how to add result events.

Send events to Business Events

Business Events V6.2 exposes a specific event and action schema for each different item. To download and export the V6.2 sample project and schema, do the following:

  1. First download Article62Test.xml .
  2. In Design Data, open the Article62Test.xml project.
  3. Right-click MyEvent, then select Event Properties.
  4. On the Event tab, click Export examples and schemas and select WBE packet schema => v6.2 Format, and click Save, as shown in Figure 3. Make sure you save the 6.2 version.
    Figure 3. Export the schema
    Export the schema

Create the interfaces and business objects

Complete the following steps to import the interfaces and business objects into your application:

  1. Right-click the WESBtoWBEIntegration2 project in the Business Integration navigator.
  2. Select File => Import => General => File System.
  3. Specify the location of the saved EventMyEvent.xsd and check the corresponding box.
  4. Click Finish.

Note: Alternatively, you can drag the xsd file from your file system and drop it in the WESBtoWBEIntegration62 project in the Business Explorer view.

A new interface is now created in your application. It is called connector, but check the namespace too.

When you explore the structure of the interface, you might find it useful to switch to the Tables view to see the fields in the Event Object, as shown in Figure 4.

Figure 4. Tables view
Tables view

The only business object that you need to create is the one representing the input message. To create this business object, complete the following steps:

  1. To create a new business object, select the WESBtoWBEIntegration2 project from the Business Integration navigator.
  2. Select File => New => Business Object, specify InputObject in the Name field, and click Finish.
  3. Click on the Add element icon icon to add an element, then save it.
  4. Add the following fields:
    Name Type
    field1 String
    field2 String
    field3 Int
    field4 Boolean
  5. You need to model an interface for the application so requests can be received from the client. To create an entryPoint interface, do the following:
    1. Select the WESBtoWBEIntegration2 project from the Business Integration navigator.
    2. Select File => New => Interface, specify entryPoint the Name field and click Finish.
    3. Click on the Add one way operation icon , change the Type of the input from string to InputObject, and click Save.
  6. Create a second interface called toWBEMyEvent with an argument connector (namespace {http://wbe.ibm.com/6.2/Event/MyEvent}). This interface is used as a target interface for the XSLT mediation primitive to transform the input message to a Business Events event.

You should now have the following interfaces for the application:

Interface name Type Operation Name Argument
entryPoint One-way <any> InputObject
toWBEMyEvent One-way <any> Connector {http://wbe.ibm.com/6.2/Event/MyEvent}

Define the assembly diagram

Now you need to define the high-level interactions between the components in the assembly diagram:

  1. Open the assembly diagram by double-clicking Assembly Diagram in the WESBtoWBEIntegration62 project in the Business Integration navigator. A mediation module has already been created, but it does not include any interfaces or references. We'll correct this later.
  2. Drag and drop the entryPoint interface onto the assembly diagram, in the pop-up menu select Export with Web Service Binding.
  3. In the transport pop-up menu, select soap/http. This export will be used by trade clients to access the trading system.
  4. Create the wire from entryPointExport1 to WESBtoWBEIntegration2.

The assembly diagram should look like Figure 5.

Figure 5. Assembly diagram
Assembly diagram

Define the mediation module

In this section, we'll create the mediation flows for converting the inbound-specific business object into the Business Events event format for MyEvent.

  1. Select the operation entryPoint.
  2. We'll start by defining the request flow for this operation. This method is invoked when the client sends a request to the service the mediation flow is to invoke. This external service is not represented in this example as this is typical WESB function: a client invoking a service via a mediation module. Only the integration is shown here. Add the following primitives:
    • XSL transformation primitive and rename it FormatMyEvent. We won't complete the configuration of the stylesheet until the wiring has been completed.
    • Business Events Event Emitter: This is the new V6.2 primitive, which makes the ESB to Business Events integration easier. Configuration of this primitive is described below.
  3. Now that you've added the primitives to the canvas, you need to implement the following wires:
    Source Terminal Name Target Terminal Name
    Input Node Out FormatMyEvent In
    FormatMyEvent Out WBEEventEmitter1 In

    Your mediation flow should look like Figure 6:

    Figure 6. Event mediation flow
    Event mediation flow
  4. Now that you've defined the wiring of the flow, you can configure the XSLT primitive.

    Listings 1 and 2 show the inbound XML and the expected outbound XML, which illustrates the mapping:

    Listing 1. Inbound XML
    <input1>
          <field1>field1</field1>
          <field2>field2</field2>
          <field3>true</field3>
          <field4>0</field4>
    </input1>
    Listing 2. Outbound XML
    <out2:connector name="TouchPoint" version="6.2">
    	<out2:connector-bundle name="MyEvent" type="Event">
    		<out2:EventObj1>
    			<out2:String1>field1</out2:String1>
    			<out2:String2>field2</out2:String2>
    		</out2:EventObj1>
            	<out2:EventObj2>
              		<out2:Int>0</out2:Int>
              		<out2:Bool>true</out2:Bool>
            	</out2:EventObj2>
    	</out2:connector-bundle>
    </out2:connector>

    As described in the V6.1 article, the outbound XML can be separated into two sections: standard template values that will remain the same across the submitted event type (highlighted in blue below) and field elements that are populated from the inbound message.

    The constant values are set in the same way as in the V6.1 article. Specify the following:

    Attribute Fixed value
    Connector.Name TouchPoint
    Connector.Version 6.2
    ConnectorBundle.Name MyEvent
    ConnectorBundle.Type Event
  5. The second phase of the transformation is to copy the relevant information from the source to the target map of value pairs. With the new event specific schema, this mapping is much easier. The values of the input fields are simply copied in the corresponding event fields.

    Map the following:

    Field1 /body/operation1/connector/connector-bundle/EventObj1[1]/String1/value
    Field2 /body/operation1/connector/connector-bundle/EventObj1[1]/String2/value
    Field3 /body/operation1/connector/connector-bundle/EventObj2[1]/Bool/value
    Field4 /body/operation1/connector/connector-bundle/EventObj2[1]/Int/value

    Figure 7 shows the complete transformation.

    Figure 7. Complete transformation to event
    Complete transformation to event
  6. Next, we'll configure the Business Events Event Emitter to ensure that the result of the transformation is sent to Business Events for processing. For the Root attribute, click Browse, and navigate the message tree to select the /body/operation1/connector. Accept the defaults for the other properties, including the JMS-related properties. The default values are correct if the scripts have been used; the mediation primitive will run out of the box. The custom primitive at the end of the flow simply prints a debug message.
  7. You can now deploy the mediation project by adding it to the ESB server, as described in Deploying modules to the test environment in the Integration Developer Information Center.

Process Business Events actions in ESB flows

Next, you'll learn how to process Business Events actions in ESB flows. The steps are similar to those for events: actions are defined in Design Data, and their schema is exported and then imported into Integration Developer, then interfaces are generated to take the newly generated business objects as arguments.

We'll define a JMS export to represent Business Events and use an interface that has one method for each action type. This is not the only way to design a ESB solution for receiving actions, but it's the approach we'll use in this article.

Set version compatibility for actions

Business Events V6.2 exposes a specific action schema for each different item. You need to select each action in Design Data and make sure the connector version compatibility is set to 6.2. To do this:

  1. In the Business Events Design Data, right-click My Action and select Action Properties.
  2. In the Properties dialog, click the Actions tab and do the following:
    • Select 6.2 for Connector Version Compatibility.
    • Click Export examples and schemas and select WBE Packet Schema, then click OK, as shown in Figure 8.
    Figure 8. Export V6.2 schema for actions
    Export V6.2 schema for actions
  3. Repeat this operation for ActionForResultEvent.

Create the interfaces and business objects

In this section, we'll walk through creating the interfaces and business objects.

To create the business objects, import the two schemas in Integration Developer as you did in Create the business objects and interfaces. Two business objects are created in your application. Both are called connector, as shown in Figure 9, but they have different namespaces. When working with these business objects, make sure you pick the right one.

Figure 9. Data objects
Data objects

Next, we'll create a new interface for the export representing Business Events. We'll use the approach described Processing actions in WebSphere Process Server and WebSphere ESB in the Business Events Information Center and create one operation for each action with the action as the argument.

We'll use the V6.2 Business Events Action Selector. When this selector is executed on receipt of a message by ESB, it determines which operation from the interface will be invoked to process the message. If the message received is an action generated by Business Events, the selector returns the name of this action. This way, when Business Events generates an action, the operation with the the same name as the action is invoked.

We'll create the following interfaces:

Interface name Type Operation Name Argument
fromWBE One-way MyAction Connector {http://wbe.ibm.com/6.2/Action/MyAction}
One-way ActionForResultEvent Connector {http://wbe.ibm.com/6.2/Action/ActionForResultEvent}

Define the assembly diagram

Now we'll update the assembly diagram for WESB_WBE_Integration62. To do this, complete the following steps:

  1. Drag and drop the fromWBE interface onto the assembly diagram,
  2. In the pop-up menu, select Export with no Binding. The export is used to receive actions from Business Events for processing,
  3. Right-click the newly created export and select Generate Binding => Messaging Binding => JMS Binding.
  4. In the Configure JMS Export Service dialog, shown in Figure 10, specify the following:
    • JMS messaging domain: Publish-Subscribe
    • JNDI name for activation specification: jca/wbe_actions
    • JNDI name for receive destination: jms/actionTopic
    • Default data format: UTF8XMLDataHandler
    • Function selector: WBE Action Selector. Note: You'll need to use Business Events V6.2 Fixpack 1 to be able to select WBE Action Selector among the available function selectors.
    Figure 10. Create JMS binding
    Create JMS binding
  5. Wire fromWBE to WESBtoWBEIntegration2.

    The assembly diagram should look like Figure 11:

    Figure 11. Completed assembly diagram
    Completed assembly diagram
  6. Right-click the mediation component and select Synchronize Interfaces and References => To implementation.
  7. To define the mediation module, select MyAction. In a real application, we would add the processing of the action to this flow. In this example, we'll have a custom mediation that prints the object it receives to the console.
  8. Add a similar custom primitive for the ActionForResultEvent operation, as shown in Figure 12.
    Figure 12. Sample flow for processing actions
    Sample flow for processing actions
  9. Deploy the updated mediation application to the runtime and invoke the entryPoint interface with Web Services Explorer. In the ESB system.out. log you should see an entry for MyAction that looks like this:
    [10/02/09 16:56:08:703 GMT] 0000005d SystemOut     O
    WESB_WBE_Integration62 : MyAction : fromWBE -> ProcessAction
    [10/02/09 16:56:08:906 GMT] 0000005d SystemOut     O 
    <?xml version="1.0" encoding="UTF-8"?>
    <p:ServiceMessageObject xsi:type="p:ServiceMessageObject"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns:ac="http://wbe.ibm.com/6.2/Action/MyAction" 
    xmlns:wbe="wsdl.http://WESB_WBE_Integration62/fromWBE" 
    xmlns:wbe_1="http://WESB_WBE_Integration62/fromWBE" 
    xmlns:p="http://www.ibm.com/websphere/sibx/smo/v6.0.1">
    .....
      <body xsi:type="wbe:MyActionRequestMsg">
        <wbe_1:MyAction>
          <ac:connector name="WBE" version="6.2">
            <ac:connector-bundle 
    		id="97A7B5DC9BD09BD011DDEECAA334FFB8"
    		name="MyAction" type="Action" 
    		workflow="FACE">
              <ac:ActionObj1/>
              <ac:ActionObj2/>
            </ac:connector-bundle>
            <ac:system>L3AAM4F</ac:system>
            <ac:timestamp>2009-02-10T16:56:08.218Z</ac:timestamp>
            <ac:loginfo>This is an event from IBM WebSphere
    		Business Events</ac:loginfo>
          </ac:connector>
        </wbe_1:MyAction>
      </body>
    </p:ServiceMessageObject>

This proves that the request coming from the Web Services Explorer has been transformed into an event. The event was received by Business Events and MyAction was generated by Business Events and then received by the processing action part of the ESB flow.

In the next section, we'll add result events to the processing of actions.

Add result events to mediation flows for processing action

First, let's look at what result events are, when they're useful and how to define them in Design Data. Then we'll see how an ESB flow processing action flow can send result events into Business Events.

Without this function, ESB would not be a proper Business Events connector and Business Events interaction sets based on result events will not be triggered is ESB processes actions.

What are result events?

A result event is a set of objects that can be returned from a touchpoint by a technology connector as the result of an action being sent to that touchpoint. This event in turn generates one or more actions.

In other words, the connector can indicate to Business Events whether the processing of the actions was successful. In order for ESB to be a full Business Events connector, it needs to be able to send result events. These result events can contribute to further patterns that Business Events can identify.

Result events were not covered in the V6.1 article.

Create result events

Now let's create a result event, as we did in the attached project.

  1. In Design Data, right-click MyAction and select Insert Event => Result of This Action, as shown in Figure 13.
    Figure 13. Insert an event
    Insert an event
  2. Accept the default (to make one event object for each action object) and click OK. This generates a result event with the same name as the action, MyAction. Design Data shows the result event as MyAction => MyAction. To avoid confusion, rename the event ResultEventForMyAction.
  3. Add a new event object by selecting, Insert => Event Object => Template from the Event Object.
  4. Select Connection => _Wesb_Result, as shown in Figure 14. This adds an event object with information that is specific to ESB.
    Figure 14. Insert event object
    Insert event object

    Once the result event is defined, you can use it in Business Events like any other event, you can define mappings to intermediate objects and interaction sets triggered by its arrival.

  5. Export the result event schema and import it into Integration Developer. Another business object called connector is created, this time with namespace {http://wbe.ibm.com/6.2/Action/ResultEventForMyAction}.

Create a new interface

The result event primitives format the result event. The actual sending is achieved by wiring it to a JMS import representing Business Events. In this section, we'll create a new interface that will be associated with this import.

The interface toWBEResultEvents has a single one-way method with a single parameter of type connector with namespace http://wbe.ibm.com/6.2/Event/ResultEventForMyAction.

Create a new interface called toWBEResultEvents with a single one-way method and a single parameter of type connector with namespace http://wbe.ibm.com/6.2/Event/ResultEventForMyAction.

The table below shows a complete list of all the interfaces for the ESB project that we have created in the previous sections, with all operations being one-way:

Interface Name MethodName Parameter Type
entryPoint operation1 InputObject
toWBEMyEvent operation1 Connector {http://wbe.ibm.com/6.2/Event/MyEvent}
fromWBE MyAction Connector {http://wbe.ibm.com/6.2/Action/MyAction}
ActionForResultEvent Connector {http://wbe.ibm.com/6.2/Action/ActionForResultEvent}
toWBEResultEvents operation1 Connector (namespace http://wbe.ibm.com/6.2/Event/ResultEventForMyAction

Update the assembly diagram

Make the following modifications to the assembly diagram:

  1. Drag and drop the toWBEResultEvents interface onto the assembly diagram.
  2. In the pop-up menu, select Import with no Binding. The import is used to submit result events to Business Events for processing.
  3. To define the binding for the import, right-click the import, and select Generate Binding => Messaging Binding => JMS Binding.
  4. In the Configure JMS Export Service dialog, specify the following information:
    • JMS messaging domain: Publish-Subscribe
    • Connection Factory: Jms/WbeTopicConnectionFactory
    • Destination: jms/eventTopic
    • Default data format: Click Select. In the Data Transformation Configuration wizard, select XML and click Next, as shown in Figure 15.
    Figure 15. Select data format transformation
    Select data format transformation
  5. On the Data transformation properties page, enter connector for Document root name and http://wbe.ibm.com/6.2/Event/ResultEventForMyAction for Document root namespace, as shown in Figure 16.
    Figure 16. Specify data transformation properties
    Specify data transformation properties
  6. Click Next and then Finish.
  7. Once the binding is generated, select the import and in the Properties view, change the default message type from Byte to Text, as shown in Figure 17, and save your changes.
    Figure 17. Change default message type
    Change default message type
  8. In the assembly diagram, connect the mediation component with the JMS import. The final diagram should look like this:
    Figure 18. Completed assembly diagram
    Completed assembly diagram
  9. Next, you need to add the primitives for formatting result events to the mediation flow. To do this, right-click the mediation component and select Synchronize interfaces and references to implementation.
  10. In the Operation connection part of the mediation flow editor, connect the MyAction operation with operation1, as shown in Figure 19.
    Figure 19. Mediation flow for processing MyAction
    Mediation flow for processing MyAction
  11. In this example, the custom mediation ProcessAction simply prints its content. We'll connect it to the Business Events Send Success primitive. This will indicate to Business Events that the processing has succeeded.
  12. The Business Events Send Success primitive has only one property describing the location of the incoming action in the message tree. If the ProcessAction primitive was to modify the message, the incoming action would first have to be saved in the transient context, and then the transient context would be the value specified as the property on WBESendSuccess primitive. Since ProcessAction does not modify the message, specify body\MyAction\connector for the Root property of the WBE primitive, and save the project.
  13. Install the application as described in Deploying modules to the test environment in the Integration Developer Information Center.
  14. Invoke the entryPoint interface using the Web Services Explorer.
  15. In the System.out for ESB, you should see the two actions received from Business Events, indicating communication going backwards and forwards between ESB and Business Events.

The ESB System.out file now contains the second action, too (omitting message headers for brevity), as shown below:

[29/01/09 17:46:43:156 GMT] 0000017a SystemOut     O 
WESB_WBE_Integration62 : ActionForResultEvent : 
	fromWBE -> LogActionForResultEvent
[29/01/09 17:46:43:156 GMT] 0000017a SystemOut     O 
<?xml version="1.0" encoding="UTF-8"?>
<p:ServiceMessageObject xsi:type="p:ServiceMessageObject" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:event="http://wbe.ibm.com/6.2/Action/ActionForResultEvent" 
xmlns:wbe="wsdl.http://WESB_WBE_Integration62/fromWBE" 
xmlns:wbe_1="http://WESB_WBE_Integration62/fromWBE" 
xmlns:p="http://www.ibm.com/websphere/sibx/smo/v6.0.1">
  <context/>
  <headers>
  </headers>
  <body xsi:type="wbe:ActionForResultEventRequestMsg">
    <wbe_1:ActionForResultEvent>
      <event:connector name="WBE" version="6.2">
        <event:connector-bundle 
	  id="549CCA3DC380EE2C11DDE216C152BE02"
	  name="ActionForResultEvent" type="Action"
	  workflow="FACE">
          <event:ActionObj1>
            <event:String1 type="String">1</event:String1>
            <event:String2 type="String">2</event:String2>
          </event:ActionObj1>
          <event:ActionObj2>
            <event:Int type="Integer">4</event:Int>
            <event:Bool type="Boolean">true</event:Bool>
          </event:ActionObj2>
        </event:connector-bundle>
        <event:system>screenda-t61</event:system>
        <event:timestamp>2009-01-29T17:46:43.015Z
	</event:timestamp>
        <event:loginfo>This is an event from IBM WebSphere 
	  Business Events</event:loginfo>
      </event:connector>
    </wbe_1:ActionForResultEvent>
  </body>
</p:ServiceMessageObject>

You have now completed the ESB - Business Events integration! In the final section, we'll take a look at some common problems related to the integration and how to fix them.


Troubleshooting ESB – Business Events integration issues

This section describes a few problems you may encounter and how to resolve them.

  • Connectivity has not been established.

    If you're using the scripts, remember to restart the servers after running them. Check that connectivity has been achieved either by verifying in Application Server administrative console that the messaging engines for the Business Events bus and SCA.application bus in ESB are started, or by looking in both server logs for messages of this type:

    [14/01/09 10:53:42:808 GMT] 00000087 SibMessage    I   [:]
    CWSIT0032I: The inter-bus connection WbeSibLink from 
    messaging engine TISMANANode05.server1-
    SCA.APPLICATION.TISMANANode05Cell.Bus in bus
    SCA.APPLICATION.TISMANANode05Cell.Bus to messaging engine
    TISMANANode01.server1-WbeBus in bus WbeBus started.
    [14/01/09 10:55:33:747 GMT] 0000008a SibMessage    I
    SCA.APPLICATION.TISMANANode05Cell.Bus:
    TISMANANode05.server1-
    SCA.APPLICATION.TISMANANode05Cell.Bus] 
    CWSIP0382I: Messaging engine 2D8A6DC035BED981 
    responded to subscription request, Publish Subscribe 
    topology now consistent. 
    [
  • Events from ESB are not reaching Business Events.

    Turn on Business Events events tracing and check whether any event touches Business Events or any actions are generated. Check that the connectivity has been established.

  • Binding errors occur when processing actions with the Business Events action selector.

    Check that the interface associated with the export has operations for all actions that Business Events generates. If some are missing, either ignore the errors (they are to be expected in this case) or add JMS selectors to the activation specification in the Application Server administrative console.

  • A ClassCastException is coming from the primitives or from the export representing Business Events.

    Possible causes of this are:

    • The event or action definition in Business Events has changed since the schemas were imported in Integration Developer. The two must be in synch,
    • The corresponding interface might not have the right connector object. Check the namespace.
  • The ESB log shows the error message "Unable to find WBEEvent.mednode".

    Make sure that the com.ibm.wbe.sibx.runtime_6.2.0.0.jar has been added to <WESB>\lib\ext.

  • Integration Developer starts but there is no Business Events category on the mediation primitive palette.

    Do the following:

    1. Check that the Business Events add-on has been installed
    2. Restart Integration Developer with the –clean option,

Summary

In this article, you learned how to create an application that demonstrates the integration points between WebSphere ESB and WebSphere Business Events V6.2. You also learned how to deal with common problems associated with the integration. The improved integration of these products makes it possible to bring to ESB service integration solutions or Process Server business process management solutions the capabilities of Business Events to detect, evaluate, and react to event patterns to meet the business objectives. Business Events adds live event pattern detection and the dynamic processes to respond to these patterns to the business process management space.


Downloads

DescriptionNameSize
Sample Business Events projectArticle62Test.xml11KB
Completed mediation moduleWESB_WBE_Integration62.zip29KB

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
ArticleID=428330
ArticleTitle=Integrating WebSphere Business Events V6.2 with WebSphere ESB and WebSphere Process Server
publish-date=09162009