You've seen hundreds of articles on how to use MuleSoft's Anypoint Platform, but very few of them take a deep dive into its inner workings. This article aims to delve into the internals of MuleSoft to find out how an API is tracked via API Instance ID. Already have existing knowledge of MuleSoft? This article is for you.

Introduction

In this post, we're going to discuss the flow of the high-level architecture presented in the image below:

1. An API specification is created using RAML or OAS in Design Center. Once this is done, it's published to Exchange.
2. An API is created in API Manager by importing the RAML from the Exchange. The outcome of this action is the API Instance ID that uniquely identifies the API.
3. The RAML is downloaded from the Exchange to the local system and the specification is implemented using Anypoint Studio. Also, the API Instance ID is configured in an Autodiscovery configuration so that the API (in step 2) is automatically tracked.

Where Is the Information Stored?

When an API (API Instance) is created in the API Manager of Anypoint Platform, the information (such as API Instance ID, Label, Implementation URL, etc.) is stored in the cloud. We don't have direct access to this info except through the REST APIs (or the Anypoint CLIs). 

On-Prem Mule Runtime

When the API Instance ID is configured in the Mule application using an Autodiscovery configuration and deployed in a local runtime environment, the API status becomes Active in the API Manager console. 

This happens because when the Mule application is deployed in the local runtime, the runtime internally talks with the Anypoint Platform (cloud) via some APIs to inform it that there is someone (the Mule application) who is actively listening to the API (API Instance).

Now, let's say we have applied a policy to the API. Will it affect our local Mule application?

The short answer is yes. The question is how it will be affected, which we'll explore in the next section.

API Tracker

All of the magic described above happens through a class called ApiTracker. But in fact, if you check the source code of the class, there is no magic at all. 

Below is the jar which contains the class.

Explanation of the Source Code - ApiTracker

The class ApiTracker implements an interface called ApiDeploymentListener. After a successful deployment of the Mule application, this listener (ApiTracker) is triggered and its onApiDeploymentSuccess (line 39) is invoked. Eventually, it invokes the trackApi (line 43) method.

Check it out on line 43 in the diagram below:

The trackApi method is responsible for keeping track of any changes to the API, such as policy additions or removals, etc.

If you deep dive into the classes by debugging the Mule Runtime, you will find that the class com.mulesoft.mule.runtime.gw.client.ApiPlatformClient defines all of the necessary API calls that the trackApi method eventually invokes.

Explanation of the Source Code - ApiPlatformClient

ApiPlatformClient class can be found in api-gateway-client-4.4.0.jar as shown in the diagram below:

The trackApi method of the ApiTracker class invokes the getApi method of the class ApiPlatformClient, as shown in the following diagram (line 167):

You can see that the method getApi performs no magic other than calling an Anypoint Platform API (line no 168)  to get information about the current API via the Instance ID.

Now, at the point when our API was being deployed in localhost, it was being tracked. The next question is:

Once the API is running, how is it tracked? 

Check the next section to find out.

Explanation of the Source Code -  ApisRunnable

Once the Mule API has been deployed, it must be tracked. So, there is a Scheduled Job for this. The job invokes the class shown below:

com.mulesoft.mule.runtime.gw.deployment.runnable.ApisRunnable

The method above is executed in a specific interval, and it internally calls the ApiPlatformClient class's getApi (line 42) method. Check the previous section for the explanation of the class ApiPlatformClient.

Line 43 is interesting in the diagram shown above. Now, at this moment, our Mule runtime has already made a call to the Cloud's API Manager to get the latest information on the API.

On the response received, it makes the call apiResponse.hasUpdates() to check whether there is any change to the API, like a policy addition or removal, or something similar. If there is a change, then it calls another method, i.e apiTracked (line 45), of the interface com.mulesoft.mule.runtime.gw.deployment.tracking.ApiTrackingService.

The implementing class of the ApiTrackingService is com.mulesoft.mule.runtime.gw.deployment.tracking.DefaultApiTrackingService.

Explanation of the Source Code -  DefaultApiTrackingService

The class can be found under the module below:

Check out the next image to see where the magic happens in the method apiTracked (line 44):

On line 50, you can see that it invokes the policiesForApi method of the interface com.mulesoft.mule.runtime.gw.policies.service.PolicySetDeploymentService.

The implementing class of the PolicySetDeploymentService interface is com.mulesoft.mule.runtime.gw.policies.service.DefaultPolicySetDeploymentService

Here's the magic:

The method does a series of operations. You can see that on line 58, it checks whether the Mule runtime can download the policies from the API Manager in the cloud. 

You can check this behavior by deleting all of the policies in the policies directory of the Mule runtime. You can verify that after the particular interval of API tracking, all of the policies applied to the API (or Instance ID) are downloaded from the API Manager.

Conclusion

In this brief article, we have explored the importance of the API Instance ID. It's the unique source of truth for the Mule runtime (on-prem or CloudHub) to communicate with the API in API Manager. The Mule runtime can detect any changes made to the API (in API Manager) via the Instance ID.