Over a million developers have joined DZone.

Dynamic CloudHub Deployment From Mule Application

Read on to learn a simple way of deploying applications to CloudHub programmatically and dynamically from a Mule application at a high level.

Is iPaaS solving the right problems? Not knowing the fundamental difference between iPaaS and dPaaS could cost you down the road. Brought to you in partnership with Liaison Technologies.

CloudHub is the Anypoint Platform which provides a fully managed, multi-tenanted, globally available, secure, and highly available cloud platform for integration and APIs as a service (iPaaS). It is managed via the Runtime Manager console.

We can deploy our applications to CloudHub in various ways such as CloudHub API, CloudHub Command Line Interface, Maven pom, from Anypoint Studio or directly from the CloudHub interface with a Mule deployable ZIP file via the Runtime Management Console.

Now, how about deploying it from Mule application on-premises?

We will demonstrate here a simple way of deploying applications to CloudHub programmatically and dynamically from a Mule application at a high level.

CloudHub exposes various CloudHub APIs via REST AP,I which can be consumed and used to do various CloudHub operations from our Mule application (such as creating an application, deploying an application, reading a log file, deleting an application, change application properties and deploy a new version of an application, and much more).

Creating an Application

To start with, we will be consuming CloudHub API to create an application in our CloudHub account from our Mule application that will run on-premises.

Here, we will create a Mule application in our Anypoint Studio that will be exposing an API of our own to the users and will create an application and domain name in our CloudHub account dynamically by consuming the CloudHub API. The advantage is that this application can create multiple CloudHub applications into our account dynamically from the application.

So, we will be designing the following RAML specification for our application to expose our own API that will internally consume CloudHub API:

Importing the RAML file in our Mule application in Anypoint Studio, will generate different flows in our application, including api-main flow, api-console flow, api-apiKitGlobalExceptionMapping flow, and post:/createApplication:api-config flow, which will implement and expose our API.

We will be modifying post:/createApplication:api-config flow as the below image so that we can implement our logic of creating an application or domain in our CloudHub account:

The flow is implemented with HTTP request component at the end to hit the CloudHub API and create the application or domain in our CloudHub account.

We will be using this API, exposed by CloudHub, for creating the application in the account and configure it in our HTTP request component. Remember to configure the HTTP endpoint with the REST API exposed by CloudHub along with your CloudHub credentials.

Testing Our Flow

After deploying the code in the server, we will be getting our own API available in the APIKit console as below:

We are ready to go! We can see our application is deployed on our on-premises Mule server with the base endpoint http://localhost:8081, and the API is available in the list of the consoles.

On clicking the /createApplication POST button, we will be getting the following screen ready with a JSON request for creating the application name in our CloudHub account.

Here, you can see the JSON request with the domain name (our application name). CloudHub workers details and other details like values in the properties file can be filled here dynamically.

In the meantime, we will be logging into our CloudHub account to monitor the activity here:

When we check the Runtime Manager, we will find no application currently present in my account:

Now, when we click the POST button of our /createApplication API, we will be creating an application dynamically to our CloudHub account with the following response in the APIKit console, indicating that the operation was successful:

Now, if we go back to our CloudHub account to check if the application was created successfully, we will find that it is created there with all the details (domain or application name, CloudHub workers details, Mule runtime version, etc.):

Now, as our application is ready, we only need to deploy our Mule deployable ZIP file in the CloudHub server.

At the end, if we click on the Settings tab on the bottom left and then go to the Properties tab from there, we will find the following properties are set (these properties are already set dynamically from the JSON request):

Deploying an Application

We will be creating a simple Mule flow that will pick a Mule deployable ZIP file from a folder and send them to the CloudHub server for deployment. Following a simple Mule flow can be created to achieve this task:

As we can see, a File inbound component is present at the beginning of the flow, which will be picking the file from a shared folder and will pass the file to the CloudHub server where it will get deployed.

We will be consuming following REST API exposed by CloudHub in our HTTP request component.

Testing Our Flow

We will be testing how our flow works by placing a Mule deployable ZIP file in a shared folder, from which the file inbound will pick up:

If we now go back to our CloudHub account, we will find the application is getting deployed in CloudHub server:

We can check the CloudHub logs for confirmation:

And finally in the dashboard, we will be happy to see it has started:

We can now create and deploy as many applications we need in our CloudHub account.

Conclusion

So, as we have already seen a small demonstration of implementing the CloudHub API in our on-premises Mule application dynamically, we can go ahead and implement other CloudHub APIs in our Mule application as per our need.

There are other REST APIs exposed by the CloudHub for all other various functions (such as getting a list of all application deployed, getting the details of a specific application deployed, deleting an existing deployed application, updating a deployed application, viewing CloudHub log details, saving as an external file, etc.) which we can easily implement in our application. This will enable you to control the CloudHub-based operation from our Mule application itself with all of values configured in a dynamic way.

Please feel free to share your feedback and experiences in the comment section below.

Discover the unprecedented possibilities and challenges, created by today’s fast paced data climate and why your current integration solution is not enough, brought to you in partnership with Liaison Technologies.

Topics:
cloudhub ,mule ,api ,integration

Published at DZone with permission of Anirban Sen Chowdhary, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}