WebSphere Message Broker Application Development Training

Prepared by: V Vijaya Raghava
WebSphere Message Broker
Concepts, Technical Walkthrough, Application Development

Prepared by: Vijaya Raghava
Mobile: +91.900.076.7644
Email ID: vvijayaraghava@hotmail.com
Prepared and Updated on: July 19, 2013
Version 1.51

3
Agenda
 Pre-requisites for the Training
 Introduction
 Application Integration
 The Complexity of Application Integration
 Challenges and Issues Businesses are facing today
 Point-to-Point Communication
 Enterprise Application Integration
 Why EAI
 Defining EAI
 The Connectivity Challenge
 Types of EAI
 EAI Approach to Integration
 Enterprise Application Integration – Benefits

4
Agenda contd…
 Service Oriented Architecture
 What is a service
 SOA Definition
 How do you know when you’ve got SOA?
 SOA vs Traditional EAI
 Benefits of SOA
 Principles & Benefits of SOA
 Enterprise Service Bus
 Definition
 SOA with an ESB
 ESB – Flexibility
 An ESB gives SOA its full value
 Integrating business applications through an ESB

5
Agenda contd…
 Enterprise Service Bus
 Different kinds of ESB
 Examples of ESB
 Various Middleware Products

6
Agenda contd…
 Introduction to WebSphere Message Broker
 Overview
 Quick Tour
 WebSphere Message Broker
 Platform Support
 Database Support
 Protocol, Transports, Data Formats and Processing
Support
 WebSphere Message Broker Business Scenario
 Technical Overview – Architecture
 Capabilities
 Enterprise Messaging
 Message Brokering

7
Agenda contd…
 Publish & Subscribe
 Publish & Subscribe – Implementation
 WebSphere MQ Interoperability
 WMB Components
 Development Environment
 Runtime Environment
 WMB Components – Interaction

8
 WebSphere MQ Explorer
 Message Flow – Revisited
 Message Broker Parsers
 Message Tree
 Logical Tree Structure
 Message tree structure
 Environment tree structure
 Local environment tree structure
 Exception list tree structure
 Message Flow Editor
 WebSphere Message Broker Software – Components
Agenda contd…

9
 WebSphere Message Broker – Built-in Nodes
 WebSphere Information Centre
Agenda contd…

10
Agenda contd…
 Technical Introduction to WebSphere MQ
 Today’s Enterprise IT Environment
 Why Interfaces are so expensive to build and maintain ?
 Service Oriented Architecture – Revisited
 Program-to-Program Communication
 Synchronous Communication Model
 Asynchronous Communication Model
 Program-to-Program Communication Factors
 Time Independence
 Three Styles of Communication
 WebSphere MQ Eliminates application network concerns

11
Agenda contd…
 Local and Remote Queue Concept
 Message Queue Interface
 Message Queue Interface – Calls
 Message Composition
 Message Types
 Message Persistence
 Queue & Queue Manager
 Message Queues Types
 Queues Expiry
 Message Broker User Roles
 How MQ Series Works

12
Agenda contd…
 Deployment Process using MQ Explorer
 Message Broker Queue Explorer
 Transformation interfaces

13
Agenda contd…
 Prerequisites
 Introduction to ESQL
 ESQL Overview
 Datatypes
 Operators
 Variables
 Statements
 Functions & Procedures
 Field References
 Modules
 Reserved Words
 Non Reserved Words
 Special Characters
 Managing ESQL files
 Writing ESQL files
 Programming Examples

14
Agenda contd…
 Developing Applications using ESQL
 LAB 1 - Simple Hello World Application
 Developing Applications using ESQL
 LAB 2 - Bookstore Application

15
Agenda contd…
 Developing Applications using Java – Concepts
 Developing Applications using Java – Labs
 LAB 4 - Connecting with Database (Bookstore Application)

16
Agenda contd…
 Developing Applications using Mappings – Concepts
 Message Sets and Message Definitions
 The Message Set Editor
 The Message Definition Editor
 The Message Mapping Editor
 LAB 6 - Simple Mapping Concept

17
Agenda contd…
 WebSphere Message Broker Installation, Startup
Configurations
 Message Broker Installation
 Startup Configurations – Windows 7
 Startup Configurations – Windows XP
 Testing Message Flow Applications
 Creating / Deleting Default Configurations
 Testing Message Flow Applications using Test Client
 Testing Message Flow Applications with SoapUI
 Debugging Message Flow Applications

18
Agenda contd…
 WebSphere Message Broker Examples
 Application Samples
 LAB 7–10
 Technology Samples
 LAB 11–15
 Troubleshooting & Problem Determination
 Documentation

19
Prerequisites for the training
 Attendees are expected to have an understanding of the following:
 Debugging in Rational Application Developer.
 XML Concepts including the following:
– XML Syntax
– XML Naming Conventions
– Prolog
– Processing Instructions
– Comments
– Document Type Definition
– Elements
– Attributes
– Entities
– XML Namespaces
– Validation of XML Documents
– XML Schema
 Web Services Concepts (including SOAP, WSDL)

21
Agenda
– What is an Application?
– Introduction to Application Integration
– Challenges and Issues Businesses facing today
– Point-to-Point Communication
– The Complexity of Application Integration
– Point-to-Point Communication – Consequences
– Enterprise Application Integration
– Why EAI
– Defining EAI
– The Connectivity Challenge
– Types of EAI
– EAI Approach to Integration
– EAI Benefits

22
What is an Application ?
User Interaction
Logic
Data
Logic
Integration
Logic
Process
Logic
Business
Rules
This image cannot currently be displayed.
This image cannot currently be displayed.
Monitoring &
Management
Logic

23
Introduction to Application Integration
 Present Situation
– Your organization probably uses many applications and services
that were built over many months or years.
– Now new business needs were identified.
– As a result, these applications probably are of different ages,
were written by different people using different languages and
technologies, reside on different hardware platforms, use
different operating systems, and provide very different
functionality.
 Impact
– Many of your applications often have very little in common at all
– Resulting in isolated functionality and multiple instances of the
same data
– Redundant activities, higher costs, and inefficient response to
your customers.

24
– Enterprise systems consist of many logical endpoints
– Off-the-shelf apps, services, packaged applications (SAP, Siebel etc)
– Web applications, devices, appliances, custom built software and many
more!
– Endpoints expose a set of inputs and outputs, which comprise:
– Protocols such as MQ, TCP/IP, database, HTTP, files, FTP, SMTP, POP3
– Formats like (C/COBOL), XML, industry (SWIFT, EDI, HL7), user-defined
– Point-to-point connections quickly deteriorate into spaghetti
– Inflexible architecture which is expensive to maintain and resistant to
change
– Message Broker connects these endpoints together in
meaningful ways
– Message Broker simplifies application and device integration!
– Avoids rewrites in response to new integration requirements
– Simplifies maintenance by reducing expensive coupling
– Flexibility adding anonymity between producers and consumers of data
– Adds insight into applications and business value they bring

25
– Application integration (sometimes called Enterprise Application
Integration or EAI) is the process of bringing data or a function
from one application program together with that of another
application program.
– Application integration is the secure and orchestrated sharing of
processes and/or data between applications within the
enterprise.
– Application Integration is a big challenge for enterprises

26
Challenges and Issues
Businesses facing today
– How are Composite (Integrating) Applications different?
The “Good Old Days”
• 1 mainframe computer
• 1 user device
• 1 network connection
• 1 population of users
• 1 set of user requirements
• 1 user location
• 1 program
• 1 program “owner”
Composite Applications
• Many computers
• Many user devices
• Many types of network connections
• Many diverse populations of users
• Many different user requirements
• Many user locations
• Many programs
• Many program “owners”

27
 Lack of business process
standards
• Architectural policy limited
 Point application buys to
support redundant LOB
needs
 Inflexible infrastructure built
over time, no roadmap

28
Inflexible IT systems: Symptoms and solutions
Symptom Solution
Multiple applications Multiple
platforms
Componentize application and IT
functions
Varying degrees of
interoperability
No seamless integration
Implement a standard method for
applications to interact with each
other
Changes to one system =
changes to other systems
Decouple system interfaces
No common data format
or process model
Implement common method for
viewing/using data and
processes

29
How to move forward

30
Point-to-Point Integration
– In a point-to-point integration model, a unique connector
component is implemented for each pair of applications or
systems that must communicate.
– This connector handles all data transformation, integration, and
any other messaging related services that must take place
between only the specific pair of components it is designed to
integrate.
– Best suited for small infrastructures, where only two or three
systems must be integrated

31
The Complexity of Application Integration
A B
CD
E

32
Point-to-Point Integration – Consequences
– Point-to-point connections quickly deteriorate into spaghetti
– Inflexible architecture which is expensive to maintain and resistant to
change

33
Enterprise Application Integration
– Application integration refers to solutions that are implemented to
integrate software applications within and between organizations
– Represents the task of integration of various applications so that
they may share information and processes freely.
– Is the creation of robust and elegant business solutions by
combining applications using common middleware and other viable
technologies.
– Application Integration is concerned with:
• integration of legacy software applications,
– these applications vary across departments,
– Written by different people at different times
– exist on different platforms,
– Coded in different programming languages
– use different data formats and provide different functionality
– Different user interfaces exist for each application.
– Integrating the applications is a more practical and cost effective
solution than the alternative of re-writing the existing applications.

34
Why EAI ?
– System development over the last 20 years has tended to
emphasize core functionality as opposed to integration
– Many systems are highly stovepiped
– There are a number of organizations fitted with different types of
open and proprietary systems. each with its own development,
database, networking and operating system. Thus resulted a
heterogeneous environment.
– Ultimately, it comes down to a cost issue. Building a system with
integration in mind reduces the amount of money spent on
further system development
– Necessity of interconnection of disparate systems in order to
meet the needs of the business

35
Why EAI ? Contd…
– Evolution of Stovepipes
– Systems tend to support single organizations with little initial
incentive to integrate with other departments
– Failure of mainframes to solve problems, provide features to
users, etc. tend to act as an incentive to stovepipes
– Organizations tend to protective of their systems and are
unwilling to compromise

36
Why EAI ? Contd…
– Integration of Stovepipe Applications Is Very Difficult
Product
Management
DB2
Inventory
Management
Configuration
Management
Service
Order
Management
Trouble
Management
Billing
Management
Performance
Management
Oracle Oracle DB2 Oracle DB2 Oracle
• Data Redundancy
• Synchronization Problems
• Application Authorization Issues
• Vendor and Application Lock-in
• Isolated data silos
• Administrative Nightmare
• Integration/customization
Nightmare
• Transition from legacy systems to
a more flexible new operational
infrastructure
Architectural Issues Integration Issues

37
Defining EAI
– EAI is defined as “the unrestricted sharing of data and business
processes among any connected applications and data sources
in the enterprise.”
– Using EAI effectively will allow us to integrate without have to
make major changes to our current infrastructure.

38
Defining EAI contd…
User Interface
level
Data
level
App Interface
level
Method
level
Legacy
Data
Packaged
Application
Business
Process

39
– Traditional Systems
– Generally referred to as ‘legacy’ systems
– May consist of anything from PC’s to minicomputers, even large
mainframes
– While the architecture of these systems may be obsolete, they still
contain functionality that must be maintained by the organization in
order to do it’s job.
– Microcomputer Systems
– Personal computers
– A wide range of hardware, operating system and applications
make it difficult to integrate these systems with each other or
legacy systems

40
– Distributed Systems
– Some number of systems tied together by a network that
supports applications run across the network
– May comprise the range of computer sizes
– A wide range of system types exist: client/server, Internet,
intranet, etc.
– Packaged Systems
– Off-the-shelf software
– Software that is purchased rather than designed
– Most are natural stovepipes, since they haven’t been designed
with integration in mind and are closed systems

41
– How did the things get this Bad ?
– Most organizations lacked architectural foresight.
– As they upgraded from legacy systems, they moved to newer
‘open’ systems without consideration to how well these new
systems would fit into their current structure and integrate with
existing legacy systems.

42
– Enterprise Chaos

43
– Application Complexity increases as technology is added
WebSphere MQ
soap/http
soap/jms
http
File
MQ/JMS

44
The Connectivity Challenge
Why?
More Flexibility
More Speed
More Efficiency
Better Services
Better Information
Increased Revenue
Reduced Cost
Lower Risk
Customers want
to improve this….
… to run their
business like this.

45
– Using EAI Technology to bring order to the enterprise

46
Types of EAI
– An enterprise system is made up of business processes and
data.
– So when an IT expert contemplates to use EAI technology, he
has to first understand how these business processes are
automated and the importance of all business processes.
– This understanding will bring out a lot of useful hints:
• For determining the amount of work needed
• How much time it will take
• Which business processes and data are to be integrated etc.

47
Types of EAI Contd…
– At What Level EAI is needed in an application?
• Data Level
• Application Interface level
• Method Level
• User Interface level

48
– Data Level
• Is the process and the techniques and technology of
transferring data between data stores.
• This can be described as extracting information from one
database, if need, processing that information, and updating
the same in another database
– Advantages
• Cost Effective
– No Code Changes
– No Deployments

49
– Application Interface Level
• leveraging of interfaces exposed by custom or packaged
applications.
• Developers make use of these interfaces to access both
business processes and simple information.
• Using these interfaces, developers are able to bring many
applications together, allowing them to share business logic
and information.
– Advantages & Usage
• Most preferred EAI technology for this type is Message
Brokers (Eg: IBM WebSphere Message Broker )
– as these can extract the information from one application, put
it in a format understandable by the target application and
transmit the information.

50
– Method Level
• Allows the enterprise to be integrated through the sharing of
common business logic or methods.
• This can be accomplished by:
– Defining methods that can be shared and therefore integrated
by a number of applications
– Providing infrastructure for such method sharing.
• The mechanisms to share methods among applications are
many including distributed objects, application servers
• Methods can be shared by
– Hosting them on a central server
– Accessing them between applications (distributed objects)

51
– User Interface Level
• Developers are able to bundle applications by using their user
interface as a common point of integration.
• For example mainframe applications that do not provide
database level access may be accessed through the user
interface application

52
EAI Approach to Integration
– Creation of business solutions by combining applications using
common middleware.
– Middleware is application-independent product that provides
services that mediate between applications.
– Rather than each application requiring a separate connector to
connect to every other connector, components in an EAI-based
infrastructure use standardized methods to connect to a common
system that is responsible for providing integration, message
brokering, and reliability functionalities to the entire network.
– EAI loosens the tightly coupled connections of point to point
integration
– An application can send a message without any knowledge of
the consumer's location, data requirements, or use for the
message
– Linking Applications, Services, Databases and Legacy
Systems

53
Enterprise Application Integration – Benefits
– Effective application integration can provide your organization
with the following important business benefits:
– Allowing applications to be introduced into the organization more
efficiently and at a lower cost
– Allowing you to modify business processes as required by the
organization
– Providing more delivery channels for your organization
– Allowing you to add automated steps into business processes that
previously required manual intervention

Service Oriented Architecture – Introduction

56
Agenda
– Current Environment
– Service Oriented Architecture – Introduction
– Bridging the Gap between Business and IT: How?
– SOA Introduction
– What is SOA?
– SOA vs Traditional EAI
– Before and After SOA
– Why SOA?
– SOA Simplifies Connectivity Interfaces
– Value of SOA
– SOA is an evolutionary step
– Expanding SOA Footprint
– Principles of SOA
– Benefits of SOA
– Applying SOA Challenges

58
Service Oriented Architecture
– What is a Service ?
– A service is an application function packaged as a reusable
component that can be used in a business process.
– Exposes a well defined interface
– Appears as a self-contained function
– Uses messages to hide implementation details
– Has no dependencies on the state of other services
– Reusable services
– Service Oriented Architecture (SOA) is an architectural style to reuse and
integrate existing systems for designing new applications.
– The goal of SOA Integration is to expose an organization's computing
assets as reusable services that can communicate and integrate more
readily. This can eliminate the "integration spaghetti" that exists in most
companies today.

59
Bridging the Gap between Business and IT: How?
How do I
optimize my
business
processes?
Business Models
Identify Process Activities
I/T Components exposed
as SOA Services
How do I
integrate to
my existing
systems?
Business and
I/T can use a
common
language
a.k.a.
“Process
Integration”
Business
Process
Activities
=
I/T Services
Granularity

60
SOA – Definition
 An approach for building distributed systems that
allows tight correlation between the business
model and the IT implementation.
 Characteristics:
– Represents business function as a service
– Shifts focus to application assembly rather than
implementation details
– Allows individual software assets to become
building blocks that can be reused in developing
composite applications representing business
processes
– Leverages open standards to represent software
assets

61
What is Service Oriented Architecture (SOA) ?
… a service?
A repeatable business
task – e.g., check
customer credit; open
new account
… service orientation?
A way of integrating your
business as linked
services
and the outcomes that
they bring
… service oriented
architecture (SOA)?
An IT architectural style
that supports
service orientation
… a composite application?
A set of related &
integrated services that
support a business
process built on an SOA

62
SOA – Definition
– An architectural style for building distributed systems that deliver
application functionality as services to either user applications or
other services
– A Software Architecture which
– … defines the use of services to support the requirements of software
users. Resources are available to other participants as independent
services accessed in a standardized way.
– … comprises loosely coupled, high interoperable application services.
These services interoperate based on a formal definition independent of
the underlying platform and programming language. The interface
definition hides the vendor and language-specific implementation.
– … is independent of development technology (e.g. Java, .NET, COBOL,
C, ASM). The software components become very reusable because the
interface is defined in a standards-compliant manner.

63
Applications can be composed of or exposed as Services

64
Applications can implement business process
workflows… by using services
Review
application
Review
application
Customer
eligibility
Retrieve
credit
report
Retrieve
credit
report
Credit
assessment
Credit
assessment
Request
additional
info
Request
additional
info
Generate declineGenerate decline
Final
application
review
Final
application
review
Generate approval
& account info
Generate approval
& account info
Determine
Customer Eligibility
Retrieve Credit
Report
Request
additional info
Generate
decline
Etc….
Business Process is implemented by integrating services

65
SOA vs Traditional EAI
– Prior to the advent of SOA, the true contender for Enterprise
Integration was EAI. A plethora of tools and technologies
emerged in this space quickly to fill the void. However, due to a
lack of standards in the initial stages several issues arose,
including:
– Proprietary vendor toolsets leading to lengthy learning curves
– Complex and lengthy implementation cycles
– Department- or Business Unit-Specific containering for EAI
implementations
– Limited application shelf life
– Technology-driven implementations without the requisite business
goal analysis.

66
SOA vs Traditional EAI contd…
Traditional EAI SOA
Technology Driven Business Driven
Project Based, confined to Department or
Business Group
Enterprise Driven, Company-wide Effort
Generally a Bottom Up approach, driven by
product and technology
Starts with Top Down approach, followed by
bottom up and then settles with Hybrid
Partially supported by Standards Almost wholly standards based at all levels
with XSD, WSDL, JAXWS, BPEL etc.
Extension of client server and Point to Point
(Adapter) integration paradigms
New Paradigm that requires a new train of
thought
Can work successfully with traditional
software development methodologies
such as SDLC, SCRUM, Agile.
Needs new types of control mechanisms
such as Governance and Competency
Centers in addition to traditional
Methodologies
Integration pattern generally resembles Hub
and Spoke
Several patterns of integration possible, of
which Hub and Spoke can be a component
Does not lend itself to enterprise-wide
integration
Complements your existing investment in
middleware by adding an Enterprise
Integration Layer on top

67
Application Centric
Application
Application
Finance
DistributionManufacturing
Supply
Narrow Consumers
Limited Business Processes
Overlapped resources
Overlapped providers
Business scope
Application
Integration
Architecture
Business functionality is
duplicated in each application
that requires it.
EAI ‘leverage’ application silos with the
drawback of data and function
redundancy.
bound to
EAI vendor
Redundancy

68
Service Centric
Service Architecture
Service
Service
Service
Service
Finance
DistributionManufacturing
Supply
Service virtualizes how that capability is
performed, and where and by whom the
resources are provided, enabling multiple
providers and consumers to participate
together in shared business activities.
Multiple Service Consumers
Multiple Business Processes
Multiple Discrete Resources
Multiple Service Providers
Business scope
SOA structures the business and its systems as a set
of capabilities that are offered
as Services, organized into a Service Architecture
Shared
Services

70
Why SOA ?
To enable Flexible, Federated Business Processes
Enabling a virtual federation of
participants to collaborate in an
end-to-end business process
Enabling alternative
implementations
Enabling reuse of
Services
Enabling virtualization of business resources Enabling aggregation from multiple
providers
Identification
Ticket Sales
Ticket Collection
Inventory
Logistics
Manufacturing
Availability
Service
Service
Service
Service
Service
Service
Service
Service Service
Service
Ordering
source:TietoEnator AB,
Kurts Bilder

71
Why SOA ? To enable Business Process Optimization
and the Real Time Enterprise (RTE)
Seamless End to End Process
Systems
SOA Pattern: Standardized Service
provided by multiple suppliers
Service from Multiple Suppliers
SOA Patterns: Single, Multi-Channel
Service for consistency
BPM Expressed in
terms of Services
Provided/Consumed
Enterprise
source:TietoEnator AB,
Kurts Bilder
Smart Clients
Stores POS
Mobile
3rd Party Agents
Portal
Service to Customers

72
Why SOA ? Other reasons…
 To keep pace with global competition:
– “We are taking apart each task and sending it
… to whomever can do it best, … and then
we are reassembling all the pieces”
from Thomas Friedman’s ‘The World is Flat’
 The standards and technology are finally in
place, with broad industry support
 Availability of best practices for
effective governance
 The necessary software to get started
is available today

73
SOA simplifies connectivity interfaces…
…but you still need to know (1) what services you can connect to, (2) where they are, (3) how
to connect to them, (4) how to log into them, (5) how to mediate the differences in data
between them.
SOA turns this… …into this.
Application Application Application Application
ApplicationApplicationApplicationApplication
Service Service Service Service
Service ServiceService Service
Interface Interface Interface
Interface Interface Interface Interface
= interface
 Enables re-use of both
the business
applications and their
interfaces.
 Decouples the
interfaces from the
business
applications.
 Reduces the
number and
technical
complexity of
interfaces.
 Introduces rich business
abstractions to describe
the application interface.

74
SOA Defined – in another way…
SOA is a software architecture model
– in which business functionality are logically grouped and encapsulated
into
• self contained,
• distinct and reusable units called services that represent a high
level business concept
• can be distributed over a network
• can be reused to create new business applications
• contain contract with specification of the purpose, functionality,
interfaces (coarse grained), constraints, usage
... of the business functionality
Services are autonomous, discrete and reusable units of business functionality
exposing its capabilities in a form of contracts.
Services can be independently evolved, moved, scaled even in runtime.

75
Value of SOA
 Service orientation promotes few, coarse grained interactions
between the service providers and consumers
 Reduces the dependencies between the two participating entities
 SOA provides for well-described service interfaces
 Allows the use of services without the need to understand their
implementation details
 SOA facilitates technology and platform independence
 SOA reduces the complexities associated with application integration
along with technology platform independence
 This should result in low cost of maintenance
 SOA manifests the same architectural model for both and external
partner application integration

76
SOA is an evolutionary step
for architecture

77
SOA is an evolutionary step
in distributed communications
Hub and Spoke
managed / centralized
Supports lose coupling of
systems
Message Broker
n lines of connectivity
Centralized management
Limited scalability
Single point of failure
Point-to-Point
unmanaged / decentralized
Suitable for small
environments
n² lines of connectivity
Message Bus
managed / decentralized
Common communication
infrastructure
Common command
infrastructure
n lines of connectivity
Proprietary communication
protocols
Complex management

78
Expanding SOA Footprint
Business Unit 1
Business Unit 3
Business Unit 2

79
SOA Principles (self study)
 Standardized Service Contracts
 Loose Coupling
 Abstraction
 Reusability
 Autonomy
 Statelessness
 Discoverability
 Composability

80
Standardized Service Contracts
 “Services within the same service inventory are in compliance with the same
contract design standards."
 Services use service contract to
– Express their purpose
– Express their capabilities
 Use formal, standardized service contracts
 Focus on the areas of
– Functional expression
– Data representation
– Policy

81
Loose Coupling
 “Service contracts impose low
consumer coupling requirements and
are themselves decoupled from their
surrounding environment."
 Create specific types of relationships
within and outside of service
boundaries with a constant emphasis
on reducing (“loosening”)
dependencies between
– Service contract
– Service implementation
– Service consumers
Source: Thomas Erl

82
Abstraction
 “Service contracts only contain essential information and information about
services is limited to what is published in service contracts”
 Avoid the proliferation of unnecessary service information, meta-data.
 Hide as much of the underlying details of a service as possible.
– Enables and preserves the loosely coupled relationships
– Plays a significant role in the positioning and design of service compositions
Source: Thomas Erl

83
Reusability
 “Services contain and express agnostic logic and can be positioned as
reusable enterprise resources."
 Reusable services have the following characteristics:
– Defined by an agnostic functional context
– Logic is highly generic
– Has a generic and extensible contract
– Can be accessed concurrently
Source: Thomas Erl

84
Autonomy
 "Services exercise a high level of control over their underlying runtime
execution environment."
 Represents the ability of a service to carry out its logic independently of
outside influences
 To achieve this, services must be more isolated
 Primary benefits
– Increased reliability
– Behavioral predictability
Source: Thomas Erl

85
Statelessness
 "Services minimize resource consumption by deferring the management of
state information when necessary."
 Incorporate state management deferral extensions within a service design
 Goals
– Increase service scalability
– Support design of agnostic logic and improve service reuse
Source: Thomas Erl

86
Discoverability
 "Services are supplemented with
communicative meta data by which
they can be effectively discovered
and interpreted."
 Service contracts contain
appropriate meta data for discovery
which also communicates purpose
and capabilities to humans
 Store meta data in a service registry
or profile documents
Source: Thomas Erl

87
Composability
 "Services are effective composition
participants, regardless of the size
and complexity of the composition."
 Ensures services are able to
participate in multiple compositions
to solve multiple larger problems
 Related to Reusability principle
 Service execution should efficient in
that individual processing should be
highly tuned
 Flexible service contracts to allow
different types of data exchange
requirements for similar functions
Source: Thomas Erl

88
Applying SOA – Benefits
– Asset reuse
– Service is component of reuse
– Lower Development Cost
– Eliminate duplicate services
– Faster Time-to-Value
– Compose new applications from existing services
– Extend Business Reach
– Allow new clients to exploit existing services without change
– Providing a new front end
– Business Responsiveness
– Dynamically reconfigure services to meet new business opportunities
– Governance
– Standardize, mandate and measure service usage
– Allows you to introduce control

89
 Service Orientation
 Reuse
 Sharing of Responsibilities
 Increased complexity!
Applying SOA – Challenges
Business functionality has to be made available as
services. Service contracts must be fixed
Implemented services must be designed with reuse in
mind. This creates some overhead.
Potential service users must be involved in the design
process and will have influence on the service design

Enterprise Service Bus – Introduction

92
Agenda
– What is an Enterprise Service Bus?
– SOA with an ESB
– ESB Flexibility
– An ESB Gives SOA its full value
– Integrating business applications through an ESB
– Two core principles of enabling flexibility
– Different kinds of ESB
– ESB Example – Healthcare Integration
– ESB Example – Retail
– ESB Example – Reservation System
– ESB Example – Role of ESB in an enterprise
– ESB Example – Role of ESB across different businesses
– Various Middleware Products in the Market
– Which Middleware Product to choose ???

93
What is an ESB ?
– A software infrastructure for SOA which
– … comprises a set of interaction points to which services are connected.
Services are able to invoke other services which are connected to the
bus.
– ... simplifies an SOA by minimizing the explicit connectivity between
services.
– … allows the creation of dynamic and flexible connectivity between
services during service invocation without changing service
consumers or providers.
– “A Web-services-capable infrastructure that supports intelligently
directed communication and mediated relationships among
loosely coupled and decoupled biz components.”
– Gartner Group

94
SOA with an ESB
– Simplification of Infrastructure
– It DOES simplify the way you think about service connectivity.
– It DOESN’T change the way you think about services.
– Dynamic and Flexible Infrastructure
– New connectivity
– e.g. add customer request audit.
– Flexible connectivity
– e.g. prioritize customer request.
– Service replacement
– e.g. New service upgrade without…

95
ESB – Flexibility
The next stage of Integration
An Enterprise Service Bus (ESB) is a flexible connectivity infrastructure
for integrating applications and services.
 Point-to-Point connection
between applications
 Simple, basic connectivity
Messaging Backbone
 EAI connects applications
via a centralized hub
 Easier to manage larger
number of connections
Enterprise Application
Integration (EAI)
 Integration and choreography of
services through an Enterprise
Service Bus
 Flexible connections with well
defined, standards-based
interfaces
Service Orientated
Integration

96
An ESB gives SOA its full value
An ESB turns this… …into this.
Enterprise Service Bus
Interface Interface Interface
Interface Interface Interface Interface
 Logs and manages
the interaction and
correlates events.
 Communicates
using the right
protocol.
 Customizes
communications so
that the message to
the receiver makes
sense.
 Connects and signs you
into the appropriate
service without
requiring a hardcoded
connection.
The ESB:

97
An ESB gives SOA its full value
Service Enrichment
•Match & Route communications
between services
•Converts between transport protocols
•Transforms between data formats
•Identifies and distributes bus events
… simplifying the overall architecture and reducing IT cost

98
Integrating business applications through an ESB
98
An Enterprise Service Bus (ESB) is a flexible connectivity infrastructure
for integrating applications and services.
An ESB performs the following
between requestor and service
Connects
Everything to everything
Matches & Routes
Communications between services
Converts
Between different transport protocols
Transforms
Between different data formats
Distributes
Business events

99
Integrating business applications through an ESB
Converts between different
transport protocols
Matches & routes communications
between services
Connects everything
to everything
Distributes Business
events
Transforms between
different data formats
An ESB enables flexible SOA connectivity for integrating
business applications, services and processes

100
Two core principles of enabling flexibility
The ESB faciltates the decoupling of interactions between
requestor(s) and provider(s)
Service Virtualization
Routing
Protocol and transports
Transformation of interfaces
The ESB fulfils two core principles in support of separation of concerns:
Aspect Oriented Connectivity
Security
Management
etc …
Log and Audit
Event tracking
Service
Requestor
Service
Requestor
Service
Requestor
Service
Requestor
Service
Provider
Service
Provider

101
Different kinds of ESB
– Basic ESB
– XML as only supported data format
– Web Services protocol emphasis (SOAP/HTTP)
– Adapters for everything
– XML conversion on and off the bus
– Protocol conversion on and off the bus
– Advanced ESB
– All formats supported natively
– XML, COBOL, C, SWIFT, EDI, MIME, Acord, X12
– All protocols supported natively
– Web Services PLUS MQ, JMS, File, SCADA device, user defined…
– Minimizes need for adapters
– Improves performance and manageability
– WebSphere MQ and Message Broker form an Advanced ESB

102
ESB Example – Healthcare Integration

103
ESB Example – Retail
An Enterprise Service Bus lets you add new services gradually.
Internet
Trading partner
communities
Analytics &
Optimization
DMZ DMZ
Internet
Customer communities
Enterprise
APP
APP
Service
Service
DBAPPDB
APP
APP DB
Commerce
Web eCommerce
– Retail is a great example of the broad landscape of integration
– Many different end points both inside and outside the organisation
– Multiple formats and protocols (TLOG, files, JSON/HTTP etc) plus devices
– Flexibility is key as new capabilities need to blend in (mobile, analytics etc)

104
ESB Example – Reservation System
Travel
Reservation
Process
New Cheque
Traveller
Service
Cheque
Credit
Service
Book
Flight
Service
Hotel
Availability
Service
Flight
Availability
Service Travel
Reservation
process
Travel
Reservation
Process
New Flight
Availability
Service
Old Flight
Availability
Service

105
ESB Example – Role of ESB in an enterprise
WebSphere MQ
soap/http
soap/jms
http
File
MQ/JMS

106
ESB Example – Role of ESB across different
businesses

107
Various Middleware Products
TIBCO
Microsoft Biztalk Server
Oracle Fusion Middleware
WebMethods
Progress Openedge
Jboss Enterprise Middleware
IBM WebSphere Message Broker

108
Which Middleware Product to choose ???
– If Integrated Development Environments are key to the
effectiveness of your team
– If your infrastructure platform is structured around
Microsoft .NET technology
– If your infrastructure runs on a Java programming platform

109
If Integrated Development Environments are key to the
effectiveness of your team
– Microsoft’s solution brings together several languages with
developer support for Web, client-server, mobile, reporting,
analytics, and integration.

110
If your infrastructure platform is structured around
Microsoft .NET technology
– Finding the closest fit with a .NET architecture will provide you
with the most seamless integration when operating on a
Microsoft platform.

111
If your infrastructure runs on a Java programming platform
– Ease of integration, compatibility with existing systems, and
scalability are things to keep in mind when selecting your vendor
product solution.

Introduction to IBM WebSphere Message Broker

114
Agenda
– WebSphere Message Broker Overview
– What is WMB
– WMB – Features
– Quick Tour
– Documentation
– WMB – Platform Support
– WMB – Database Support
– Comprehensive protocols, transports, data formats and processing
– WebSphere Message Broker Business Scenario
– Mergers and Acquisitions Scenario
– WMB Architecture
– WebSphere Message Broker Capabilities
– Message Routing
– Interacting with External Systems and Resources
– Message Broker -Transforms messages ‘in flight’
– Message Transformation and Enrichment

115
Agenda contd…
– How do we connect applications?
– Enterprise Messaging
– Message Brokering
– Publish & Subscribe
– Publish & Subscribe Implementation
– Publish Subscribe Implementation – Example 1: Bus and Train
Schedules
– Publish Subscribe Implementation – Example 2: Bus, Train, Plane
Schedules
– Publish Subscribe – Other Examples
– Magazine publishing
– Airline departure notification
– WebSphere MQ Interoperability

116
Agenda contd…
– WMB Components - Overview
– Development Environment
– Message Flows
– Message Sets
– Broker Application Perspective
– Runtime Environment
– Broker
– Execution Groups
– Configuration Manager
– Broker Domain
– User Name Server
– Broker Administration perspective
– WMB – Components revisited
– Interaction of Message Broker Main Components
– WebSphere Message Broker runtime architecture
– Usage Patterns with Message Broker

117
WebSphere Message Broker Overview
– Business integration is the coordination and cooperation of all
your business processes and applications.
– It involves bringing together the data and process intelligence in
your enterprise, and harnessing these so that your applications
and your users can achieve their business goals.
– It provides a mechanism for
• connecting, routing, and transforming business data from a
variety of transports without any need to change the underlying
applications generating the data.
– WebSphere Message Broker, in short WMB from now
onwards, enhances the flow and distribution of information by
enabling the transformation and intelligent routing of messages
without the need to change either the applications that are
generating the messages or the applications that are consuming
them.

118
WMB (contd.)
– In WebSphere Message Broker, connectivity is provided by applications
that communicate by sending and receiving messages.
– WebSphere MQ messaging provides a secure and far-reaching
communications infrastructure that you can expand with WebSphere
Message Broker or WebSphere Event Broker to apply intelligence to
your business data as it travels through your network.
– Key capabilities that make WebSphere Message Broker a valuable
solution for business integration
– Distributes any type of information across and between multiple
diverse systems and applications, providing delivery of the correct
information in the correct format and at the correct time
– Reduces the number of point-to-point interconnections and simplifies
application programming by removing integration logic from the
applications

119
WMB (contd.)
– Routes information in real time based on topic and content to any
endpoint using a powerful publish/subscribe messaging engine
– Validates and transforms messages in-flight between any
combination of different message formats, including Web Services,
and other XML and non-XML formats
– Routes messages based on (evaluated) business rules to match
information content and business processes
– Improves business agility by dynamically reconfiguring information
distribution patterns without reprogramming end-point applications
– Access control to securely deliver personalized information to the
right place at the right time

120
So what is WMB ?
– WebSphere Message Broker is a powerful information broker that
allows both business data and information, in the form of messages, to
flow between disparate applications and across multiple hardware and
software platforms.
– Business rules can be applied to the data that is flowing through the
message broker in order to route, store, retrieve, and transform the
information.
– With WebSphere Message Broker, organizations of any size can
eliminate point-to-point connections and batch processing in order to
increase business flexibility and smart interoperability of systems
regardless of platform, protocol or data format.

121
So what is WMB ?
Built for universal connectivity and transformation in
heterogeneous IT environments
Range of EAI
patterns
Multiple platforms
High volume
processing
Extensive
transformations of data
formats
Standard protocols
Built on WebSphere
MQ

122
So what is WMB ? contd…
– Endless integration to virtually any
platform, operating system or device
– Exploits the industry-leading WebSphere
MQ messaging infrastructure
– Easily handles complex messaging
structures delivering extensive
administration and systems management
facilities
– Continued Innovation:
– Over 100 nodes for connectivity, integration,
and transformation
– Starter to full enterprise versions
– Works with the latest implementations of
standards

123
WebSphere Message Broker (contd.)
– WebSphere Message Broker addresses the needs of business
and application integration by managing the flow of information.
– It provides services, based on message brokers, to allow one to:
– Route a message to several destinations, using rules that act on the
contents of one or more of the fields in the message or message
header.
– Transform a message, so that applications using different formats can
exchange messages in their own formats.
– Store a message, or part of a message, in a database.
– Retrieve a message, or part of a message, from a database.
– Modify the contents of a message; for example, by adding data
extracted from a database.

124
WebSphere Message Broker (contd.)
– The benefits of WebSphere Message Broker can be realized
both within and outside an enterprise:
– Processes and applications can be integrated by providing message
and data transformations in a single place, the broker. This helps
reduce the cost of application upgrades and modifications.
– Systems can be extended to reach suppliers and customers by
meeting their interface requirements within the brokers; can help
improve the quality of interactions, allowing expeditious responses to
changing or additional requirements.

125
WMB – Features
 Universal connectivity from anywhere, to anywhere
– Simplify application connectivity for a flexible and dynamic infrastructure
 Comprehensive protocols, transports, data formats and processing
– Connect to applications, services, systems and devices:
– MQ, JMS, HTTP(S), SOAP, REST, file (including FTP, FTE, ConnectDirect),
database, TCP/IP, MQTT, CICS, IMS, SAP, SEBL, .NET, PeopleSoft,
JDEdwards, SCA, CORBA, email and more!
– Understands the broadest range of data formats:
– Binary (C/COBOL), XML, CSV, DFDL, JSON, industry (SWIFT, EDI, HL7 etc),
IDOCs, user-defined
– Built-in suite of request processors:
– Route, filter, transform, enrich, monitor, publish, decompose, sequence,
correlate, detect…
 Extensive management, performance and scalability
– Extensive administration and systems management facilities for developed solutions
– Wide range of operating system and hardware platforms including virtual and cloud
– High performance transactional processing, additional vertical & horizontal
scalability
– Deployment options include Trial, Express, Standard and Advanced

126
Quick Tour
– IBM WebSphere Message Broker - Version 7
– http://www-01.ibm.com/software/integration/wbimessagebroker/v7-
video.html
– Quick tour: WMB 6.1
– http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etools.mft.
quicktour.doc/doc/quick_tour.htm
– Quick tour: WMB 7.x
quicktour.doc/doc/quick_tour.html
– Quick tour: WMB 8.x
quicktour.doc/doc/quick_tour.html
quicktour.doc/doc/WMB_BusinessNeeds/tour.html

127
Documentation
– Documentation ( WMB and MQ )
– http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/index.jsp
– http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp
– Technical Resources
– http://www-1.ibm.com/software/integration/wbimessagebroker/library/
– http://www.redbooks.ibm.com/abstracts/sg247826.html?Open
– http://www.ibm.com/developerworks/websphere/library/techarticles/0912_lucas/09
12_lucas.html

128
WebSphere Message Broker – Platform Support
– AIX®
– HP-Itanium
– HP-UX on PA-RISC
– Linux on POWER®
– Linux on x86
– Linux on x86-64
– Linux on System z
– Solaris on SPARC
– Solaris on x86-64
– Windows 32-bit
– z/OS4
Always check the WebSphere Message Broker site for the latest updates
http://www-306.ibm.com/software/integration/wbimessagebroker/

129
WMB – Database Support
– DB2
– Informix
– Microsoft SQL Server
– Oracle
– Sybase

130
Comprehensive protocols, transports, data formats
and processing
– Connect to applications, services, systems and devices:
– MQ, JMS, HTTP(S), SOAP, REST, file (including FTP, FTE,
ConnectDirect), database, TCP/IP, MQTT, CICS, IMS, SAP, SEBL,
.NET, PeopleSoft, JDEdwards, SCA, CORBA, email and more!
– Understands the broadest range of data formats:
– Binary (C/COBOL), XML, CSV, DFDL, JSON, industry (SWIFT, EDI, HL7
etc), IDOCs, user-defined
– Built-in suite of request processors:
– Route, filter, transform, enrich, monitor, publish, decompose, sequence,
correlate, detect…
– Universal connectivity from anywhere, to anywhere
– Simplify application connectivity for a flexible and dynamic infrastructure

131
Comprehensive protocols, transports, data formats
and processing – Contd…
WebSphere MQ Multicast
(Reliable Multicast Messaging (RMM))
(Very low latency for LANs)
WebSphere MQ Real-time
(Very low latency over WANs, and the
Internet)
WebSphere MQ Telemetry
(RFID, sensors & actuators)
WebSphere MQ Everyplace
(Mobile device applications)
WebSphere MQ (+ File Transfer Edition)
(Enterprise applications (+ managed file transfer))
Any 3rd-party JMS
(TIBCO EMS, Sonic MQ, BEA JMS, webMethods,
See Beyond, Vitria)
HTTP and HTTP(S)
TCP/IP Sockets
FTP and File
TIBCO Rendezvous
(plug-in component)
SMTP
IBM Protocols Industry and Vendor Protocols
Enterprise Applications
SAP
Oracle Siebel
JDEdwards
Peoplesoft
CICS
Custom

132
WMB Business Scenario (self study)
– WMB manages the flow of information in your business, applying
business rules to route, store, retrieve, and transform the
information as required by the different systems in your business
and the systems of your customers, suppliers, partners, and
service providers.
– Mergers and acquisitions scenario

133
Mergers and Acquisitions Scenario –
The Background
– Company A is a motor and general insurance company that has
been in business for approximately 50 years and currently has
approximately 5 million policyholders.
– The company uses agents and a call center to communicate with
customers. The company has a large legacy IT infrastructure,
which includes CICS® Transaction Server on z/OS® and IBM®
DB2® Universal Database™ on z/OS.
– Company B is small Internet-based motor insurance company,
which currently has less than one million policyholders, and is
expanding.
– The company's IT infrastructure includes WebSphere Application
Server on Windows® 2003, and Oracle Enterprise and IBM DB2
Universal Database on Windows XP.

134
The Problem
– Company A acquired Company B to gain access to the Internet-
based insurance market and to use Company B's Internet-based
skills and IT infrastructure.
– The two companies have customer and policy data of different
formats but, for legal reasons, the data from the separate
companies cannot be merged.
– However, the administration costs of managing the separate IT
infrastructures are high. Also, customers, agents, and call center
staff need a single administration process to interact with the
company's data.

135
The Solution
– As the two companies have merged:
– users can request an insurance quotation
by giving some basic personal information
in a form on the new company's Web site.
– WebSphere Application Server, on which
the Web site runs, forwards the request in
XML format to WebSphere Message Broker
using the request queue in a WebSphere
MQ cluster.
– WebSphere Message Broker transforms
the XML request to the COMMAREA format
that is used by Company A's systems, then
routes the request to Company A's
systems.
– WebSphere Message Broker also routes
the request, in XML format, to Company B's
systems. Both systems return a quotation to
WebSphere Message Broker.

136
WebSphere Message Broker – Architecture

137
WebSphere Message Broker – Architecture

138
WMB – Capabilities
– Applications have much greater flexibility in selecting which
messages they want to receive, because they can specify a topic
filter, or a content-based filter, or both, to control the messages that
are made available to them.
– Diverse applications can exchange information in dissimilar forms,
with Message Brokers handling the processing required for the
information to arrive in the right place in the correct format, according
to the rules that you have defined. The applications do not need to
know anything except their own conventions and requirements.
– The Message Broker provides a framework that supports supplied
basic functions along with user-defined enhancements, to enable
rapid construction and modification of business processing rules that
are applied to messages in the system

139
WMB – Capabilities (contd.)
– The primary capabilities of WebSphere Message Broker are
• Message Routing
• Message Transformation
• Message Enrichment
• Publish/Subscribe
• Database Access
• Web Services Support
• Aggregation
• Augmentation
– Together these capabilities make WebSphere Message Broker a
powerful tool for Business Integration

140
– WebSphere Message Broker processes messages in two ways:
message routing and message transformation.
– Message Routing
– Message Transformation
Receive Message
Filter
Message
Lookup
Mechanism
Set
Destination
Route to
Destination

141
– Message Routing
– Messages can be routed from sender to recipient based on the
content of the message.
– The message flows that you design control message routing.
– A message flow describes the operations to be performed on the
incoming message, and the sequence in which they are carried out.
– Each message flow consists of the following parts:
– A series of steps used to process a message.
– Connections between the nodes, defining routes through the processing.
– The routing can be simple point-to-point routing or it can be based on
matching the content of the message to business rules defined to the
broker.
– WebSphere Message Broker is built upon WebSphere MQ

142
– Message Routing (contd..)
– IBM supplies built-in nodes and samples for many common functions.
– You create message flows in the Message Broker Toolkit which is an
integrated development environment and broker domain administration
console, and is known as the workbench.
142
[Customer, Order,
Quantity, Price, Date]
Fred Smith,
Graphics Card,
32, 1.50,
07/11/06
A B
<order>
<name>Mr. Smith</name>
<item>Graphics Card</item>
<quantity>32</quantity>
<price>1.05</price>
<date>11/07/06</date>
</order>
C

143
Creating an Application Integrator
 Join Applications &
Information sources
 Heterogeneous &
decoupled
 Data validate
 Data routing
 Data transform
(reshape, reformat)
 DBMS Integration
 Transactional
 Stateless
 Simple
 Extensible
 Standards Based
 Transformation (Reshape, Reformat)
 Business Rules
 Intelligent Routing, Publish / Subscribe
 Multiple Protocols in and out.

144
• Examine the content of a message
• Transform the content
Message Broker
Input
Node
Appl.
A
Q1
Original
Message
Appl.
B
Q2
Reformatted
/ Reshaped
Message
Content accessed
from database
Database
Content
+
Output
Nodes
Augment message
Appl.
C
Q3
Augmented
Message
Transformation
Node
Transform message
Transform
Database
Node
Augment
Warehouse
Node
Warehoused
Message
Warehouse
Message Broker -Transforms messages ‘in flight’
– Delivers messages to the right place and in the right format.
– Examine the content of a message
– Transform the content
– Augment the message
– Warehouses the message and assure Transactional delivery.

145
– Messages can be transformed before being delivered
– Messages can be transformed between applications to use different
formats, for example, transforming from a custom format in a legacy
system to XML messages that can be used with a Web service.
– Messages can also be transformed and enriched by integration with
multiple sources of data such as databases, applications, and files
– For the messages that flow through the broker, business information
can be stored in databases or can be extracted from databases and
files and added to the message for processing in the target
applications.
– Complex manipulation of message data can be performed using the
facilities provided in the Message Brokers Toolkit, such as ESQL and
Java.

146
– Message Transformation and Enrichment (contd.)
– Can also be transformed by modifying, combining, adding, or
removing data fields, perhaps involving the use of information stored
in a database.
– Information can be mapped between messages and databases. More
complex manipulation of message data can be achieved by writing
code, for example in Extended SQL (ESQL) or Java, within
configurable nodes.
– Transformations can be made by various nodes in a message flow.
– Before a message flow node can operate on an incoming message, it
must understand the structure of that message.
– Some messages contain a definition of their own structure and
format. These messages are known as self-defining messages, which
you can handle without the need for additional
information about structure and format.

147
– Message Transformation and Enrichment (contd.)
– Other messages do not contain information about their structure and
format. To process them, you must create a definition of their
structure.
– The message definitions that you design are created within a
message set which contains one or more message definitions.
– Message sets also categorize message definitions.

148
– Message Broker has several transformation options including:
– Mapping
– XSLT
– ESQL
– Java
– PHP
– .NET
– Every transformation option has strengths and weaknesses !!!
– Performance and scalability
– Backend integration
– Skill sets and learning curve
– Developer usability
– Portability and maintenance
– Use a transformation technology appropriate to the problem at hand!

149
149
<order>
<name>
<first>John</first>
<last>Smith</last>
</name>
<item>Graphics Card</item>
<quantity>32</quantity>
<price>200</price>
<date>07/11/08</date>
</order>
John,Smith,Graphics Card,
32,200,07/11/08
John Smith............
Graphics Card.........
3220020071108.........
Order
Name Item Qty Price Date
First Last
String String
String Integer Integer Date
Physical Logical
XML
Custom
CSV
Same logical tree
regardless of formats
making it easy to add
new formats

150
Message Set
C Header
XML
Schema
COBOL
Copybook
WSDL
DTD
File Import
Enterprise
Information
System
(SAP, Siebel,
PeopleSoft)
Pre-built
SOAP, MIME, CSV,
IDOC, SWIFT,
EDIFACT, X12, FIX,
HL7,
etc
Define
your own
using the
Eclipse-based
Tooling
Parsers
Message Broker
WebSphere
Transformation
Extender
Type tree

151
– The conversion of one message format into another
 Graphical, easy to
use
 Drag and Drop
fields, apply
functions
 Convert XML to
anything
 Uses standard XSL
Style sheets
 Describe powerful
transformations
quickly
 Uses SQL-based
language (ESQL)
 Uses Java
programming
language
 Ability to use XPath
 Run a WebSphere
Transformation
Extender map

152
– Examples of Message Addressing
152
public class jcn extends MbJavaComputeNode {
public void evaluate(MbMessageAssembly assembly) throws MbException {
...
String lastName =
(String)assembly.getMessage().evaluateXPath(“/Body/Order/Name/Last”);
...
}
}
IF Body.Order.Date < ‘2008/01/01’ THEN
INSERT INTO Database.OldOrders (LastName,Item,Quantity)
VALUES (Body.Order.Name.Last,
Body.Order.Item,
Body.Order.Quantity);
ENDIF;

153
How Do We Connect Applications?
Protocols
Message Formats
Mediation Patterns
Applications need to talk with each
other over a communications protocol.
e.g. MQ, TCP/IP, HTTP, File system,
FTP, SMTP etc.
Applications need to exchange data,
with specific formats
e.g. Binary (C/COBOL), XML, Industry
(SWIFT, EDI, HL7), User-defined
Mediation patterns allow applications to
interoperate. e.g. Route, Transform,
Enrich, Filter, Monitor, Distribute,

154
Enterprise Messaging
– Messaging Transmission

155
Message Brokering
– Message Broker offers various kinds of processing nodes:
– Receive and Route messages.
– Transform a message to an alternative representation
– Select a message for further processing based upon the content.
– Interact with an external database to augment a message or store the
whole part of a message.
– Respond to events and errors.
AppA
App C
QM C
QM A
QM B
comma
separated
COBOL
XML
App B
(MQ)
Input
Filter
(MQ)
Output
(MQ)
Output
Compute
Compute
xml
CWF
QM BRK1
Message Broker
Message
Flow

156
Publish and Subscribe
– The simplest way of routing messages is to use point-to-point
messaging to send messages directly from one application to
another.
– Publish/subscribe provides an alternative style of messaging in
which messages are sent to all applications that have subscribed
to a particular topic.
– The broker handles the distribution of messages between
publishing applications and subscribing applications.

157
Publish and Subscribe (contd.)
– Information Delivery Models
– The publish / subscribe model can be used in different ways.
– The number of publishers might be small, and the number of subscribers
might be large.
– An example of this might be a large sporting event, where a large number of
individuals want to receive information about a small number of events.
– The number of publishers might be large, with a small number of subscribers.
– An example of this might be an internet ordering system, where a large number of
clients place orders, but the subscriber is a single instance of the order application.

158
Publish Subscribe Implementation – Contd..

159
Publish Subscribe Implementation – Contd..

160
Publish Subscribe Implementation – Example 1
Bus and Train Schedules
Publisher 1
Bus Schedules
Publisher 2
Train Schedules
Subscriber 1
Train Schedules
Subscriber 2
Train and Bus
Schedules
Broker
Schedules are
published to the
broker
Published information
is subscribed to and
then received by the
subscribers

161
Publish Subscribe Implementation – Example 2
Bus, Train, Plane Schedules
Publisher 1
Bus Schedules
Publisher 2
Train Schedules
Subscriber 1
Train and Plane
Schedules
Subscriber 2
Bus
Schedules
Broker 1
Publisher 3
Plane
Schedules
Subscriber 3
All Schedules
Broker 2

162
Publish Subscribe – Other Examples
– Magazine publishing
– Airline departure notification

163
WebSphere MQ Interoperability
– Single Administrative explorer
for WebSphere Message
Broker and WebSphere MQ
Operations and security.
– Publish /Subscribe topology
defined with WebSphere MQ
v7 facilities.
– Support and exploitation of
WebSphere MQ Multiple
Instance Queue Managers for
high availability.

164
WebSphere MQ Interoperability contd…

165
WMB – Components Overview

166
WMB – Components Overview (contd.)
Development Environment
– For the creation of message flows, message sets, and other
message flow application resources
Runtime Environment
– Contains the components for running those message flow
applications that are created in the development environment

167
Development Environment
– The development environment is where the message flow
applications that provide the logic to the broker are developed.
– The broker uses the logic in the message flow applications to
process messages from business applications at run time.
– In the Message Brokers Toolkit, you can develop both message
flows and message sets for message flow applications.
– Development Environment comprises of the following
components
• Message Flows
• Message Sets
• Broker Application Perspective

168
Development Environment (contd.)
Message Flows
– The development environment is where the message flow
applications that provide the logic to the broker are developed.
– The broker uses the logic in the message flow applications to
process messages from business applications at run time.
– A choice of methods is available for defining the logic in the
message flows to transform data. (See Message Transformations on pg.: 103)
• Extended Structured Query Language (ESQL)
• Java
• eXtensible Style sheet Language for Transformations (XSLT)
• Drag-and-drop mappings
– The nodes in the message flows define the source and the target
transports of the message, any transformations and
manipulations based on the business data, and any interactions
with other systems such as databases and files.

170
Message Flow (contd.)
– Message flows are transactional
– Provides vital processing and data manipulation
– Completes all or none of its processing successfully.
– Message flows are multithreaded
– Message passing through a series of nodes will execute on a single
thread.
– To allow message flows can be defined with many additional
threads assigned to them to increased message throughput.
– Peak workloads use additional threads, which are pooled during inactivity.
– Message flow nesting and chaining allow construction of enhanced
capabilities.
– Sophisticated flows can be rapidly constructed by linking individual flows
together as well as nesting flows within each other.

171
Sample Message Flow (contd.)
– Pre-defined sequence of operations
– Typically one input message processed per Message Flow instance
– Multiple alternative paths possible.
– Routes to 1—n resources and runs sequence of operations

172
Message Flow Example
– For more information Message Nodes
A message flow contains the set of
operations required to take a message
from an originating application and
deliver copies of it, some possibly
transformed, to any number of
connected applications for processing.
Output targetTransform
Input source Output target
Output target
(Failure)
 Reusable
 Scalable
 Transactional

173
Message Flow Scenario – Example
Routing decision
is made based on
a field described
in the incoming
message
Message is routed to the ‘Generate batch
file’ node, which formats the message for
subsequent output to a file in the ‘Write
file’ node.
Message Flows
Provides the processing sequence
Required to connect
applications together
Nodes
Performs a different
(input, output or processing) action

174
Message Flow Error Behavior - Summary
Transactional?N
Y
MQMD.BackoutCount >
Queue BOTHRESH
N
Y
2.
BackoutQ
3.
DeadLetterQ
local FAIL path
insert
rollback to inputQ
inputQ
Input node's CATCH path
TryCatch node's CATCH path
Local error log
ExceptionList
Root & LocalEnvironmentreset
Get Msg (retry)
1
2
5
6
4
3
1. Input node's
FAIL path
BackoutCount >
2 * BOTHRESHY
N

175
Message Sets
– A message set is a definition of the structure of the messages
that are processed by the message flows in the broker.
– In order for a message flow to be able to manipulate or transform
a message, the broker must know the structure of the message.
– The definition of a message can be used to verify message
structure, and to assist with the construction of message flows
and mappings in the Message Brokers Toolkit.

176
Broker Application Development perspective
– The Broker Application Development perspective is the part of
the Message Brokers Toolkit that is used to design and develop
message flows and message sets. It contains editors that create
message flows, create transformation code such as ESQL, and
define messages.

177
Broker Application Development Perspective
Toolkit Help
Quick Starts Wizard
Appear in the
Project pane, when
workspace is empty.
Perspectives

178
Broker Application Development Perspective (contd.)
Projects
Brokers
Properties
Problems
Deployment Log
Node Palette

179
Runtime Environment
– The runtime environment is the set of components that are
required to deploy and run message flow applications in the
broker.
– Runtime Environment comprises of below components:
• Broker
• Execution Groups
• Configuration Manager
• Broker Domain
• User Name Server
• Broker Administration perspective

180
Runtime Environment (contd.)
Broker
– A broker is a set of execution processes that hosts one or more
message flows to route, transform, and enrich in flight messages.
– When a message arrives at the broker from a business
application, the broker processes the message before passing it
on to one or more other business applications.
– The broker routes, transforms, and manipulates messages
according to the logic that is defined in their message flow
applications.
– A broker uses WebSphere MQ as the transport mechanism both
to communicate with the Configuration Manager, from which it
receives configuration information, and to communicate with any
other brokers to which it is associated.
– Each broker has a database in which it stores the information
that it needs to process messages at run time.

181
– When you create a broker, the following resources are also
defined and created:
• A WebSphere MQ queue manager, if one does not exist.
• A set of fixed-name queues that are defined to the WebSphere
MQ queue manager.

182
Execution Groups
– An execution group is a named grouping of message flows that
have been assigned to a broker.
– The broker enforces a degree of isolation between message
flows in distinct execution groups by ensuring that they run in
separate address spaces, or as unique processes.
– Execution groups enable message flows within the broker to be
grouped together.
– Each broker contains a default execution group.

183
Execution Groups – Contd…
– Additional Execution Groups can be created as long as they are
given UNIQUE names within the Broker.
– Each execution group is a separate operating system process
and, therefore, the contents of an execution group remain
separate from the contents of other execution groups within the
same broker.
– Message flow applications are deployed to a specific execution
group.
– To enhance performance, the same message flows and
message sets can be running in different execution groups.

184
Configuration Manager
– The Configuration Manager is the interface between the
Message Brokers Toolkit and the brokers in the broker domain.
– It Stores configuration details for the broker domain in an
repository, providing a central store for resources in the broker
domain..
– When the Message Brokers Toolkit connects to the Configuration
Manager, the status of the brokers in the domain is derived from
the configuration information stored in the Configuration
Manager’s repository.

185
Configuration Manager (contd.)
– The Configuration Manager has four main functions:
– Records configuration details
– Deploys the broker topology and message processing operations to
the Broker component
– Provides status of the broker domain
– Communicates with other components in the broker domain.

186
Configuration Manager (contd.)
– Each broker domain must have a unique Configuration Manager.
– The Configuration Manager runtime component uses the
following resources (created when the Configuration Manager is
created):
– An repository.
– A WebSphere MQ queue manager
– may use an existing queue manager
– must be on the same physical system as the Configuration Manager
– A set of fixed-name queues, defined to the queue manager that hosts
the Configuration Manager.

187
Broker Domain
– Brokers are grouped together in broker domains.
– The brokers in a single broker domain share a common
configuration that is defined in the Configuration Manager.
– A broker domain contains one or more brokers and a single
Configuration Manager. It can also contain a User Name Server.
– The components in a broker domain can exist on multiple
machines and operating systems, and are connected together
with WebSphere MQ channels.
– A broker belongs to only one broker domain.

188
User Name Server
– A User Name Server is an optional component that is required
only when publish/subscribe message flow applications are
running, and where extra security is required for applications to
be able to publish or subscribe to topics.
– The User Name Server provides authentication for topic-level
security for users and groups that are performing
publish/subscribe operations.
– User Name Server requires
– A WebSphere MQ queue manager.
– A set of fixed-name queues, defined to the WebSphere MQ queue
manager that hosts the User Name Server.

189
Broker Administration Perspective
– The Broker Administration perspective is the part of the Message
Brokers Toolkit that is used for the administration of any broker
domains that are defined to the Message Brokers Toolkit.
– This perspective is also used for the deployment of message
flows and message sets to brokers in the defined broker
domains.
– Contains tools for creating message broker archive (bar) files.
– Bar files are used to deploy message flow application resources
such as message flows and message sets.
– Contains tools to help test message flows.
• These tools include Enqueue and Dequeue for putting and
getting messages from WebSphere MQ queues.

190
WMB – Components revisited
Controller Administrative
Agent
"Root
"
Repor
t
"Body
"
"Root
"
Repor
t
"Body
"
"Root
"
Repor
t
"Body
"
"Root
"
Repor
t
"Body
"
"Root
"
Repo
rt
"Bod
y"
"Root
"
Repo
rt
"Bod
y"
Execution Groups
Message
Flows
Dictionaries
(Msg Sets)
Broker
App.
App. App.
App.
Message
Brokers
Toolkit
Config.
Manager
User Name
Server
Application Development:
Message Flows and
Message Definitions
Broker
Administration
Repository
Broker
Domain

191
Interaction of Message Broker Main Components

192
Interaction of Message Broker Main Components

193
WebSphere Message Broker runtime architecture

194
Usage Patterns with Message Broker
Service Enablement
Service Virtualization
OR
OR
OR
Message Enablement
Message Brokering
File Processing
Event Processing

Introduction to IBM WebSphere MQ Explorer

197
Agenda
– Introduction
– Capabilities
– Broker Properties
– Message Flow Properties
– Message Flow Revisited
– Predefined and self-defining messages
– Why Model Messages?
– Message Model
– Modeling Messages – Advantages
– Message Broker Parsers
– Message Processing Nodes
– Message Tree
– How the Message Tree is populated?

198
Agenda contd…
– Logical Tree Structure
– Message tree structure
– Environment tree structure
– Local environment tree structure
– Exception list tree structure
– Logical Tree Structure Examples
– Message Flow Editor

199
WebSphere MQ Explorer
– The Message Broker Explorer displays information about the
broker environment, information about the defined execution
groups, and information about the deployed applications..

200
WebSphere MQ Explorer – Capabilities
– Create, delete, start, and stop local brokers without using the
command line.
– Show the relationships between the brokers and queue
managers.
– Deploy a broker archive file to multiple execution groups in one
step.
– Visualize a brokers accounting and statistics data.
– Configure broker properties, including creating and modifying
services for broker communication with external services, such
as SMTP, JMS providers, and adapters.
– View the broker administration queue and remove pending tasks
that were submitted to the broker.
– View the Administration Log showing all activity that occurred on
a given broker.

203
Message Flow – Revisited
– A message flow is a sequence of processing steps that run in
the broker when an input message is received.
– You define a message flow in the workbench by including a
number of message flow nodes, each of which represents a set
of actions that define a processing step.
– The connections in the flow determine which processing steps
are carried out, in which order, and under which conditions.
– A message flow must include an input node that provides the
source of the messages that are processed. You must then
deploy the message flow to a broker for execution.
– When you want to exchange messages between multiple
applications, you might find that the applications do not
understand or expect messages in exactly the same format.

204
– You might need to provide some processing between the
sending and receiving applications that ensures that both can
continue to work unchanged, but can exchange messages
successfully.
– You define the processing that is required when you create and
configure a message flow.
– The way that you do this determines what actions are performed
on a message when it is received, and the order in which the
actions are completed.
– You can create a message flow using the built-in nodes, nodes
that you or a vendor have created (user-defined nodes), or other
message flows (known as subflows).
– When you want to invoke a message flow to process messages,
you deploy it to a broker, where it is executed within an
execution group.

205
– Subflows are simply message flows that are invoked from
another flow
– Input and output nodes in the subflow become terminals in the main flow
– Use subflows to break up large problems into smaller more manageable chunks
– Subflows are directly deployable to the Message Broker runtime
– Shared subflows deployed just once per execution group (or application)
– No need to redeploy message flows after changes to shared routines are made
– Redeployment of a subflow is automatically picked up by any consumers

206
Predefined and self-defining messages
– Each message that flows through a broker has a specific
structure that is meaningful to the applications that send or
receive that message.
– Predefined messages
– When you create a message in the WebSphere Message Broker
Toolkit, you define the fields (Elements) in the message, along with
special field types that you might need, and specific values (Value
Constraints) to which the fields might be restricted.
– When you deploy a message set to a broker, the message model is
sent to the broker in a form appropriate to the parser that is used to
parse and write the message.
– Self-defining messages
– You can create and route messages that are self-defining. The best
example of a self-defining message is an XML document.
– You can also model self-defining messages in the WebSphere
Message Broker Toolkit. However, you do not need to deploy these
message sets to the brokers that support those message flows.

207
Predefined and self-defining messages
– You can use:
– Messages that you have modeled in the Broker Application
Development perspective of the WebSphere® Message Broker
Toolkit; these messages are referred to as predefined messages.
– A model-driven parser requires predefined messages.
– Messages that can be parsed without a model; these are called self-
defining messages.

208
Why Model Messages ?
– WebSphere® Message Broker supplies a range of parsers to
parse and write message formats.
– Some message formats are self-defining and can be parsed
without reference to a model.
– However, most message formats are not self-defining, and a
parser must have access to a predefined model that describes
the message, if it is to parse the message correctly.
– An example of a self-defining message format is XML.
– In XML, the message itself contains metadata in addition to data
values, and it is this metadata that enables an XML parser to
understand an XML message even if no model is available.

209
Message Model
Physical message format
("wire format")
Logical message format
Parsed
Constructed
"Root"
MQMD
Format
Report
Version
"Body"
Order
Name
Supplier
Order #
Address
Item
Physical message format
("wire format")
Parsed
Constructed
"Root"
MQMD
Format
Report
Version
"Body"
Order
Name
Supplier
Order #
Address
Item
Parsed
Constructed
"Root"
MQMD
Format
Report
Version
"Body"
Order
Name
Supplier
Order #
Address
Item
MQMD
Order
Supplier
Item
Message
Repository Manager
(MRM)
NEON
self-defining
undefined
predefined

210
Message Model (contd.)
– Models are needed for parsing, validation and transformation
– Domains avoid the need to write custom code to parse messages!

211
Modeling Messages – Advantages
– Examples of messages that do not have a self-defining message
format are CSV text messages, binary messages that originate
from a COBOL program, and SWIFT formatted text messages.
– None of these message formats contain sufficient information to
enable a parser to fully understand the message.
– In these cases, a model is required to describe them.
– Even if your messages are self-defining, and do not require
modeling, message modeling has the following advantages:
– Runtime validation of messages. Without a message model, a parser
cannot check whether input and output messages have the correct
structure and data values.
– Enhanced parsing of XML messages. Although XML is self-defining,
all data values are treated as strings if a message model is not used.
If a message model is used, the parser is provided with the data type
of data values, and can cast the data accordingly.

212
Modeling Messages – Advantages
– Improved productivity when writing ESQL. When you are creating
ESQL programs for WebSphere Message Broker message flows, the
ESQL editor can use message models to provide code completion
assistance.
– Drag-and-drop operations on message maps. When you are creating
message maps for WebSphere Message Broker message flows, the
Message Mapping editor uses the message model to populate its
source and target views. Without message models, you cannot use
the Message Mapping editor.
– Reuse of message models, in whole or in part, by creating additional
messages that are based on existing messages.
– Generation of documentation.
– Provision of version control and access control for message models
by storing them in a central repository.
– To make full use of the facilities that are offered by WebSphere
Message Broker, model your message formats.

213
Message Broker Parsers
– A parser is a program that interprets the physical bit stream of
an incoming message, and creates an logical representation of
the message in a tree structure.
– The parser also regenerates a bit stream for an outgoing
message from the message tree representation.
– A parser is called when the bit stream that represents an input
message is converted to the form that can be handled by the
broker; this invocation of the parser is known as parsing.
– The form, a logical tree structure, is described in Logical tree
structure section.
– The way in which the parser interprets the bit stream is unique to
that parser; therefore, the logical message tree that is created
from the bit stream varies from parser to parser.

214
Message Broker Parsers – Contd…
– The parser that is called depends on the structure of a message,
referred to as the Message Template.
– Message template information comprises:
– Message domain
– Message set
– Message type
– physical format of the message.
– Together, these values identify the structure of the data that the
message contains.
– The broker requires access to a parser for every message
domain to which your input messages and output messages
belong. Parsers are called when required by the message flow.

215
– WebSphere® Message Broker provides built-in support for
messages in the following message domains by providing
message body parsers:
MRM
IDOC
This is an example text. Go ahead and replace it
JMSMap and JMSStream
XMLNSC, XMLNS, XML
DataObject
BLOB
1
2
3
4
5
6
7
SOAP
8 JSON
9 DFDL

216
– Some Body Parsers are model driven, which means that they
use predefined messages from a message set when parsing and
writing.
– The MRM, SOAP, DataObject, IDOC, and (optionally) XMLNSC
parsers are model-driven parsers.
– To use these parsers, messages must be modeled in a message set
and deployed to the broker from the WebSphere Message Broker
Toolkit.
– Other body parsers are programmatic, which means that the
messages that they parse and write are self-defining messages,
and no message set is required.
– When you use a model-driven parser, you must also specify the
Message Set and, optionally, the Message Type and Message
Format so that the parser can locate the deployed message
definition with which to guide the parsing or writing of the
message.

217
…draCscihparG,htimSderF
Input Message Bit-stream
…n/<htimS.rM>eman<>redro<
Output Message Bit-streamOutput Message Bit-stream
Parser converts
bit-stream to
logical structure
Model
Parser converts
logical structure
to bit-stream
Model

218
– On input, the broker
receives a message
bitstream and parses it into
a logical message tree
– On output, the broker
serializes a message tree
into a message bitstream.
– The parser and serializer
understand the structure of
the message because it
has been modeled by the
user in a message set.
<Person age=’32’ height=‘172’>
<Name>Joe Bloggs</Name>
</Person>
struct {
int height;
int age;
char Name[48];
} Person;
172 32 Joe Bloggs

219
Message Processing Nodes
DataInsert
IF Body.Person.height > 183 THEN
INSERT INTO Database.TallPeople
(Name,Height,Age)
VALUES (Body.Person.Name,
Body.Person.height,
Body.Person.age);
ENDIF;
Compute
IF (XML format required) THEN
OutputRoot.Properties.MessageFormat = 'XML';
ELSE IF (custom format)
OutputRoot.Properties.MessageFormat = 'CWF';
ELSE IF (SWIFT format)
OutputRoot.Properties.MessageFormat = 'TDS';
ENDIF;
Java
Compute
public class jcn extends MbJavaComputeNode {
public void evaluate(MbMessageAssembly assembly)
throws MbException
{
…
String personAge =
(String)assembly.getMessage().evaluateXPath(“/Body/Person/Age”);
…
}

220
Message Tree
– A message tree is a structure that is created, either by one or
more parsers when an input message bit stream is received by a
message flow, or by the action of a message flow node.
– A message is used to describe:
– A set of business data that is exchanged by applications
– A set of elements that are arranged in a predefined structure
– A structured sequence of bytes
– WebSphere Message Broker routes and manipulates messages
after converting them into a logical tree. This process of
conversion is called parsing.
– Parsing makes it understandable content and structure of a
message, and simplifies later operations.
– After a message has been parsed, it can be processed in a
message flow.

221
How the Message Tree is populated ?
– The message tree is initially populated by the input node of the
message flow.
– When the input node receives the input message, it creates and
completes the Properties tree (the first subtree of the message
tree).

222
Logical Tree Structure
– The logical tree structure is the (broker) representation of a
message. It is also known as the message assembly.
– When a message arrives at a broker, it is received by an input
node that you have configured in a message flow.
– Before the message can be processed by the message flow, the
message must be interpreted by one or more parsers that create
a logical tree representation from the bit stream of the message
data.
– The tree format contains identical content to the bit stream from
which it is created, but it is easier to manipulate in the message
flow.

223
MessageFormat = Physical format layer ID
Msd = 'MRM ' = 'BLOB'
Fmt = Physical format layer ID
Root
Properties
MQMD
MQRFH2
XMLNSC
MessageSet = MessageSet-ID
MessageType = MessageID
ReplyToQ
Format ='MQHRF2 '
mcd
Set = MessageSet-ID
Type = MessageID
Message
Name
Version
Complaint
Type
MRM BLOB
(Body)
Name
Version
Complaint
Type

224
Logical Tree Structure - Example
Root
Properties
MQMD
MRM
HomeAddress
Line
Zip
Country
WorkAddress
Line
Zip
Country
MessageType AddressesMsg
My_SetMessageSet
01 AddressesMsg.
10 HomeAddress.
20 Line PIC X(20) OCCURS 2 TIMES.
20 Country PIC X(2).
20 Zip PIC X(10).
10 WorkAddress.
20 Line PIC X(20) OCCURS 2 TIMES.
20 Country PIC X(2).
20 Zip PIC X(10).
AddressesMsg
t_AddressesMsg
HomeAddress WorkAddress
t_Address
Line Country Zip
xsd:string
My_AddressesMsg.mxsd
My_Set_Project
messageSet.mset
My_Set

225
– The input node creates this message assembly, which consists
of four trees
– Message tree structure
– Environment tree structure
– Local environment tree structure
– Exception list tree structure
– The first of these trees is populated with the contents of the input
message bit stream, the remaining three trees are initially empty.
– Each of the four trees created has a root element
– Each tree is made up of a number of discrete pieces of
information called elements.
– The root element has no parent and no siblings
– The root is parent to a number of child elements. Each child
must have a parent, can have zero or more siblings, and can
have zero or more children.

226
Message Tree Structure
– The message tree is a part of the logical message tree in which
the broker stores its representation of the message body.
– The message tree includes all the headers that are present in
the message, in addition to the message body.
– The tree also includes the Properties subtree, if that is created
by the parser.
– If a supplied parser has created the message tree, the element
that represents the Properties subtree is followed by zero or
more headers.
– The last element beneath the root of the message tree is always
the message body.

227
Message Tree Structure contd…
– The message tree is a part of the logical message tree in which
the broker stores its representation of the message body.
– Each element in the parsed tree is one of three types:
• Name element
• Value element
• Name – Value Element

228
Environment Tree Structure
– The environment tree is a part of the logical message tree in
which you can store information while the message passes
through the message flow.
– This tree is always present in the input message
– An empty environment tree is created when a message is
received and parsed by the input node.

229
Environment Tree Structure
– The local environment tree is a part of the logical message tree
in which you can store information while the message flow
processes the message.
– This tree is always present in the input message
– Is created when a message is received by the input node.

230
Exception List Tree Structure
– Message flow writes information about exceptions that occur
when a message is processed.
– The root of the exception list tree is called Exception List
– The tree consists of a set of zero or more exception descriptions.
– The exception list tree is populated by the message flow if an
exception occurs.
– If no exception conditions occur during message flow
processing, the exception list that is associated with that
message consists of a root element only.

231
Exception List Tree Structure contd…
– The following list includes some of the exception types:
• FatalException
• RecoverableException
• ConfigurationException
• SecurityException
• ParserException
• ConversionException
• DatabaseException
• UserException
• CastException
• MessageException
• SqlException
• SocketException
• SocketTimeoutException
• UnknownException

232
Logical Tree Structure – XML Source

233
Corresponding Logical Tree Structure

234
– </Create_Book_Order_MSG>
– <Customer_ID>0123456789</Customer_ID>
– <Order_Date>2002-10-20 12:00:00</Order_Date>
– <Airmail>Yes</Airmail>
– <Book_Details>
– <ISBN>0123456789</ISBN>
– <Book_Price>15.99</Book_Price>
– <ISBN>1425112342</ISBN>
– <ISBN>9736316345</ISBN>
– </Book_Details>
– </Create_Book_Order_MSG>

235

236
– <?xml version=”1.0”?>
– <Book_Order_Response_MSG>
– <Customer_ID>0123456789</Customer_ID>
– <Order_Number>0123456789TIMESTAMP '2002-10-20
– 12:00:00'</Order_Number>
– <Order_Date>2002-10-20T12:00:00-08:00</Order_Date>
– <Airmail>Yes</Airmail>
– <Delivery_Price>8</Delivery_Price>
– <Book_Details>
– <ISBN>0123456789</ISBN>
– <ISBN>1425112342</ISBN>
– <ISBN>9736316345</ISBN>
– </Book_Details>
– <Total_Price>49.97</Total_Price>
– <Order_Status>Order Received</Order_Status>
– </Book_Order_Response_MSG>

237

238
Message Flow Editor
– The graphical Message Flow editor in the Message Brokers
Toolkit enables you to build message flows by clicking one of the
supplied message flow nodes on the node palette (on the left of
the Message Flow editor) and placing it on the canvas

WebSphere Message Broker Software – Components

241
Agenda
– Message Broker Toolkit components
– Message Broker Toolkit – IDE
– Perspectives in Message Broker Toolkit
– Resources in WebSphere Message Broker

242
Message Broker Toolkit components
– WebSphere Message Broker consists of the following components
– WebSphere Message Broker runtime
– WebSphere Message Broker Toolkit
– IBM WebSphere MQ Runtime
– IBM WebSphere MQ Explorer
– Other softwares we use in addition to WMB
– Textpad
– SoapUI

243
Message Broker Toolkit – IDE

244
Perspectives in Message Broker Toolkit
– The following links provide a description of each of the perspectives in
the Message Broker Toolkit
• Broker Administration perspective (< v7 )
– Setting up the broker domain, for example creating collectives
– Creating and removing domain connections.
– Connecting and removing brokers.
– Adding and removing execution groups.
– Creating and deploying broker archive (BAR) files.
– Defining and managing publish/subscribe topic hierarchies.
– Querying, viewing and deleting subscriptions.
– Clearing and filtering deploy event log entries.
– Activating, deactivating, filtering, and clearing alerts.
– Adding, removing, and updating entries in access control lists
(ACLs).
• Broker Application Development perspective
– Develop message sets and message flows.
– Enqueue and Dequeue test and production messages, which is
useful when you are debugging message flows.
• Debug perspective
• Plug-in Development perspective

245
– Broker Administration Perspective ( Available only with versions <v7.0)

246
– Broker Application Development perspective

247
– Debug Perspective

248
Resources in WebSphere Message Broker
– The projects, folders, and files that you work with in the
WebSphere® Message Broker Toolkit workspace are called
resources.
– By default, these resources are stored with their metadata in the
workspace directory in your local file system.
– The workspace directory is created the first time that you start
the WebSphere Message Broker Toolkit.
– The default locations for the workspace are in the following
places:
• On Windows XP and Windows Server 2003, the default
workspace directory is created at C:Documents and
Settingsuser_IDIBMwmbt70workspace

249
Resources in WebSphere Message Broker contd..

250
– Source files
• are included in your workspace and are accessible from the Broker
Application Development perspective. When you create source files,
they are grouped by file type in folders, in the same way as the
directories of a file system.
– .msgflow
• files contain the message nodes and connections that you create to
form a message flow.
• These files are displayed in the Broker Application Development
perspective in a folder called Flows.
• The Flows folder is always created and displayed.
– .esql
• files are optional and contain ESQL code that performs specific
processing steps within a message node.
• You can code ESQL to tailor message processing in Compute,
Database, and Filter nodes.
• If you have created ESQL files, they are displayed in the Broker
Application Development perspective in a folder called ESQLs.

251
– .msgmap
• files are optional and map the relationships between different data
sources (typically database tables and messages) that you have
created by using the graphical mapping tools.
• You can create maps to tailor message processing in DataDelete,
DataInsert, DataUpdate, and Warehouse nodes.
• If you have created mapping files, they are displayed in the Broker
Application Development perspective in a folder called Maps.
– .mxsd
• files are optional and contain definitions of the messages you have
modeled.
• If you have created message models, they are displayed in the
Broker Application Development perspective in a folder called
Message Definitions.

252
– WSDL
• files are optional and contain WSDL definitions which you have
imported into the workspace to use as a source for message
definitions.
• If you have created WSDL files, they are displayed in the Broker
Application Development perspective in a folder called Deployable
WSDL, and are grouped by namespace.
– Helper Files
• Helper files maintain information that supports other activities
• .broker files contain definitions of broker connections.
• .bar files contain deployable and other files that you have chosen to
send to a broker.
• .mbtest files contain the steps that define a test that you use with the
Test Client to debug your applications.

253
– Deployable Files
• Deployable files are included in a broker archive (BAR) file and
deployed to the broker where they are involved in some way in the
processing of messages.
– A BAR file might contain
• A .cmf file for each message flow. This file is a compiled version of
the message flow. You can have any number of these files within
your BAR file.
• A .dictionary file for each message set dictionary. You can have any
number of these files within your BAR file.
• One or more XSD compressed files (.xsdzip), if XML Schema and
WSDL are defined within a message set.

254
– A BAR file might contain
• A broker.xml file. This file is called the broker deployment descriptor.
You can have only one of these files within your BAR file. This file, in
XML format, is contained in the META-INF folder of the compressed
file and can be modified by using a text editor or shell script.
• One or more XML files (.xml), style sheets (.xsl), and XSLT files
(.xlst), if required by nodes in the message flows you have added to
this BAR file.
• One or more JAR files, if required by JavaCompute nodes in the
message flows you have added to this BAR file.
• And so on…
– For More information:
• http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic
/com.ibm.etools.mft.doc/ab00230_.htm

WebSphere Message Broker - Built-in Nodes

257
Agenda
– Message Flow Node Palette
– Node Types
– Message Node Components
– Built-in Nodes
– WebSphere MQ
– WebServices
– HTTP
– Routing
– Transformation
– Construction
– Validation
– WebSphere Information Centre

258
Message Flow Node Palette
– The building blocks of message flows
– WebSphere Message Broker supplies built-in
nodes that you can use to define your message flows.
– The nodes are listed in the categories under which they
are grouped in the node palette.
– Each node type performs a different (input, output
or processing) action
– In the v7 Toolkit approximately 82 Nodes were present.

259
– Built-in nodes encapsulate transports, technologies and applications
– Our intent is always to make the common tasks easy, and the rest
possible!
– Use the built-in nodes to reduce the amount of custom code required
– This makes best use of the built-in facilities like activity trace and
resource statistics
Node Types

260
– Nodes represent both logical end points and processing functions
– User-defined nodes can be written in Java, C/C++ and also as subflows
– Several broad categories of node exist in Message Broker
– Input, output, get and request nodes that manage end points
– Asynchronous variations also exist for more efficient processing
Node Types

261
Message Node Components
Action
input
terminal
input
connector
output
connectorsnode
input
message
tree
output
message
trees
output
terminals
• Nodes represent functional routines encapsulating integration logic
• Terminals represent the various outcomes possible from node processing
• Connectors join the various nodes through their terminals

263
Built-in Nodes (WMB v7) contd…

264
Built-in Nodes
– Various nodes wired together to forms a message flow
– WebSphere® Message Broker supplies built-in nodes that you
can use to define your message flows.
– Each node has its specific task to do in message flow Various
regularly used inbuilt nodes are discussed in following sections
– Depending on functionality, nodes can be roughly categorized in
following groups
– WebSphere MQ
– JMS
– HTTP
– WebServices
– SCA
– WebSphere Adapters
– Routing
– Validation
– Security
– Transformation
– Construction
– Database
– File
– Email
– TCP/IP
– CORBA
– IMS
– Timer
– CICS

265
Built-in Nodes
– For ease, again they have been categorized in to:
– Input Nodes
– Output Nodes
– Nodes for manipulating, enhancing, and transforming messages
– Decision making nodes
– Nodes for controlling time-sensitive operations
– Error handling and reporting nodes
– Other Nodes

266
WebSphere MQ
– The following list of nodes will be covered in this section
– MQInput
– MQOutput
– MQReply
– MQGet
– MQHeader

267
WebSphere MQ – MQInput
– The MQInput node receives a message from a WebSphere MQ message
queue that is defined on the queue manager of the broker.
– The node uses MQGET to read a message from a specified queue, and
establishes the processing environment for the message.
– The MQInput node handles messages in the following message domains:
– DFDL
– XMLNSC
– DataObject
– JSON
– BLOB
– MIME
– MRM
– JMSMap
– JMSStream
– XMLNS

268
WebSphere MQ – MQInput contd..
The output terminal to which the message is routed
if an error occurs. Even if the Validation property is
set, messages propagated to this terminal are not
validated.
if it is successfully retrieved from the
WebSphere MQ queue.
if an exception is thrown downstream
and caught by this node..
Out

269
WebSphere MQ – MQOutput
– MQOutput
– Use an MQOutput node if the target application expects to receive messages on a
WebSphere MQ queue, or on the WebSphere MQ reply-to queue that is specified
in the input message MQMD
– The node uses MQPUT to put the message to the destination queue or queues
that you specify.
– You can configure the MQOutput node to put a message to a specific
WebSphere MQ queue that is defined on any queue manager that is accessible by
the queue manager for the broker, or to the destinations identified in the local
environment that is associated with the message.

270
WebSphere MQ – MQOutput contd..
if an error occurs. Even if the Validation property is
set, messages propagated to this terminal are not
validated.
if it is successfully retrieved from the
WebSphere MQ queue.
The input terminal that accepts
a message for processing
by the node.
In

271
WebSphere MQ – MQReply
– MQReply
– The MQReply node is a specialized form of the MQOutput node that puts the
output message to the WebSphere® MQ queue that is identified by the ReplyToQ
field of the input message header.
– Use an MQReply node if the target application expects to receive messages on the
WebSphere MQ reply-to queue that is specified in the input message MQMD.

272
WebSphere MQ – MQReply contd..
The output terminal to which the message is routed if
a failure is detected when the message is put to the
output queue.
The output terminal to which the message is routed if
it has been successfully put to the output queue, and
if further processing is required in this message flow.
The input terminal that accepts
a message for processing by
the node.
In

273
WebSphere MQ – MQGet
– MQGet
– Use an MQGet node if the messages arrive at the broker on a WebSphere MQ
queue and the node is not to be at the start of a message flow.
– The MQInput node handles messages in the following message domains:
– DFDL
– XMLNSC
– DataObject
– JSON
– BLOB
– MIME
– MRM
– JMSMap
– JMSStream
– XMLNS

274
WebSphere MQ – MQGet contd..
Terminal Description
In
The input terminal that accepts the message that is being
processed by the message flow.
Failure
The output terminal to which the input message is routed if an
error (with a CC that indicates an error that is more severe than a
warning) occurs in the node while trying to get a message from
the queue.
Out
The output terminal to which the message is routed if it is
retrieved successfully from the WebSphere MQ queue.
Warning
The output terminal to which the output tree is propagated if an
error (with a CC that indicates a warning) occurs in the node
while trying to get a message from the queue. The MQMD part of
the message is parsed, but the rest of the message is an
unparsed BLOB element. The warning is discarded if the terminal
is not connected, and there is no output propagation from the
node at all.
No
Message
The output terminal to which the input message is routed if no
message is available on the queue. The output message that is
propagated to the No Message terminal is constructed from the
input message only, according to the values of the Generate
mode, Copy message, and Copy local environment properties.

275
WebSphere MQ – MQHeader
– MQHeader
– Use the MQHeader node to add, modify, or delete MQ Message Descriptor
(MQMD) and MQ Dead Letter Header (MQDLH) headers.
– You can add or remove a whole header, or you can change only certain fields in a
header. You can set these fields to a fixed value, or to a value specified by an
XPath expression to access a value in one of the message trees. XPath is used to
provide a valid location from which a value for a property can be copied. For
example, the location can be the body of the message, the local environment tree,
or an exception list.

276
WebSphere MQ – MQHeader contd..
In
The input terminal that accepts a message for processing by the
node.
Failure
The output terminal to which the input message is routed if a
failure is detected.
Out
The output terminal to which the transformed message is routed
if the input message is processed successfully.

277
WebServices
– SOAPInput node
– SOAPReply node
– SOAPRequest node
– SOAPEnvelope node
– SOAPExtract node

278
WebServices – SOAPInput
– SOAPInput
– Use the SOAPInput node to process client SOAP messages, so that the broker
operates as a SOAP Web Services provider.
– The SOAPInput node is typically used with the SOAPReply node, which can be
included in the same message flow, or a different flow in the same execution
group.
– You can connect a SOAPReply node to the Out terminal to handle successful
responses. If you also want your message flow to handle reply processing after a
timeout, connect a SOAPReply node to the HTTP Timeout terminal.
– The SOAPInput node can be used in a message flow that accepts and processes
SOAP messages. The node is configured using deployable WSDL. Look at the
following sample to see how to use this node:
– A client can send an HTTP GET to the web service endpoint exposed by the
SOAPInput node, suffixed with a query string ?wsdl, and receive a response with
the WSDL definition used to configure the flow;

279
WebServices – SOAPInput contd…
Failure The output terminal to which a SOAP message is routed if a
failure is detected when the message received is propagated to
the Out terminal (such as a message validation failure).
Out The output terminal to which the SOAP message is routed when
it is received successfully and if further processing is required in
this message flow. If no errors occur in the input node, a valid
SOAP message that is received from an external resource is
always sent to the Out terminal first.
HTTPTimeout The output terminal to which a timeout SOAP fault message is
routed if the SOAPReply node that is connected to the Out
terminal does not respond within the time interval specified by
the Maximum client wait time property. This terminal is used only
if the message is sent across the HTTP transport, and WS-RM is
not being used.
Catch The output terminal to which the message is routed if an
exception is thrown downstream and is caught by this node.

280
WebServices – SOAPReply
– SOAPReply
– Use the SOAPReply node to send SOAP messages from the broker to the
originating client in response to a message received by a SOAPInput node.
– The SOAPReply node is typically used with the SOAPInput node, which can be
included in the same message flow, or a different flow in the same execution
group.
– The SOAPReply node can be used in any message flow that needs to send SOAP
messages from the broker to the originating client in response to a message
received by a SOAPInput node. If a SOAPReply node is connected in a message
flow that receives a one-way message, the message propagates to the Failure
terminal of the SOAPReply node, and an exception is raised.

281
WebServices – SOAPReply contd…
In
The input terminal that accepts a message for processing by the
node.
Failure
The output terminal to which the message is routed if a failure is
detected when the message is propagated.
Out
The output terminal to which the message is routed if it has been
propagated successfully, and if further processing is required
within this message flow.

282
WebServices – SOAPRequest
– SOAPRequest
– Use the SOAPRequest node to send a SOAP request to the remote Web service.
– The SOAPRequest node is a synchronous request and response node, which
blocks processing after sending the request until the response is received. This
node enables the HTTP 1.1 Keep-Alive method by default.
– The SOAPRequest node can be used in any message flow that needs to call a
Web service.

283
WebServices – SOAPRequest contd…
In The input terminal that accepts a message for processing by the
node.
Failure The output terminal to which a message is routed if a failure is
detected when the message is propagated to the Out flow (such
as a message validation failure). Failures routed to this terminal
include failures caused by the retry processing occurring before
the retry propagates the message to the Out flow.
Out The output terminal to which the message is routed if the SOAP
request has been sent and responded to successfully, and if
further processing is required within this message flow. If no errors
occur within the SOAPRequest node and a none fault SOAP
response is received from the external resource it is always sent to
the Out terminal first.
Fault SOAP fault messages received in response to the sent request are
directed to the Fault terminal. If no connection is provided to the
Fault terminal no further processing occurs for a received fault
within this message flow.

284
WebServices – SOAPEnvelope
– SOAPEnvelope
– Use the SOAPEnvelope node to add a SOAP envelope onto an existing message.
This node is designed to be used with the SOAPExtract node.
– The default behavior of the SOAPEnvelope node is to attach the SOAP envelope
from a standard location ($LocalEnvironment/SOAP/Envelope) in the local
environment tree; you can specify an explicit location by using an XPath
expression.
– You can also use the node in a flow without a corresponding SOAPExtract node;
the node has an option to create a default SOAP envelope.
– This node is designed to be used in conjunction with the SOAPExtract node
– This node is designed to work with SOAP messages. Use one of the following
parsers:
– XMLNSC
– MRM
– XMLNS
– Other XML parsers are not supported because they do not support namespaces.
An exception is thrown if a message is received which is not using the correct
parser or does not conform to the basic structure of a SOAP message.
– Full validation is not done on the SOAP message, which just needs to contain a
body element.

285
WebServices – SOAPEnvelope contd…
In The input terminal that accepts a SOAP message for processing
by the node.
Out The output terminal that outputs the SOAP message that was
constructed from the SOAP message body and a SOAP envelope.
Failure The output terminal to which the message is routed if a failure is
detected during processing.

286
WebServices – SOAPEnvelope
– Example SOAP Messages:

287
WebServices – SOAPExtract
– SOAPExtract
– Use the SOAPExtract node to remove SOAP envelopes, allowing just the body of a
SOAP message to be processed. It can also route a SOAP message based on its
operation name. Both functions are optional; they are contained in one node
because they are often used together.
– The SOAPExtract node can perform two functions:
– Extract function
– The default behavior is to detach the SOAP envelope to a standard location
($LocalEnvironment/SOAP/Envelope) in the LocalEnvironment tree. Alternatively, you can
specify an explicit location using an XPath expression. Any existing SOAP envelope at the
chosen location is replaced.
– Routing function
– The SOAP message is routed to a Label node in the message flow as identified by the
SOAP operation in the message. The SOAP Operation is identified in the SOAP body tag.

288
WebServices – SOAPExtract
– Ensure that the message parser options in the properties folder of the
outgoing message are correctly set up to parse the message, by copying
the message set and message format from the incoming message.
– The message type is derived from the SOAP envelope message body first
child.
– This node is designed to work with SOAP messages. Use one of the
following parsers:
– SOAP
– XMLNSC
– MRM
– XMLNS
– Other XML parsers are not supported because they do not support
namespaces. An exception is thrown if a message is received which is not
using the correct parser or does not conform to the basic structure of a
SOAP message.
– Full validation is not done on the SOAP message, which just needs to
contain a body element.

289
WebServices – SOAPExtract contd…
In The input terminal that accepts a SOAP message for processing
by the node.
Out The output terminal that outputs the SOAP message body (without
the envelope if the Remove envelope check box is selected on the
node properties).
detected during processing.

290
HTTP
– HTTPInput node
– HTTPReply node
– HTTPRequest node
– HTTPHeader node

291
HTTP – HTTPInput
– HTTPInput
– Use the HTTPInput node to receive an HTTP message from an HTTP client for
processing by a message flow.
– If you use the HTTPInput node with the HTTPReply and HTTPRequest nodes, the
broker can act as an intermediary for web services, and web service requests can
be transformed and routed in the same way as other message formats that are
supported by WebSphere® Message Broker.
– Web service requests can be received either in standard HTTP (1.0 or 1.1) format
or in HTTP over SSL (HTTPS) format.
– The HTTPInput node supports HTTP POST and HTTP GET.
– If your message flows are processing SOAP messages, use the SOAP nodes in
preference to the HTTPInput node to take advantage of enhanced features,
including WS-Addressing and WS-Security.

292
HTTP – HTTPInput
– The HTTPInput node handles messages in the following message domains:
– MRM
– XMLNSC
– XMLNS
– MIME
– BLOB
– XML (this domain is deprecated; use XMLNSC)
– JSON
– DFDL

293
HTTP – HTTPInput contd…
Failure The output terminal to which the message is routed if an error
occurs.
Out The output terminal to which the message is routed if it is
successfully retrieved.
HTTPTimeout The output terminal to which a timeout fault message is routed if
the HTTPReply node that is connected to the Out terminal does
not respond within the time interval specified by the Maximum
client wait time property. This terminal is used only if the
execution group has been configured so that HTTP nodes use
the embedded execution group listener.
Catch The output terminal to which the message is routed if an
exception is thrown downstream and caught by this node.

294
HTTP – HTTPReply
– HTTPReply
– Use the HTTPReply node to return a response from the message flow to an HTTP
client. This node generates the response to an HTTP client from which the input
message was received by the HTTPInput node, and waits for confirmation that it
has been sent.
– The HTTPReply node can be used in a message flow that sends a response to an
inbound HTTP or HTTPS messages. The most common example of this scenario is
a message flow that implements a Web service.
– By default, HTTP messages are handled by the broker-wide listener, which is
started when a message flow that includes HTTP nodes is started. All inbound and
outbound HTTP messages are routed through this listener, for all HTTP nodes
deployed to all message flows in all execution groups on the broker.

295
HTTP – HTTPReply contd…
node.
detected when the message is propagated.
Out The output terminal to which the message is routed if it has been
propagated successfully, and if further processing is required in
this message flow.

296
HTTP – HTTPRequest
– HTTPRequest
– Use the HTTPRequest node to interact with a web service.
– The HTTPRequest node interacts with a web service, using all or part of the input
message as the request that is sent to that service. You can also configure the
node to create an output message from the contents of the input message,
augmented by the contents of the web service response, before you propagate the
message to subsequent nodes in the message flow.
– Depending on the configuration, this node constructs an HTTP or an HTTP over
SSL (HTTPS) request from the specified contents of the input message, and sends
this request to the web service. The node receives the response from the web
service, and parses the response for inclusion in the output tree. The node
generates HTTP headers if they are required by your configuration.

297
HTTP – HTTPRequest contd…
– HTTPRequest
– You can use this node in a message flow that does or does not contain an
HTTPInput or HTTPReply node.
– The HTTPRequest node handles messages in the following message domains:
– DFDL
– XMLNSC
– JSON
– BLOB
– MIME
– MRM
– XMLNS
– The HTTPRequest node treats the 100 series status codes as a 'continue'
response, discards the current response, and waits for another response from the
web server.
– The 200 series status codes are treated as success, the settings on the various
tabs on the node determine the format of the output message that is generated,
and the response is routed to the Out terminal of the node.

298
– HTTPRequest
– The 300 series status codes are for redirection. If the Follow HTTP(s) Redirection
property is selected, the node resends the request to the new destination that is
specified in the response that is received. If the Follow HTTP(s) Redirection
property is not selected, the codes are treated as an error
– The 400 and 500 series status codes are errors

299
node.
detected during processing in the node.
Out The output terminal to which the message is routed if it
represents successful completion of the web service request,
and if further processing is required within this message flow.
Error The output terminal to which messages that include an HTTP
status code that is not in the range 200 through 299, including
redirection codes (3xx) if you have not set the property Follow
HTTP(s) redirection property, is routed.

300
HTTP – HTTPHeader
– HTTPHeader
– Use the HTTPHeader node to add, modify, or delete HTTP headers such as
HTTPInput, HTTPResponse, HTTPRequest and HTTPReply.
– The HTTPHeader node provides a toolkit interface to manipulate HTTP headers
without any need for coding; it does not modify the message body.
– You can add or remove a whole header, or selected header properties. You can
set the properties to a fixed value, or to a value specified by an XPath expression
that accesses a value in one of the message trees. XPath is used to provide a valid
location from which a value for a property can be copied.
– For example, the location can be the body of the message, the local environment
tree or exception list. HTTPInput and HTTPResponse headers can only be deleted
or carried forward from the incoming message; their header properties cannot be
modified or added to.

301
HTTP – HTTPHeader contd…
node.
Failure The output terminal to which the input message is routed if a
failure is detected during extraction.
Out The output terminal to which the transformed message is routed
if the input message is processed successfully.

302
Routing
– Filter node
– Label node
– Publication node
– RouteToLabel node
– Route node
– AggregateControl node
– AggregateReply node
– AggregateRequest node
– Collector node
– Resequence node
– Sequence node

303
Routing – Filter node
– Filter Node
– Use the Filter node to route a message according to message content.
– Create a filter expression in ESQL to define the route that the message is to take.
You can include elements of the input message or message properties in the filter
expression, and you can use data that is held in an external database to complete
the expression. The output terminal to which the message is routed depends on
whether the expression evaluates to true, false, or unknown.
– Connect the terminals that cover all situations that could result from the filter; if the
node propagates the message to a terminal that is not connected, the message is
discarded even if it is transactional.

304
Routing – Filter node contd…
node
detected during the computation
Unknown The output terminal to which the message is routed if the
specified filter expression evaluates to unknown or a null value
False The output terminal to which the message is routed if the
specified filter expression evaluates to false
True The output terminal to which the message is routed if the
specified filter expression evaluates to true

305
Routing – Filter node contd…
– Intelligent Routing of
messages within flows is
possible using the
RouteToLabel or Filter
methods
– If using a Filter method be
sensitive to the relative
volumes of each message
type likely to be passed
through the flow.
– Design flows so the
majority of messages flow
through the minimum
– number of possible nodes

306
Routing – Route node
– Route Node
– Use the Route node to direct messages that meet certain criteria down different
paths of a message flow.
– As an example, you can forward a message to different service providers, based
on the request details. You can also use the Route node to bypass unnecessary
steps. For example, you can check to see if certain data is in a message, and
perform a database lookup operation only if the data is missing. If you set the
Distribution Mode property to All, you can trigger multiple events that each require
different conditions. For example, you can log requests that relate to a particular
account identifier, and send requests that relate to a particular product to be
audited.

307
Routing – Route node contd…
In The static input terminal that accepts a message for processing
by the node.
Match A dynamic output terminal to which the original message can be
routed when processing completes successfully.
Default The static output terminal to which the message is routed if no
filter expression resolves to true.
Failure The static output terminal to which the message is routed if a
failure is detected during processing.

308
Transformation
– .NETCompute node
– Mapping node
– XSLTransform node
– Compute node
– JavaCompute node
– PHPCompute node

309
Transformation – Mapping node
– Use the Mapping node to
– create a new message from the input message by mapping the content of
elements of the output message from elements of the input message, or from
database content.
– You can also extract parts of the message, and optionally change their content, to
create a new output message that is a partial copy of the message that is received
by the node.
– Use the Mapping node to construct one or more new messages and populate them
with various types of information.
– You can populate the new messages with the following types of information:
– New information
– Modified information from the input message
– Information taken from a database
– You can modify elements of the message body data, its associated environment,
and its exception list.
– Use the Mapping node to:
– Build a new message
– Copy messages between parsers
– Transform a message from one format to another

310
Transformation – Mapping node contd…
– Mapping Node

311
Transformation – Mapping node contd…
node.
Failure The output terminal to which the input message is propagated if
a failure is detected during the computation. If you have selected
Treat Warnings as Errors, the node propagates the message to
this terminal if database warning messages are returned, even
though the processing might have completed successfully.
Out The output terminal that propagates the message following
completion of the mappings.

312
Transformation – Compute node
– Use the Compute node to
– The output messages that you create in the Compute node might be created by
modifying the information that is provided in the input message, or by using only
new information which can be taken from a database or from other sources.
– Elements of the input message (for example, headers, header fields, and body
data), its associated environment, and its exception list can be used to create the
new output message.
– Use the Compute node to:
– Build a new message using a set of assignment statements
– Copy messages between parsers
– Convert messages from one code set to another
– Transform messages from one format to another

313
Transformation – Compute node contd…
node.
Failure The output terminal to which the input message is routed if an
unhandled exception occurs during the computation.
Out The output terminal to which the transformed message is routed
when processing in the node is completed. The transformed
message might also be routed to this terminal by a PROPAGATE
statement.
Out1 The first alternative output terminal to which the transformed
message might be routed by a PROPAGATE statement.
Out2 The second alternative output terminal to which the transformed
Out3 The third alternative output terminal to which the transformed
Out4 The fourth alternative output terminal to which the transformed

314
Transformation – JavaCompute node
– Use the JavaCompute node:
– To work with messages by using the Java language.
– By using this node, you can complete the following tasks:
– Use Java to examine an incoming message and, depending on its content,
propagate it unchanged to one of the two output terminals of the node.
– The node behaves in a similar way to a Filter node, but uses Java instead of ESQL
to determine which output terminal to use.
– Use Java to change part of an incoming message and propagate the changed
message to one of the output terminals.
– Use Java to create and build a new output message that is totally independent of
the input message.
– The Java code that is used by the node is stored in an Eclipse Java project.

315
Transformation – JavaCompute node contd…
node.
Failure The output terminal to which the input message is routed if a
failure is detected during the computation. (Even if the Validate
property is set, messages that are propagated to the Failure
terminal of the node are not validated.)
Out The output terminal to which the transformed message is routed.
Alternate An alternative output terminal to which the transformed message
can be routed, instead of to the Out terminal.

316
Construction
– Input node
– Output node
– Throw node
– Trace node
– TryCatch node
– FlowOrder node
– Passthrough node
– ResetContentDescriptor node

317
Construction – Input node
– Use the Input node as an In terminal for an embedded message flow (a
subflow).
– You can use a subflow for a common task that can be represented by a
sequence of message flow nodes. For example, you can create a subflow to
increment or decrement a loop counter, or to provide error processing that
is common to a number of message flows.
– You must use an Input node to provide the In terminal to a subflow; you
cannot use a standard input node (a built-in input node such as MQInput, or
a user-defined input node).
– When you have started your subflow with an Input node, you can connect it
to any In terminal on any message flow node, including an Output node.
– You can include one or more Input nodes in a subflow. Each Input node that
you include provides a terminal through which to introduce messages to the
subflow. If you include more than one Input node, you cannot predict the
order in which the messages are processed through the subflow.

318
Construction – Input node contd…
Out The input terminal that delivers a message to the subflow.

319
Construction – Output node
– Use the Output node as an out terminal for an embedded message flow (a
subflow).
– You can use a subflow for a common task that can be represented by a
sequence of message flow nodes. For example, you can create a subflow to
increment or decrement a loop counter, or to provide error processing that
is common to a number of message flows.
– You must use an Output node to provide the Out terminal to a subflow; you
cannot use a standard output node (a built-in output node such as
MQOutput, or a user-defined output node).
– You can include one or more Output nodes in a subflow. Each one that you
include provides a terminal through which you can propagate messages to
subsequent nodes in the message flow in which you include the subflow.

320
Construction – Output node contd…
In The output terminal that defines an out terminal for the subflow.

321
Construction – Throw node
– Use the Throw node to throw an exception in a message flow.
– An exception can be caught and processed by:
– A preceding TryCatch node
– The message flow input node (the built-in nodes, for example HTTPInput and
MQInput, have Catch terminals)
– A preceding AggregateReply node
– Include a Throw node to force an error path through the message flow if the
content of the message contains unexpected data. For example, to back out
a message that does not contain a particular field, you can check (using a
Filter node) that the field exists; if the field does not exist, the message can
be passed to a Throw node that records details about the exception in the
exception list subtree in the message.

322
Construction – Throw node contd…
node.

323
Construction – Trace node
– Use the Trace node to generate trace records that you can use to monitor
the behavior of a message flow.
– Trace records can incorporate text, message content, and date and time
information, to help you to monitor the behavior of the message flow.
– You can write the records to the user trace file, another file, or the local
error log (which contains error and information messages written by all other
WebSphere® Message Broker components). If you write traces to the local
error log, you can issue a message from the default message catalog that is
supplied with WebSphere Message Broker, or you can create your own
message catalog.
– The operation of the Trace node is independent of the setting of user tracing
for the message flow that contains it. In particular, records that are written
by the Trace node to the user trace log are written even if user trace is not
currently active for the message flow.

324
Construction – Trace node contd…
node.
Out The output terminal through which the message is propagated.

325
Construction – TryCatch node
– Use the TryCatch node to provide a special handler for exception
processing.
– Initially, the input message is routed on the Try terminal, which you must
connect to the remaining non-error processing nodes of the message flow.
– If a downstream node (which can be a Throw node) throws an exception,
the TryCatch node catches it and routes the original message to its Catch
terminal.
– Connect the Catch terminal to further nodes to provide error processing for
the message after an exception.
– If the Catch terminal is connected, the message is propagated to it.
– If the Catch terminal is not connected, the message is discarded.

326
Construction – TryCatch node contd…
node.
Catch The output terminal to which the message is propagated if an
exception is thrown downstream and caught by this node.
Try The output terminal to which the message is propagated if it is
not caught.

327
Construction – FlowOrder node
– Use the FlowOrder node to control the order in which a message is
processed by a message flow.
– The FlowOrder node propagates the input message to the first output
terminal, and the sequence of nodes that is connected to this terminal
processes the message. When that message processing is complete,
control returns to the FlowOrder node.
– If the message processing completes successfully, the FlowOrder node
propagates the input message to the second output terminal, and the
sequence of nodes that is connected to this terminal processes the
message.
– The message that is propagated through the second output terminal is the
input message; it is not modified in any way, even if the sequence of nodes
that is connected to the first terminal has modified the message.
– You can include this node in a message flow at any point where the order of
execution of subsequent nodes is important.

328
Construction – FlowOrder node contd…
node.
detected during the computation.
First The output terminal to which the input message is routed in the
first instance.
Second The output terminal to which the input message is routed in the
second instance. The message is routed to this terminal only if
routing to First is successful.

329
Built-in Nodes (contd.)
– More information about Built-in Nodes (for WMB v7)
• http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com
.ibm.etools.mft.doc/ac04550_.htm

330
WebSphere Information Center
– View, Browse and search online information
• With in the WebSphere Message Broker Toolkit

331
WebSphere Information Center – contd…
• Within the WebSphere Message Broker Explorer

332
WebSphere Information Center – contd…
• From the Internet on IBM Public Website
• http://www-01.ibm.com/software/integration/messagebrokerproductline/
• http://www-01.ibm.com/software/integration/wbimessagebroker/library/

Technical Introduction to WebSphere MQ

335
Agenda
– Today’s Enterprise IT Environment
– Why Interfaces are so expensive to build and maintain?
– Service Oriented Architecture – Revisited
– WebSphere MQ – Universal Messaging Backbone
– WebSphere MQ connects virtually anything
– Did you know?
– Program-to-Program Communication
– How does WebSphere MQ Work?
– Synchronous Communication Model
– Asynchronous Communication Model
– Program-to-Program Communication Factors
– Three Styles of Communication
– WebSphere MQ Eliminates application network concerns.
– Local and Remote Queue Concept

336
Agenda contd…
– Message Queue Interface
– Message Queue Interface – Calls
– Message Composition
– Message Types
– Message Persistence
– Queue
– Queue Manager
– Message Queues Types
– Queues Expiry
– Message Broker User Roles
– Deployment process using Message Broker Explorer
– Deployment Process using MQ Explorer
– Message Broker Queue Explorer
– WebSphere Message Broker Environments

337
Introduction to WebSphere MQ
– Today’s Enterprise IT Environment

338
Why Interfaces are so expensive to build and maintain ?
– Application interface logic is intertwined with business logic.
– Tightly integrated interfaces are difficult to change.
– The more interfaces, the more complex the application —
interface logic may exceed business logic.
– In such circumstances, reuse becomes difficult and impractical.
How do I
optimize my
business
processes?
How do I
integrate to
my existing
systems?

339
Service Oriented Architecture – Revisited

340
WebSphere MQ – Universal Messaging Backbone
– WebSphere MQ is the market-leading messaging integration middleware
product.
– Originally introduced in 1993 (under the IBM MQSeries® name)
– WebSphere MQ provides an available, reliable, scalable, secure, and high-
performance transport mechanism to address businesses connectivity
requirements.
– By implementing messaging technologies, businesses can use a consistent
approach to connectivity, decoupling the business application from the
complexity of handling failures, error recovery, transaction integrity, security,
and scalability.
– IBM® WebSphere® MQ provides the universal messaging backbone for
service-oriented architecture (SOA) connectivity.
– It connects virtually any commercial IT system, with support for more than
80 platforms.

341
WebSphere MQ connects virtually anything
WebSphere MQ has probably the software industry’s broadest support for:
– programming languages
– messaging interfaces
– application environments
– OS platforms
HP-UX Windows zLinux Solaris AIX OS/400 NSS OVMS
.NET (C#)
Microsoft
MQ Interface
IBM de facto
JMS (Java)
Open standard
XMS (C, C++)
IBM standard
zOS Linux
80+ platform configurations
WebSphere MQ
RPG, COBOL,…
core and legacy

342
Did you know ?
– IBM WebSphere MQ has the following credentials and industry
recognition:
– It is the most widely deployed messaging backbone, with over 10,000
customers using the IBM Messaging Backbone:
– Over 90 percent of Fortune 50 companies and of Fortune 10 companies
use the IBM Messaging Backbone.
– Over 80 percent of Global 25 companies and 70 percent of Global 10
companies use the IBM Messaging Backbone.
– It is entrusted with tens of billions of messages each day:
– A government client sends 675 million messages per day.
– A banking client handles over 213 million messages per day on IBM
z/OS® alone.
– It is relied upon as the mission-critical backbone:
– A financial markets client handles US$1 trillion worth of traffic per day on
one WebSphere MQ network.
– A banking client sends US$7 - US$35 trillion worth of traffic per day on just
one WebSphere MQ-based SWIFT gateway.

343
Program-to-Program Communication
– IBM WebSphere MQ is a means of program-to-program
communication.
– Program A prepares a message and puts it on a queue. Program
B then gets the message from a queue and processes it.
– Both Program A and Program B use an application programming
interface (API) to put messages on a queue and get messages
from a queue.
– The IBM WebSphere MQ API is called the Message Queue
Interface (MQI).

344
How does WebSphere MQ Work ?
– Connects applications using
Messages sent via Queues.
– Queues are owned by Queue
Managers which store and forward
messages.
– Routing is dynamic and
configurable
– This allows applications to be very
loosely coupled…
– Cuts location dependencies
– Sender does not need to know where the receiver is
running
– Cuts timing dependencies (asynchronous)
– Sender does not need to know whether the receiver is
running
– Cuts platform dependencies
– Sender does not need to know the platform the receiver
is running
– Cuts data dependencies
– With a Broker they do not even need to agree on the
data format
Q Manager Q Manager
Message
Queue
Application ZApplication A
Channels

345
Program-to-Program Communication contd…
– Program A puts a message on the queue, Program B may not be
executing.
– The queue stores the message safely until Program B starts and
is ready to get the message.
– Likewise, at the time when Program B gets the message from the
queue, Program A may no longer be executing.
– Using IBM WebSphere MQ, there is no requirement for two
programs communicating with each other to be executing at the
same time.
– IBM WebSphere MQ provides several functions that are
mandatory for successful message transport:
– Assured delivery
– Once-only delivery
– Asynchronous delivery

346
Synchronous Communication Model
– If Program A sends a message to Program B and expects a
reply, one option is for Program A to put a message on Queue 1
and then wait for the reply to appear on Queue 2.
– This is called the synchronous model for two-way communication
between programs.
– Using the synchronous model, Program A and Program B would
normally be executing at the same time. However, if Program B
fails, Program A might potentially have to wait a long time for a
reply. How long Program A should wait before continuing with
other processing is a design issue.

347
Asynchronous Communication Model
– Using the extended asynchronous model, Program A puts
messages on Queue 1 for Program B to process, but it is
Program C, acting asynchronously to Program A, which receives
replies from Queue 2 and processes them.
– Typically, Program A and Program C would be part of the same
application.

348
Asynchronous Communication Model contd…
– The asynchronous model is a natural model for IBM WebSphere
MQ. Program A can continue to put messages on Queue 1 and
is not blocked by having to wait for a reply to each message.
– It can continue to put messages on Queue 1 even if Program B
fails. In that case, Queue 1 stores the messages safely until
Program B is restarted.

349
Program-to-Program Communication Factors
– Time Independence
– Protocol Support
– Assured Delivery of Information
– Data Conversion

351
Three Styles of Communication

352
Three Styles of Communication Contd…

353
WebSphere MQ
– Eliminates application network concerns.

354
Local and Remote Queue Concept

356
Message Queue Interface – Calls

357
Message Composition
– Set by application and queue manager
– Header
– MQMD
– Application data
– Any sequence of bytes
– Meaningful only to the sending and receiving applications
– Not meaningful to the queue manager

358
Message Composition contd…

359
Message Composition contd…
– Some Message Headers
– MQMD – MQ Message Descriptor Contains…
– Message ID
– Correlation ID
– Message Type
– Priority
– Put Date
– Persistence
– Reply to Q
– Reply to Q Manager

360
Message Types
– MQ Series knows four types of messages:
– Datagram
– A message containing information for which no response is
expected.
– Request
– A message for which a reply is requested.
– Response
– A reply to a request message.
– Report
– A message that describes an event such as the occurrence of
an error or a confirmation on arrival or a delivery.

362
Queue
– Queue is a data structure in which the messages are stored.
– Messages can be put on, or got from, the Queue by applications
by a Queue Manager.
– Queues exists independently of the applications that use them,
whether the applications are active or inactive, Queue can store
messages.
– Queue belongs to a Queue Manager, which is responsible for
maintaining that Queue.

363
Queue Manager
– Heart of MQSeries Runtime program.
– Job is to manage queues of messages.

364
Message Queues
– Queues are defined as objects belonging to a Queue Manager.
– Local Queue
– Remote Queue
– Transmission Queue
– Dynamic Queue
– Alias Queue
– Model Queue
– Initiation Queue
– Reply-To Queue
– Dead-Letter Queue
– Event Queue
– Command Queue

365
Message Queues contd…
– Local Queue
– A Local Queue is local iff it is owned by the queue manager to
which the application program is connected.
– Local Queue is a real queue.
– Remote Queue
– Is the local definition of a Remote Queue

366
Message Queues contd…
– Dead Letter Queue
– A Queue Manager must be able to handle situations when it
cannot deliver a message. It will be used as a repository for all
messages that cannot be delivered.
– Message Delivery Failure scenarios
– The Destination queue is Full.
– The Destination Queue doesn’t exist.
– Message puts have been inhibited on the destination queue.
– The sender is not authorized to use the destination queue.
– The message is too large.

368
Message Broker User Roles
– Create message flows and
related artifacts
– Create, customize and
deploy BAR files
– Unit test on local or non-
critical brokers
– Receive tested BAR files
– Controlled deployment
– Management of business
critical MQ and broker
environments

369
Message Broker User Roles (contd.)
– Complete Application
Development (AD) and Design,
Code Unit Test environment
– Administration perspective
replaced with design, code, unit
test
– Create message flows and
related artifacts Create,
customize and deploy barfiles
– Message Broker Explorer’
only
– Import, customize and
deploy barfiles
– Manage MQ and broker
environments Smaller
footprint
– Plug-in to MQ Explorer

370
Deployment process using
Message Broker Explorer
– Prepare barfile
– Message Broker Toolkit -build your bar files
– MB Explorer -import your bar files into the MB Explorer or drag from
MB Toolkit
– Or can use an intermediate code repository
– Customize barfile if necessary
– Deploy barfile
– Deployment takes place in background
– Deployment log updates when complete

371
Deployment process using
Message Broker Explorer (contd.)
– MB Explorer provides a selection of deployment
mechanisms
– Drag barfile from file system
– Drag barfile from Message Broker Toolkit application development
perspective to execution group in MB Explorer
– Drag barfile from the “Broker Archive Files” in MB Explorer to
execution group
– Right-click execution group, and select “Deploy” from pop-up
menu to deploy several barfiles
– From file system
– From MB Explorer workspace
– Right-click barfile in workspace, select “Deploy File” in pop-up
menu to deploy a barfile to a group of execution groups
– Simultaneous deploys of a single barfile to several executions groups
– Use barfile properties page and select “Deploy Broker Archive”

372
Message Broker Queue Explorer

373
WebSphere Message Broker Environments

376
Agenda
– Prerequisites
– ESQL Overview & Concepts
– Datatypes
– Variables
– Operators
– Statements
– Functions & Procedures
– Field References
– Modules
– Reserved Words
– Non Reserved Words
– Special Characters
– Managing ESQL files
– Writing ESQL files

377
Pre-requisites
– Knowledge in SQL, Stored Procedures.

378
What is ESQL ?
– Extended Structured Query Language (ESQL) is a programming
language defined by WebSphere Message Broker to define and
manipulate data within a message flow.
– ESQL is based on Structured Query Language (SQL) which is in
common usage with relational databases such as DB2.
– ESQL extends the constructs of the SQL language to provide
support for you to work with message and database content to
define the behavior of nodes in a message flow.
– You can use the ESQL code in the following nodes:
– Compute Node
– Database Node
– Filter Node

379
What is ESQL ?
– You can also use the ESQL code in the following nodes:
– DataDelete Node
– DataInsert node
– DataUpdate node
– Extract node
– Mapping node
– Warehouse node

380
ESQL Concepts
– To use ESQL correctly and efficiently in your message flows, you
must also understand the following concepts
– Datatypes
– Variables
– Operators
– Statements
– Functions
– Procedures
– Constants
– Field References
– Modules
– Reserved Words
– Non Reserved Words
– Special Characters

381
ESQL Datatypes
– A data type defines the characteristics of an item of data, and
determines how that data is processed. ESQL supports six data
types
– BOOLEAN (TRUE, FALSE, UNKNOWN)
– DATETIME
• ESQL supports several data types that handle datetime values.
– DATE
– TIME
– GMTTIME
– TIMESTAMP
– GMTTIMESTAMP
– INTERVAL
– NULL
– NUMERIC
• DECIMAL, FLOAT, INTEGER

382
ESQL Datatypes (contd.)
– REFERENCE
– The REFERENCE data type holds the location of a field in a message.
Ex - InputRoot.MQMD.Priority
– is a field reference literal that refers to the Priority field contained within
an MQMD structure within an input message.
– STRING
– BIT, BLOB, CHARACTER

383
ESQL Variables
– An ESQL variable is a data field that is used to help process a
message.
– You must declare a variable and state its type before you can use it.
– The data type of a variable is fixed; if you code ESQL that assigns a
value of a different type, either an implicit cast to the data type of
the target is implemented or an exception is raised (if the implicit
cast is not supported).
– Their use is defined in the DECLARE statement.
– The names of ESQL variables are case-sensitive;
– The simplest way to guarantee that you are using the correct case
is always to define variables using uppercase names.

384
ESQL Variables (contd.)
– ESQL variables can be described as
• External variables
– External variables (defined with the EXTERNAL keyword) are also
known as user-defined properties.
– They exist for the entire lifetime of a message flow and are visible to all
messages that pass through the flow.
– Access user-defined properties (UDPs) as variables in your ESQL
program by specifying the EXTERNAL keyword on a DECLARE
statement.
– For example, the ESQL statement DECLARE today EXTERNAL
CHARACTER 'monday' defines a user-defined property called today
with an initial value monday.
• Normal variables
– Normal variables have a lifetime of just one message passing through a
node.
– They are visible to that message only.
– To define a normal variable, omit both the EXTERNAL and SHARED
keywords.

385
ESQL Variables (contd.)
• Shared variables (a.k.a Long-lived variables)
– You can use appropriate long-lived ESQL data types to cache data in
memory.
– Sometimes data has to be stored beyond the lifetime of a single
message passing through a flow. One way to store this data is to store
the data in a database.
– Using a database is good for long-term persistence and
transactionality, but access (particularly write access) is slow.
– You can use appropriate long-lived ESQL data types to provide an in-
memory cache of the data for a certain period of time.
– Using long-lived ESQL data types makes access faster than from a
database, although this speed is at the expense of shorter persistence
and no transactionality.
– You create long-lifetime variables by using the SHARED keyword on
the DECLARE statement
– They exist for the lifetime of the execution group process, the lifetime of
the flow or node, or the lifetime of the node's SQL that declares the
variable (whichever is the shortest)

386
ESQL Operators
– An ESQL operator is a character or symbol that you can use in
expressions to specify relationships between fields or values.
– Simple comparison operators
• >, <, >=, <=, =, and <>
– Complex comparison operators
• BETWEEN, EXISTS, IN, IS, LIKE
– Logical operators
• AND, OR, NOT

387
ESQL Operators (contd.)
– Numeric Operators
• +, −, *, /, and ∥
– String Operator
• ||
• The result is the concatenation of the two operands. You can
concatenate string values (CHARACTER, BIT, and BLOB).
• If either operand is NULL, the result is NULL.
– Rules for ESQL operator precedence
1. Parentheses
2. Unary operators including unary - and NOT
3. Multiplication and division
4. Concatenation
5. Addition and subtraction

388
ESQL Statements
– You can use ESQL statements to manipulate message trees,
update databases, or interact with nodes.
– Basic statements
– Message tree manipulation statements
– Database update statements
– Node interaction statements
– Other statements

389
ESQL Statements
BEGIN … END
CALL
CASE
CREATE FUNCTION
CREATE MODULE
CREATE
PROCEDUCE
DECLARE
IF
ITERATE
LEAVE
LOOP
REPEAT
RETURN
SET
THROW, WHILE
ATTACH
CREATE
DELETE
DETACH
FOR
MOVE
DELETE FROM
INSERT
PASSTHRU
UPDATE
PROPAGATE BROKER SCHEMA
DECLARE
HANDLER
EVAL
LOG
RESIGNAL
Basic
Statements
Message
Tree
Manipulation
Statements
Database
Update
Statements
Node
Interaction
Statements
Other
Statements

390
ESQL – Basic Statements
– BEGIN … END Statement
– The BEGIN ... END statement gives the statements defined within the
BEGIN and END keywords the status of a single statement.
– This allows the contained statements to:
– Be the body of a function or a procedure
– Have their exceptions handled by a handler
– Have their execution discontinued by a LEAVE statement
– Example

391
ESQL – Basic Statements contd…
– CALL statement
– The CALL statement invokes a routine. A routine is a user-defined
function or procedure that has been defined by one of the following:
– A CREATE FUNCTION statement
– A CREATE PROCEDURE statement
– standard user-defined functions and procedures
– Invoke built-in (broker-provided) functions
– User-defined SQL functions
– You can use the CALL statement to invoke a routine that has been
implemented in all the following ways:
– ESQL.
– Java.
– As a stored procedure in a database.

392
– CALL statement
– The called routine must be invoked in a way that matches its definition.
For example, if you have defined a routine with three parameters, the first
two of type integer and the third of type character, the CALL statement
must pass three variables to the routine, each of a data type that matches
the definition.
– This technique is called exact signature matching, which means that the
signature provided by the CALL statement must match the signature
provided by the definition of the routine.
– Exact signature matching also applies to the value returned to a routine.
– If the RETURNS clause is specified on the CREATE FUNCTION
statement, or the routine is a built-in function, the INTO clause must be
specified on the CALL statement.
– A return value from a routine cannot be ignored. Conversely, if the
RETURNS clause is not specified on the CREATE FUNCTION
statement, the INTO clause must not be specified, because there is no
return value from the routine.

393
– CASE statement
– The CASE statement uses rules defined in WHEN clauses to select a
block of statements to process.
– Example:
Simple CASE Statement
CASE size
WHEN minimum + 0 THEN
SET description = 'small';
SET description = 'medium';
SET description = 'large';
CALL handleLargeObject();
ELSE
SET description = 'unknown';
CALL handleError();
END CASE;
Searched CASE Statement
CASE
WHEN i <> 0 THEN
CALL handleI(i);
WHEN j> 1 THEN
CALL handleIZeroAndPositiveJ(j);
ELSE
CALL handleAllOtherCases(j);
END CASE;

394
– CREATE FUNCTION statement
– The CREATE FUNCTION statement defines a callable function or
procedure, also known as a routine.
– You can also use the CREATE PROCEDURE statement to define a
callable function or procedure, also known as a routine.
– Routines are useful for creating reusable blocks of code that can be run
independently many times. You can implement them as a series of ESQL
statements, a Java method, a .NET method, or a database stored
procedure.
– Example:

395
– CREATE MODULE statement (Self Study)
– .
– Example:
– http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/c
om.ibm.etools.mft.doc/ak04965_.htm

396
– CREATE PROCEDURE statement (Self Study)
– .
– Example:

397
– DECLARE statement
– Use the DECLARE statement to define a variable, the data type of the
variable and, optionally, its initial value.
– You can define three types of variable with the DECLARE statement:
– External
– Normal
– Shared
– The following will be used in conjunction with the DECLARE Statement.
– CONSTANT
– DataType
– EXTERNAL
– NAME
– NAMESPACE
– SHARED

398
– CONSTANT
– Use CONSTANT to define a constant. You can declare constants within
schemas, modules, routines, or compound statements
– DataType
• BOOLEAN
• INT
• INTEGER
• FLOAT
• DECIMAL
• DATE
• TIME
• TIMESTAMP
• GMTTIME
• GMTTIMESTAMP
• INTERVAL
• CHAR
• CHARACTER
• BLOB
• BIT
• ROW
• REFERENCE TO

399
– EXTERNAL
– Use EXTERNAL to denote a user-defined property (UDP).
– A UDP is a user-defined constant whose initial value (optionally set by the
DECLARE statement) can be modified
– at design time, by the Message Flow editor (see Message Flow editor)
– overridden, at deployment time, by the Broker Archive editor (see Broker
Archive editor).
– The value of a UDP cannot be modified by ESQL.
– For example, if you code:
– DECLARE deployEnvironment EXTERNAL CHARACTER 'Dev';
– you have defined a UDP variable of deployEnvironment with an initial value
Dev.
– DECLARE mycolor EXTERNAL CHARACTER 'blue';
– DECLARE TODAYSCOLOR EXTERNAL CHARACTER;
SET COLOR = TODAYSCOLOR;
– where TODAYSCOLOR is a user-defined property that has a TYPE of
CHARACTER and a VALUE set by the Message Flow editor.

400
– NAME
– Use NAME to define an alias (an alternative name) by which a variable can
be known.
– NAMESPACE
– Use NAMESPACE to define an alias (an alternative name) by which a
namespace can be known.
– Example
– This example illustrates a namespace declaration, its use as a SpaceId in a
path, and its use as a character constant in a namespace expression:
DECLARE prefixOne NAMESPACE 'http://www.example.com/PO1';
-- On the right hand side of the assignment a namespace constant
-- is being used as such while, on the left hand side, one is
-- being used as an ordinary constant (that is, in an expression).
SET OutputRoot.XMLNS.{prefixOne}:{'PurchaseOrder'} =
InputRoot.XMLNS.prefixOne:PurchaseOrder;

401
– SHARED
– Use SHARED to define a shared variable. Shared variables are private to
the flow (if declared within a schema) or node (if declared within a module),
but are shared between instances of the flow (threads).
– No type of variable is visible beyond the flow level; for example, you cannot
share variables across execution groups.
– You can use shared variables to implement an in-memory cache in the
message flow;
– Shared variables exist for the lifetime of the: (whichever is the shortest)
– Execution group process
– Flow or node, or
– Node ESQL code that declares the variable

402
– IF statement
– The IF statement executes one set of statements based on the
result of evaluating condition expressions.
– Each expression is evaluated in turn until one results in TRUE;
the corresponding set of statements is then executed. If none
of the expressions returns TRUE, and the optional ELSE
clause is present, the ELSE clause's statements are executed
IF i = 0 THEN
SET size = 'small';
ELSEIF i = 1 THEN
SET size = 'medium';
ELSEIF j = 4 THEN
SET size = 'large';
ELSE
SET size = 'unknown';
END IF;
IF J> MAX THEN
SET J = MAX;
SET Limit = TRUE;
END IF;

403
– ITERATE statement
– The ITERATE statement stops the current iteration of the containing
WHILE, REPEAT, LOOP, or BEGIN statement identified by Label.
– The containing statement evaluates its loop condition (if any), and
either starts the next iteration or stops looping, as the condition
dictates.
DECLARE i INTEGER;
SET i = 0;
X : REPEAT
SET i = i + 1;
-- Some statements 1
IF i IN(2, 3) THEN
ITERATE X;
END IF;
-- Some statements 2
UNTIL
i>= 4
END REPEAT X;

404
– LEAVE statement
– The LEAVE statement stops the current iteration of the containing
WHILE, REPEAT, LOOP, or BEGIN statement identified by Label.
– The containing statement's evaluation of its loop condition (if any)
is bypassed and looping stops.
DECLARE i INTEGER;
SET i = 1;
X : REPEAT
...
IF i>= 4 THEN
LEAVE X;
END IF;
SET i = i + 1;
UNTIL
FALSE
END REPEAT;

405
– LOOP statement
– The LOOP statement executes the sequence of statements
repeatedly and unconditionally.
– Ensure that the logic of the program provides some means of
terminating the loop. You can use either LEAVE or RETURN
statements.
DECLARE i INTEGER;
SET i = 1;
X : LOOP
...
IF i>= 4 THEN
LEAVE X;
END IF;
SET i = i + 1;
END LOOP X;

406
– REPEAT statement
– Processes a sequence of statements, then evaluates a condition
expression.
– The REPEAT statement repeats the steps until condition is TRUE.
Ensure that the logic of the program is such that the loop
terminates. If the condition evaluates to UNKNOWN, the loop
does not terminate.
DECLARE i INTEGER;
SET i = 1;
X : REPEAT
...
SET i = i + 1;
UNTIL
i>= 3
END REPEAT X;

407
– RETURN statement
– The RETURN statement ends processing. What happens next
depends on the programming context in which the RETURN
statement is issued.
– If the RETURN statement is used in the Main Function:
Node RETURN TRUE; RETURN FALSE;
RETURN UNKNOWN (if
BOOLEAN type) or
RETURN NULL;
RETURN;
Compute
Propagate message
to Out terminal.
Stop propagation Stop propagation
Deploy failure
(BIP2912E: Type
mismatch on RETURN)
Database
Propagate message
to Out terminal.
Stop propagation Stop propagation
Deploy failure
(BIP2912E: Type
mismatch on RETURN)
Filter
Propagate message
to True terminal
Propagate
message to False
terminal
Propagate message
to Unknown terminal
Deploy failure
(BIP2912E: Type
mismatch on RETURN)

408
– User defined functions and procedures
Action
Performed
RETURN expression;
RETURN NULL;
(or return
expression that
evaluates to NULL)
RETURN; No RETURN statement
User
defined
function or
procedure
with a
RETURNS
clause
Returns control to
the calling
expression with
the value of
expression
Returns control
to the calling
expression with
NULL
Deploy failure
(BIP2912E: Type
mismatch on
RETURN)
Returns control to the
calling expression
with NULL after all the
statements in the
function or procedure
have been run
User
defined
function or
procedure
without a
RETURNS
clause
Deploy failure
(BIP2401E:
Syntax error:
expected ; but
found expression)
Deploy failure
(BIP2401E:
Syntax error:
expected ; but
found NULL)
Returns control to
the calling
expression
Returns control to the
calling expression
after all the
statements in the
function or procedure
have been run

409
– Example
CREATE FILTER MODULE ProcessOrder
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
DECLARE SpecialOrder BOOLEAN;
SET OutputRoot.MQMD = InputRoot.MQMD;
CALL IsBulkOrder(InputRoot.XMLNS.Invoice.Purchases) INTO SpecialOrder;
--
-- more processing could be inserted here
-- before routing the order to the appropriate terminal
--
RETURN SpecialOrder;
END;

410
– Example Contd…
CREATE FUNCTION IsBulkOrder (P1 REFERENCE)
RETURNS BOOLEAN
BEGIN
-- Declare and initialize variables--
DECLARE a INT 1;
DECLARE PriceTotal FLOAT 0.0;
DECLARE NumItems INT 0;
DECLARE iroot REFERENCE TO P1;
-- Calculate value of order, however if this is a bulk purchase, the --
-- order will need to be handled differently (discount given) so return TRUE --
-- or FALSE depending on the size of the order --
WHILE a <= CARDINALITY(iroot.Item[]) DO
SET NumItems = NumItems + iroot.Item[a].Quantity;
SET PriceTotal = PriceTotal + iroot.Item[a].UnitPrice;
SET a = a + 1;
END WHILE;
RETURN (PriceTotal/NumItems> 42);
END;
END MODULE;

411
– Example Contd…
– In the example, if the average price of items is greater than 42, TRUE is
returned; otherwise FALSE is returned. Thus, a Filter node could route
messages describing expensive items down a different path from
messages describing inexpensive items.
– From the example, the CALL
IsBulkOrder(InputRoot.XMLNS.Invoice.Purchases) INTO SpecialOrder;
statement can also be written as
SpecialOrder = IsBulkOrder(InputRoot.XMLNS.Invoice.Purchases);

412
– SET statement
– Evaluates a source expression, and assigns the result to the target
entity.
– Example:
– SET OutputRoot = InputRoot;
– SET OutputRoot.XMLNS.Order.Name = UPPER(InputRoot.XMLNS.Order.Name)
– If you want to assign a NULL value to a field without deleting the field, use
a statement like this:
– SET OutputRoot.XMLNS.Order.Name VALUE = NULL;

413
– THROW statement
– Use the THROW statement to generate a user exception.
– The USER keyword indicates the type of exception being thrown.
(Currently, only USER exceptions are supported, and if you omit the
USER keyword the exception defaults to a USER exception anyway.)
– Specify the USER keyword, even though it currently has no effect, for
the following reasons:
– If future broker releases support other types of exception, and the default
type changes, your code will not need to be changed.
– It makes it clear that this is a user exception.
– Examples
– THROW USER EXCEPTION;
– THROW USER EXCEPTION CATALOG 'BIPmsgs' MESSAGE 2951;

414
– WHILE statement
– The WHILE statement evaluates a condition expression, and if it is TRUE
executes a sequence of statements.
– The WHILE statement repeats the steps specified in DO provided that
condition is TRUE.
– It is your responsibility to ensure that the logic of the program is such that the
loop terminates. If condition evaluates to UNKNOWN, the loop terminates
immediately.
DECLARE i INTEGER;
SET i = 1;
X : WHILE i <= 3 DO
...
SET i = i + 1;
END WHILE X;

415
ESQL – Message Tree Manipulation Statements
– ATTACH and DETACH statements
– The ATTACH statement attaches a portion of a message tree into a new
position in the message hierarchy.
– For Example, if you have the following message:
<Data>
<Order>
<Item>cheese
<Type>stilton</Type>
</Item>
<Item>bread</Item>
</Order>
<Order>
<Item>garlic</Item>
<Item>wine</Item>
</Order>
</Data>
SET OutputRoot = InputRoot;
DECLARE ref1 REFERENCE TO OutputRoot.XMLNSC.Data.Order[1].Item[1];
DETACH ref1;
ATTACH ref1 TO OutputRoot.XMLNSC.Data.Order[2] AS LASTCHILD;
<Data>
<Order>
<Item>bread</Item>
</Order>
<Order>
<Item>garlic</Item>
<Item>wine</Item>
<Item>cheese
<Type>stilton</Type>
</Item>
</Order>
</Data>

416
– DELETE statement
– The DELETE statement detaches and destroys a portion of a message tree,
allowing its memory to be reused. This statement is particularly useful when
handling very large messages.
– If the target field does not exist, the statement does nothing and normal
processing continues.
– For Example:
DELETE FIELD OutputRoot.XMLNS.Data.Folder1.Folder12;
DELETE LASTCHILD OF Cursor;

417
– FOR statement
– The FOR statement iterates through a list (for example, a message array).
– For each iteration, the FOR statement makes the correlation variable equal to
the current member of the list, then executes the block of statements.
– The advantage of the FOR statement is that it iterates through a list without
your having to write any sort of loop construct
– For Example:
SET OutputRoot.MQMD=InputRoot.MQMD;
SET Environment.SourceData.Folder[1].Field1 = 'Field11Value';
DECLARE i INTEGER 1;
FOR source AS Environment.SourceData.Folder[] DO
CREATE LASTCHILD OF OutputRoot.XMLNSC.Data.ResultData.MessageArrayTest.Folder[i]
NAME 'FieldA' VALUE '' || source.Field1 || '' || CAST(i AS CHAR);
CREATE LASTCHILD OF OutputRoot.XMLNSC.Data.ResultData.MessageArrayTest.Folder[i]
NAME 'FieldB' VALUE '' || source.Field2 || '' || CAST(i AS CHAR);
SET i = i + 1;
END FOR;

418
– FOR statement
– generates the output message:
<Data>
<ResultData>
<MessageArrayTest>
<Folder>
<FieldA>Field11Value1</FieldA>
<FieldB>Field12Value1</FieldB>
</Folder>
<Folder>
<FieldA>Field21Value2</FieldA>
<FieldB>Field22Value2</FieldB>
</Folder>
</MessageArrayTest>
</ResultData>
</Data>

419
– MOVE statement
– The MOVE statement changes the field to which the Target reference variable
points.
– For Example:
– http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.
etools.mft.doc/ak05090_.htm

420
ESQL – Node Interaction Statements
– PROPAGATE statement
– The PROPAGATE statement propagates a message to the downstream
nodes.
– For Example:
– http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.i
bm.etools.mft.doc/ak05110_.htm

421
ESQL – Other Statements
– BROKER SCHEMA statement
– The BROKER SCHEMA statement is optional; use it in an ESQL file to
explicitly identify the schema that contains the file.
– For Example:
– http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm
.etools.mft.doc/ak04915_.htm

422
ESQL – Other Statements
– EVAL statement
– The EVAL statement takes a character value, interprets it as an SQL
statement, and processes that statement.
– For Example:

423
ESQL Statements (contd.)
– More information about ESQL Statements:
/com.ibm.etools.mft.doc/ak04900_.htm

424
ESQL Functions
ESQL Database State Functions1
3
ESQL numeric functions
2
ESQL datetime functions
4
ESQL string manipulation functions
5
ESQL field functions
6
ESQL list functions
7
Complex ESQL functions
8
Miscellaneous ESQL functions

425
ESQL Functions – Self Study

426
Functions, Procedures
– Functions
– A function is an ESQL construct that calculates a value from a
number of given input values.
– A function usually has input parameters and can, but does not
usually have, output parameters.
– It returns a value calculated by the algorithm described by its
statement. This statement is usually a compound statement, such as
BEGIN... END, because this allows an unlimited number of nested
statements to be used to implement the algorithm.
– ESQL provides a number of predefined, or "built-in", functions which
you can use freely within expressions. You can also use the CREATE
FUNCTION statement to define your own functions.
– When you define a function, you must give it a unique name.
– Example:
– SET Diameter = SQRT(Area / 3.142) * 2;

427
Functions, Procedures (contd.)
– Procedures
– An ESQL procedure is a subroutine that has no return value. It can
accept input parameters from, and return output parameters to, the
caller.
– Procedures are very similar to functions. The main difference
between them is that, unlike functions, procedures have no return
value. Thus they cannot form part of an expression and are invoked
by using the CALL statement. Procedures commonly have output
parameters.
– Example:

428
Functions, Procedures (contd.)

429
ESQL Field References
– An ESQL field reference is a sequence of period-separated
values that identify a specific field (which might be a structure)
within a message tree or a database table.
– The path from the root of the information to the specific field is
traced using the parent/child relationships.
– A field reference is used in an ESQL statement to identify the
field that is to be referenced, updated, or created within the
message or database table.
– For example, you might use the following identifier as a message
field reference
– Body.Invoice.Payment
– More information about Field References:

430
ESQL Field References (contd.)
– Example:
IF InputRoot.XML.Create_Book_Order_MSG.First_Class = 'Yes' THEN
SET OutputRoot.XML.Book_Order_Response_MSG.First_Class =
InputRoot.XML.Create_Book_Order_MSG.First_Class;
…
…
END IF;

431
ESQL Reserved Words
– The keywords listed are reserved in uppercase, lowercase, or
mixed case.
– You cannot use these keywords for variable names. However,
you can use reserved keywords as names in a field reference.
– ALL
– ASYMMETRIC
– BOTH
– CASE
– DISTINCT
– FROM
– ITEM
– LEADING
– NOT
– SYMMETRIC
– TRAILING
– WHEN

432
ESQL Non Reserved Words
– Some keywords are used in the ESQL language, but are not
reserved.
– Do not use them for variable, function, or procedure names (in
any combination of uppercase and lowercase) because your
code can become difficult to understand.
– There are 181 Non Reserved Keywords available in ESQL as of
IBM WebSphere Message Broker v8.0.
– Complete List of Non Reserved Keywords:
/com.ibm.etools.mft.doc/ak04890_.htm

434
ESQL Code Conventions
– ESQL Special Characters
– ESQL code conventions in WebSphere Message Broker
• http://www.ibm.com/developerworks/websphere/library/techarti
cles/0803_shen/0803_shen.html

435
Managing ESQL Files (Self Study)
– Creating an ESQL file
– Opening an existing ESQL file
– Creating ESQL for a node
– Modifying ESQL for a node
– Saving an ESQL file
– Copying an ESQL file
– Renaming an ESQL file
– Moving an ESQL file
– Changing ESQL preferences
– Deleting ESQL for a node
– Deleting an ESQL file

436
Writing ESQL Files (Self Study)
– When you create a message flow, you include input nodes that
receive the messages and, optionally, output nodes that send
out new or updated messages.
– If required by the processing that must be performed on the
message, you can include other nodes after the input node that
complete the actions that your applications need.
– Some of the built-in nodes enable you to customize the
processing that they provide.
– ESQL provides a rich and flexible syntax for statements and
functions that enable. You can:
– Read the contents of the input message
– Modify message content with data from databases
– Modify database content with data from messages
– Construct new output messages created from all, part, or none of the
input message (in the Compute node only)

437
Writing ESQL Files (Self Study)
– The following topics provide additional information specific to the
parser that you have specified for the input message:
– Manipulating messages in the MRM domain
– Manipulating messages in the XML domain
– Manipulating messages in the XMLNS domain
– Manipulating messages in the XMLNSC domain
– Manipulating messages in the JMS domains
– Manipulating messages in the IDOC domain
– Manipulating messages in the MIME domain
– Manipulating messages in the BLOB domain
– Writing ESQL Files
bm.etools.mft.doc/ac06000_.htm

Developing Message Flow Applications
using ESQL

440
Agenda
– Messages in WebSphere Message Broker
– ESQL and the ESQL editor in the Message Brokers Toolkit
– Defining the logic of a message flow using ESQL
– Inserting data into a database using a message flow
– LAB 1 - Simple Hello World Application
– LAB 2: Bookstore Message Flow Application

441
Messages in WebSphere Message Broker
– The body of the message is a hierarchical tree of elements, or
message fields.
– The message flow can interpret the hierarchy of elements in the
message body only if the input node has been configured to use
the correct parser.

442
ESQL and ESQL Editor
– ESQL is based on Structured Query Language (SQL), which is
commonly used to query relational databases like DB2 Universal
Database.
– You can define the logic of message flows using ESQL by
inserting ESQL code into built-in nodes that are supplied with
WebSphere Message Broker, such as:
• Compute node
• Database node
• Filter node.
– The ESQL is stored in a separate file, which you edit in the ESQL
editor.

445
LAB 1: Simple Message Flow Application
Simple Message Flow Application
– The Simple message flow application demonstrates how to build
a very basic message flow.
– The ESQL_Simple message flow takes an XML input message
from a WebSphere MQ queue, uses ESQL in a Compute node to
build an XML output message that has the same contents as the
input message, then puts the output message on another
WebSphere MQ queue.
Example
Page (52-79), WebSphere Message Broker Basics (sg247137).pdf

446
LAB 2: Bookstore Message Flow Application
Bookstore Message Flow application
• The Bookstore message flow application is based around the
scenario of an online bookstore. The first message flow,
ESQL_Create_Customer_Account, uses ESQL in a Database
node to create accounts in a DB2 database table for new
customers who have registered their details with the bookstore,
for example, their contact details and delivery address.
• The second message flow, ESQL_Book_Order, uses ESQL in
a Compute node to process an order that has been submitted
by an online customer and create a response message to
confirm the order with a unique order number.
Example

447
Developing the Bookstore scenario using ESQL
– In this section, we create a more complex message flow
application that is based around the scenario of an online
bookstore.
– The Bookstore scenario message flows process messages with
different structures, and interact with databases to update
database tables.
– The Bookstore scenario includes two message flows
• The ESQL_Create_Customer_Account message flow
• The ESQL_Book_Order message flow

448
Developing the Bookstore scenario using ESQL
– The ESQL_Create_Customer_Account message flow
• This message flow uses ESQL in a Database node to create
accounts in a DB2 database table for new customers who have
registered their details with the bookstore, for example, their
contact details and delivery address.
– The ESQL_Book_Order message flow
• This message flow uses ESQL in a Compute node to process
an order that has been submitted by an online customer and
create a response message to confirm the order with a unique
order number.

449
Developing the Bookstore scenario using ESQL – Steps
– Create the Bookstore scenario database (BSTOREDB).
– Create the ESQL_Create_Customer_Account message flow.
– Create the ESQL_Book_Order message flow.

450
Developing the Bookstore scenario using ESQL – Steps
– Configure Input and Output Queue Nodes.
– Configure Database Node.
– Write ESQL for Database, Compute Nodes.
– Create Queue Manager and Local Queues.
– Create Broker Application Archive (BAR) File.
– Create Broker and Execution Group.
– Deploying the ESQL Bookstore message flows.
– Create the Test Environment.
– Test the ESQL Bookstore message flows.
Code Examples
– ftp://www.redbooks.ibm.com/redbooks/SG247137

Developing Message Flow Applications using

453
Agenda
– The Java Compute Node
– Java and the Java editor in the Message Brokers Toolkit
– Inserting data into a database using a message flow
– Transforming a message from one XML structure to another
– LAB 4 - Connecting with Database (Bookstore Application)

454
The Java Compute Node
– Use the JavaCompute node to work with messages using the
Java language.
– Those with Java skills can use the JavaCompute node to code
the logic of a flow wholly in Java.
– Capabilities of the JavaCompute Node
• Route messages based on message content
• Enrich a message as it passes through the node
• Create a new output message
• Use other capabilities provided by the Java language

455
– General purpose programmable
node
– Java programming language
– High Performance for processing logic
and tree access
– Offers “Compute node” alternative
for Java programmers
– Similar “look and feel”
– No ESQL skill or experience required

456
The Java Compute Node – Revisited
– Capabilities of the JavaCompute Node
• Examine an incoming message and, depending on its content,
propagate it unchanged to one of the node's output terminals.
• The node behaves in a similar way to a Filter node, but uses
Java instead of ESQL to determine which output terminal to
use.
• Change part of an incoming message and propagate the
changed message to one of the output terminals.
• Interact with a database through a JDBC type 4 connection to
modify the content of the message or the database and pass
on one or more new messages
• Create and build a new output message that is totally
independent of the input message.

457
Creating the Code for Java Compute Node.
– Example:
http://www.ibm.com/developerworks/websphere/library/techarticl
es/0605_crocker/0605_crocker.html

460
LAB 3: Simple Message Flow Application
– The Simple message flow application demonstrates how to build
a very basic message flow.
Example
Page (101-110), WebSphere Message Broker Basics
(sg247137).pdf

461
LAB 4: Bookstore scenario using Java
– In this section, we create a more complex message flow
application that is based around the scenario of an online
bookstore.
– The Bookstore scenario message flows process messages with
different structures, and interact with databases to update
database tables.
– The Bookstore scenario includes two message flows
• The Java_Create_Customer_Account message flow
• The Java_Book_Order message flow

462
Developing the Bookstore scenario using Java
– Bookstore message flow application
• The Java_Create_Customer_Account message flow
– This message flow uses Java in a JavaCompute node to
create accounts in a DB2 database table for new customers
who have registered their details with the bookstore, for
example, their contact details and delivery address.
• The Java_Book_Order message flow
– This message flow uses Java in a JavaCompute node to
process an order that has been submitted by an online
customer and create a response message to confirm the order
with a unique order number.
Example

463
Developing the Bookstore scenario using Java - Steps
– Create the Bookstore scenario database (BSTOREDB).
– Create the JAVA_Create_Customer_Account message flow.
– Create the JAVA_Book_Order message flow.

464
Developing the Bookstore scenario using Java - Steps
– Configure Input and Output Queue Nodes.
– Write Java Class for Compute Node for both Message Flows.
– Create Queue Manager and Local Queues.
– Create Broker Application Archive (BAR) File.
– Create Broker and Execution Group.
– Deploy the Java Bookstore Message Flows.
– Create the Test Environment.
– Test the Java Bookstore Message Flows.
Code Examples
– ftp://www.redbooks.ibm.com/redbooks/SG247137

Developing Message Flow Applications
using Mappings

467
Agenda
– Message Sets and Message Definitions
– The Message Set Editor
– The Message Definition Editor
– The Message Mapping Editor
– LAB 6 - Simple Mapping Concept

468
Message Sets and Message Definitions
– A message set is a template that defines the structure of the
messages that are processed by a message flow.
– A message definition:
• held externally to the message in the message set
• when the message set is deployed, the definition is compiled into a
dictionary.
• When the message flow is processing a message, the message flow
can refer to this dictionary, which is held in the broker
– If the messages do not conform to the structure defined in the
message set, the message flow cannot process them.
– The Mapping node enables you to map fields from one message
to another without having to write the complex ESQL or Java that
you would have to write for a Compute node or JavaCompute
node to perform the equivalent function.

469
– Messages have
– Physical Formats
– Logical Formats
– The physical format defines the format or formats that the
message flow can process, for example, XML or Tagged
Delimited Strings (TDS).
– You can edit the physical format of messages in the Message
Brokers Toolkit using the graphical Message Set editor
– The logical format defines the organization of the content in the
message body—the message structure.
– You can edit the logical format of messages in the Message
Brokers Toolkit using the graphical Message Definition editor

470
– Resources in Message Set
– Message set file messageSet.mset
– Message definition files that have the suffix .mxsd
– WSDL files that have the suffix .wsdl
– Message category files that have the suffix .category

471
– Message set file – messageSet.mset
• There is always one, and only one, messageSet.mset file in a
message set.
• This file contains message model properties that are common
to all the content of the message set.
• It is also where you define the physical formats that you want
for this message set.
• These can be Custom Wire Format (CWF), Tagged Delimited
String Format (TDS), and XML Wire Format (XML).
• The file is created for you when a new message set is created,
and you manipulate its content with the Message Set Editor.

472
– Message definition files that have the suffix .mxsd
• A message definition file contains the messages, elements,
types and groups which make up a message set.
• You can have many message definition files in a message set.
Each file contains the logical model and the associated
physical model, in XML Schema form, for a group of related
messages.
• Every message set requires at least one message definition
file to describe its messages.
• Message definition files use the XML Schema language to
describe the logical format of one or more messages.

473
– WSDL files that have the suffix .wsdl
• These files are used by the SOAP domain. You can have
many WSDL files in a message set.
– Message category files that have the suffix .category
• These files are optional. You can have many message
category files in a message set.
• A message category provides another way of grouping your
messages, perhaps for documentation purposes, or to assist
with generating Web Services Description Language (WSDL)
files.

474
– When you have completed the resources in your message set,
you can generate the content of the message set in a form that
can be used by a broker parser or an application as:
• a message dictionary for deployment to a broker
• XML Schema for use by an application building XML
messages, or for deployment to a broker
• Web Services Description Language (WSDL) for a Web
services client, or for deployment to a broker
• documentation to give to programmers or business analysts

476
The Message Definition Editor

477
The Message Mapping Editor

479
LAB 5: Simple Message Flow using Mappings
– Developing a Simple Message Flow using Mappings
– The Simple message flow application demonstrates how to build a very
basic message flow from three nodes.
– The Mapping Simple message flow takes an XML input message from
a WebSphere MQ queue, uses mappings in a Mapping node to build
an XML output message that has the same contents as the input
message, then puts the output message on another WebSphere MQ
queue.
Hello World Example
Code Samples:
ftp://www.redbooks.ibm.com/redbooks/SG247137

480
LAB 6: Bookstore Scenario using Mappings
– The Bookstore message flow application is based around the
scenario of an online bookstore.
– The first message flow, Mapping_Create_Customer_Account,
uses mappings in a DataInsert node to create accounts in a DB2
database table for new customers who have registered their
details with the bookstore, for example, their contact details and
delivery address.
– The second message flow, Mapping_Book_Order, uses
mappings in a Mapping node to process an order that has been
submitted by an online customer and create a response
message to confirm the order with a unique order number.
Example
Page (160-203), WebSphere Message Broker Basics
(sg247137).pdf
Code Examples
ftp://www.redbooks.ibm.com/redbooks/SG247137

WebSphere Message Broker Installation,
Startup Configurations

483
Agenda
– Message Broker Installation
– Startup Configurations – Windows 7
– Startup Configurations – Windows XP

484
Message Broker Installation
– Message Broker Installation
– Attached the document containing the Installation of WMB 8 along with
the dependent components.
– http://www.slideshare.net/vvijayaraghava/web-sphere-message-broker-
installation-guide

485
Startup Configurations – Windows 7
– Let’s start setting up the IBM WebSphere MQSeries in a local
Windows 7 Workstation.
– Note: Some of the actions stated in this section will only persist till the
Local Workstation is running. Upon restart, you have to perform those
actions again, in order to start the MQSeries in Local Workstation.

486
– Go to: Start Menu  Control Panel  System and Security 
Administrative Tools  Computer Management
– Open this icon as “Run as Administrator” option.

487
– The following screen will be displayed.

488
– You can also do this by opening Command Prompt as Administrator.

489
– Navigate to c:Windowssystem32 and Type: compmgmt.msc
– The below screen will be displayed.

490
– Navigate to Local Users and Groups  Groups and select Administrators
and double click on it.

491
– Add your user accounts.

492
– Repeat the action for DB2ADMINS(if available), mqbrkrs, mqm Groups

493
– NOTE: You don’t need to add your names to the above groups whenever
the system restarts, except for Administrator Group. You have to add
your Name to Administrators Group every time you restart your machine.
(This is applicable if you are connecting to a network inorder to logon to
your workstation.)
– Configuring Component Services
– Go to: Start Menu  Control Panel  System and Security  Administrative
Tools  Component Services
– Open this icon as “Run as Administrator” option.
– You will get the below screen

494
– You can also open this screen from command prompt:
– Go to Command prompt and type comexp.msc:

495
– Go to Console Root  Computers  My Computer  DCOM Config 
IBM MQSeries Services

496
– Navigate to Identity Tab and Select This User radio button and enter your
User ID and our password and then click OK.
• NOTE: You have to perform this step every time you restart your machine.

497
– Go to: Start Menu  Control Panel  System and Security  Administrative
Tools  Services
– Select the Services Icon and Run as Administrator
– You can also navigate to this
screen from Command Prompt
(Command Prompt running as Administrator).

498
– Navigate to IBM MQSeries and Double Click on it.

499
– Navigate to General Tab and Click Start.

500
– Note: You have to manually start the IBM WebSphere MQSeries this way only,
every time you restart the local workstation, otherwise IBM WebSphere
MQSeries will fail to start.
– Open the IBM WebSphere Message Broker, IBM WebSphere Message Broker
Tool Kit with normal credentials only.

501
Startup Configurations – Windows XP
– Let’s start setting up the IBM WebSphere MQSeries in a local
Windows XP Workstation.
– Note: Some of the actions stated in this section will only persist till the
Local Workstation is running. Upon restart, you have to perform those
actions again, in order to start the MQSeries in Local Workstation.

502
– Go to: Start Menu  Settings  Control Panel  Administrative
Tools  Computer Management
– Navigate to Local Users and Groups Section and select Groups.
– Navigate to Administrators and double click on it.

503
– Click on Add and enter your User ID and then click on Check Names
button.

504
– Click OK. Now you can see your User ID has been added to
Administrators Group.
– Repeat the above steps for the following Groups.
– DB2ADMINS
– mqbrkrs
– Mqm
Note: You don’t need to add your names to the above groups whenever the
system restarts, except for Administrator Group. You have to add your
Name to Administrators Group every time you restart your machine.

505
Next Step:
1. Go to: Start Menu  Settings  Control Panel  Administrative Tools 
Component Services
2. Go to Component Services  Console Root  Computers  My
Computer DCOM Config  IBM MQSeries Services

506
Next Step:
1. Right Click on IBM MQSeries Services and select Properties,
2. Navigate to Identity Tab and Select This User radio button and enter user
id and workstation password and then click on OK.

507
NOTE: You have to perform this step every time you restart your machine.
Go to: Start Menu  Settings  Control Panel  Administrative Tools 
Services
Navigate to IBM MQSeries and Double Click on it.

508
• Click on Start
– Note: You have to manually start the
IBM WebSphere MQSeries this way,
whenever you restart the local
workstation, otherwise IBM WebSphere
MQSeries will fail to start.

Testing Message Flow Applications

511
Agenda
– Creating Default Configuration
– Deleting Default Configuration
– Creating Broker
– Creating MQ Queues
– Linking Queues to the Message Flow
– Packaging Applications
– Deploying Applications to Broker
– Testing using Test Client
– Testing with SoapUI Interface
– Debugging Message Flow Applications

512
Creating Default Configuration
– You can create the Default Configuration of WebSphere® Message
Broker by using Create the Default Configuration wizard.
– You can also remove the Default Configuration by using the link
provided.
– Create the Default Configuration wizard creates all the components
that you need to import and deploy the WebSphere Message Broker
samples, as well as to build your own samples.
– Here is the link: How to create default configuration

513
How to create Default Configuration
– Pre-requisites
– Startup Configurations – Windows 7 section must have been completed
successfully.
– Open IBM WebSphere Message Broker Toolkit
– Open IBM WebSphere MQ Explorer
– In the Broker Toolkit go to: File  New  Other  Create Default
Configuration

514
– Click on Next

515
– During installation it may ask you admin credentials. So please provide
the same. This process will take some time. So please be patient.

516
– If everything goes fine, the below screen is displayed. If some thing is
wrong, then you did a mistake during configuration.
– Click on Finish to close the wizard.
– Now you could see the following:
– Default Broker Instance (MB7BROKER)
– Default Queue Manager (MB7QMGR)

517
Deleting Default Configuration
– You can delete the Default Configuration of WebSphere® Message
Broker by using Remove the Default Configuration wizard.
– Remove the Default Configuration wizard removes all the
components that were created as a part of Creation of Default
Configuration process.
– Here is the link: How to delete Default Configuration

518
How to delete Default Configuration
– Pre-requisites
– You must have completed the Create Default Configuration wizard
successfully.
– Open IBM WebSphere Message Broker Toolkit
– Open IBM WebSphere MQ Explorer
– In the Broker Toolkit go to: File  New  Other  Remove Default
Configuration

519
– Click on Next

520
– Click on Next, Click on Finish to close the wizard.

521
Manual Creation
– Creating Broker
– Creating MQ Queues

522
Manual Creation
– Creating Broker
– In order to create a Broker, you must have a MQ Queue Manager
created first. So let’s create Queue Manager first.
– Navigate to MQ Explorer, right click on Queue Manager  New 
Queue Manager

523
Manual Creation
– Creating MQ Queue Manager(contd…)

524
Manual Creation

525
Manual Creation

526
Manual Creation
– Creating MQ QM(contd…)

527
Manual Creation
– Creating Broker
– Upon successful creation of MQ Queue, lets create Broker.
– Open the IBM WebSphere Message Broker Toolkit.
– Right click on the Brokers in the Brokers Tab in the left bottom corner.
– Select New  Local Broker ; Click on Finish.

528
Manual Creation
– Creating Broker (contd…)
– After entering all the details click on finish
– The Broker Creation will get started.

529
Manual Creation
– Upon successful creation of Broker, you will see the following wizard.
– Click on Close to end the wizard.

530
Manual Creation
– Upon successful creation of Broker, you will see the following wizard.
– Click on Close to end the wizard.

531
Manual Creation
– The first: In the message Broker
Tool kit
– The Second: In the MQ Explorer
– You could see the new broker now at two places.

532
Testing Message Flow Applications Contd…
– The following points will be discussed in the Hello World Message Flow
Application

533
Create and Deploy Bar File
Server Project
Message Flow Project Message Set Project
Execution Group
compiled message flow (.cmf)
dictionary (.dictionary)
Broker Archive (.bar)
Configuration
Manager
Broker
Message Flow Message Set
"Root"
Report
"Body"
"Root"
Report
"Body"
Broker
refers to
pack (zip)Create BAR and include
contents
Configure queues,
DSNs for broker
environment
(Deployment
Descriptor)
Drag BAR into
execution group
(deploy)
unzip

534
Testing Message Applications – Using Test Client
– You can test message flows in a safe environment before they are
used on a production system by using the Test Client.
– You can use the Test Client to send test messages to message flows
that use WebSphere® MQ, JMS, SOAP, or HTTP input nodes. The Test
Client monitors the output nodes in the message flow, and can provide
information about the path that a test message takes through a
message flow. The Test Client can also provide information about
errors that are generated by the message flow.
– You can test message flows in the context of an application or library,
or you can test flows in isolation.
– You can complete the following tasks by using the Test Client:
– Testing a message flow
– Configuring the test settings
– Creating and editing a test message
– Using the Test Client in trace and debug mode

535

536

537
– Create Enqueue and Dequeue
– Configure Invoke Message Flow
• Go to Configuration Tab  Deployment  Specify Broker
Archive File  <give the location of BAR File>
• Go to Configuration Tab  Deployment  Deployment
Location  <select the Broker and Execution group> 

538

539
– Configure Enqueue
– Configure Dequeue

540

541
Testing Message Applications – Using Soap UI
– Navigate to Start Menu and locate Soap UI. If not installed,
please get it from http://www.soapui.org/
– Please go with free download option.

542
Testing Message Applications – Using Soap UI
– For a quick understanding of How to create a new project and
test your first application using Soap UI, please refer to the
following URL:
– http://www.soapui.org/Getting-Started/your-first-soapui-project.html
– The complete usage of Soap UI is available in the below URL:
– http://www.soapui.org/About-SoapUI/what-is-soapui.html

543
Debugging Message Flow Applications

544
 You may find this guide useful whenever you need to start
debugger sessions in your WMB Toolkit, specially when running
the emulators. Note that this is not a fixed process of debugging
and deployment and the information provided here may be
changed during the project’s lifecycle.
 Debugging Messages
 http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etools.
mft.doc/ag11355_.htm
 Debugging ESQL
 Debugging Java
 Debugging using Trace

545
Please refer to the following sites for more information about WMB
debugger:
 Attaching the flow debugger to an execution group for debugging
 http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.i
bm.etools.mft.doc/ag11186_.htm
 Attaching the flow debugger to an execution group for debugging
 http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ib
m.etools.mft.doc/ag11186_.htm
 Debugging a message flow
 Debug: ending a session

546
To attach the debugger to a server, please keep these guidelines in
mind:
 Finish the changes in the application
 Attach the debugger
 Run a sample message to validate if any change is required
 Stop the debugger
 Clean the debugger window
 Change the application
 Attach the debugger again
 Stop the debugger session and clean the debugger window

547
– Start the debugger and put break points in desired places of the flows or
ESQL files

548
– In the Web Service client (SOAP UI), increase the timeout of the request,
for example 10 or 15 minutes)
– This is necessary because the debug process may take long time and, to
avoid time outs, just increase the amount of time the Web Service clients
waits until it times out the message call.
– Send a request from Web Service client (SOAP UI)
– The WMB receives focus and the flow stops in the first break point

549

550
– Use the options in “Run” menu to move the process to the next step. For
example:F6 and F8.
– Note the number of the Thread running at a given moment.
– The debug command (F6, F8 etc.) affects the current thread only.
– In the picture above, the current thread is the Thread 90, but in your
WMB Toolkit that thread number may be different.
– When the back end emulator is activated, then the debugger will start
more than one thread.
– If the debug process exceeds the time out set up in the Web Service
client, then an exception will be thrown either in the flow and in the Web
Service client.

551
– In the WMB flow, the time out is set up in the nodes, for example see the
following screen:

552
More information about debugger threads.
– You can see two suspended threads and their respective stack, in the
Debug view, when the back end emulator is running. Click in the first
element of the stack of one of those suspended threads to focus the flow
where the break point is highlighted.

553
– After you have finished debugging your flows, make sure to terminate all
the debugging sessions that are running in the Toolkit.
– This step is necessary to prevent the debugger port being locked by one
debugger.
– To finish the debugger sessions, right click the debugger line and choose
Terminate, or Terminate All, or Terminate and Remote options.
– Pay special attention to this step before you finish the work for the
day and you are about to close your WMB Toolkit.

554

WebSphere Message Broker Samples

557
Agenda
– WebSphere Message Broker Samples
– Application Samples
– LAB 7 – Error Handler Sample (Self Study)
– LAB 8 – Video Rental Sample (Self Study)
– LAB 9 – Message Routing sample (Self Study)
– LAB 10 – Airline Reservation Sample (Self Study)
– Technology Samples
– LAB 11 – Message Transformation – Java Compute Node Sample (Self
Study)
– LAB 12 – Message Formats – XMLNSC Validation sample (Self Study)
– LAB 13 – WebService – SOAP Nodes sample (Self Study)
– LAB 14 – WebService – RESTful Web Service Using JSON sample (Self
Study)
– LAB 15 – Address Book Sample (Self Study)
– How to run Application / Technology Samples
– Application Samples: Airline Reservation Sample – Review

558
– The WebSphere® Message Broker Toolkit provides sample
applications that show the features that are available in WebSphere
Message Broker, and how to use them.

559
– How to Open Application Samples Way – 1

560
Navigate to:
WebSphere Message Broker
Version 7.0.0.3 > Product overview
> Samples > Application samples

561

562

563
– The WebSphere® Message Broker Toolkit provides samples that
show the features that are available in WebSphere Message
Broker, and how to use them. Use these samples to learn how to
use WebSphere Message Broker.
– The samples are categorized as Application Samples and Technology
samples.
– Application Samples
– The Application samples are small end-to-end WebSphere Message
Broker applications that were created by using the WebSphere
Message Broker Toolkit.
– Technology Samples
– The Technology samples are small WebSphere Message Broker
message flow applications that each show a specific feature of
WebSphere Message Broker.
– Before you can use the samples you must Create the Default
Configuration

564
Application Samples
– The Application samples demonstrate how to transform and
route messages through message flows.
– We are going to cover the following Application Samples.
– LAB 7 – Error Handler Sample (Self Study)
– http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.eto
ols.mft.samples.errorhandler.doc/doc/overview.htm
– LAB 8 – Video Rental Sample (Self Study)
ols.mft.samples.video.doc/doc/overview.htm
– LAB 9 – Message Routing sample (Self Study)
ols.mft.samples.routing.doc/doc/overview.htm
ols.mft.samples.airline.xml.doc/doc/overview.htm

565
Technology Samples
– Each Technology sample demonstrates a specific feature of
WebSphere Message Broker; for example, how to use particular
message flow nodes, or how to use industry standard message
sets.

566
Technology Samples
– We are going to cover the following Technology Samples.
– LAB 11 – Message Transformation – Java Compute Node Sample (Self
Study)
– http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etool
s.msgbroker.samplesgallery/doc/transformation.htm
– LAB 12 – Message Formats – XMLNSC Validation sample (Self Study)
s.msgbroker.samplesgallery/doc/formats.htm
– LAB 13 – WebService – SOAP Nodes sample (Self Study)
s.mft.samples.SOAPNodes.doc/doc/overview.htm
– LAB 14 – WebService – RESTful Web Service Using JSON sample (Self
Study)
s.mft.samples.jsonrest.doc/doc/overview.htm
– LAB 15 – Address Book Sample (Self Study)
s.mft.samples.wssecsamp.doc/doc/overview.htm

567
How to run Application / Technology Samples
– For each example you could see the following sections:
Heading Brief Description
Read about the sample Provides more description about the sample.
Set up the database This hyperlink is available for only those
samples, where the Database connectivity is
required.
Import and Deploy the sample This option imports the sample files into your
workspace and deploys the sample to the
broker. This option also sets up additional
resources for the sample, for example,
WebSphere MQ queues.
Import the sample This option imports the sample files into your
workspace. Additional manual steps might be
required to configure the sample for testing.
Run the sample This option will run the Application / Technology
Sample.
Build it yourself This option will enable to build and run the
sample manually.

568
How to run Application / Technology Samples contd…
– For each example you could see the following sections:
Note: You can import or import and deploy a sample only when you use the
information center that is integrated with the WebSphere Message Broker
Toolkit.
Heading Brief Description
Cleaning up the database. When you have finished with the sample, you
can remove the database,
This hyperlink is available for only those
samples, where the Database connectivity is
required.
Remove the sample from the broker,
but leave its resources in the workspace
When you have finished with the sample, you
can remove it. Using this option will remove the
sample from Broker but not from the
workspace.
Remove the sample from the broker
and the workspace
When you have finished with the sample, you
can remove it. Using this option will remove the
sample from Broker and from the workspace.

569
Application Samples:
Airline Reservation Sample – Review
– Lets quickly revise the following sample.
– For more information about this sample, please navigate to the
following URL:
etools.mft.samples.airline.xml.doc/doc/overview.htm

570
Application Samples:
Airline Reservation Sample – Review
– The Airline Reservations sample is a message flow application
based on the scenario of an airline reservation system.
– You can run the Airline Reservations sample by using the supplied
self-defining XML messages.
– The Airline Reservations sample demonstrates how to use a range
of message flow nodes, including the following nodes:
• AggregateControl, AggregateReply, and AggregateRequest
• Compute
• Database
• Filter
• Label and RouteToLabel
• Throw and Trace

571
Airline Reservation Sample
– The Airline Reservations sample performs the following actions:
 Reserves seats that are listed in the input message, and updates the
user database to show that seats have been reserved and that there are
now fewer seats available.
 Generates reply messages to confirm that the seats have been reserved.
 Retrieves information about the reservations that have been made, and
outputs a message containing the information.
 Requests and retrieves information about the flights and the passengers
who have reserved seats on the flights, and outputs a reply message
containing the information.
 Cancels the reservations listed in the input message, and updates the
user database to show that there are now fewer seats reserved and more
seats available on the flights.

572
– The following sections describe the Airline Reservations sample
in more detail
• The message flows
• The messages
• The database
• The WebSphere MQ queues

573
Airline Reservation Sample – Message Flows
– The Airline Reservations sample includes the following message
flows
• XML_Reservation message flow
– XML_Reservation reserves the seats listed in the
XML_Reservation input messages.
• XML_PassengerQuery message flow
– XML_PassengerQuery dynamically routes the message and
retrieves information about the reservations that have been
made.
• XML_FlightQueryOut message flow
– XML_FlightQueryOut, the aggregation fan-out flow in
XML_FlightQuery, retrieves information about a flight and the
reservations that have been made on the flight

574
Airline Reservation Sample – Message Flows
• XML_FlightQueryReply message flow
– XML_FlightQueryReply, the aggregation reply flow in
reservations that have been made on the flight,
XML_FlightQueryIn, the aggregation fan-in flow in
reservations that have been made on the flight, see About
the XML_FlightQueryIn message flow.
• XML_CancelReservation message flow
– XML_CancelReservation cancels the reservations that are
listed in the input message.

575
Airline Reservation Sample – Messages
– The Airline Reservations sample processes self-defining, or
generic, XML messages.
– A self-defining XML message carries the information about its
content and structure within the message in the form of a
document that adheres to the XML specification.
– When the message flow receives the message, the message is
identified by the generic XML parser (XMLNSC), and the
message is parsed according to the XML definitions contained
within the message itself.

576
Airline Reservation Sample – Messages
– Six self-defining XML input messages are supplied so that you
can run the message flows in the Airline Reservations sample
• Two XML_Reservation input messages
– The first message requests four seats on a flight, two in first
class and two in economy class.
– The second message requests an additional seat, on a
different flight, for one of the passengers
• Two XML_PassengerQuery input messages
– The first message requests four seats on a flight, two in first
class and two in economy class.
– The second message requests an additional seat, on a
different flight, for one of the passengers

577
Airline Reservation Sample - Messages
• One XML_FlightQuery input message
– The message requests information about a specific flight and
a list of passengers who have reservations on that flight
• One XML_CancelReservation input message
– The message requests that a list of reservations are
canceled

578
Airline Reservation Sample - Database
• The Airline Reservations sample has one database called
RESERVDB.
• The message flows in this sample directly access RESERVDB,
which contains two database tables called XMLFLIGHTTB and
XMLPASSENGERTB.

579
Airline Reservation Sample – MQ Queues

580
Setting up Database (DB2)
om.ibm.etools.mft.samples.airline.xml.doc/doc/create_db_reserv
db.htm
Running the Airline Reservation Sample
om.ibm.etools.mft.samples.airline.xml.doc/doc/running.htm

Troubleshooting and Problem Determination

583
Agenda
– Locating Error Information
– Event Messages
– Messages within the Message Broker Toolkit
– Diagnostic Messages

584
Locating Error Information
– Event Messages
• Event messages showing errors are usually the first indication
that a problem may exist and must be resolved in some part of
the WebSphere Message Broker’s configuration or deployed
applications.
• These messages are displayed in:
– Message Brokers Toolkit
– in the operating system logs
– on the command line in response to a command or a
command-line utility

585
– Event messages generated by the WebSphere Message Broker
have the following structure:
• BIP8081E
– BIP is the three-character product family identity, the same as in
previous versions of the product.
– The four-character number (8081)following BIP is the unique
identifier of the message. This indicates the condition that
generated the message in the product and can be looked up in
the product help or message catalog for further information.
– The final character (E) indicates the event message type: I for an
Information message, W for a Warning message, or E for an
Error message.
– Diagnostic Messages Complete List:
• http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/inde
x.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fay66001_.htm

586
– Event Message Types
• Information
• Warning
• Error

587
– Messages within the Message Broker Toolkit
• Pop-up messages
• Problems view
• Alerts view
• Message Brokers Toolkit Event Log
• Windows Event Viewer

588
– Popup Messages

589
– Problems View
– Alerts View

590
– Message Broker Toolkit Event Log

591
– Windows Event Viewer

592
– Windows Event Viewer (contd..)

593
– Windows Event Viewer (contd..)

596
Reference Library
– WebSphere Message Broker Reference Library Online

597
Reference Documentation
– SQL Functions
• http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.
• http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/index.jsp?topic
=%2Fcom.ibm.etools.mft.doc%2Fak01080_.htm
– ESQL Statements
– ESQL Operators
– ESQL Datatypes
etools.mft.doc/ac05920_.htm
– Special characters, case sensitivity, and comments in ESQL
– ESQL Reserved Keywords

598
– ESQL NonReserved Keywords
– Test Client
etools.mft.doc/af52104_.htm
– Troubleshooting
etools.mft.doc/au09090_.htm
– Using the Select Function
– Developing Message Flow Applications
etools.mft.doc/bc88710_.htm
– ESQL Comparison Operators

599
– Developing ESQL
– Parsers
– WebSphere Message Broker Samples
etools.mft.doc/ax20230_.htm
– ESQL PDF
• http://www.ibm.com/search/csass/search?q=ESQL&cc=zz&en=utf&co=us
&sn=mh&lang=en&lo=any&o=60
– Interaction with Databases using ESQL

600
– Other Important Links
– http://www-01.ibm.com/software/integration/wmq/wmq-library/
– https://www14.software.ibm.com/webapp/iwm/web/signup.do?source=sw
-
app&S_PKG=mq_messaging_mm&S_TACT=109KA1PW&S_CMP=web_
ibm_ws_appint_ct_wmq-lb
– http://www.ibm.com/developerworks/websphere/library/techarticles/0510_
tan/0510_tan.html
– http://www-01.ibm.com/software/integration/wbimessagebroker/library/
– Quick Tour:
etools.mft.quicktour.doc/doc/WMB_BusinessNeeds/tour.html?noframes=t
rue
etools.mft.quicktour.doc/doc/WMB_Concepts/tour.html?noframes=true

601
Other Important Links
– The diagnostic messages list found in the link above is useful to find out the
cause of the error occurred during debug. You can also find this list of
errors in Tollkit's Help.
• http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/index.jsp?topic
=%2Fcom.ibm.etools.mft.doc%2Fay66001_.htm
– Quick Tour
• http://publib.boulder.ibm.com/infocenter/wbihelp/v6rxmx/topic/com.ibm.et
ools.mft.quicktour.doc/quick_tour/quick_tour.html?noframes=true
– Using the new Applications and Libraries feature in WebSphere Message
Broker V8
• http://www.ibm.com/developerworks/websphere/library/techarticles/1112_
quan/1112_quan.html
– Routing mechanisms in WebSphere Message Broker V7
• http://www.ibm.com/developerworks/websphere/library/techarticles/1107_
rajan/1107_rajan.html

WebSphere Message Broker Application Development Training

Prepared by: Vijaya Raghava
Contact Me: +91.900.076.7644
Email ID: vvijayaraghava@hotmail.com
Prepared and Updated on: July 19, 2013
Version 1.51

WebSphere Message Broker Application Development Training

More Related Content

What's hot (20)

Similar to WebSphere Message Broker Application Development Training (20)

Recently uploaded (20)

WebSphere Message Broker Application Development Training