In the world of data integration, error handling is crucial to a successful data integration strategy, however, it is often one of the most overlooked areas because, quite frankly, it can be quite intimidating when you initially try and understand it. In my series of blog posts, I hope to reduce this complexity by breaking it up into simple concepts that are easier to digest.
It’s a new year and people are re-inventing themselves with their new year resolutions. We can apply this same concept to other aspects of our days, such as the way we integrate systems! Here are five things that you should start (or stop) doing when it comes to data integration in 2020.
Reuse is the catalyst that turns the vision of API-led connectivity into a reality. In the context of MuleSoft, reuse can come in many different forms:
- Frameworks added as a jar/maven dependency
- Pre-packaged project templates within Exchange, which could then be imported into Anypoint Studio
In a modern cloud architecture, one of the common patterns that is observed is the use of message queues to:
- Decouple applications
- Improve performance
- Increase reliability
- Implement granular scalability
Often times when you are processing data through a flow, you may want to treat certain errors differently than others. For instance, if you are trying to select records from Salesforce, you would want to handle a record not found error differently than an out of memory error. For this reason, MuleSoft allows us to handle errors based on use cases as well as the types of errors that are being thrown.
In my previous blog post, I discussed the basics of error handling with Mule 4, helped understand what a Mule error is, what the two major error handling scopes in Mule 4 are, as well as how they work. In this post, I will discuss how to take these basic concepts and build them up so that you can implement error handling strategies in your application (and not be completely lost when doing so).
Like many developers and architects who build APIs and integrations, I was on top of the world when I completed the training on Anypoint Platform Development fundamentals (Mule 4); I was now able to take an idea for an API and build, design, deploy, and implement my API in a matter of hours. I now held the shiny key to become a MuleSoft Certified Developer — I just had to pass the MuleSoft Certified Developer –
If you ever used Mule 3, then there are probably two things about error handling you already know:
- It’s really Java exception handling
- It’s a “trial and error” experience
In this post, I’ll explain the major changes introduced in Mule 4 around error handling, including easier routing and the introduction of our new try scope.
As part of our upcoming Anypoint Platform June 2016 announcement, we are excited to release Mule 3.8. This release extends the flexibility of Mule, the runtime engine of Anypoint Platform, by unifying integration and API management capabilities into one lightweight distribution. It also significantly enhances core Mule functionality including DNS round robin load balancing, DataWeave Flat File, Fixed Width and COBOL Copybook support,
This all began with a very popular request: “We want to be able to throw an Exception from a flow”. The motivation for this is that it’s fairly common to run into “business errors” (errors not related to the handling and transmission of data but the data itself) which should actually be treated in the same way as a connection or system error (things like the remote endpoint is down).
Given the popularity of the request we decided to look into it and started by asking: “which are the use cases in which you would throw an exception?”.