We hope that the information on this page is relevant enough to be helpful to you and to give you some insight on our experience and capabilities. If you need more information, please fill out the "Need Additional Information" form.
Most of us have been there. Working with relational databases, or several different databases, and needing to join data outside of SQL means finding a common key and writing code to iterate through lists of data. While it is not terribly difficult to do, there should be an easier way. Well, let's see how Anypoint Studio and DataWeave can do it.
First, we need a use case, so why don't we start with a simple case. We have two database tables that we need to join. As a side-bar, my actual production use case required us to join data from two SalesForce queries. For this more generic example, we have the following data:
When a set of API’s becomes even mildly complex, it is often more easily managed by separating the resource definitions into either their own RAML file or their own Mule ESB applications. In either instance, the difficulty shifts from managing RAML files to managing URL paths. In my experience, there are a few very easy steps to take in order to combat this problem. There very well could be a more elegant solution that I have not seen, so I will post my solution and let the more informed people tear me apart.
With Mule ESB, each HTTP listener needs a unique path in order to know which listener to invoke. It makes complete sense. The problem arises when you are trying to define a nice, consistent URL scheme throughout our API’s. For example, let’s say that you have three API definitions for three different interfaces, apples, oranges, and pears. Your goal is to expose these three separate interfaces with the same URL pattern: