Using MuleSoft Anypoint Exchange as an API Hub.

Introduction

MuleSoft Anypoint Exchange is one of the amazing platforms available in MuleSoft for sharing various reusable components, REST APIs, SOAP APIs, etc. In this document, we will try to use MuleSoft Anypoint as an API Hub, a single place to visit and understand all APIs in our landscape. In this document, we would import a non-Mule API in MuleSoft Exchange, however, we will not use this as a Proxy, so we will not be able to put the MuleSoft policies or any other features. This can only be used as an API placeholder for someone to discover and use this API.

Prerequisite

For this blog, we would need to make sure, there are a few things. We will not go through how to get them, because that would not be a part of this document.

• Anypoint Platform with Anypoint Exchange
• An API with an Open API Specification running on a non-Mule server. I am using a Node.js API running on an EC2 instance with an OAS.

Anypoint Exchange

Anypoint exchange is a marketplace for connectors, templates, examples, and of course APIs. This can be used to discover, and use pre-build assets from the MuleSoft ecosystem, or to save, share and reuse internal best practices.

However, we, in this case, will use only the API Management part, where we would Publish an asset, describe the same, and then allow us to simulate data using a mock endpoint and connect to the actual endpoint.

So, let us log in to the MuleSoft platform using the URL https://anypoint.mulesoft.com and then click on the option of Exchange. This can be found in the middle of the page or found in the menu on the top Left. 

Once this is done, we will get into the exchange page, and this is where we will try to publish our API.

Non-Mule API created using Node.js

I have created a non-mule API here using Node.js, this can be any non-mule API e.g., it can be an API using SAP Cloud Platform, however, to add this API to the exchange platform, it must support and have an API Definition using OAS Specification. MuleSoft supports RAML, OAS 2.0, or OAS 3.0 both in JSON and YAML format.

These are my API created in AWS.

I have created the same API in 2 different EC2 servers, naming one as dev and one as stg. This is similar to another application that can have multiple environments like dev, stage, and production. Both the APIs are accessible using the endpoint http://<host>:3000/

This is a simple API that does CRUD operation on 2 tables named User Master, and User Transactions. The APIs are consumable using the endpoint as per the Open API Specification. Here is an example call:

The open API Specification is accessible using the endpoint

https://<host>:3000/openapi.json

A similar API is available in the stg instance using a different IP Address. 

We should select the Development Open API Specification and download it to a folder on our computer. 

Step 1 to Import to MuleSoft: Design Center

The Design center can be used to write API definitions with RAML using API Designer. This can be accessible by Clicking the Menu on the Left Top and clicking Design Center. Initially, there will be an empty design center. We can create a new API Specification here, however, we will simply import the downloaded API Spec (OAS).

We will simply Click on the Create New button and then click on Import from File.

Now we should fill in the necessary fields, like Project Name, we will select the import type as REST API and then choose the file that we downloaded earlier. Next, we will select Import.

Our Open API Specification will be imported into the Design Center and we should be able to visualize all the API endpoints that are available in this OAS on the right side of the screen.

Step 2 to Import to MuleSoft: Publish to Exchange

Since we are not changing anything in the Design Center, we will simply publish this in the Exchange. Let us press the button Publish, fill up the details like Asset version, etc. and click Publish to Exchange as a Stable version.

Upon successful deployment, we should receive a confirmation with a link to our Exchange document. 

We can press the link to navigate to our API in the Exchange with all the details that we had earlier filled up. In the exchange, we find all the API endpoints on the Left side. Also, we can notice, that there is a Mocking Service already associated with our API.

MuleSoft exchange converts an OAS to RAML as well as a RAML document to an OAS, so, once we press the Download button, we have an option of downloading our API using both RAML and OAS.

Step 2 to Import to MuleSoft: API Manager Setup

Once our API is in Exchange, we must set up the API Manager so that a different version of the API is available in the Exchange hub. This is important since we would want our consumers to find both our Dev and Stg versions in the Exchange hub so that they can get access to and consume the different environments as necessary.

Here, we need to click on Add API. This will provide us with a few options and we will simply select Mule Gateway.

We will select the API Defined in Exchange and click on Next

This will take us to the API Managers screen for our Development Instance. Please note that Design Center and Exchange are not environments specific, however, API Manger is environment specific, and we are now in the Dev environment of the exchange.

The Implementation URL and the Consumer Endpoint on this page point to the IP Address of our Dev EC2 Instance. Once this is set up, we can head back to the Exchange and now we will see, that there is a Dev environment along with the Mocking Service showing up in the Asset Version.

Migrating API to the Higher environment.

Our next step is to set up the higher environment. For this, we will head back to the API Manager and select the Test Instance.

Next, we must click on the Add API and then select "Promote API from environment".

This will allow us to select the API from the Dev environment and promote this to our Test environment.

After selecting the various details like Source, API Name, and Version, we will Promote this to the Test environment and then change the Implementation URL and the Consumer endpoint to point to the Stg EC2 instance, which we noted earlier.

We should now click next, and we will find all the details. Note that our API will show unregistered since we are not creating a Mule Proxy, we are simply using the Exchange hub as an API registry, and this API will not be secured or managed by our MuleSoft platform.

Once we are done with this step, we will check our Exchange page and now, we can find that along with Mocking and Dev, a Test option is also present. 

We can select any API endpoint, e.g., /ping, and if we click on the "Select server" drop-down, we should see the option of selecting Dev or Stg to test the API.

If we select, Test instance, we can see, that the Test IP Address of the EC2 instance shows up. 

We can click the Send button to check the end-to-end connectivity to our API.

Exchange Tags for Searchability

We can add tags in the Exchange so that this API can be easily searched when the exchange has more APIs. Generally, any API are searchable in the exchange by any endpoint names, tag names, or name of the API itself.

Conclusion

This blog shows how to use MuleSoft Anypoint Exchange as an Enterprise API Hub. In case, we have MuleSoft in our landscape, and we have APIs in another platform, we do not need another third-party API hub, we can use MuleSoft Anypoint Exchange as a single point of Enterprise hub to promote both Mule and Non-Mule API. Also, note that this blog does not contain a single line of code. So, this entire process is done as a no-code option.