Managing Mule Schedules with Anypoint Runtime Manager

Mule ESB applications allow you to integrate different systems. Frequently, we need to schedule processing at 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.

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"/>
        <logger message="#['Payload in Poll scoped Flow: '+ payload]" level="INFO" doc:name="Logger"/>

The cron expression is defined in

Listing 1.B Cron Expression
poll.cron.expression=0 0/5 * 1/1 * ? *
To quickly generate the cron expressions, I refer to Cronmaker site.

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 application is running, we may want to do any of the following -

  1. Change the CRON expression

  2. Disable a polling flow

  3. 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 initialState attribute and then REDEPLOYMENT the application. The other way can be, is to have a custom script that allows stopping of 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 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, 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 on-premise server registered on ARM. Below screenshot shows mule application deployed on Cloudhub as well as 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.

  1. Change the polling frequency or CRON expression (Highlight 5)

  2. Enable or Disable Polling (Highlight 3)

  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 -

ARM Schedules
Figure 1.B Application Schedules Tab

Modify Scheduling frequency

For Mule Runtime 3.9 and higher, CRON expression (or standard frequency) can be modified from 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 -

Modify CRON Expression
  • When running with multiple Cloudhub workers, the job will run only on one worker.

  • Any changes to the schedule expression/time are read on next job execution. If you need your changes to take effect immediately then you will have to run the job using 'Run now' feature on Cloudhub. For Hybrid applications, change will be picked up on next execution.

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 user already has necessary roles and permissions to access Runtime Manager and Application (at least Read), you can follow below steps to add Manage Schedules permission -

  • Login to Access Management section on Anypoint Platform and Select '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 (+) icon.

Alternatively, you can also assign 'Schedule Manager' Role to user or Under Roles section add target users to 'Schedule Manager' role.

Access Management

3.3 Audit Logs

Now, all users who have access to schedules and can run the jobs. But how to find out who changed the time or ran the job?

One more great feature Access Management section provides is 'Audit Logs'. Here you can find the audit of every activity performed by any user on Anypoint platform.

In below screenshot, you can see logs of some actions performed by user 'manik_mule1'. Action column will tell you what activity user performed such as Run or Modify.

ARM Audit Logs

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 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 what was a previous value like what was the cronExpression before it was changed. This could be crucial to revert the change if needed.
         "name":"mule-scheduling-poll-scope-Flow Poll",
            "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

on twitter to get updates on new posts.

Stay updated!

On this blog, I post articles about different technologies like Java, MuleSoft, and much more.

You can get updates for new Posts in your email by subscribing to JavaStreets feed here -

Lives on Java Planet, Walks on Java Streets, Read/Writes in Java, JCP member, Jakarta EE enthusiast, MuleSoft Integration Architect, MuleSoft Community Ambassador, Open Source Contributor and Supporter, also writes at Unit Testers, A Family man!