Mule ESB applications allow you to integrate different systems. Frequently, we need to schedule processing at a certain time or interval. Mule provides two components to add scheduled polling functionality to your flow - quartz:inbound-endpoint and poll scope. It’s easy to add a scheduler to the application but it might get tricky to maintain it after deployment. In this article, we will see the challenges in managing applications with schedules and how Anypoint Platform’s Runtime Manager helps us to make life easy.
As of Mule 3.9, Quartz connector is marked as deprecated and Poll scope is recommended over Quartz. Quartz connector will not be available in Mule 4.0. We will be using Poll Scope in this example.
Table of Contents
- 1. Sample Application
- 2. Maintenance Challenge
- 3. Anypoint Runtime Manager (ARM)
- 4. Conclusion
- 5. References and further reading
1. Sample Application
Let’s consider a simple Mule application that has below flow -
Listing 1.A Mule flow with Poll scope
<flow name="mule-scheduling-poll-scope-Flow">
<poll doc:name="Poll">
<schedulers:cron-scheduler expression="${poll.cron.expression}"/>
<set-payload value="#['Hello from Mule Poll']" doc:name="Set Payload"/>
</poll>
<logger message="#['Payload in Poll scoped Flow: '+ payload]" level="INFO" doc:name="Logger"/>
</flow>The cron expression is defined in mule-app.properties.
Listing 1.B Cron Expression
poll.cron.expression=0 0/5 * 1/1 * ? *To quickly generate the cron expressions, I refer to Cronmaker.
2. Maintenance Challenge
Once we build our Mule application, we are ready to deploy it on a standalone on-premise Mule Runtime or on Cloudhub.
While the application is running, we may want to do any of the following:
Change the CRON expression.
Disable a polling flow.
- Run the flow on-demand.
For Mule Runtime 3.8 and older, these scenarios can be handled as described below.
Change the CRON Expression: This will need a modification of the CRON expression in the properties file, followed by the RESTART of the Mule instance. This restart may affect other applications running in the same instance.
Disable a polling flow: This will need a modification to flow the initialState attribute and then the REDEPLOYMENT of the application. The other way to proceed is to have a custom script that allows one to stop the flows.
Running Flows on-demand: As the flows have quartz as an inbound endpoint, we will need to provide another way of accessing these flows. The easiest way to do this is to add a flow with an HTTP listener and then call the scheduled flow using flow-ref. To run the flow on demand, you can access the HTTP URL.
In this approach, the Quartz inbound endpoint or Poll scope should not set any payload. When calling the scheduled flow using flow-ref, inbound endpoints or poll scopes will not be executed.
3. Anypoint Runtime Manager (ARM)
From the docs:
Runtime Manager is the Anypoint Platform tool used to deploy and manage all of your Mule applications from one central location, whether your apps are running in the cloud or on-premises.
In this post, we will not go into detail about how to manage servers and deploy applications to Runtime Manager. There are different Deployment Strategies you can follow with Anypoint Runtime Manager.
Starting with Mule Runtime 3.9.0, Anypoint Platform provides capabilities to manage the Scheduled flows from Runtime Manager.
Let’s assume our application is either deployed to Cloudhub or an on-premise server registered on ARM. The below screenshot shows a Mule application deployed on Cloudhub as well as an on-premise runtime:
Figure 1.A: ARM Deployed Applications
3.1 Managing Schedules
Starting with Mule Runtime 3.9.0, Anypoint Platform provides capabilities to manage the Scheduled flows from Runtime Manager. When you deploy a Mule Application with polling flows, Runtime Manager automatically identifies all those flows and displays them on the Schedules tab for the application.
On this tab, you can select the polling elements and perform any of the below tasks during runtime, without making any changes in the underlying application.
- Change the polling frequency or CRON expression (Highlight 5).
- Enable or Disable Polling (Highlight 3).
- Run the polling immediately (Highlight 3).
Running the scheduled flow is only available for applications running in Cloudhub and not for on-premise applications.
If you click on the application name, it should show you a detail view, as shown in below screenshot:
Figure 1.B: Application Schedules Tab
Modify Scheduling Frequency
For Mule Runtime 3.9 and higher, CRON expressions (or standard frequencies) can be modified from the Scheduler tab itself.
If you click on the expression under schedule column (Highlight 5), it should open a nice popup for you to change the expression:
|
3.2 Access Management
As with any system, it is equally important to control who can manage application schedules. Anypoint Platform allows you to perform Access Management for all of your users.
To manage schedules, the user needs to have 'Manage Schedules' permission for a target environment.
Assuming that the user already has the necessary roles and permissions to access Runtime Manager and Application (at least Read), you can follow the below steps to add a Manage Schedules permission:
- Log in to the Access Management section on Anypoint Platform and select the 'Users' menu on the right.
- Once you choose the target user, Click on 'Runtime Manager.'
- Choose the target environment.
- Add 'Manage Schedules' roles and click on the (+) icon.
Alternatively, you can also assign the 'Schedule Manager' role to a user or, under the roles section, add target users to the 'Schedule Manager' role.
3.3 Audit Logs
Now, all users who have access to schedules can run the jobs. But how to find out who changed the time or ran the job?
One more great feature that the Access Management section provides is 'Audit Logs.' Here you can find the audit of every activity performed by any user on Anypoint Platform.
In the below screenshot, you can see logs of some actions performed by the user 'manik_mule1'. The action column will tell you what activity a user performed such as Run or Modify.
The second audit entry shows that something was modified. But what?
If you download the payload of that event (click on the download icon in the last column of that row), you will see the JSON payload for this event.
Even though it tells you the values of the different attributes after the modification was performed, it doesn’t say anything about previous values, like what was the cronExpression before it was changed? This could be crucial to revert the change if needed.
{
"properties":{
"jobId":"5a5ec04e9a03e917bc66a272_mule-scheduling-poll-scope-Flow_polling_mule-scheduling-poll-scope-Flow_1",
"scheduleInfo":{
"id":"5a5ec04e9a03e917bc66a272_mule-scheduling-poll-scope-Flow_polling_mule-scheduling-poll-scope-Flow_1",
"name":"mule-scheduling-poll-scope-Flow Poll",
"enabled":true,
"schedule":{
"timeUnit":"seconds",
"period":0,
"cronExpression":"0 0/10 * 1/1 * ? *"
}
}
}
}4. Conclusion
Anypoint Platform offers many features to run and manage Mule applications. In this article, we looked at how we can manage schedules using Runtime Manager. It makes it easy to maintain these schedules without affecting and modifying any of the running applications or restarting Mule instances. We also learned how to manage access and view audit logs for any activity around scheduling.
5. References and Further Reading
- Anypoint Platform’s Runtime Manager
- Anypoint Platform’s Access Management
- Anypoint Platform documentation Managing Schedules for Cloudhub
- Anypoint Platform documentation Managing Schedules for Hybrid
- Getting started with Anypoint Platform