In addition to running on-demand logic, we may want to have certain logics run periodically or at specific times. For this we have scheduled tasks.
Through the Enterprise Integrator, from now on EI, we will be able to create programmed tasks that execute our logic differentiating in how and when it will be executed. Next we will see more in detail these two aspects that will help us to define them:
How to execute tasks through Enterprise Integrator
To execute the scheduled task we can create our own Java class that implements the task we want to perform. This Java class that org.apache.synapse.task.Task must implement, must be included in a library compatible with those already existing in the EI and must also be inside the {EI_HOME}/dropins directory before we start the server.
On the other hand, Synapse gives us the ability to create tasks through the WSO2 console. This will be a predefined task, with which we can invoke a sequence or a proxy among other attributes.
But at the same time, this predefined task is a Java class named org. apache.synapse.startup.tasks.MessageInjector and which also implements the Task class. Creating the task through the administration console, we will avoid having to restart the server and have greater control in the event that Java programming is not our strong suit.
When we execute tasks in Enterprise Integrator
When executing it, we can indicate that the times for its execution through a Cron expression. With which we will have a greater control of when we are going to execute it and for how long we want to execute it.
Or we can indicate in a more simplified way, how many exact times we want to execute it and with what interval of time between the executions.
Example of task executed through Enterprise Integrator
Throughout an example we will see how to do a scheduled task with each of the options. On the one hand we will see a task with Java implementation and Cron expression. And on the other hand a scheduled task managed by Synapse and with simple execution.
In the task we will indicate the data of a message processor already configured and we will check if it is working or not. In a more real scenario we could send emails in case the message processor was not active, but to keep it simpler, we’ll just activate it again. To perform all of these operations, we will use the WSO2 administration services. The login service to allow us to invoke the rest of the services, and the ‘isActive’ and ‘activate’ methods of the message processors administration service.
In order to avoid that the examples are too extensive and in search of legibility, they will have commented parts such as the creation of the messages of the administration services or utility code that allows us to make calls to the services.
-Maybe you are interested: Strategies for Enterprise Application Integration
Implementation through Synapse
Before we start the example, we need to know by what means we want to create our scheduled task. Through a proxy service or through a sequence. We will choose the sequence, since it will allow us to simplify it even more.
In our sequence, we will obtain the input values through property mediators, we will create the messages for the calls with the payload factory mediators and we will make the calls through the call mediators encapsulated in templates. And we won’t need to indicate a respond or loopback mediator.
<sequence name="messageProcessorChecker" xmlns="http://ws.apache.org/ns/synapse"> <property expression="$body/mc:mpChecker/mc:userName" name="userName" xmlns:mc="http://ws.apache.org/ns/sample" /> <property expression="$body/mc:mpChecker/mc:userPass" name="userPass" xmlns:mc="http://ws.apache.org/ns/sample" /> <property expression="$body/mc:processorName" name="processorName" xmlns:mc="http://ws.apache.org/ns/sample" /> <payloadFactory media-type="xml"> <format> <soap:Envelope xmlns:aut="http://authentication.services.core.carbon.wso2.org" xmlns:soap="http://www.w3.org/2003/05/soap-envelope"> <soap:Header/> <soap:Body> <aut:login> <aut:username> $1</aut:username> <aut:password> $2</aut:password> <aut:remoteAddress> localhost </aut:remoteAddress> </aut:login> </soap:Body> </soap:Envelope> </format> <args> <arg evaluator="xml" expression="$ctx:userName" literal="false" /> <arg evaluator="xml" expression="$ctx:userPass" literal="false" /> </args> </payloadFactory> <call-template target="callAdminServices_temp"> <with-param name="urlService" value="https://localhost:9443/services/AuthenticationAdmin"/> <with-param name="userName" value="$ctx:userName"/> <with-param name="userPass" value="$ctx:userPass"/> <with-param name="action" value="urn:login"/> </call-template> <!-- create payload for MessageProcessorAdminService with method isActivate --> <call-template target="callAdminServices_temp"> <with-param name="urlService" value="https://localhost:9443/services/MessageProcessorAdminService"/> <with-param name="userName" value="admin"/> <with-param name="userPass" value="admin"/> <with-param name="action" value="urn:isActive"/> </call-template> <filter xpath="//ns:return = 'false'"> <then> <!-- create payload for MessageProcessorAdminService with method activate --> <!-- call MessageProcessorAdminService with method activate --> </then> <else /> </filter> </sequence>
Once we have correctly created the associated sequence and template, we will move on to the creation of the scheduled task. The tasks programmed by Synapse are actually predefined Java tasks to which we pass certain input values. This predefined class is org.apache.synapse.startup.tasks.MessageInjector and which also implements the class org.apache.synapse.task.Task. As it is a predefined task, it has specific input parameters that need to be filled in. These are the ones:
- Message: Required field to indicate an incoming message. If we want input parameters we can pass them through this message. And if we don’t want any we can just put a dummy message, but there is always include it.
- injectTo: Mandatory field where we must indicate if we are going to inject the message in a sequence, in a proxy, or in the main sequence by default ‘main’.
- proxyName: Optional field where the name of the associated proxy is indicated, depending on whether ‘proxy’ has been selected in the injectTo field.
- secuenceName: Optional field where the name of the associated sequence is indicated, depending on whether ‘sequence’ has been selected in the injectTo field.
- To: Optional field where we can indicate an endpoint address.
- format: Optional field where the endpoint address format is indicated.
- soapAction: Optional field where soap action is indicated for the address endpoint.
In the following section we will indicate what type of programming we want. For this example we will use the simple programming and for them we will have to fill in the following fields:
- Count: Total number of times we want the sequence to be executed.
- Interval: Interval in seconds between task executions.
In this way, as you can see, the configuration is simpler but at the same time more limited.
Implementation through Java
To perform a purely Java programmed task, we must create a class that inherits from org.apache.synapse.task.Task, that implements the execute method and performs within it, the desired logic.
If we want the scheduled task to have input parameters, we must create class attributes with their corresponding getters and setters.
public class MessageProcessorCheckerTask implements Task {
private final static String LOGIN_CALL = "<soap:Envelope xmlns:soap=\"http://www.w3.org/2003/05/soap-envelope\" xmlns:aut=\"http://authentication.services.core.carbon.wso2.org\">"
+ "<soap:Header/> <soap:Body> <aut:login>"
+ "<aut:username>%s</aut:username> <aut:password>%s</aut:password>"
+ "<aut:remoteAddress>localhost</aut:remoteAddress> </aut:login> </soap:Body> </soap:Envelope>";
private final static String MP_ISACTIVE__CALL = "...";
private final static String MP_ACTIVATE_CALL = "...";
//input parameters
private String urlService;
private String userName;
private String userPass;
private String messageProcessorName;@Override
public void execute() {
// Login
HttpUtil.getINSTANCE().postSecureSoap12(urlService + "/services/AuthenticationAdmin",
String.format(LOGIN_CALL, userName, userPass), userName, userPass, "urn:login");
// Obtain if MP is active or not
String response = HttpUtil.getINSTANCE().postSecureSoap12(urlService + "/services/MessageProcessorAdminService", String.format(MP_ISACTIVE__CALL, messageProcessorName), userName, userPass, "urn:isActive");
// Get Response
if (!Boolean.valueOf(ResponseUtil.getINSTANCE().getNsReturnValue(response))) {
// Activate is it's not
HttpUtil.getINSTANCE().postSecureSoap12(urlService + "/services/MessageProcessorAdminService", String.format(MP_ACTIVATE_CALL, messageProcessorName), userName, userPass, "urn:activate");
}
}
//Getters and Setters
}
Once the class is created, we must pack it as a jar file, include it in the EI_HOME/dropins folder and restart the server.
The next step will be the creation of the scheduled task as such. To do this, we must indicate the following values:
- Task Name: Name of our task
- Task Group: Group associated with the task, by default synapse.simple.quartz.
- Task Implementation: The full name of our class.
After indicating the full name of our class, clicking on the ‘Reload Task Properties’ button, a lower property will be created for each of the class parameters that have created their set method.
In the following section we must indicate what type of programming we want for the task, the basic or the Chron. Therefore, for this first case, we must indicate a valid Cron expression in the associated field. This type of expression will give us practically unlimited power and programming capacity.
Finally, in case our EI is clustered, we could indicate the list of nodes in which we want to execute the scheduled task.
Through these examples we have been able to see how to easily perform scheduled tasks with Enterprise Integrator. As always, logic can be more complex depending on our needs. But what we must have clear is that WSO2 offers multiple tools and utilities for the mediation of messages.
