<flow name="poll> <poll frequency="1000"> <db:select config-ref="MySQL_Configuration"> <db:parameterized-query>SELECT * FROM PERSON></db:parameterized-query> <db:select> </poll> <flow-ref name="doProcess" /> </flow>
Migrating the Poll Component
Standard Support for Mule 4.1 ended on November 2, 2020, and this version of Mule will reach its End of Life on November 2, 2022, when Extended Support ends.
Deployments of new applications to CloudHub that use this version of Mule are no longer allowed. Only in-place updates to applications are permitted.
MuleSoft recommends that you upgrade to the latest version of Mule 4 that is in Standard Support so that your applications run with the latest fixes and security enhancements.
In Mule 3, the
<poll> element was used to trigger a certain flow at a fixed frequency of time. This element was also a scope which required one (and only one) message processor to live inside of it. The output of that processor would be the message that the flow receives.
In Mule 4, the
<poll> element was replaced with the
<scheduler> element. Main differences are:
It just triggers the flow. It’s no longer a scope
It supports both fixed frequency and cron expressions
<flow name="poll> <scheduler> <scheduling-strategy> <fixed-frequency frequency="1000"/> </scheduling-strategy> </scheduler> <db:select config-ref="MySQL_Configuration"> <db:sql>SELECT * FROM PERSON></db:sql> <db:select> <flow-ref name="doProcess" /> </flow>
For more information on the
<scheduler> element, please read the Scheduler documentation.
<poll> element also supported a
<watermark> element which was used to aid and scheduled synchronizations. That element doesn’t exist anymore. Instead, please read
the Migrating Watermarks page.
In Mule 3, a
quartz transport existed that was deprecated in favor of the
poll, so most of its uses may also be replaced by the
scheduler in Mule 4.
Some features of the
quartz transport do not exist in Mule 4, so a different approach is necessary to migrate those use cases.
repeatCount is not supported in Mule 4 by the
If you really need to fetch it, compare and store a counter in an Object Store.
This endpoint is not supported in Mule 4.
An alternative approach is to write the events to a queue (JMS or VM, for instance) and have another flow with a Scheduler that consumes all the messages from the queue and processes them.
The transport used in a
job-endpoint, when migrated to a Mule 4, can be migrated to a connector that has a polling source (such as File). In that case, you can put the Scheduler configuration directly into the polling source.
<flow name="poll> <quartz:inbound-endpoint name="quartzInboundEndpoint" cronExpression="0/3 * * * * ?" jobName="cronJob"> <quartz:endpoint-polling-job> <quartz:job-endpoint address="sftp://.../~/data" /> </quartz:endpoint-polling-job> </quartz:inbound-endpoint> <flow-ref name="doProcess" /> </flow>
<flow name="poll> <sftp:listener config-ref="inboundEndpointConfig" directory="data"> <scheduling-strategy> <cron expression="0/3 * * * * ?"/> </scheduling-strategy> </sftp:listener> <flow-ref name="doProcess" /> </flow>