The Fastest and Easiest Way to turn WSDLs into a Reusable Connector

Reading Time: 8 minutes

Can MuleSoft connect ________ (insert name of any system) to ________? Regardless of how you’ve filled in the blanks, anyone from MuleSoft will answer with an enthusiastic, ‘Yes, we can!’

To enable this universal connectivity, along with increasing the breadth and the quality of our out-of-the-box connectors, we are continuing to invest in expanding the usability and feature set of our connectivity tooling, including our: HTTP Connector, Web Service Consumer, and our SDK, Anypoint Connector DevKit.

DevKit, as many users have noticed, went through a tremendous facelift in the past year. Along with new features such as real-time error highlighting and and code templates that make the development process more intuitive, we’ve also added other features such as support for external libraries and the ability to generate functional and interop test cases.

To add to this list, we are thrilled to introduce a new DevKit feature called SOAP Connect, which will be included in our Mule 3.7 release.

What is SOAP Connect?

SOAP Connect is a feature within DevKit that allows users to quickly package multiple WSDL files or fetch them dynamically into a single reusable connector with minimal coding. Not only does this simplify the building process, but the dynamic fetching of APIs dramatically simplifies the process of updating API versions as well. On top of this, connectors created using SOAP Connect also support DataSense, which allows you to dynamically pick and choose your connector operations while the connector is being consumed.

As with any other connector built using DevKit, the connector can be installed in Anypoint Studio and used (and reused) in different Mule applications.

Web Service Consumer vs. SOAP Connect

Web Service Consumer is a pre-installed connector within Anypoint Studio that you can use to quickly consume an API using the information contained in a service’s WSDL. You simply need to identify the location of the WSDL file, then ask the Web Service Consumer to configure itself from the WSDL – the host, the port, and the address.

When considering your options, if you have all the configuration details for the WSDL and only need to consume a few services, we recommend using the Web Service Consumer. It’ll be the quickest and simplest option for connecting.

However, if you need to connect to multiple APIs (we know some applications have thousands of WSDLs) and want to use them repeatedly in a consistent manner, we would recommend SOAP Connect. While the Web Service Consumer will enable connectivity, SOAP Connect will build a connector which allows you to scale and reuse in a consistent manner across the organization.

Using SOAP Connect

To use SOAP Connect, you need to have Anypoint Studio 5.2 with the latest Anypoint DevKit plugin, which will be available early July.

For this post we are going to use the Cookbook API, an example provided on the DevKit tutorial page, to demonstrate how to connect to a SOAP API.

  1. First, let’s create a new Anypoint Connector Project by right clicking in the Package Explorer.
  2. Select the SOAP Connect option.
soap2
  1. Choose a name for the connector and add the WSDL file(s). For this example, we are going to pick Cookbook as the connector name, and add a WSDL file from the tutorial.
soap3
  1. Choose an icon (or use the default icon) for your connector, then hit finish.

soap4
Let’s take a look at the code generated under org.mule.modules.cookbook.config.ConnectorConfig:

Note that the method annotated with @WsdlServiceRetriever (#18) returns a single ServiceDefinition object providing DevKit with the following information:

  • the place where the WSDL file is (in this case, it is remote, but it could be local /src/main/resources)
  • the service
  • the port

All of the above are auto-populated by the wizard, which took the job of introspecting the WSDL file under https://docs.mulesoft.com. Additionally, the code generated will also allow users to change the endpoint by feeding a different value under the @Configurable (#18) address field.

  1. Install the connector in Anypoint Studio and use it in a Mule app

soap5We have now developed a connector from scratch that is installed and ready to used in any Mule application!

  1. To put the connector to use, create a flow with the Cookbook connector surrounded by two HTTP Connectors.

soap6Click on the Cookbook connector to configure it. To configure the connector, click on the green “+” sign next to “Connector Configuration”.

soap7We will continue to use the same address for this example, but you can change it should you want for your use case. Click “OK” when done.

soap8Simple and ready to use in just 6 steps!

To try the feature for yourself, make sure you download Mule 3.7 (Anypoint Studio 5.2) and the DevKit plugin early July. For a detailed walkthrough of this feature, register now for our demo on July 8th at 10am PT/ 1pm ET.

API-led connectivity and CQRS: Aligning business & IT with RAML

Reading Time: 11 minutes

Part 2: Building a Data Query Application

In a previous blog, we talked through how you might design a solution to deliver a Command Query Responsibility Segregation (CQRS) pattern with Anypoint Platform. In this blog, we’ll discuss how an API-led connectivity approach can help you deliver this pattern (and the mobile application your business is demanding) with speed and scale while maintaining control over your critical data assets.

API-led connectivity and API design

api-led-connectivity-design

To deliver this mobile application successfully, you need to bring together two groups of people:

  • Your client’s Supplier Relationship Management (SRM) domain experts
  • Your developers implementing the mobile application and underlying connectivity

You discovered RAML, the RESTful API Modeling Language, to start design discussions between your client’s SRM experts and your mobile and backend developers. RAML is a language of the web and therefore can be understood and interpreted by technical and non-technical people alike. This means it’s practical for supporting cross-team communication. By iterating on the RAML specification, the team can jointly discover how to deliver great business value and accurate resource naming like “item” or “part”, “material” or “product”, etc.  Imagine the following design was agreed as sufficient for the first prototype implementation.

The power of RAML for driving Consensus

Let’s now discuss how you might have gotten the non-technical domain experts on board.

raml-design


The picture above shows the RAML design for the API you want to build.

 After some conversations with your clients, you identified the “construction-machine” API needed to be provide search for parts (/parts/search).  You also discovered that parts should be accessible via a resource id (/parts/{part_id}), and that every part has a price (/parts/{part_id}/price). Additionally, in the first iteration suppliers should also be searchable (/suppliers/search).

 With this contract in place (agreed upon by both parties), you can now begin thinking about implementation.  And while you work on implementing the API, front-end developers can begin coding against a mocked version leveraging sample data you provide with the mocking service available in API Designer.

Data Query Application Implementation

data-query-application-integration

The first step in building the Data Query Mule application is to load the mutually agreed RAML specification into Anypoint Studio, which then creates a stub implementation of your API. This application by itself is now runnable and can be deployed on any Mule runtime, either in the cloud or on-premises.

The second step in building the application is to add a Mule XML configuration file to host your Neo4j graph database functionality. It includes Cypher query generation and reaches out to your Neo4j installation to run the query via the Neo4j REST API. 

This kind of separation gives you freedom to grow your application’s functionality in future versions of your project should you decide to move away from Neo4j.

The complete functioning solution can be reviewed here.

https://github.com/Brazo/data-query

Solution In Action

Now let’s see this implementation in action with an example. Suppose a user is querying your API from a mobile device in order to retrieve all parts that belong to your client’s Excavator Chassis (e.g. with part id = 13). The user is requesting the following resource: http://localhost:8081/api/parts/search?belongs-to=13.

  1. APIKit router validates all incoming requests from the mobile device and outgoing message formats according to your RAML specification
    apikit-router
  2. Depending on the request resource (e.g. /parts/search?belongs-to=13) the corresponding Mule flow is invoked
    <flow name=”get:/parts/search:construction-config”>
    construction-mule-flow
  3. The /parts/search flow extracts and validates the supplied query parameters
    <add-message-property key=”belongsto”
    value=”#[message.?inboundProperties[‘http.query.params’][‘belongs-to’] or -1]” />
  4. Query parameters were stored into a flow variable and used in the Choice router for correct handling
    <when expression=”#[?belongsto >= -1]”>
    <flow-ref name=”neo4j-adapter-search-parts-belongs-to”
    doc:name=”neo4j-adapter-search-parts-belongs-to” />
    </when>
  5. The given belongs-to query parameter invokes a specific flow on the Neo4j adapter implementation that generates a corresponding Cypher query
    <flow-ref name=”neo4j-adapter-search-parts-belongs-to”
    doc:name=”neo4j-adapter-search-parts-belongs-to” />
    cypher-query
  6. The Neo4j API for single transaction Cypher queries (db/data/transaction/commit) is invoked using the standard Mule HTTP connector
    <flow name=”neo4j-adapter-search-parts-belongs-to”>
    <set-payload value=”{ “statements” : [ { “statement” : “match
    (n:Part)-[:belongsTo]->(p:Part) where p.itemId=#[belongsto] return n” }
    ]}” doc:name=”Set Payload”/>
    <flow-ref name=”neo4j-adapter-call-out” doc:name=”neo4j-adapter-call-out”/>
    </flow>neo4j-callout
  7. Neo4j answers with a JSON response containing the query result
  8. DataMapper is used to transform the Neo4j JSON result message to your XML Schema format
    <data-mapper:transform config-ref=”JSON_To_Xml_search_result_” doc:name=”JSON To Xml search-result” />
  9. The API XML response is returned to the Caller, in this case a mobile device
    api-xml

Extending the application with business logic.

With the data query solution working smoothly, you can now move on to address the requirement of real-time currency conversion.  The goal: every item’s price can be retrieved with the current exchange rate. For that, you wrote a Currency Converter using Google Finance and Anypoint DevKit.

Once built, you can drop the custom connector into the API resource /parts/{part_id}/price flow. First, look it up in your Connectors list:

Then add it to your API implementation flow…

… and finally configure the currency conversion to be dynamic.

Now you have a functioning resource for all parts prices. Whatever Euro amount Neo4j returns is dynamically converted into the requested currency code.  Another requirement solved!

The Impact of API-led Connectivity

If we take a step back and think through the solution we just created, a few key advantages come to mind:

  • API-led Connectivity ensures alignment across business and IT at critical design-time
  • Exposable and manageable experience API hides backend complexity
  • Solution was delivered without custom code, increasing speed of delivery
  • Solution can be deployed on-premises or in the cloud, with one Mule runtime
  • Each application component acts as subdomain in Mule, nicely separated and extendable without affecting the other parts of the solution
  • The business can switch from Neo4j to another storage solution without affecting the API, it would only require you to reference the new storage adapter
  • You can refactor the Data Query Application into two single applications by using an asynchronous protocol (JMS, AMQP) to decouple them instead of a flow reference
    • That could prove very useful if the API implementation needs to scale up massively
  • Cypher is powerful but developers or API user might not want to learn it
    • You wrapped Cypher language into the Neo4j adapter
    • The API implementation part (and thus developers) don’t know about Cypher
    • The Neo4j adapter can grow separately and in-house developers can work on it using Cypher without affecting the API implementation
  • The real-time currency converter is now a reusable component built quickly with functionality available to every developer in Anypoint Studio

Ready to start your own innovation project? Get started with Anypoint Platform.  The next post will discuss how to build a write API.

XSLT transformations: also faster since Mule 3.6

Reading Time: 3 minutes
speed

This is a follow up to the last post in which we discussed performance improvements on our XPath functionality obtained from the revamped XPath and XSLT support in Mule 3.6. This time, we’ll go through the same exercise but for the XSLT use case.

The test

Just like with XPath, we worked with Luciano Gandini from the performance team. He came up with a test in which he measures the transactions per second (TPS) and latency of two XSLT transformations which inverts the tags of an XML.

This is what the two XSLT files looks like:

And finally, this is the mule flow that was tested:

The Results

image (4)

Let’s analyze the results starting from a TPS point of view:

When tested with few threads, the performance is pretty much the same. However, as we started increasing the concurrency level, then the performance climbed up to 50% faster than the same transformation running un Mule 3.5.2.

The first conclusion is that concurrency is a factor here. So let’s take a look at the latency:

image

Again, latency stays pretty much the same until the concurrency starts to climb, reaching an average of 30% less latency once concurrency went past 50 threads. So the question was, what happens if we give it even more concurrency?

image (1)

Hitting the flow with more than 1000 concurrent threads showed pretty much the same behavior as before, until at some point the lines began to converge. This comes as no surprise since – as we always say in all the performance related posts – less threads are often more.

Summary

Just as with XPath, XSLT also got a performance boost in the 3.6 release. However, this improvement only gets considerably noticeable in cases of high concurrency.

Thank you for reading!

Anypoint Platform June 2015 Release: Business Groups

Reading Time: 6 minutes

I’m excited to announce a new capability released with Anypoint Platform June 2015: Business Groups. Business Groups provide a mechanism for delegating management and administration of Anypoint Platform to users within different business units or functions. Additionally, Business Groups provide complete isolation of resources allowing for multi-tenant use cases within your Anypoint Platform account.

Centralized administrators can create a multi-level, hierarchical structure of Business Groups and then delegate users from the specific groups to be administrators. These group administrators then have the ability to manage permissions and roles as needed within their group. Business group administrators can utilize external identity providers such as PingFederate or OpenAM to easily map external LDAP groups to roles within the Anypoint Platform. This simplifies management of permissions across Business Groups. Additionally, Business Groups administrators have the option of creating their own sub-groups and delegate administrators of those sub-groups

Business Group administrators only have visibility to the groups they manage. They cannot view or manage permissions for resources outside of their specific group.

To learn more about how to create and manage Business Groups you can visit this documentation page.

Anypoint_Platform

Once Business Groups have been configured, individual users can then switch between Business Groups using the new Business Groups menu in the navigation bar (screen shot below). This will change their context in the active applications. Only resources from the selected Business Group will be visible in each application.

Anypoint_Platform_for_APIs___API_administration_and_Google_Calendar


Business Groups & CloudHub

One large benefit of Business Groups for CloudHub customers is the ability to easily delegate vCore workers across Business Groups. This allows customers to have a single subscription to manage and easily track usage & chargebacks by business unit or project. When creating a Business Group administrators can easily select how many production and sandbox vCores are available for consumption. Administrators of the Business Group can then create additional sub-groups and further divide their vCore allotments to those lower levels.

Anypoint_Platform

Business Groups & Anypoint Platform for APIs

Business Groups provides some additional functionality to the Anypoint Platform for APIs as well. First, Business Groups provides inheritance of API portal theming. If the top level Business Group sets a portal theme (colors, logo, etc) then, by default, all Business Groups lower in the tree will utilize this same theme. Individual Business Groups can set their own themes which can override the inherited theme, however.

Additionally, Business Groups allows users from individual groups to run their own API gateways. This allows the IT teams from each business or project group to be independent of centralized IT. That is each business or project group  can register API gateways using their own credentials and ensure that visibility of APIs managed through their gateway is limited to users and roles within that scope.

Business Group availability & additional resources

The Business Groups feature will be available to all Anypoint Platform customers with an Enterprise level subscription or higher. If you are not currently an Enterprise customer but would like access to the feature please contact your MuleSoft representative. To learn more about the feature you can find the documentation here or you can visit http://anypoint.mulesoft.com to get started.

CloudHub June 2015 Release: Hybrid Management

Reading Time: 5 minutes
hybrid-management

The June 2015 release of CloudHub and Anypoint Management Center features a major new functional capability on the Anypoint Platformhybrid management – the ability to manage on-premises servers and applications from the CloudHub management console. With hybrid management, users can manage applications and servers running anywhere, whether within the CloudHub managed cloud, or on-premises within their data center, from a single management plane.

When you log into CloudHub today, you’ll notice that there’s a change in the look and feel of the management UI. In this blog, I’ve provided a video walkthrough of this new UI as well as a few screenshots of the key changes you’ll see when you first log in.

The first change you’ll notice in the new UI: there’s now a new tab called Servers on the top landing page.

Server Deployment

This is the tab you will use to configure and manage any on-premises servers. In order to make an on-premises server available as a deployment target on Anypoint Management Center, it first needs to be registered with CloudHub. For details on how to register and manage your on-premises servers, please refer to the documentation.

Server Type

Once a server is registered and running, it becomes available as a deployment target for your applications. In addition to deploying applications to on-prem servers, you can also deploy to API Gateways as shown in the screenshot below. Please refer to the documentation for more details.

Deployment Target

After you’ve deployed an application to an on-premises server, it shows up on the list of your applications with a special icon that designates it as running on an on-prem server.

On-Prem Server

Last but not least, hybrid management allows you to manage groups of servers as a single deployment unit. You can use the “Create Group” button on the servers page to add servers to a group, and once the group is created, it becomes a deployment target to which you can deploy applications – and it is treated as a single entity to which an application can be deployed. Using this functionality, a user can manage cluster deployments by mapping a cluster to a server group, which allows the user to configure an application to run in a redundant fashion on multiple servers, for high availability. Group deployments show up in your applications page with a unique icon which quickly identifies it as a server group, and the details pane shows details of individual servers within the group. Please refer to the documentation for more details.

Server Group

In summary, with the June 2015 release of Anypoint Management Center, users have gained an important new addition to their management toolkit – the ability to manage applications and servers, whether running in the cloud or on-premises within their data center, from a single management panel on CloudHub.

Looking to get started? Sign up for an Anypoint Platform trial. Current MuleSoft Enterprise customers will have the hybrid management entitlement enabled later this week.

MuleSoft Announces the Champions Wall of Fame

Reading Time: 4 minutes
champions

MuleSoft Champions are the life-blood of the MuleSoft community – experts who work tirelessly to give back to the community – whether it be through core contributions, creating connectors, writing blog posts, or through answering questions on our forums and StackOverflow.

For the work that our Champions do, we cannot recognize them enough. First we started with the creation of the MuleSoft Champions Program of which only 7 people have reached the highest honor, becoming a MuleSoft Champion.

Becoming a Champion in itself is difficult, and is worthy of as much recognition as possible. It requires someone who is dedicated to becoming proficient in the different MuleSoft technologies, while also having a passion for the community, and being selfless enough to give back time and time again without expecting anything in return.

tomas_blohm

One such Champion in Tomas Blohm, an Integration Architect with Pulsen. Tomas is not just a MuleSoft Champion, but was also the first to receive the highest level of certification in Mule ESB – becoming a Mule Certified Developer, as well as the first to be recognized as a Champion – being hand picked by MuleSoft founder Ross Mason!

To give you an idea of his experience and dedication, Tomas was first introduced to Mule ESB 1.2 back in 2005. Over the last 10 years he has been an active member of the community, answering hundreds of questions on the forums, as well as contributing to the Mule ESB core and the SFTP, LDAP, and JBPM connectors.

Today it is my privilege, while announcing the MuleSoft Champions Wall of Fame, to recognize Tomas for all of his work over the last 10 years, and to add one more MuleSoft first to his resume – being the first to make it on the wall.

His work provides an inspiration to us all. A role-model for those who have already joined the program and work to make the community better everyday.

Please join me in congratulating Tomas in the comments below. To learn more about the MuleSoft Champions program, and how you too can be featured on our Wall of Fame, visit https://developer.mulesoft.com/champions.

Mule 3.7.0 and Anypoint Studio June 2015 RC: Introducing DataWeave

Reading Time: 9 minutes
dataweave

Building on the success of CONNECT 2015 in San Francisco, we’re happy to announce the final release candidate for Mule 3.7 and Anypoint Studio June 2015.  Planned GA is now less than a month away!

Highlights of this release:

  • DataWeave: a new language and module for querying and transforming data
  • Metadata enabled payloads: attach metadata to payloads for context-aware connectivity
  • Non-blocking HTTP proxies: Scale APIs with higher concurrency
  • Java 8 support: Mule 3.7 is compliant with both Java 7 and Java 8

Introducing DataWeave

As organizations struggle to deal with the proliferation of applications and APIs inside their organization, being able to integrate data at speed and scale plays a pivotal role.  Specifically, we’re seeing with our customers a need to:

Continue reading

Continuous Integration with Mule and Gradle

Reading Time: 7 minutes
gradle

We use automated build systems not only because they make our lives easier by taking care of building our apps, but because they can run our automated tests and deploy what we build to the target platform. One of our options for building applications (especially Mule applications) is Gradle. The Gradle plugin for Mule apps provides a variety of ways to deploy Mule apps and that’s what we’ll be covering in this post!

Note:This is the fifth part of our Gradle plugin series; be sure to check out the previous posts!

First, I want to mention what our current version of Gradle can do today. Then, I’ll introduce features that are under development for release 2.0 of the plugin.

Continue reading