Anypoint Studio October 2014, Mule 3.6.0-M2 and 3.5.2 released
Today we’re releasing Anypoint Studio October 2014, Mule 3.6.0 – Milestone 2 (M2), and Mule 3.5.2. This release includes new HTTP capabilities which make it easy to connect to RESTful APIs with RAML, and productivity enhancements inside Anypoint Studio – such as DataSense for APIkit and a new Studio launcher.
I am excited to announce release 39 of CloudHub! This release is based on a lot of user feedback, and contains a beta of our redesigned user interface as well as one of our most requested features – CPU & memory.
We’ve been hard at work the last few months building a revamped user interface which helps you be more productive and integrates seamlessly with the Anypoint Platform for APIs. We’re excited to preview some of that work today. You’ll notice a clean, modern interface that makes it easier to get things done. For example, the home page now provides easy access to your applications, settings, and logs at a glance. It now also has a handy summary of resource utilization and the number of recent transactions processed.
The “Man-in-the-Middle” attack is such a well-recognized security risk, with established solutions and preventative measures in place that when I first heard about the recent ruckus around the Apple security flaw, I thought Apple’s trouble was more legal in natural, maybe some sort of royalties dispute between iTunes and the Michael Jackson estate. Only later did I found out what all the fuss was about “in the middle”, not “in the mirror”, and why I had to upgrade the iOS on my iPhone on a beautiful Saturday afternoon.
Regarding the specifics to Apple’s security flaw, there is already plenty of press coverage out there. For example, David Auerbach wrote a great analysis over at Slate.com.
In this post, I’d like to illustrate how automated unit testing with appropriate code coverage could have detected that particular kind of error, the one caused by grammatically correct code that inadvertently invalidated the whole logic of the program. We will build the unit tests using the MUnit module, an open source Mule testing framework that significantly streamline and simplify the process of writing unit tests.
First, we will start by defining two factories, one called greeter and the other called worldGreeter. What we want to achieve here is writing unit tests for the worldGreeter factory instance.
Let’s start with a module named myApp that contains both factories:
As you can see, worldGreeter is simply concatenating the input from greeter. So, when injecting worldGreeter the result will be the string HelloWorld.
The testing frameworks we will be using are mocha as runner and chai for assertions. So let’s write the test:
We will replace greeter with our own implementation. The additional injected parameter named $delegate is a reference to the old greeter instance. It is really helpful if you plan to use them with a mocking or stubbing framework like sinon.
Next, we are going to use another angular trick. We name the instance to be injected _worldGreetereter_ so we can have a worldGreeter instance on the describe scope. inject recognizes this and injects the proper instance allowing the usage of the more handy worldGreeter variable.
Finally, we write an assertion to verify that greeter was replaced successfully:
The bottom line
To sum up, great things can be achieved by using decorator in tests as it is really useful when having to replace instance dependencies. Last but not least, you can see the code working in this jsfiddle.
Our integration tests should be portable, meaning that if we shared our project, everyone would be able to run our tests on any platform without needing to install any framework or application. This is a very common issue when we test flows that have an SFTP outbound endpoint. In order to do an integration test of our flow, we need to start an SFTP server on our machine or use a public SFTP server, which implies adding network overhead to our tests.
A simple solution to portable SFTP testing is embedding an SFTP server into our tests. A good and really light weight framework to do so is Apache Mina.
Let’s suppose we want to test the following flow:
We want our test to look something like this:
With Apache Mina we can make this test portable by creating this class:
Testing using an external API can be a PITA, especially if the API uses any HTTP Callbacks or redirects such as OAuth or WebHooks. If your using any callback functionality like this then the Service Provider needs a way to callback your application and therefore be accessible to the public Internet.
When you start integrating these APIs, it’s much easier to work on your local development machine, but these are usually behind firewalls, NAT, or are otherwise not able to provide a public URL and it’s not really feasible to push to a staging environment every time you want to test something.
So we need a way to make our local applications available to the Internet; there are a few good services and tools out there to help with this such as: Tunnlr, ProxyLocal, showoff.io or you can setup your own reverse SSH Tunnel if you already have a remote system to forward you requests.
In this post, I am going to use a service called LocalTunnel and show how we can share a local Mule application with the world and customize some Cloud Connectors to receive Callbacks locally.
One aspect of Mule DataMapper that makes it a grate data integration tool is its ability to do mappings involving complex and different data structures (XML, Json, POJOs, CSV, Excel files and more). One feature that is really attractive is the possibility to test your mappings without the need to launch your Mule application, so that you can provide sample input data and preview what the result of the DataMapper will be.
After reading this post you should be able to:
Understand how to add and use Input Arguments
Test your mappings with the Preview Functionality
Create an input POJO to test the mapping
What are Input Arguments?
The DataMapper component maps/transforms anything that comes in the Mule flow payload into another format. But what happens when you want to enrich the contents of the payload, by sending other values that should be used as input for the mapping? For these cases you can use Input Arguments by defining a name and a value. The value can be a literal or any Mule Expression that returns a native value (String, Integer, Long, Double, …).
Adding Input Arguments to your DataMapper Component
Let’s start with a simple mule flow that has a DataMapper component. For simplicity we will start with a VM inbound endpoint (where the mapping input POJO will be received), a DataMapper component and a file outbound endpoint to save the output into a CSV file.
Now lets add the input arguments. If not done yet, first run the DataMapper wizard. In this case I created a Pojo to CSV mapping providing a sample java class and a sample csv file (download the sample Studio project with both files from here). Input arguments are created from the mapping editor.
Right click on the Input arguments label and click on Add input argument. Complete all details in the editor:
Name: Is the name used to display the input argument in the mapping editor
Type: Choose the variable type of the argument
Mule expression: Literal or expression that will generate the value in runtime
Previewing your mappings
DataMapper comes with a preview functionality that allows you to run the mapping without the need of starting the Mule application. As there is no runtime, you need to provide the input values yourself. In order to do this you should go to the preview tab (1) and then provide values for the input pojo (2) and the input arguments (3).
Sampling the input Pojo
Create a groovy script that builds, set values and return an instance of your java object
Choose the groovy script you created by clicking the button (2)
Sample Groovy Script used in this example (Please forgive my bad groovy skills!)
Providing values to Input arguments
Click on the Input Arguments button (3)
Select the input argument from the table list and provide a value
The only thing that’s left now is to Run the Mapping and check the results in the Text pane!
That was all. You can use the preview functionality for other types too, so I invite you to try them and get back to me with your feedback!
Most people who write UIs don’t care about testing. You know why? Because it’s hard. So hard, they’d rather not even bother and test things manually. You have multiple browsers. You have multiple platforms. And worse, you have all these frameworks and toolkits which are difficult to test. I’ll pick on GWT here for a moment. It takes 20 seconds to start a test – let alone a server side component to interact with or the time it takes to run your test. 
Testing exception handling code is not always an easy task. You either need to setup the external conditions that cause the exception to be raised or generate mocks to get the same results.
A third option is using a bytecode injection tool like Byteman. Using Byteman scripting language you can insert custom behavior into the application code under test. The main use cases for Byteman are:
MuleSoft provides the most widely used integration platform for connecting any application, data source or API, whether in the cloud or on-premises. With Anypoint Platform®, MuleSoft delivers a complete integration experience built on proven open source technology, eliminating the pain and cost of point-to-point integration. Anypoint Platform includes CloudHub™ iPaaS, Mule ESB™, and a unified solution for API management™, design and publishing.