Sometimes you’re expecting a JSON, specially when publishing or consuming a REST API. But you need to make sure it’s a good JSON, not the kind of JSON that would kill you with a machete. Since the Javascript Object Notation format (JSON for short) can be used to described pretty much anything, validating that the one you received actually complies with what you expected is no simple task.
Sometimes when transforming complex data structures or applying business rules to your integration, you may face the need to add some custom code. We make our best effort to try to productize and solve every common use case we come across, but sometimes it’s just not enough. When that happens, you probably turn to the programming language you love the most for help. If you’re a Java guy, you can build your own custom components and/or transformers inside Mule.
In spite of JSON’s reign as the king of API data format, XML still remains the exchange data format of choice for a number of systems. Any service exposing functionality through SOAP, and many application built years ago (or even nowadays) still depend on XML to share data – to such an extent that in April 2013 the W3C published a new spec for version 3.0 of the XPath, XSLT and XQuery standards.
“Logs are like car insurance. Nobody wants to pay for it, but when something goes wrong everyone wants the best available” – Pablo Kraan
The phrase above fully explains why logs are important and why we need to be able to log as much information as possible without impacting performance. Because logging usually implies an I/O operation, it’s a naturally slow operation.
Before Mule 3.6,
This post describes a real-world tuning example in which we worked with a customer to optimize their Mule ESB application.
A customer presented us with an application that was to be a proxy to several endpoints. As such, it needed to be very lightweight since the endpoints introduced their own latency. We required the application to provide high throughput and minimal latency.
This real-world example shows how we helped the customer tune their application from a number of angles.
Trust no one! Most security issues comes from assuming that no bad person is going to tamper with your input data. We usually pay more attention to it when processing the most common inputs, such as an HTTP request or some argument that’s going into an SQL query. But we usually don’t pay much attention to other types of resources that are also vulnerable to malicious thinking – such as an XML file.
We’re happy to announce the release of Anypoint Studio July 2014 and Mule ESB 3.5.1. The Anypoint Studio release now contains support for finding Anypoint Templates to help you rapidly integrate systems as well as many usability and productivity improvements. The July 2014 release of Anypoint Studio also contains the Mule ESB 3.5.1 release, which builds on the 3.5.0 release with many bug fixes.
The July 2014 release Anypoint Studio release contains many improvements targeted at improving your productivity on Anypoint Platform.
Fact: Batch Jobs are tricky to handle when exceptions raise. The problem is the huge amounts of data that these jobs are designed to take. If you’re processing 1 million records you simply can’t log everything. Logs would become huge and unreadable. Not to mention the performance toll it would take. On the other hand, if you log too little then it’s impossible to know what went wrong, and if 30 thousand records failed, not knowing what’s wrong with them can be a royal pain.
A good part of the Mule community has learnt to use Mule with the first edition of Mule in Action. With the advent of Mule 3, there has been huge demand for a book covering the latest improvements, best practices and lessons learned in the trenches.
Mule in Action, Second Edition, released by Manning Publications after two years of intense work, hopes to fill this need.
In this book you can find:
A common integration scenario is where a single message needs to be sent through multiple routes.
Take for example a case in which you’re receiving a message about a new client’s on-boarding. The message needs to be routed through the CRM to create the client, to marketing who will want to know how the client heard about the company, and finally passed to provisioning and stock systems so they can work their magic as well.
