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. If you’re into .NET, we recently released our .NET integration framework. We also have something we call the “scripting pack” which enables the use of scripting languages such as Groovy, Javascript, Python or Ruby inside your flows. For Mule 3.6, we decided to give it a big upgrade!

Indy Sen on Tuesday, January 27, 2015

Developer Spotlight: Chocolabs

0

To app your life, CHOCOLABS takes an API-first approach

CHOCOLABS is one of the largest app publishers in Taiwan with over 50 iOS/Android entertainment focused apps under their belt. We recently spoke with Jerry Weng, one of their co-founders, to talk about building a team, finding a niche, and driving business growth with the right development tools.
Q – Indy | A – Jerry

Q: Who is CHOCOLABS?
A: We are an app publishing company led by three co-founders who met as interns at Microsoft Taiwan. It’s a long story, but we were all in different years, and had different backgrounds—for example Kevin and I both did computer science, whereas our CEO, David, got his masters in business management and worked at a global marketing research firm before we met and decided to form the company.

Financial services information technology (IT) has transformed from order taker to strategic business partner. As part of this transformation, IT organizations are finding they must address key challenges with legacy modernization, data management and digital transformation.

MuleSoft has launched a three-part white paper series discussing these challenges and how financial institutions are overcoming them. In the first installment in our Connected Financial Institution white paper series, we discussed how aging back office systems, operational effectiveness and open source adoption are driving legacy modernization initiatives across the financial services industry. The second installment in the series discusses key data management challenges facing firms including an ever-evolving regulatory compliance landscape, deepening customer relationships with a 360-degree view, and improving data driven decision making.

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. We decided it was time to update the platform’s support for these standards and fix a couple of things while at it.

Mariano Gonzalez on Wednesday, January 21, 2015

Give your old school API some love

2

If you’re an assiduous reader of this blog, then you probably already heard about our vision around APIs, our Anypoint API Manager solution and all our RAML based stories. Those are our recommended way of approaching REST APIs and if you haven’t already, we all highly recommend you to take a look at them. However, we’re about connecting everything, everywhere. Thus we recognize that there are a lot of APIs out there built in plain old Java code and a migration process is not something you can do overnight. If you own such an API, this post is about us wanting to help you too. Anypoint Platform includes a Jersey module to allow embedding Jersey-based APIs into the runtime, reusing the Java code powering your API but still gaining access to all the other features of the platform. In Mule 3.6 we upgraded our supported Jersey version from 1.6 to v2.11 to give you access to the latest and greatest that Jersey has to offer.

victor.romero on Tuesday, January 20, 2015

Become an Integration Hero

0

MuleSoft got its start years ago with a great open source project, Mule ESB.

Today we continue to be big believers of open development and that’s why every single line of the community edition source code is publicly available on GitHub.

We leverage many open source technologies everywhere within Anypoint Platform, from the core integration engine, Mule ESB; to hundreds of connectors, tooling, and plugins of all kinds.

Mariano Gonzalez on Tuesday, January 20, 2015

Asynchronous Logging in Mule 3.6

8

“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.

The Problem

Before Mule 3.6, logging operations were done using synchronous I/O. This means that the thread processing your message has to wait for the log message to be fully handled before it can continue.

As part of our API-led Anypoint Platform January 2015 launch, I’m pleased to announce the next version of our runtime and tooling, Mule ESB 3.6 and Anypoint Studio January 2015. This release helps users more quickly connect to and design APIs based on a new HTTP connector that adopts a design-first and resource-based approach, all with higher performance. The new release of Anypoint Studio also improves the design experience, upgrades the base Eclipse runtime, and connects to Anypoint Exchange, our expansive library for connector and example information. Finally, major updates to AMQP and our SDLC tooling have been released.

Mike Stowe on Thursday, January 15, 2015

API Best Practices: Hypermedia (Part 3)

0

Part four of the API design best practices series. Read part one: Plan Your API.

Or jump to part one of the hypermedia sub-series.

A Road Trip

First off, let me apologize for the delay in this third part of the hypermedia sub-series. Christmas meant a warm trip back to Minnesota, a road trip through the Texas panhandle, and numerous snow storms in between — until finally I had the chance to cut through the mountainous desert of Southern California on my way back to beautiful San Francisco.

Now I understand some of you are probably wondering what any of that has to do with this post, other than it’s about 3 weeks after promised. One of the greatest challenges of the drive was battling my way through the snow and construction, and just hoping that the interstate would stay open (they literally close the interstates if it’s bad enough). But the one thing I could be sure of was that at every turn, between my steady GPS and road signs, I knew where I was going, and I knew when my path was being detoured or I couldn’t take a certain road… I knew this, because everything was nice and uniform.

Nial Darbey on Tuesday, January 13, 2015

Secure your APIs

0

Securing an API in Anypoint Platform is easy. In a previous post we showed how Anypoint Platform for APIs allows you to fully protect your API. We concluded then that the combination of HTTPS and OAuth 2.0 are a rule-of-thumb best practice for Web API security. In this post, we’ll take a deeper dive into the makeup of a security configuration in Anypoint Platform and explore in more detail the areas of Basic Authentication and OAuth2 Authorization in the context of Identity Management. We’ll also give you some pointers about when and how to use these two standards.

Security Manager

Central to authentication in Mule is the Security Manager. This is the bridge between standard mule configuration and Spring Security beans. In the example we build in this blog, we will use Spring Security to authenticate credentials against an LDAP server. We suggest you read the Spring Documentation on this topic if you want to delve further.