With Mule’s December 2013 release we introduced the new batch module. We received great feedback about it and we even have some CloudHub users happily using it in production! However, we know that the journey of Batch has just begun and for the Early Access release of Mule 3.5 we added a bunch of improvements. Let’s have a look!
Support for not Serializable Objects
A limitation in the first release of batch was that all records needed to have a Serializable payload. This is so because batch uses persistent queues to buffer the records making it possible to processes “larger than memory” sets of data. However, we found that non Serializable payloads were way more common that we initially thought. So, we decided to have batch use the Kryo serializer instead of the Java’s standard. Kryo is a very cool serialization library that allows:
Serializing objects that do not implement the Serializable interface
Serializing objects that do not have (nor inherit) a default constructor
It’s way faster than the Java serializer and produces smaller outputs
Introducing Kryo into de project did not only made batch more versatile by removing limitations, it also had a great impact in performance. During our testing, we saw performance improvements of up to 40% by doing nothing but just using Kyro (of course that the speed boost is relative to the jobs characteristics; if you have a batch job that spends 90% of its time doing IO, the impact in performance won’t be as visible as in one that juggles between IO and CPU processing)
Here’s our weekly roundup of the top 5 integration and API articles of the week. Take a look, let us know if we missed any, and share your thoughts in the comments. Don’t forget to follow @MuleSoft to stay up-to-date on integration & APIs!
If you’re interested in Integration and APIs, don’t miss CONNECT 2014 – the event behind the integration revolution!
The business and building blocks of APIs are pretty clear at this point, but the politics of APIs are going to become an increasingly hot topic as the space continues to grow.
How quickly can you enable OAuth on an API and allow for client applications to be rapidly built for them? With the new OAuth 2.0 policy that is now available with the Anypoint Platform for APIs, the answer is no more than five minutes! Have a look for yourself with the following viewlet:
For this week’s Meet a Muley post, we chatted with Nicolas Mondada, Product Manager for Dataloader.io, DevKit, and Connectors. Read on learn about what makes Nicolas a unique addition to our team!
First thought that came to mind when you looked into the mirror today?
Geez, I need a coffee.
How did you find MuleSoft?
After working for relatively large companies for a couple of years I was looking for something small where I could learn, collaborate and deliver faster.
Gradle is gaining more and more popularity as a build system. It combines the power of scripting with the simplicity of conventions. Declarative builds are very straightforward, where customizations do not end up in tons of messy configurations.
Currently, Mule has two ways of building projects:
Apps can be built through Mule Studio, which is simple by nature but not very friendly with continuous integration, source control management and related tools.
The recommended way to manage your build is with Maven. This plugin is integrated with Mule Studio and has a lot of power on its own.
Now the open source community has presented a brand new way of building Mule apps with Gradle. The project aims to provide a very simple way to build Mule apps that is friendly with continuous integration and can work easily with Mule Studio. One of the interesting things about Gradle is that it can reduce over 90% the complexity of the build if we compare it with the same build based on Maven.
The plugin in under development but it provides the basic features to build Mule apps:
For this week’s featured Muley, we thought we’d head over to the Channel and Services Team and introduce you to Samrah Khan, Director of Strategic Channel Partners! When she’s not in the office, she’s probably out doing yoga or checking out the newest restaurants. Read on to learn about her greatest weakness, what sets her apart, and why she’s one of our favorite Muleys!
First thought that came to mind when you looked into the mirror today?
OMG you need to get some more sleep – I’m getting old.
How did you find MuleSoft?
MuleSoft found me! I went through an extensive round of interviews and was very impressed by the rigorous process. Greg was inspiring and the culture was a good fit.
How did you first get interested in your field?
In college I majored in Computer Science and joined a semiconductor company. Pretty soon I realized that I was bored out of my mind and I needed to do something different. I’ve always been a people person but I also love technology. Alliances seemed to be a natural fit.
What exactly do you do?
I work with our partners to drive mutual business for revenue. My responsibility is to strengthen relationships with our strategic channel partners. These partners utilize/sell MuleSoft solutions to their end user customers and I help them with the process.
What was your very first job?
I was an admin in a police station doing paperwork. It had it perks as a teenager, aka no speeding tickets!
What’s a typical day like for you?
I wake up buy some delicious yet overpriced coffee and head into work. I think about ways to create more value and make MuleSoft successful and execute. After work I usually do yoga or a dance class – zumba, salsa, bhangra – you name it, I do it. I’m also a big foodie so I try to check out new restaurants during the weekdays.
Best perk of being at MuleSoft?
I’m surrounded by people that are truly, “best in class”. MuleSoft has hardworking people. My team is willing to go out of their way to help each other and everyone wants to see you be successful. That is a powerful thing. It makes me set my bar higher and higher. When you are on an A -team it challenges you to up your game.
Biggest challenge since you’ve been at MuleSoft?
The ropes course I did at last summer’s company meet up. The bruises lasted 2 weeks.
Best piece of advice you’ve received?
“There is no plan B. There is only plan A. So go make it happen.”
Typical weekend?
I like to catch up with friends and family over coffee, brunch or a movie. I also volunteer at the YMCA and help special kids with various activities. I also like to go dancing or just get out and check out new places to explore.
Most embarrassing moment?
Oh there are so many ….
If you could have any superpower, what would it be and why?
Being able to shop without a care in the world! Or even better, have the ability to eat whatever I want and still look and feel good without having to exercise.
What three words would your friends use to describe you?
Fashionista, Traveler, Tough
If you weren’t doing what you’re doing, what would you do?
Dancer or Yoga teacher – except my bills are too high. I like Hatha or Iyengar yoga. I don’t do well in a hot room. You can put music on and I will dance to anything – and I mean it, anything.
Most memorable moment at MuleSoft?
The JP Morgan Run that the MuleSoft team participated in. It felt good to make a difference together.
What is your weakness?
Shoes, shoes and shoes.
What’s something about you that often catches people off guard?
I speak 4 different languages fluently and switch between them pretty easily during conversation. That always gets a “wow” reaction from people listening nearby.
That wraps it up for this week’s Meet a Muley post! Be sure to check back next week to meet another member of the team! Till then, be sure to follow us on Twitter@MuleSoft and LinkedIn for all things integration!Interested in working with talented people? Think you’re a superstar and have what it takes? Visit our MuleSoft Careers page to check out our latest openings.
This week’s Muley comes to us from the cloud integrations team in Buenos Aires! As an Engineering Manager, Alejandro focuses on keeping things running smoothly. Read on to learn about some of biggest challenges he has to overcome.
First thought that came to mind when you looked into the mirror today?
How hot I am, wait, I mean old… that was the word.
How did you find MuleSoft?
Nahuel Lofeudo, a fellow Muley, worked on my team at Travelocity and quit to come to MuleSoft. As a result, I hated MuleSoft! Little did I know I’d be here too.
How did you first get interested in your field? What is your field?
It all started with Logo and video games on an MSX computer back when I was 6. I was really interested in how computers work. Next thing you know I was studying Computer Science at UBA.
What exactly do you do?
Good question… It’s a combination of meetings, interviewing, hiring, managing the team and more meetings.
How was the interview process?
I interviewed for another position first so the process took longer than I anticipated. I had a total of 7 interviews! The odd thing about my process is that I got to meet Greg, our CEO, in person while he was in BA and he interviewed me before the hiring manager did.
What’s a typical day like for you? Daily routine?
Getting up late 9am-ish… going through emails on the subway. Then it’s mostly meetings and fire drills.
What are you currently working on?
My team uses our tools (Studio, Mule ESB, CloudHub) to build SaaS integrations. Some of them develop multi-tenanted OOTB, self-served integrations. Another group is working on a secret project to improve time to value of our customers.
Biggest challenge of the day?
Being able to schedule a meeting on a Lifesize with both SF and BA offices :]
Best perk of being at MuleSoft?
Working with amazing people and free food (you never, ever, say no to free food).
Biggest challenge since you’ve been at MuleSoft?
Hiring, we get a lot of candidates but we want only the best.
What’s something new you learned while being at MuleSoft?
Being able to pass on good candidates, when you want the best people you have to learn to wait for them.
Best piece of advice you’ve received?
“Try not to fight for EVERYTHING” and “You don’t get charged for using please and thank you”. I still fail to follow those two :]
Typical weekend?
TV, movies, video games, swimming pool, visiting parents, going out for dinner, etc, etc
Most embarrassing moment?
My embarras-o-meter is broken, but once I sent a huge internal only rant to a customer by mistake D:
If you could have any superpower, what would it be and why?
Teleportation. I can’t believe that in 2014 we still need to sit and wait for 15hrs to get from BA to SFO. Somebody do something!
Favorite food you could eat everyday if you had to?
Ice cream (but I can’t as I’m a Diabetic).
If you weren’t doing what you’re doing, what would you do?
Can I dream here? Pro tennis player.
If you could have any pet in the world, what would you want?
None, I can barely take care of myself
Most memorable moment at MuleSoft?
Probably last company meetup’s hackathon project presentation. One team presented a project that consisted of triggering API calls when human contact was made (like taking a picture when 2 people high five eachother), it had a ridiculous name to go with it. No words to explain it. You’d have to join MuleSoft and ask for the video (I hope someone has it).
That wraps it up for this week’s Meet a Muley post! Be sure to check back next week to meet another member of the team! Till then, be sure to follow us on Twitter@MuleSoft and LinkedIn for all things integration!
Interested in working with talented people? Think you’re a superstar and have what it takes? Visit our MuleSoft Careers page to check out our latest openings.
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.
We have built a simple,demonstrative application that processes incoming messages differently depending on whether a property of the payload, called “goodguy”, has value of “true” or not. If the value was true, the message would be processed one way and an HTTP 200 status would be returned. If it was not, the message would be processed another way and an HTTP status 400 would be returned: The key logic for routing the message is shown below:
If you look at the W3C document listing HTTP status codes, you may notice that only a small portion of all possible codes represents the happy path – i.e. 2xx codes. Most other codes are there to let client know that something went wrong with the request and the expected response cannot be returned. When building an APIKit-based application, developers must properly handle error conditions and set status codes accordingly. As always with Mule, there are many ways to achieve that. Let’s look at some of them.
Our use case is a very simple ACME Company API which returns a product information based on a particular product ID. In other words,
When we create a new APIKit project in Studio and add a RAML file, it generates flows for each RESTful call. In our case, it will produce one flow which handles our request:
We can now replace the default content of this flow with a business logic that queries the database and returns product information:
But what if our query returns no results? From the JDBC transport perspective, this is not an error condition – the returned payload will simply be an empty list. In this case, our API call will return an empty response, with the HTTP status code 200 – something the client would expect. Or, if our transformation logic expects some data from the database, it may fail, throwing an exception – again, not the desired behavior. What we really need is to return status 404 and potentially some object containing more details. All we need is to add a <choice> message processor, e.g.:
How about any other scenarios where something else may go wrong? Wouldn’t it be great if we had an exception strategy which can automatically map exceptions to response codes?
Let’s look at our generated code again. There’s a new global element called apikit:mapping-exception-strategy:
It allows mapping exception types to status codes, content types, error messages and anything else you may want to return as a part of your error response. You can add as many mappings as you need, however, you will have to either know all types of exceptions at the design time (which is not always possible) or throw a specific exception using Java or scripting component, e.g.:
In reality, a combined approach should be used. Use as much logic as possible to gracefully handle some error conditions, use mapping exception strategy to intercept and map other errors.
Now you can finish your ACME API, connect it to a database of your choice and send the request for a product that does not exist in the database.
Quoth the server, 404…
You have been redirected
You have been redirected to this page because Servicetrace has been acquired by MuleSoft. Click here to learn more.
