Commanding the System With Mule
It's very easy to operate System commands through a Mule application using a Java class.
Join the DZone community and get the full member experience.
Join For FreeRecently, I wrote an article called (Data)Weaving Expressions in Java that demonstrated how we can execute a Dataweave expression language in Java.
This time, I thought of writing a different kind of article that would demonstrate a dynamic execution of system operations with a Mule application that we generally do in a system command prompt.
This article will demonstrate how we can dynamically pass a system command in a Mule application and get our job done.
We will be using a Java class in our Mule application to execute the System command as follows:
package com.service;
import java.io.*;
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
public class SysCommand {
private static Logger log = LogManager.getLogger(SysCommand.class);
public String process(String command) {
StringBuffer response=new StringBuffer();
String line;
try {
Process .getRuntime().exec("cmd /c "+command);
process.waitFor();
BufferedReader reader = new BufferedReader(new InputStreamReader(process.getInputStream()));
BufferedReader error = new BufferedReader(new InputStreamReader(process.getErrorStream()));
while ((line = reader.readLine()) != null) {
response.append(line + "\n");
log.info(line);
}
while ((line = error.readLine()) != null) {
response.append(line + "\n");
log.error(line);
}
} catch (IOException e1) {
} catch (InterruptedException e2) {
}
return response.toString();
}
}
Here, you can see we are passing the system commands dynamically through a variable and we are using the exec() method of the Runtime class to run the command as a separate process. Invoking the exec method will return a Process object for managing the subprocess.
Now, we design our Mule flow as follows:
<http:listener-config name="HTTP_Listener_Configuration" host="0.0.0.0" port="8087" doc:name="HTTP Listener Configuration"/>
<flow name="systemappFlow">
<http:listener config-ref="HTTP_Listener_Configuration" path="/execute" doc:name="HTTP"/>
<object-to-string-transformer doc:name="Object to String"/>
<component class="com.service.SysCommand" doc:name="Java"/>
<logger message="Executed !" level="INFO" doc:name="Logger"/>
</flow>
So, everything is set! We will be testing our application with few system commands.
Testing the Application
After we deploy our application on Mule server, we will hit the application from a REST client such as Postman with the URL http://localhost:8087/execute with a POST method:
Here, we can see if we pass the command dir as a payload body, we will get all the details of files and directory under present director which is the application directory.
Here's another example where we pass the ver command in our application and get the version of MS-DOS or Windows command prompt system:
Let’s take another example where we will be moving a file from one location to another. Let’s consider we have a file named abc.txt under the E:\temp folder as follows:
So, we will be moving this text file to another location (say, the E:\destination folder), so we will be using the following command in Postman for our Mule application as follows:
Now, if we go to the destination location, we will find the file has been moved into the destination folder:
We can open Notepad from our application:
If we want to execute any external script file such as a .bat file, we can do so easily:
By the same way, we can start our on-premises Mule runtime standalone server (or any other server) directly through our Mule application:
Testing Invalid Commands
Now, if we pass an invalid command to our application, our application is wise enough to detect it and display a response:
Conclusion
As you can see, it is very easy to operate System commands through a Mule application. We can execute different commands for different purposes starting from some kind of reporting or monitoring to get different system information to other purposes (such as executing different script files and bat files, as well as starting and maintaining different servers directly from this application itself).
Opinions expressed by DZone contributors are their own.
Comments