WebSphere Message Broker Application Development Training

  • 18,835 views
Uploaded on

IBM WebSphere Message Broker Application Development Presentation gives introduction to WMB and MQ concepts. …

IBM WebSphere Message Broker Application Development Presentation gives introduction to WMB and MQ concepts.

Proficiency Level: Beginner to Intermediate.

This document should not be considered as reference for WMB and MQ concepts. This is only an understanding document.

Please post your comments/reviews/suggestions/complaints here or email me: vvijayaraghava@hotmail.com

I tried to upload the Powerpoint presentation, but the document is not getting uploaded. Hence uploading the presentation in the form of PDF.

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
18,835
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1,380
Comments
0
Likes
13

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Prepared by: V Vijaya Raghava WebSphere Message Broker Concepts, Technical Walkthrough, Application Development
  • 2. 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. 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. 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. 5 Agenda contd…  Enterprise Service Bus  Different kinds of ESB  Examples of ESB  Various Middleware Products
  • 6. 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. 7 Agenda contd…  Publish & Subscribe  Publish & Subscribe – Implementation  WebSphere MQ Interoperability  WMB Components  Development Environment  Runtime Environment  WMB Components – Interaction
  • 8. 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. 9  WebSphere Message Broker – Built-in Nodes  WebSphere Information Centre Agenda contd…
  • 10. 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. 11 Agenda contd…  Technical Introduction to WebSphere MQ  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. 12 Agenda contd…  Technical Introduction to WebSphere MQ  Deployment Process using MQ Explorer  Message Broker Queue Explorer  Transformation interfaces
  • 13. 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. 14 Agenda contd…  Developing Applications using ESQL  LAB 1 - Simple Hello World Application  Developing Applications using ESQL  LAB 2 - Bookstore Application
  • 15. 15 Agenda contd…  Developing Applications using Java – Concepts  Developing Applications using Java – Labs  LAB 3 - Simple Hello World Application  LAB 4 - Connecting with Database (Bookstore Application)
  • 16. 16 Agenda contd…  Developing Applications using Mappings – Concepts  LAB 5 - Simple Hello World Application  Message Sets and Message Definitions  The Message Set Editor  The Message Definition Editor  The Message Mapping Editor  LAB 6 - Simple Mapping Concept
  • 17. 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. 18 Agenda contd…  WebSphere Message Broker Examples  Application Samples  LAB 7–10  Technology Samples  LAB 11–15  Troubleshooting & Problem Determination  Documentation
  • 19. 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)
  • 20. Application Integration
  • 21. 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. 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. 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. 24 Introduction to Application Integration – 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. 25 Introduction to Application Integration – 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. 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. 27 Challenges and Issues Businesses facing today  Lack of business process standards • Architectural policy limited  Point application buys to support redundant LOB needs  Inflexible infrastructure built over time, no roadmap
  • 28. 28 Challenges and Issues Businesses facing today 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. 29 Challenges and Issues Businesses facing today How to move forward
  • 30. 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. 31 The Complexity of Application Integration A B CD E
  • 32. 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. 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. 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. 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. 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. 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. 38 Defining EAI contd… User Interface level Data level App Interface level Method level Legacy Data Packaged Application Business Process
  • 39. 39 Defining EAI contd… – 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. 40 Defining EAI contd… – 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. 41 Defining EAI contd… – 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. 42 Defining EAI contd… – Enterprise Chaos
  • 43. 43 Defining EAI contd… – Application Complexity increases as technology is added WebSphere MQ soap/http soap/jms http File MQ/JMS
  • 44. 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. 45 Defining EAI contd… – Using EAI Technology to bring order to the enterprise
  • 46. 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. 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. 48 Types of EAI Contd… – 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. 49 Types of EAI Contd… – 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. 50 Types of EAI Contd… – 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. 51 Types of EAI Contd… – 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. 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. 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
  • 54. ?
  • 55. Service Oriented Architecture – Introduction
  • 56. 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
  • 57. 57 Current Environment
  • 58. 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. 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. 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. 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. 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. 63 Applications can be composed of or exposed as Services
  • 64. 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. 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. 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. 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. 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
  • 69. 69 Before SOA – After SOA
  • 70. 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. 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. 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. 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. 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. 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. 76 SOA is an evolutionary step for architecture
  • 77. 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. 78 Expanding SOA Footprint Business Unit 1 Business Unit 3 Business Unit 2
  • 79. 79 SOA Principles (self study)  Standardized Service Contracts  Loose Coupling  Abstraction  Reusability  Autonomy  Statelessness  Discoverability  Composability
  • 80. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  • 90. ?
  • 91. Enterprise Service Bus – Introduction
  • 92. 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. 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. 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. 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. 96 An ESB gives SOA its full value An ESB turns this… …into this. Service Service Service Service Service ServiceService Service Enterprise Service Bus Service Service Service Service Service ServiceService Service 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: Enterprise Service Bus
  • 97. 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. 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. 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. 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. 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. 102 ESB Example – Healthcare Integration
  • 103. 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. 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 Enterprise Service Bus New Flight Availability Service Old Flight Availability Service
  • 105. 105 ESB Example – Role of ESB in an enterprise WebSphere MQ soap/http soap/jms http File MQ/JMS Enterprise Service Bus
  • 106. 106 ESB Example – Role of ESB across different businesses
  • 107. 107 Various Middleware Products TIBCO Microsoft Biztalk Server Oracle Fusion Middleware WebMethods Progress Openedge Jboss Enterprise Middleware IBM WebSphere Message Broker
  • 108. 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. 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. 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. 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.
  • 112. ?
  • 113. Introduction to IBM WebSphere Message Broker
  • 114. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etools.mft. quicktour.doc/doc/quick_tour.html – Quick tour: WMB 8.x – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etools.mft. quicktour.doc/doc/quick_tour.html – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etools.mft. quicktour.doc/doc/WMB_BusinessNeeds/tour.html
  • 127. 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. 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. 129 WMB – Database Support – DB2 – Informix – Microsoft SQL Server – Oracle – Sybase
  • 130. 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. 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. 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. 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. 134 Mergers and Acquisitions Scenario – 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. 135 Mergers and Acquisitions Scenario – 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. 136 WebSphere Message Broker – Architecture
  • 137. 137 WebSphere Message Broker – Architecture
  • 138. 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. 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. 140 WMB – Capabilities (contd.) – 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. 141 WMB – Capabilities (contd.) – 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. 142 WMB – Capabilities (contd.) – 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. 143 WMB – Capabilities (contd.) 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. 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. 145 WMB – Capabilities (contd.) – Message Transformation and Enrichment – 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. 146 WMB – Capabilities (contd.) – 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. 147 WMB – Capabilities (contd.) – 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. 148 WMB – Capabilities (contd.) – Message Transformation and Enrichment – 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 WMB – Capabilities (contd.) – Message Transformation and Enrichment 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. 150 WMB – Capabilities (contd.) – Message Transformation and Enrichment 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. 151 WMB – Capabilities (contd.) – Message Transformation and Enrichment – 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. 152 WMB – Capabilities (contd.) – 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. 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. 154 Enterprise Messaging – Messaging Transmission
  • 155. 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. 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. 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. 158 Publish Subscribe Implementation – Contd..
  • 159. 159 Publish Subscribe Implementation – Contd..
  • 160. 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. 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. 162 Publish Subscribe – Other Examples – Magazine publishing – Airline departure notification
  • 163. 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. 164 WebSphere MQ Interoperability contd…
  • 165. 165 WMB – Components Overview
  • 166. 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. 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. 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.
  • 169. 169 Sample Message Flow
  • 170. 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. 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. 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. 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. 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. 175 Development Environment (contd.) 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. 176 Development Environment (contd.) 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. 177 Broker Application Development Perspective Toolkit Help Quick Starts Wizard Appear in the Project pane, when workspace is empty. Perspectives
  • 178. 178 Broker Application Development Perspective (contd.) Projects Brokers Properties Problems Deployment Log Node Palette
  • 179. 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. 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. 181 Runtime Environment (contd.) – 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. 182 Runtime Environment (contd.) 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. 183 Runtime Environment (contd.) 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. 184 Runtime Environment (contd.) 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. 185 Runtime Environment (contd.) 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. 186 Runtime Environment (contd.) 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. 187 Runtime Environment (contd.) 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. 188 Runtime Environment (contd.) 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. 189 Runtime Environment (contd.) 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. 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. 191 Interaction of Message Broker Main Components
  • 192. 192 Interaction of Message Broker Main Components
  • 193. 193 WebSphere Message Broker runtime architecture
  • 194. 194 Usage Patterns with Message Broker Service Enablement Service Virtualization OR OR OR Message Enablement Message Brokering File Processing Event Processing
  • 195. ?
  • 196. Introduction to IBM WebSphere MQ Explorer
  • 197. 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. 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. 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. 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.
  • 201. 201 WebSphere MQ Explorer
  • 202. 202 Broker Properties
  • 203. 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. 204 Message Flow – Revisited – 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. 205 Message Flow – Revisited – 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. 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. 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. 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. 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") Logical message format Parsed Constructed "Root" MQMD Format Report Version "Body" Order Name Supplier Order # Address Item Logical message format 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. 210 Message Model (contd.) – Models are needed for parsing, validation and transformation – Domains avoid the need to write custom code to parse messages!
  • 211. 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. 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. 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. 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. 215 Message Broker Parsers – Contd… – 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. 216 Message Broker Parsers – Contd… – 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. 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 Message Broker Parsers – Contd…
  • 218. 218 Message Broker Parsers – Contd… – 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. 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. 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. 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. 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. 223 Logical Tree Structure 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. 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. 225 Logical Tree Structure – 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. 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. 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. 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. 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. 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. 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. 232 Logical Tree Structure – XML Source
  • 233. 233 Corresponding Logical Tree Structure
  • 234. 234 Logical Tree Structure – XML Source – </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> – <Book_Price>7.99</Book_Price> – <ISBN>9736316345</ISBN> – <Book_Price>25.99</Book_Price> – </Book_Details> – </Create_Book_Order_MSG>
  • 235. 235 Logical Tree Structure – XML Source
  • 236. 236 Logical Tree Structure – XML Source – <?xml version=”1.0”?> – <Book_Order_Response_MSG> – <Customer_ID>0123456789</Customer_ID> – <Order_Number>0123456789TIMESTAMP &apos;2002-10-20 – 12:00:00&apos;</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> – <Book_Price>15.99</Book_Price> – <ISBN>1425112342</ISBN> – <Book_Price>7.99</Book_Price> – <ISBN>9736316345</ISBN> – <Book_Price>25.99</Book_Price> – </Book_Details> – <Total_Price>49.97</Total_Price> – <Order_Status>Order Received</Order_Status> – </Book_Order_Response_MSG>
  • 237. 237 Logical Tree Structure – XML Source
  • 238. 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
  • 239. ?
  • 240. WebSphere Message Broker Software – Components
  • 241. 241 Agenda – Message Broker Toolkit components – Message Broker Toolkit – IDE – Perspectives in Message Broker Toolkit – Resources in WebSphere Message Broker
  • 242. 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. 243 Message Broker Toolkit – IDE
  • 244. 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. 245 Perspectives in Message Broker Toolkit – Broker Administration Perspective ( Available only with versions <v7.0)
  • 246. 246 Perspectives in Message Broker Toolkit – Broker Application Development perspective
  • 247. 247 Perspectives in Message Broker Toolkit – Debug Perspective
  • 248. 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. 249 Resources in WebSphere Message Broker contd..
  • 250. 250 Resources in WebSphere Message Broker contd.. – 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. 251 Resources in WebSphere Message Broker contd.. – .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. 252 Resources in WebSphere Message Broker contd.. – 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. 253 Resources in WebSphere Message Broker contd.. – 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. 254 Resources in WebSphere Message Broker contd.. – 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
  • 255. ?
  • 256. WebSphere Message Broker - Built-in Nodes
  • 257. 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. 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. 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. 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. 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
  • 262. 262 Built-in Nodes (WMB v7)
  • 263. 263 Built-in Nodes (WMB v7) contd…
  • 264. 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. 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. 266 WebSphere MQ – The following list of nodes will be covered in this section – MQInput – MQOutput – MQReply – MQGet – MQHeader
  • 267. 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. 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. The output terminal to which the message is routed if it is successfully retrieved from the WebSphere MQ queue. The output terminal to which the message is routed if an exception is thrown downstream and caught by this node.. Out
  • 269. 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. 270 WebSphere MQ – MQOutput 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. The output terminal to which the message is routed if it is successfully retrieved from the WebSphere MQ queue. The input terminal that accepts a message for processing by the node. In
  • 271. 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. 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. 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. 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. 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. 276 WebSphere MQ – MQHeader contd.. Terminal Description 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. 277 WebServices – The following list of nodes will be covered in this section – SOAPInput node – SOAPReply node – SOAPRequest node – SOAPEnvelope node – SOAPExtract node
  • 278. 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. 279 WebServices – SOAPInput contd… Terminal Description 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. 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. 281 WebServices – SOAPReply contd… Terminal Description 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. 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. 283 WebServices – SOAPRequest contd… Terminal Description 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. 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. 285 WebServices – SOAPEnvelope contd… Terminal Description 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. 286 WebServices – SOAPEnvelope – Example SOAP Messages:
  • 287. 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. 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. 289 WebServices – SOAPExtract contd… Terminal Description 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). Failure The output terminal to which the message is routed if a failure is detected during processing.
  • 290. 290 HTTP – The following list of nodes will be covered in this section – HTTPInput node – HTTPReply node – HTTPRequest node – HTTPHeader node
  • 291. 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. 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. 293 HTTP – HTTPInput contd… Terminal Description 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. 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. 295 HTTP – HTTPReply contd… Terminal Description 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 in this message flow.
  • 296. 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. 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. 298 HTTP – HTTPRequest contd… – 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. 299 HTTP – HTTPRequest contd… Terminal Description 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 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. 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. 301 HTTP – HTTPHeader contd… Terminal Description 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 during extraction. Out The output terminal to which the transformed message is routed if the input message is processed successfully.
  • 302. 302 Routing – The following list of nodes will be covered in this section – Filter node – Label node – Publication node – RouteToLabel node – Route node – AggregateControl node – AggregateReply node – AggregateRequest node – Collector node – Resequence node – Sequence node
  • 303. 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. 304 Routing – Filter node contd… Terminal Description 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 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. 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. 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. 307 Routing – Route node contd… Terminal Description 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. 308 Transformation – The following list of nodes will be covered in this section – .NETCompute node – Mapping node – XSLTransform node – Compute node – JavaCompute node – PHPCompute node
  • 309. 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. 310 Transformation – Mapping node contd… – Mapping Node
  • 311. 311 Transformation – Mapping node contd… Terminal Description In The input terminal that accepts a message for processing by the 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. 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. 313 Transformation – Compute node contd… Terminal Description 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 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 message might be routed by a PROPAGATE statement. Out3 The third alternative output terminal to which the transformed message might be routed by a PROPAGATE statement. Out4 The fourth alternative output terminal to which the transformed message might be routed by a PROPAGATE statement.
  • 314. 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. 315 Transformation – JavaCompute node contd… Terminal Description 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 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. 316 Construction – The following list of nodes will be covered in this section – Input node – Output node – Throw node – Trace node – TryCatch node – FlowOrder node – Passthrough node – ResetContentDescriptor node
  • 317. 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. 318 Construction – Input node contd… Terminal Description Out The input terminal that delivers a message to the subflow.
  • 319. 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. 320 Construction – Output node contd… Terminal Description In The output terminal that defines an out terminal for the subflow.
  • 321. 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. 322 Construction – Throw node contd… Terminal Description In The input terminal that accepts a message for processing by the node.
  • 323. 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. 324 Construction – Trace node contd… Terminal Description In The input terminal that accepts a message for processing by the node. Out The output terminal through which the message is propagated.
  • 325. 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. 326 Construction – TryCatch node contd… Terminal Description In The input terminal that accepts a message for processing by the 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. 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. 328 Construction – FlowOrder node contd… Terminal Description 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 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. 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. 330 WebSphere Information Center – View, Browse and search online information • With in the WebSphere Message Broker Toolkit
  • 331. 331 WebSphere Information Center – contd… – View, Browse and search online information • Within the WebSphere Message Broker Explorer
  • 332. 332 WebSphere Information Center – contd… – View, Browse and search online information • From the Internet on IBM Public Website • http://www-01.ibm.com/software/integration/messagebrokerproductline/ • http://www-01.ibm.com/software/integration/wbimessagebroker/library/
  • 333. ?
  • 334. Technical Introduction to WebSphere MQ
  • 335. 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. 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. 337 Introduction to WebSphere MQ – Today’s Enterprise IT Environment
  • 338. 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. 339 Service Oriented Architecture – Revisited
  • 340. 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. 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. 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. 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. 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. 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. 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. 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. 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. 349 Program-to-Program Communication Factors – Time Independence – Protocol Support – Assured Delivery of Information – Data Conversion
  • 350. 350 Time Independence
  • 351. 351 Three Styles of Communication
  • 352. 352 Three Styles of Communication Contd…
  • 353. 353 WebSphere MQ – Eliminates application network concerns.
  • 354. 354 Local and Remote Queue Concept
  • 355. 355 Message Queue Interface
  • 356. 356 Message Queue Interface – Calls
  • 357. 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. 358 Message Composition contd…
  • 359. 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. 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.
  • 361. 361 Message Persistance
  • 362. 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. 363 Queue Manager – Heart of MQSeries Runtime program. – Job is to manage queues of messages.
  • 364. 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. 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. 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.
  • 367. 367 Queues Expiry
  • 368. 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. 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. 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. 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. 372 Message Broker Queue Explorer
  • 373. 373 WebSphere Message Broker Environments
  • 374. ?
  • 375. Introduction to ESQL
  • 376. 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. 377 Pre-requisites – Knowledge in SQL, Stored Procedures.
  • 378. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 392 ESQL – Basic Statements contd… – 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. 393 ESQL – Basic Statements contd… – 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'; WHEN minimum + 1 THEN SET description = 'medium'; WHEN minimum + 2 THEN 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. 394 ESQL – Basic Statements contd… – 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. 395 ESQL – Basic Statements contd… – CREATE MODULE statement (Self Study) – . – Example: – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/c om.ibm.etools.mft.doc/ak04965_.htm
  • 396. 396 ESQL – Basic Statements contd… – CREATE PROCEDURE statement (Self Study) – . – Example: – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/c om.ibm.etools.mft.doc/ak04970_.htm
  • 397. 397 ESQL – Basic Statements contd… – 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. 398 ESQL – Basic Statements contd… – DECLARE statement – 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. 399 ESQL – Basic Statements contd… – DECLARE statement – 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. 400 ESQL – Basic Statements contd… – DECLARE statement – 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. 401 ESQL – Basic Statements contd… – DECLARE statement – 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. 402 ESQL – Basic Statements contd… – 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. 403 ESQL – Basic Statements contd… – 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. 404 ESQL – Basic Statements contd… – 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. 405 ESQL – Basic Statements contd… – 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. 406 ESQL – Basic Statements contd… – 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. 407 ESQL – Basic Statements contd… – 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. 408 ESQL – Basic Statements contd… – RETURN statement – 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. 409 ESQL – Basic Statements contd… – RETURN statement – 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. 410 ESQL – Basic Statements contd… – RETURN statement – 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. 411 ESQL – Basic Statements contd… – RETURN statement – 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. 412 ESQL – Basic Statements contd… – 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. 413 ESQL – Basic Statements contd… – 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. 414 ESQL – Basic Statements contd… – 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. 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. 416 ESQL – Message Tree Manipulation Statements – 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. 417 ESQL – Message Tree Manipulation Statements – 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'; SET Environment.SourceData.Folder[1].Field2 = 'Field12Value'; SET Environment.SourceData.Folder[2].Field1 = 'Field21Value'; SET Environment.SourceData.Folder[2].Field2 = 'Field22Value'; 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. 418 ESQL – Message Tree Manipulation Statements – 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. 419 ESQL – Message Tree Manipulation Statements – 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. 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. 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. 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: – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm. etools.mft.doc/ak05020_.htm
  • 423. 423 ESQL Statements (contd.) – More information about ESQL Statements: • http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic /com.ibm.etools.mft.doc/ak04900_.htm
  • 424. 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. 425 ESQL Functions – Self Study – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/c om.ibm.etools.mft.doc/ak19550_.htm
  • 426. 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. 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. 428 Functions, Procedures (contd.)
  • 429. 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: – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.i bm.etools.mft.doc/ak04861_.htm
  • 430. 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. 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. 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: • http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic /com.ibm.etools.mft.doc/ak04890_.htm
  • 433. 433 ESQL Special Characters
  • 434. 434 ESQL Code Conventions – ESQL Special Characters – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.i bm.etools.mft.doc/ak04870_.htm – ESQL code conventions in WebSphere Message Broker • http://www.ibm.com/developerworks/websphere/library/techarti cles/0803_shen/0803_shen.html
  • 435. 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. 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. 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 – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.i bm.etools.mft.doc/ac06000_.htm
  • 438. ?
  • 439. Developing Message Flow Applications using ESQL
  • 440. 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. 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. 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.
  • 443. 443 ESQL Editor
  • 444. 444 Time for an Exercise
  • 445. 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. 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 Page (79-94), WebSphere Message Broker Basics (sg247137).pdf
  • 447. 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. 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. 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. 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
  • 451. ?
  • 452. Developing Message Flow Applications using
  • 453. 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 3 - Simple Hello World Application – LAB 4 - Connecting with Database (Bookstore Application)
  • 454. 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. 455 The Java Compute Node – 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. 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. 457 The Java Compute Node Creating the Code for Java Compute Node. – Example: http://www.ibm.com/developerworks/websphere/library/techarticl es/0605_crocker/0605_crocker.html
  • 458. 458 The Java Editor
  • 459. 459 Time for an exercise
  • 460. 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. 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. 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 Page (110-133), WebSphere Message Broker Basics (sg247137).pdf
  • 463. 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. 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
  • 465. ?
  • 466. Developing Message Flow Applications using Mappings
  • 467. 467 Agenda – Message Sets and Message Definitions – The Message Set Editor – The Message Definition Editor – The Message Mapping Editor – LAB 5 - Simple Hello World Application – LAB 6 - Simple Mapping Concept
  • 468. 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. 469 Message Sets and Message Definitions – 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. 470 Message Sets and Message Definitions – 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. 471 Message Sets and Message Definitions – 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. 472 Message Sets and Message Definitions – 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. 473 Message Sets and Message Definitions – 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. 474 Message Sets and Message Definitions – 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
  • 475. 475 The Message Set Editor
  • 476. 476 The Message Definition Editor
  • 477. 477 The Message Mapping Editor
  • 478. 478 Time for an Exercise
  • 479. 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 Page (141-160), WebSphere Message Broker Basics (sg247137).pdf Code Samples: ftp://www.redbooks.ibm.com/redbooks/SG247137
  • 480. 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
  • 481. ?
  • 482. WebSphere Message Broker Installation, Startup Configurations
  • 483. 483 Agenda – Message Broker Installation – Startup Configurations – Windows 7 – Startup Configurations – Windows XP
  • 484. 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. 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. 486 Startup Configurations – Windows 7 – Go to: Start Menu  Control Panel  System and Security  Administrative Tools  Computer Management – Open this icon as “Run as Administrator” option.
  • 487. 487 Startup Configurations – Windows 7 – The following screen will be displayed.
  • 488. 488 Startup Configurations – Windows 7 – You can also do this by opening Command Prompt as Administrator.
  • 489. 489 Startup Configurations – Windows 7 – Navigate to c:Windowssystem32 and Type: compmgmt.msc – The below screen will be displayed.
  • 490. 490 Startup Configurations – Windows 7 – Navigate to Local Users and Groups  Groups and select Administrators and double click on it.
  • 491. 491 Startup Configurations – Windows 7 – Add your user accounts.
  • 492. 492 Startup Configurations – Windows 7 – Repeat the action for DB2ADMINS(if available), mqbrkrs, mqm Groups
  • 493. 493 Startup Configurations – Windows 7 – 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. 494 Startup Configurations – Windows 7 – You can also open this screen from command prompt: – Go to Command prompt and type comexp.msc:
  • 495. 495 Startup Configurations – Windows 7 – Go to Console Root  Computers  My Computer  DCOM Config  IBM MQSeries Services
  • 496. 496 Startup Configurations – Windows 7 – 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. 497 Startup Configurations – Windows 7 – 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. 498 Startup Configurations – Windows 7 – Navigate to IBM MQSeries and Double Click on it.
  • 499. 499 Startup Configurations – Windows 7 – Navigate to General Tab and Click Start.
  • 500. 500 Startup Configurations – Windows 7 – 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. 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. 502 Startup Configurations – Windows XP – 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. 503 Startup Configurations – Windows XP – Click on Add and enter your User ID and then click on Check Names button.
  • 504. 504 Startup Configurations – Windows XP – 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. 505 Startup Configurations – Windows XP 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. 506 Startup Configurations – Windows XP 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. 507 Startup Configurations – Windows XP 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. 508 Startup Configurations – Windows XP • 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.
  • 509. ?
  • 510. Testing Message Flow Applications
  • 511. 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. 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. 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. 514 How to create Default Configuration – Click on Next
  • 515. 515 How to create Default Configuration – During installation it may ask you admin credentials. So please provide the same. This process will take some time. So please be patient.
  • 516. 516 How to create Default Configuration – 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. 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. 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. 519 How to delete Default Configuration – Click on Next
  • 520. 520 How to delete Default Configuration – Click on Next, Click on Finish to close the wizard.
  • 521. 521 Manual Creation – Creating Broker – Creating MQ Queues – Linking Queues to the Message Flow – Packaging Applications – Deploying Applications to Broker
  • 522. 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. 523 Manual Creation – Creating MQ Queue Manager(contd…)
  • 524. 524 Manual Creation – Creating MQ Queue Manager(contd…)
  • 525. 525 Manual Creation – Creating MQ Queue Manager(contd…)
  • 526. 526 Manual Creation – Creating MQ QM(contd…)
  • 527. 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. 528 Manual Creation – Creating Broker (contd…) – After entering all the details click on finish – The Broker Creation will get started.
  • 529. 529 Manual Creation – Creating Broker (contd…) – Upon successful creation of Broker, you will see the following wizard. – Click on Close to end the wizard.
  • 530. 530 Manual Creation – Creating Broker (contd…) – Upon successful creation of Broker, you will see the following wizard. – Click on Close to end the wizard.
  • 531. 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. 532 Testing Message Flow Applications Contd… – The following points will be discussed in the Hello World Message Flow Application – Linking Queues to the Message Flow – Packaging Applications – Deploying Applications to Broker
  • 533. 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. 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. 535 Testing Message Applications – Using Test Client
  • 536. 536 Testing Message Applications – Using Test Client
  • 537. 537 Testing Message Applications – Using Test Client – 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. 538 Testing Message Applications – Using Test Client
  • 539. 539 Testing Message Applications – Using Test Client – Configure Enqueue – Configure Dequeue
  • 540. 540 Testing Message Applications – Using Test Client
  • 541. 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. 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. 543 Debugging Message Flow Applications
  • 544. 544 Debugging Message Flow Applications  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  http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etools. mft.doc/ag11360_.htm  Debugging Java  http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etools. mft.doc/ag11370_.htm  Debugging using Trace  http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etools. mft.doc/ag66250_.htm
  • 545. 545 Debugging Message Flow Applications 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  http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ib m.etools.mft.doc/ag11080_.htm  Debug: ending a session  http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ib m.etools.mft.doc/ag11420_.htm
  • 546. 546 Debugging Message Flow Applications 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. 547 Debugging Message Flow Applications – Start the debugger and put break points in desired places of the flows or ESQL files
  • 548. 548 Debugging Message Flow Applications – 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. 549 Debugging Message Flow Applications
  • 550. 550 Debugging Message Flow Applications – 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. 551 Debugging Message Flow Applications – In the WMB flow, the time out is set up in the nodes, for example see the following screen:
  • 552. 552 Debugging Message Flow Applications 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. 553 Debugging Message Flow Applications – 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. 554 Debugging Message Flow Applications
  • 555. ?
  • 556. WebSphere Message Broker Samples
  • 557. 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. 558 WebSphere Message Broker Samples – 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. 559 WebSphere Message Broker Samples – How to Open Application Samples Way – 1
  • 560. 560 WebSphere Message Broker Samples – How to Open Application Samples Way – 2 Navigate to: WebSphere Message Broker Version 7.0.0.3 > Product overview > Samples > Application samples
  • 561. 561 WebSphere Message Broker Samples – How to Open Application Samples Way – 2
  • 562. 562 WebSphere Message Broker Samples – How to Open Application Samples Way – 2
  • 563. 563 WebSphere Message Broker Samples – 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. 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) – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.eto ols.mft.samples.video.doc/doc/overview.htm – LAB 9 – Message Routing sample (Self Study) – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.eto ols.mft.samples.routing.doc/doc/overview.htm – LAB 10 – Airline Reservation Sample (Self Study) – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.eto ols.mft.samples.airline.xml.doc/doc/overview.htm
  • 565. 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. 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) – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etool s.msgbroker.samplesgallery/doc/formats.htm – LAB 13 – WebService – SOAP Nodes sample (Self Study) – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etool s.mft.samples.SOAPNodes.doc/doc/overview.htm – LAB 14 – WebService – RESTful Web Service Using JSON sample (Self Study) – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etool s.mft.samples.jsonrest.doc/doc/overview.htm – LAB 15 – Address Book Sample (Self Study) – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etool s.mft.samples.wssecsamp.doc/doc/overview.htm
  • 567. 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. 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. 569 Application Samples: Airline Reservation Sample – Review – Lets quickly revise the following sample. – LAB 10 – Airline Reservation Sample (Self Study) – For more information about this sample, please navigate to the following URL: – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm. etools.mft.samples.airline.xml.doc/doc/overview.htm
  • 570. 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. 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. 572 Airline Reservation Sample – The following sections describe the Airline Reservations sample in more detail • The message flows • The messages • The database • The WebSphere MQ queues
  • 573. 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. 574 Airline Reservation Sample – Message Flows • XML_FlightQueryReply message flow – XML_FlightQueryReply, the aggregation reply flow in XML_FlightQuery, retrieves information about a flight and the reservations that have been made on the flight, XML_FlightQueryIn, the aggregation fan-in flow in XML_FlightQuery, retrieves information about a flight and the 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. 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. 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. 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. 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. 579 Airline Reservation Sample – MQ Queues
  • 580. 580 Airline Reservation Sample Setting up Database (DB2) – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/c om.ibm.etools.mft.samples.airline.xml.doc/doc/create_db_reserv db.htm Running the Airline Reservation Sample – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/c om.ibm.etools.mft.samples.airline.xml.doc/doc/running.htm
  • 581. ?
  • 582. Troubleshooting and Problem Determination
  • 583. 583 Agenda – Locating Error Information – Event Messages – Messages within the Message Broker Toolkit – Diagnostic Messages
  • 584. 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. 585 Locating Error Information – 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. 586 Locating Error Information – Event Message Types • Information • Warning • Error
  • 587. 587 Locating Error Information – Messages within the Message Broker Toolkit • Pop-up messages • Problems view • Alerts view • Message Brokers Toolkit Event Log • Windows Event Viewer
  • 588. 588 Locating Error Information – Popup Messages
  • 589. 589 Locating Error Information – Problems View – Alerts View
  • 590. 590 Locating Error Information – Message Broker Toolkit Event Log
  • 591. 591 Locating Error Information – Windows Event Viewer
  • 592. 592 Locating Error Information – Windows Event Viewer (contd..)
  • 593. 593 Locating Error Information – Windows Event Viewer (contd..)
  • 594. Help Documents
  • 595. 595 Reference Books
  • 596. 596 Reference Library – WebSphere Message Broker Reference Library Online
  • 597. 597 Reference Documentation – SQL Functions • http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm. etools.mft.doc/ak19550_.htm • http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/index.jsp?topic =%2Fcom.ibm.etools.mft.doc%2Fak01080_.htm – ESQL Statements • http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm. etools.mft.doc/ak04900_.htm – ESQL Operators • http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm. etools.mft.doc/ak01035_.htm – ESQL Datatypes • http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm. etools.mft.doc/ac05920_.htm – Special characters, case sensitivity, and comments in ESQL • http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm. etools.mft.doc/ak04870_.htm – ESQL Reserved Keywords • http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm. etools.mft.doc/ak04880_.htm
  • 598. 598 Reference Documentation – ESQL NonReserved Keywords • http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm. etools.mft.doc/ak04890_.htm – Test Client • http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm. etools.mft.doc/af52104_.htm – Troubleshooting • http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm. etools.mft.doc/au09090_.htm – Using the Select Function • http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm. etools.mft.doc/ac67150_.htm – Developing Message Flow Applications • http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm. etools.mft.doc/bc88710_.htm – ESQL Comparison Operators • http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm. etools.mft.doc/ak01040_.htm
  • 599. 599 Reference Documentation – Developing ESQL • http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm. etools.mft.doc/ak09030_.htm – Parsers • http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm. etools.mft.doc/ac70570_.htm – WebSphere Message Broker Samples • http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm. 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 • http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm. etools.mft.doc/ak05800_.htm
  • 600. 600 Reference Documentation – 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: – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm. etools.mft.quicktour.doc/doc/WMB_BusinessNeeds/tour.html?noframes=t rue – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm. etools.mft.quicktour.doc/doc/WMB_Concepts/tour.html?noframes=true
  • 601. 601 Reference Documentation 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
  • 602. ?
  • 603. 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