This series of HowTo blog posts are simple use-case based tutorials to help you as you do your evaluations with the Anypoint Platform. Based on a theme each series consists of up to three tutorials.
We created the series by collecting common use-cases encountered by our field teams and feedback from our massive customer and partner base.
We will be launching the first series this month followed by a new series each quarter.
If you would like to provide feedback or suggest topics, please use how-to-feedback@mulesoft.com and we will able happy to include them in our future series.
As of October 21, 2015, the future is now the past. That was the date that Marty McFly and Doc Brown travel through time to in Back to the Future 2. Some things have come true in the 1985 vision of 2015 – drones, for example, or self-lacing sneakers, and some things haven’t yet. Where are our flying cars?
But one thing is certain – companies are doing things with technology today that we couldn’t even imagine thirty years ago. Mobile, social media, big data, and the Internet of Things are making jaw-dropping innovations possible every day. Here are just a few of the amazing things today’s businesses are making possible:
A recent ComputerWorld article reports that US bank Wells Fargo is providing personalized offers and coupons using beacon technology every time people step into particular stores.
UK taxi company Addison Lee allows customers to order a cab from their mobile phone from anywhere in the world.
News Corporation is bringing customized news to you faster than you knew you wanted it.
UCSF is revolutionizing how doctors communicate with one another, making interactions with patients easier and more effective.
The world is changing in truly extraordinary ways and things that were difficult 30 years ago are instantaneous today. Thanks to mobile, wearable technology, SaaS, big data, and the integrations that connect them, companies are able to harness the digital revolution and create innovations that make all of our lives better. MuleSoft is proud to work with these companies and we’re excited to see what the next 30 years will bring.
For more exciting and futuristic work our customers are doing with Anypoint Platform, take a look at our case studies.
When business leaders think about their organization’s data, they might think about records kept in on-premises systems or even in cloud applications, but they generally think of that data as very much inside the business. But what if those data assets could be reimagined and repackaged as a complete service and then exposed, inside and outside the business, through APIs? Now enterprise data not only has the possibility to spur growth but also provide new revenue streams for the business. It all begins with a great API strategy.
Ross Mason, our founder and VP of product strategy, and Uri Sarid, our CTO, have outlined the possibilities for APIs in the Wall Street Journal. They make the point that businesses have two approaches to API strategy: they can either build APIs on a project-by-project basis, or they can “build an internal discipline for creating APIs strategically. Put a team together to build the initial APIs, create definitions for what APIs mean to your organization, and define common traits so you’re not reinventing the wheel each time.” This approach to API strategy requires a business to think slightly differently about how their technology assets are managed, but not only does this approach save time (and therefore money) for IT teams, it enables the business to consider the assets that really matter and how to make them into compelling business offerings.
We’ve highlighted companies that are using APIs to build new revenue streams as traditional ones declined; the lessons learned from those companies is that strategic thinking about core competencies as well as competitive differentiators enable business to turn their data into sellable services via APIs. That thought process around API strategy is a new way of imagining the value of data, and it’s a natural way for IT leaders to evolve their roles.
Ross and Uri lay out a blueprint for how to go about reimagining the way your business thinks of APIs. “Set up a developer program and educate staff about APIs, “ they advise. “Switch the mindset so that IT thinks not just about building, testing, and runtimes, but about delivering the data—the assets of value. Consider a new role: the cross-functional project manager who can weave together various systems into a compelling new business offering.”
Digital disruption doesn’t just mean headaches for the business – API strategy can turn it into an extraordinary opportunity for the business. Any company, no matter what industry it’s in or how settled a business model, can benefit from an API strategy. We have lots of resources to help change the thinking about what you’re doing with your enterprise data; take a look and see what benefits APIs can bring your company.
Since I joined the company this summer, one of my main tasks has been to improve the connector certification program. To do this, I’ve engaged with partners, developers and MuleSoft employees; to further familiarize myself with our technology and processes, I decided to build my own Google Translate Connector. I’ve learned a lot by going through the process and wanted to share some resources I found most useful as I was building my connector.
Additional tip: As going through the process, I experienced some challenges while setting the configuration for authentication, implementing the first operation (Translate a text) and defining the first entity class for return values, but I was able to quickly overcome these challenges using the Jersey example above and asking questions on the DevKit Forum.
Once my connector was fully developed, I prepared it for certification. If you follow the connector examples I mentioned in 4, 5 or 6 and use the latest DevKit version (3.7.0 or above), you should be in good shape for certification and will likely need to just do a bit of work on code coverage, test automation, and documentation. I’ve submitted my connector for certification and completed a demo session and am now eagerly awaiting the confirmation of my first MuleSoft Certifiedconnector! [Update – 11/6/2015] I just heard that my connector passed the MuleSoft certification!!!
If you are interested in submitting your connector for certification, please visit this website or emailing us at connectors-certification@mulesoft.com! Along with answering any questions you might have, we can provide guidance on which connectors are most requested by users, and guide you through the process as well.
Don’t let the fear of the unknown keep you from building your own connector. Use the resources above, engage with other Muleys on the DevKit forum, and get started building your connector today!
When deployed as an API Gateway and managed with API Manager, the highly performant Anypoint Platform enables you to control which traffic is authorized to pass through your APIs to various backend services, meter the traffic flowing through your API, log transactions, and apply runtime policies.
A policy is a mechanism the gateway uses to enforce filters on traffic as it flows through the gateway. These filters generally control things like authentication, access, allotted consumption, and SLAs. Anypoint Platform comes with a number of pre-built policies including rate limiting, throttling, OAuth 2, basic HTTP authentication, and XML and JSON threat protection. Custom policies can also be built to support needs not addressed by out-of-the-box policies.
Enforcing these policies on incoming requests incurs CPU cycles. The benchmark below provides guidance on the type of overhead one might expect to be added to round-trip time for each API request. This is measured by applying a specific policy on an existing API with API Gateway 2.0 and measuring the added latency in milliseconds.
One of the great uses of Anypoint Platform is automating business processes that need to interact with multiple systems and deliver useful functions. Many times these business processes are ones that started out requiring humans and as the business has grown it has become clear that the human process will no longer scale with the demand.
We’ve seen that here at MuleSoft. Here’s a great example: Sales has put together a package that meets our customer’s needs, the package has been reviewed and approved by our Sales Operations team, and now we need to create an invoice. The sales system is Salesforce and the finance system is Netsuite, so how can we bridge that gap? Anypoint, of course!
Using Anypoint Studio, we used the SalesforceAPI to look for opportunity objects that are in the correct state (Closed/Won and reviewed by Sales Operations). From there we map the fields in the opportunity object to the appropriate products in NetSuite and we check and see if NetSuite already has a record of the customer. If there is a customer record, we verify the billing and shipping information matches. If there is not a customer record we create a new one and add the shipping and billing addresses from Salesforce. The invoice is then double checked by an analyst and approved before it is sent out to the customer.
Let’s go over the wins for this scenario:
Sales and Finance each get to use the system that they are most familiar with without having to be concerned about the quality or availability of “out of the box” integrations provided by those tools.
The solution is built to fit the specific needs of each group.
Data isn’t being manually transferred between systems, thus avoiding the risk of data entry errors. The business analyst in finance simply has fully complete invoices delivered to their workflow.
The business process doesn’t need an army of clerks as the volume of transactions grows.
The integration can be modified over time to suit changing and evolving needs. Since this is not an “out of the box” solution provided by someone else, we can tweak it as needs change.
Stay tuned as we introduce other exciting ways MuleSoft uses Anypoint technology! And check out this upcoming webinar on how MuleSoft uses Anypoint Platform:
For a while now there have been maven archetypes for creating mule apps and domains. Such archetypes make getting started with development easier by automatically generating the basic core structure and files of mule projects (think configuration files, test classes, pom). This is especially interesting since the introduction in 3.5.0 of shared resources through mule domains which could make your app depend on another external project (a domain) and using Maven to manage dependencies makes perfect sense. We will see how to use these archetypes to create a domain and an application that uses it.
IMPORTANT: This post is intended for developers comfortable and familiar with Maven.
Creating a domain
We’ll start by creating a domain where we’ll define an HTTP listener to be shared.
This will create a project named my-mule-domain that contains a mule-domain-config.xml file where we can define our listener config:
Creating an app
Now we’ll create a project for an app that uses my-mule-domain. In this case, we can indicate which transports and modules we’ll be starting with and the mule version we’ll be using.
This will create a project named my-mule-app that contains a mule app configuration file already set up with the namespaces of the transports and modules indicated, as well as the dependencies for them set up in the project’s pom file. In there you’ll also find a mule-deploy.properties file with the domain specified to my-mule-domain and an ExampleFunctionalTestCase for our app.
Let’s modify the app to use the shared HTTP listener and it’s test accordingly. We’ll get rid of the vm endpoints and extra initial message processors and add our listener:
In ExampleFunctionalTestCase we can now use the MuleClient to send a request to “http://localhost:8081/domain/test”. Let’s replace the vm related client code and modify the expected payload since now we’ll be expecting “Received”:
That’s it, we now have an application that’s using a listener defined in a domain AND a test case for it. This works because the external domain project is added as a dependency of our project, as well as a Maven plugin to unpack it’s configuration file, all of which was set up when we created the app through the archetype. Just compile everything and run the test.
You can find the entire code for the domain and app here.
Extra
Archetypes are not all there is to offer for Maven projects though. Each of the projects mentioned above uses a special maven plugin to manage the packaging into deployable .zip files.
If I want to generate the deployable .zip for my domain I just have to run:
mvn package
To handle deployment, you can use the Mule Maven Plugin which supports deploying to a standalone instance, a cluster, Anypoint Runtime Manager or CloudHub. You can find some examples here.
To learn more on our Maven Tools you can visit our github project and check out our docs site for this and even more information about developing Mule applications with Maven.
You have been redirected
You have been redirected to this page because Servicetrace has been acquired by MuleSoft. Click here to learn more.
