Mulesoft Internals — AutoDiscovery
Introduction
You have read hundreds of articles on the Internet about using MuleSoft’s Anypoint platform, but I believe very few of them dive deep into it. So this article aims to dive into the internals of MuleSoft to find out how an API is tracked through the API instance ID. The article is aimed at an audience that already has knowledge of MuleSoft.
Ten thousand feet above
In this article, we will discuss the above flow.
An API specification is created using RAML or OAS in Design Center. Once this is done, it is published in Exchange.
An API is created in API Manager by importing the RAML from Exchange. The result of this action is the API instance ID, which uniquely identifies the API.
The RAML is downloaded from Exchange to the local system and the specification is implemented using Anypoint Studio. In addition, the API instance ID is configured in an autodiscovery configuration so that the API is automatically discovered (in step 2).
Stored Information in Cloud
When an API (API instance) is created in Anypoint Platform’s API Manager, the information such as API instance ID, label, implementation URL, etc. is stored in the cloud. We do not have direct access to them except through the REST APIs (or the Anypoint CLIs).
Mule Runtime — Localhost (On-Prem)
When the API Instance ID is configured in the Mule application with an autodiscovery configuration and deployed to a local runtime environment, the API status in the API Manager console is set to Active.
This happens because when the Mule application is deployed in the local runtime environment, the runtime environment communicates internally with the Anypoint Platform (Cloud) through some APIs to communicate that there is someone (the Mule application) actively listening to the API (API instance).
Now, let’s say we have applied a policy to the API. Will it affect my local Mule application?
The short answer is yes. The question is how and to know it please check the next section.
API Tracker
All the above magic happens through a class called ApiTracker. In fact, if you look at the source code of the class, there is no magic at all.
Below is the jar that contains the class.
Analysis of the Source Code — ApiTracker
The ApiTracker class implements an interface called ApiDeploymentListener, which is triggered after a successful deployment of the Mule application and calls its onApiDeploymentSuccess (line 39). Finally, it calls the trackApi method (line 43).
Check this on line 43 in the diagram below.
The trackApi method is responsible for tracking all changes (i.e. adding or removing policies, etc.) to the API.
If you dive deep into the classes when debugging the Mule Runtime, you will notice that the com.mulesoft.mule.runtime.gw.client.ApiPlatformClient class defines all the necessary API calls that the trackApi method eventually invokes.
Analysis of the Source Code — ApiPlatformClient
ApiPlatformClient class can be found in api-gateway-client-4.4.0.jar as shown in the below diagram.
The trackApi method of the ApiTracker class calls the getApi method of the ApiPlatformClient class, as shown in the following figure (line 167).
You can see that the getApi method does nothing more than call an Anypoint Platform API (line 168) to get information about the current API via the Instance ID.
Now, at this point, when our API was deployed in localhost, it was tracked. The next question is:
Once the API is running how it’s tracked?
Check the next section to understand it.
Analysis of the Source Code — ApisRunnable
Once the Mule API is deployed, it needs to be tracked. There is a scheduled job for this. The job calls the class below:
com.mulesoft.mule.runtime.gw.deployment.runnable.ApisRunnable
The above method is executed at a specified interval and internally calls the getApi method (line 42) of the ApiPlatformClient class. See the previous section for an explanation of the ApiPlatformClient class.
Line 43 is interesting in the diagram above. At this moment, our Mule runtime has already called the cloud API manager to get the latest information about the API.
On the response received, it calls apiResponse.hasUpdates() to check if there is a change (e.g. adding or removing policies, etc.) in the API. If there is a change, it calls another method, 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
Analysis of the Source Code — DefaultApiTrackingService
It can be found under the below module:
Below magic happens in the method apiTracked (line 44),
On line no 50 you can see that it invokes 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
The method performs a series of operations. You can see that line 58 checks whether the Mule runtime environment was able to download the policies from the API manager in the cloud.
You can check this behavior by deleting all the policies in the policies directory of the Mule runtime environment. You can verify that after the specified API tracking interval, all the policies applied to the API (or instance ID) are downloaded from the API Manager.
Conclusion
In this short article, we have looked at the importance of the API instance ID. It is the single source of truth for the Mule runtime (on-premises or via CloudHub) to communicate with the API in API Manager. Through the ID instance, the Mule runtime environment can detect any changes to the API (in the API Manager).
