Running Mule API in Hybrid Mode – 3.8.x

Things are moving fast with Mule (no pun intended).

It has been barely a year since I posted about the Mule hybrid API with 3.7 release.  That version has already become somewhat obsolete. With the Mule release 3.8, the API gateway and ESB are firmly fused into one (technically that already happened with the last 3.7.x) and it is called Mule (Runtime) Engine.

Since some readers are still following the old post, they ended up installing old version gateway separately. This is a follow-up post to revise the steps in the old post, so the instructions will work for a single server install.

You can also reference this post for API deployment.

Mule Runtime Server Install & Configuration

If you don’t have an Anypoint Platform account, you can create one for free here.

Download and install the trial version of Mule runtime engine (server) here.

As of this writing, the current release is 3.8.3. After the servers are installed and running, we can move on to register these local servers in the “cloud”.

As a side note, if your server runs into an exception like this:

Root Exception stack trace:[UnexpectedErrorFault [ApiFault  exceptionCode=’UNSUPPORTED_CLIENT’

exceptionMessage=’TLS 1.0 has been disabled in this organization. Please use TLS 1.1 or higher when connecting to Salesforce using https.’

The most likely cause is you are running Java 7. You need to upgrade to java 8.

Additionally, if you plan to apply client-id or OAuth2 policies to your local server, you also need to do the following. We are skipping this step, because we are not using these policies in our examples.

# example from wrapper.conf
wrapper.java.additional.<n>=-Danypoint.platform.client_id=ORG-CLIENT-ID-HERE
wrapper.java.additional.<n>=-Danypoint.platform.client_secret=ORG-SECRET-HERE

Register the Servers

From the Anypoint Platform web console, go to the Runtime manager, then click on “servers”, and copy the “amc_setup” (AMC stands for Anypoint Management Console) line.

From the command prompt of your localhost, cd to the bin directories of the server, and execute the amc_setup commands.

Choosing a Global Software Development Partner to Accelerate Your Digital Strategy

To be successful and outpace the competition, you need a software development partner that excels in exactly the type of digital projects you are now faced with accelerating, and in the most cost effective and optimized way possible.

Get the Guide

My local server bin directory is C:\mule\mule-3.8.3\bin

Run “./amc_setup -H 23cd6*** **** 9f2—*** local-mule3.8.3” (your local server name can be different)

Now, our local servers will show up in the Anypoint console.

Part I – Create RAML and the Application

Now the servers are configured and running. Let’s create the API application.

1. Create the RAML with the Mule API management console

Technically, you can use any editor to create the RAML.  In this case, we will create the RAML from the Mule API management console. Login to anypoint.mulesoft.com; click on “API”, then click “Add new API”. Type in the API name “hello”, and start to edit/design the RAML.

In this example, my finished RAML is the good O “Hello world” (see the very end of this post)

This post doesn’t cover the steps of editing the RAML. You can find plenty of examples online on RAML.

2. Create the API project in Studio

After you are done editing the RAML, download it and use Anypoint Studio to create the API project based on the RAML

3. Finish Implementing the application

With the Studio, you can implement complicated functions based on RAML. In this example, I only touched the JSON response with something like “This is local get impl — hello #[name]”.

4. Deploy the application to Mule runtime engine (server):

Export the finished project as a .zip file. Now log into anypoint.mulesoft.com. Click on CloudHub, then “Applications/Deploy application.”  Select the application name. Select “local-mule3.8.3” as the target. (Your server name can be different. Make sure the server is running, otherwise, it will not show up in the dropdown list)

Check your application configuration file, and take a note of the URL (host, port, path) of your application. In this example, it is http://localhost:8082/api/*

Please note:

• I’m using localhost in this example. If you want to access the service or the API interface directly from the internet, the server needs to be on a domain that’s publicly accessible.
• Do not deploy the application directly to the local server. If you do, it won’t be visible from the CloudHub console.
• You can also deploy the application to CloudHub. If you do, your URL will be something like http://myapp-name.cloudhub.io. I used “local-mule3.8.3” in this case to show you the hybrid deployment.

5. Kick the tires

Browse to http://localhost:8082/api/console/. You can test the API using the console. You can also hit it directly with Chrome (IE may not like the Json response) http://localhost:8082/api/hello/foo, you should see something like:  {  “greeting”: “This is local get impl — hello foo”  }

Now we know the application is running on the server. In the next section we will expose this service as an API.

Part II – Deploy the API proxy

1. In step 1 of the last section, we merely used the API management console to create the RAML file. We haven’t done anything to manage the “hello” API.

Let’s go back to the API management console and click the version number 1 to the right of API “hello”.

On the next screen, click on “configure endpoint”:

2. Select the configuration values:

Remember the application runs on the Mule engine with the endpoint “http://localhost:8082/api”

I have picked the proxy to run on 8081 and path is /api-proxy

3. Deploy the API proxy

Click Save & Deploy, then select “local-mule3.8.3”, and deploy the proxy.

When the deployment is complete, you will see a “hell-v2-2.x.x” (that’s a system generated default proxy file name) is deployed in the apps folder on the local Mule server

4. Test the proxy

With Chrome, hit the proxy endpoint http://localhost:8081/api-proxy/hello/bar. You should see a similar response to step 5 in the previous section { “greeting”: “This is local get impl — hello bar” }

5. Let’s sum it up:

• We have created a “hello world” RAML using the RAML designer from the API management console.
• We have created an application based on the RAML using Anypoint Studio.
• We have deployed the application to the Mule runtime engine (server): “local-mule3.8.3”.
• We have created a proxy for API “hello” and deployed the proxy to the same server. Remember gateway and ESB are fused into one server now. The proxy is wired to the “hello” application on the same server.

For managing API policies, the steps are the same as in the previous post found here.