MuleSoft.U — Week 3 — Deploying APIs and API Proxy

In the first week, we designed our APIs. In the second week, we implemented the APIs. In this week we are going to deploy our APIs and also create API proxies.

Contents

Deployment Options
Application Properties
Deploy Application to the Cloud
API Proxy
Manage Access to APIs
Restricting Access to API Implementations

Deployment Options

  1. On-prem Mule Runtime
  2. CloudHub (Recommended)
  • Hosted Mule runtime on AWS
  • PaaS of Anypoint Platform
  • Fully-managed by MuleSoft, highly available, highly secure

Application Properties

Application properties are used to specify environment-specific information e.g. application port, database username and password instead of hardcoding them in the application.

Create a Properties File

Create a new file named american-DEV.properties.

Input the following into the file and save:

http.port = 8081
db.host = mudb.mulesoft-training.com
db.port = 3306
db.user = mule
db.password = mule
db.database = training

Open interface.xml and go to Global Elements. Click Create.

Select Property Placeholder and click OK.

Input american-DEV.properties into Location field and click OK.

Edit HTTP Listener Configuration and update Port to ${http.port}.

Go to implementation.xml → Global Elements and edit MySQL Configuration.

Set the following fields:
Host: ${db.host}
Port: ${db.port}
User: ${db.user}
Password: ${db.password}
Database: ${db.database}

Test connection and save.

Note: You may need to update database configuration to use the online one instead i.e. MySQL.

Run the application and test it with Postman.

Setting Environment

Open mule-project.xml and add a new Environment variable env=DEV.

Note that the variable created is stored in the file mule-app.properties.

Go to interface.xml → Property Placeholder and edit it. Replace Location with american-${env}.perperties.

Run and test the application again to make sure everything is still working.

Deploy Application to the Cloud

Deployment Options

  1. From Anypoint Studio directly
  2. From Anypoint Platform Runtime Manager
  • Export from Anypoint Studio as a ZIP file
  • Create application in Runtime Manager

CloudHub Workers

  • Worker is an instance running Mule application.
  • Each worker is running on separated server.
  • Each worker can have different memory and processing power.
  • You can add multiple workers for an application.

Create Production Environment

Go to your Subscription on Anypoint Platform.

If you see like below, you need to create Production environment and run application under Production environment instead of Sandbox.

Go to Access Management → Environments and click Add environment.

Add Production and click Create.

Go to your profile and select Production as your default environment.

Deploy Application

Deploy to cloud by choosing Anypoint Platform → Deploy to Cloud.

Set the application name. It must be unique which indicated by green light.
Set the worker size to 0.1 vCores.

Go to tab Properties and you will see the application properties is already set correctly. Click Deploy Application.

Once it is deployed, click Open in Browser.

You should see your application is in Deployed status. You can access your application with App url.

Go to your_app_url/api/flights.

Test your app with Postman.

Upload Mule Application Archive

Click Manage Application.

In the Settings, click Choose file and select apdev-american-ws.zip from student files/resources.

Go to Logs and wait until you see message Your application has started successfully.

Test with Postman with query string ?code=SFO.

Prepare RAML file for Proxy

Go to API Manager. Open American Flights v1.0 and open API Designer.

Turn off Mocking Service and replace the RAML with:

#%RAML 0.8
title: American Flights API
version: 1.0
schemas:
- flight: |
{
"properties": {
"code": {
"description": "The flight ID",
"type": "string",
"required": true
},
"price": {
"description": "The flight price",
"type": "number",
"required": true
},
"departureDate": {
"description": "The flight departure date",
"type": "string",
"required": true
},
"origin": {
"description": "The three letter airport code for the airport of origination",
"type": "string",
"required": true
},
"destination": {
"description": "The three letter airport code for the airport of destination",
"type": "string",
"required": true
},
"emptySeats": {
"description": "The number of available seats",
"type": "integer",
"required": true
},
"plane": {
"description": "The plane specs",
"type": "object",
"properties": {
"type": {
"type": "string"
},
"totalSeats": {
"type": "integer"
}
}
}
}
}

/flights:
get:
queryParameters:
code:
enum: [SFO, LAX, PDX, CLE]
responses:
200:
body:
application/json:
example: |
[{"ID":1, "code": "ER38sd","price": 400, "departureDate": "2016/03/20", "origin": "MUA", "destination": "SFO", "emptySeats": 0, "plane": {"type": "Boeing 737", "totalSeats": 150}}, {"ID":2,"code": "ER45if", "price": 345.99, "departureDate": "2016/02/11", "origin": "MUA", "destination": "LAX", "emptySeats": 52, "plane": {"type": "Boeing 777", "totalSeats": 300}}]
post:
body:
application/json:
schema: flight
example: |
{"code": "ER38sd","price": 400, "departureDate": "2016/03/20", "origin": "MUA", "destination": "SFO", "emptySeats": 0, "plane": {"type": "Boeing 737", "totalSeats": 150}}
responses:
201:
body:
application/json:
example: |
{"message": "Flight added (but not really)"}

/{ID}:
get:
responses:
200:
body:
application/json:
example: |
{"ID":1, "code": "ER38sd","price": 400, "departureDate": "2016/03/20", "origin": "MUA", "destination": "SFO", "emptySeats": 0, "plane": {"type": "Boeing 737", "totalSeats": 150}}

delete:
responses:
200:
body:
application/json:
example: |
{"message": "Flight deleted (but not really)"}

put:
body:
application/json:
schema: flight
example: |
{"code": "ER38sd","price": 400, "departureDate": "2016/03/20", "origin": "MUA", "destination": "SFO", "emptySeats": 0, "plane": {"type": "Boeing37", "totalSeats": 150}}

responses:
200:
body:
application/json:
example: |
{"message": "Flight updated (but not really)"}

Now you should see our APIs has more functionalities. Save change.

API Proxy

API Proxy is to control access through the use of API Gateway.

API Gateway is to host API or open connection to API on somewhere else.

Creating API Proxy

Add baseUri with your application URL/api.

Go back to API settings and click Configure endpoint.

Leave default values and select Configure proxy for CloudHub. Click Save.

You can click View configuration details to see the connection diagram.

Deploy Proxy

Click Deploy proxy.

Assign a unique name again and click Deploy proxy.

Wait until the deployment completed.

Go to Runtime Manager and you will the proxy application is running.

Test the proxy with Postman.

Monitoring API

Go back to API Settings and move down you will the usage graph.

Click Analytics Dashboard link to open more detailed view.

Managing Access to APIs

API Manager manages access to the APIs including:

  • SLA tiers — set approval process to access your APIs. Request API access button will appear in API portal.
  • Runtime policies — enforced by API Gateway to control request and access. Including:

Applying Rate Limiting Policy

Go to Policies and click Apply New Policy.

Select Rate limiting and click Configure Policy.

Input 3 per 1 minute and click Apply.

Test with Postman. You will get 429 Too Many Requests when requesting beyond the limited rate.

Applying SLA-based Policy

Go to SLA Tiers. Click Add SLA tier.

Input the following and click Add.
Name: Free
Approval: Automatic
Limits: 1/hour

Add another one:
Name: Premium
Approval: Manual
Limits: 1/second

Go to Policies and remove the existing policy.

Add a new Rate limiting — SLA based policy.

Leave the default values to get client_id and client_secret from the query string. Click Apply.

Test with Postman and you will get 401 Unauthorized.

Requesting API Access

Open API Portal.

Click Request API Access. Click New application.

Name your application and click Add. Select Premium and click Request API access.

Click Application detail to see the client_id and client_secret.

Go back to API Settings → Applications and click Approve.

Test with Postman by giving client_id and client_secret.

http://american-flights-api-pacroy.cloudhub.io/flights?client_id=<your_client_id>&client_secret=<your_client_secret>

Note the response header specifies rate limiting information.

Restricting Access to API Implementations

You can restrict access to backend APIs by putting them behind firewall and let clients access via API Proxies only.

In case you use CloudHub as your API Proxies, you can setup VPC.

The End

Now, I have quite enough picture about what I can do with MuleSoft. And due to other priorities, I’ve decided to stop my learning journey here. Enjoy your journey!

Show your support

Clapping shows how much you appreciated Chairat Onyaem’s story.