Level: Introductory Bhargav Perepa (bvperepa@us.ibm.com), WebSphere Integration Technology Specialist, IBM
Christine D. Rothemich (crothemi@us.ibm.com), Senior Editor, IBM
30 Apr 2008 Learn about the changes to the Message Logger mediation primitive
in WebSphere® Enterprise Service Bus V6.1, and how you can improve the display
of logged messages in V6.1.
Overview
The WebSphere ESB message logger primitive helps developers build mediation
business applications that can log messages to relational databases as the request
and response messages are flowing through the business application.
In this article, we'll walk through a simple mediation scenario that features a
message logger mediation primitive in both request and response flows. The
scenario uses the Derby 10.1 database, but is valid for other supported relational
databases.
The scenario
The requirement for this scenario is that all sent and received service requests
are logged to a relational database for auditing and regulatory compliance
purposes. We want to use only pre-built components, rather than creating custom
logic.
To meet the requirements, we'll develop a mediation module in WebSphere
Integration Developer (hereafter called Integration Developer) that uses the
WebSphere ESB Message Logger mediation primitive with the default, out-of-the-box
configuration. We'll walk through how to deploy the mediation module application
using in Integration Developer V6.1 and WebSphere ESB V6.1, and point out the
places where it differs from the V6 versions of the software.
Figure 1 shows the architecture of the mediation module in the Integration
Developer assembly editor. In our scenario, the mediation module receives requests
from client requesters using a Service Component Architecture (SCA) Web service
export component, performs request logging, routes the requests to a service
provider using a Java™ SCA reference component, performs reply message
logging when the service provider responds, and returns the reply message to
client requesters using the SCA export component.>
Figure 1. CustomerRewardsLogMedMod in
the assembly editor
Figure 2 shows the architecture of the mediation module in the Integration
Developer mediation flow editor, which shows the wiring of the mediation module
component to the SCA referenced Java-implemented service provider partner
component.
Figure 2. CustomerRewardsLogMedMod in
the mediation flow editor:
Figure 3 shows the request flow with message logging, and Figure 4 shows the
response flow with message logging. Both flows use the message logger mediation
primitive with the default options.
Figure 3. CustomerRewardsLogMedMod
request flow logging in the mediation flow editor
Figure 4. CustomerRewardsLogMedMod
response flow logging in the mediation flow editor
The problem
One of the key differences in V6 and V6.1 is the column type of messages. For V6,
the column type is LONG VARCHAR, as shown in the schema definition for the
Cloudscape database shown in Figure 5. This means request or reply messages being
logged to the Cloudscape database can be a maximum length 263-1
characters. This limits the characters in a message, as well as specifying that
messages are stored in the database as characters. The storing of messages as
characters has implications for the way messages are displayed.
Figure 5. Cloudscape V5.1 schema
definition for the message logger mediation
Figure 6 shows a sample request message flow log in the Database Explorer for V6.
As you can see, you can easily see the logged messages in Integration Developer
V6.
Figure 6. CustomerRewardsLogExport
request message log in the Database Explorer
However, in WebSphere ESB V6.1, the Message Logger mediation primitive logs an
XML transcoded copy of the service message object (SMO), which makes the display
of the logged messages trickier. (For more information on the message logger
mediation primitive in WebSphere ESB V6.1, see the topic
Message Logger mediation primitive
in the WebSphere ESB V6.1 Information Center.
Also, in V6.1, as described in the Information Center, the SQL type of the
message changes from LONG VARCHAR to CLOB (see Figure 9). This change the
database message logging column type has implications for how messages are
displayed.
The CLOB data type is defined as a character large object capable of storing
characters up to 2,147,483,647 long. CLOB is used to store Unicode character-based
data, such as large documents in any character set. The maximum number of
characters being stored in a database can be specified as a numeric size or in
byte multiples of Kilo, Mega or Giga, with suffixes K, M or G. Thus, changed
column type for storing logged messages in databases enables logging of messages
in any character set.
Figures 7 and 8 show the component test of the mediation module, and the request
message inputs and response message outputs. To test the module, we completed the
following steps:
- Started the WebSphere ESB V6.1 server.
- Deployed the mediation module to the WebSphere ESB server.
- Launched the component test module
- Filled in the requested parameter input information as shown in Figure 7.
- Invoked the mediation module application, and received the response output as
shown in Figure 8.
Figure 7. CustomerRewardsLogExport
component test
Figure 8 shows the console output from the CustomerRewardsLogExport component
test in V6.1. Notice that the application is running successfully, and that we're
using the Apache Derby relational database.
Figure 8. CustomerRewardsLogExport
component test output
Figure 9 shows the schema definition. Notice that the type of the message
column to which the primitive logs is CLOB.
Figure 9. Derby V10.1 schema
definition for the Message Logger mediation
Figure 10 shows the database log output in the Database Explorer.
Figure 10. CustomerRewardsLogExport
component test output in the Database Explorer
Figure 11 shows the request message flow log in the Database Explorer. Because
the logged messages are in XML in Integration Developer V6.1, it's not as easy to
display them as it was in V6.
Figure 11. CustomerRewardsLogExport
request message log in the Database Explorer
Figure 12 shows the response message flow log in the Database Explorer. Again,
you can see that the messages are in XML and do not display easily.
Figure 12. CustomerRewardsLogExport
response message log in the Database Explorer
The solution
You can display the XML messages logged to the relational database by extracting
them. To do this, complete the following steps:
- In the Database Explorer, right-click MSGLOG and select Data
=> Extract as XML, as shown in Figure 13.
Figure 13. Extract database
contents as XML
- In the XML from SQL Query dialog shown in Figure 14, select Elements,
and specify the Output folder. For this example, we'll use
CustomerRewardsLogMedMod.
- Click Finish. You'll see a message indicating that the XML file has
been successfully generated and saved to the specified output folder.
Figure 14. Generate XML from an
SQL query
To view the XML request and response messages logged to the relational database,
you can use the Integration Developer V6.1 XML editor. However, an easier way to view the XML request and response messages logged to the
relational database is to use the Integration Developer system editor. To do this,
right-click the log in the Physical Resources perspective, and select Open with
=> System Editor, as shown in Figure 15.
Figure 15. Open log in the system
editor
The log displays in the system editor, as shown in Figure 16.
Figure 16. Request and response log in
the system editor
Summary
Congratulations! You have successfully developed, deployed and studied a simple
database logging service. In the process, you have uncovered subtle behavioral
differences between message logger mediation primitives between releases, and
learned how you can optimize the display of logged messages in Integration
Developer V6.1. You should also have a better understanding of the purpose and
value of this pre-built mediation primitive component.
Acknowledgments
The author would like to thank Leonard McWilliams, IBM Software Group Federal
Technical Sales, for pointing out the differences in message logging between the
releases and suggesting the importance of documenting a method for improving
message display in Integration Developer V6.1.
Resources
About the authors  | 
| |
Bhargav Perepa is a WebSphere IT Specialist with IBM Federal Software Group in Washington D.C. He was a WebSphere developer at the IBM Austin WebSphere Development Lab and has previous Smalltalk and C++ development experience. Bhargav holds a Masters degree in Computer Sciences from IIT, Chicago and an MBA degree from UT-Austin, Texas. You can reach Bhargav at bvperepa@us.ibm.com. |
| 
| |
Chris Rothemich is a Senior Content Editor with IBM developerWorks WebSphere. She’s responsible for acquiring, editing, and publishing content for WebSphere SOA, Web services, business process management, and wireless solutions. Chris’s background is in user technologies, product and information design, and information development. She holds a B.A. in English/Writing and Editing from North Carolina State University. You can reach Chris at crothemi@us.ibm.com. |
Rate this page
| 
