Book Image

WSO2 Developer's Guide

By : Ramón Garrido, Fidel Prieto Estrada
Book Image

WSO2 Developer's Guide

By: Ramón Garrido, Fidel Prieto Estrada

Overview of this book

WSO2 Enterprise Integrator brings together the most powerful servers provided by the WSO2 company for your SOA infrastructure. As an Enterprise Service Bus (ESB), WSO2 Enterprise Integrator provides greater flexibility and agility to meet growing enterprise demands, whereas, as a Data Services Server (DSS), it provides an easy-to-use platform for integrating data stores, creating composite views across different data sources, and hosting data services. Using real-world scenarios, this book helps you build a solid foundation in developing enterprise applications with powerful data integration capabilities using the WSO2 servers. The book gets you started by brushing up your knowledge about SOA architecture and how it can be implemented through WSO2. It will help build your expertise with the core concepts of ESB such as building proxies, sequences, endpoints, and how to work with these in WSO2. Going further, you will also get well-acquainted with DSS data service concepts such as configuring data services, tasks, events, testing, and much more. The book will also cover API management techniques. Along with ESB and DSS, you will also learn about business process servers, the rules server and other components that together provide the control and robustness your enterprise applications will need. With practical use cases, the book covers typical daily scenarios you will come across while using these servers to give you hands-on experience.
Table of Contents (14 chapters)

Checking the payload content

When we have a service, we usually work with a lot of different payload structures in the service workflow: incoming requests, calls to a backend, error messages, responses of the backend, and so on. We need to ensure that every one of these messages have the correct format, because our service will get an error otherwise; so, part of the job when we develop a service is to check those messages.

If we don't check those messages, we'll get an unhandled exception, and the final client will be waiting for the response of the service until we get a timeout without any type of response for our service. Also, the service won't be processed (or at least, not completely) so this is not a good solution.

If we check those messages, we can leave the normal processing when the messages are good; however, in other cases, we can perform an action...