FizzBuzz on Mule 4 with a While Loop using VM Queue
A friend shared this youtube video on the Art of Code where FizzBuzz was demonstrated on SonicPi and also at end of the video (I won’t spoil it for you). After watching it, I was highly inspired to also implement it on Mule, because why not? I even searched the web to see if anyone had already done a FizzBuzz loop on Mule. The fact that I then did it last night kinda tells you that the answer was no.
It turns out that I also learnt a thing or two implementing FizzBuzz on Mule 4. FizzBuzz is one of the ways loops are introduced when learning a programming language. Even the recent Golang course I took also introduces loops using FizzBuzz. For the uninitiated, FizzBuzz is derived from a children’s game, the problem statement for a FizzBuzz programme is pretty straightforward. This is the same one you can find at HackerRank.
Write a short program that prints each number from 1 to 100 on a new line. For each multiple of 3, print "Fizz" instead of the number. For each multiple of 5, print "Buzz" instead of the number. For numbers which are multiples of both 3 and 5, print "FizzBuzz" instead of the number.
As you can see, you need a for loop, and a nested if/else statement. Implementing a nested if/else statement is as simple as just nesting choice routers in Mule. Implementing a loop as a flow in Mule, however, can be slightly trickier. Of course, I could just use a script component to execute the FizzBuzz loop but that would be cheating. 🙂
Let’s explore loops on Mule in the next section.
Implementing Loops on Mule 4
Using the Flow Reference component
In my first attempt to implement FizzBuzz flow on Mule 4, I instinctively used the Flow Reference component to loop the flow back to the FizzBuzz subflow routine when the index count is still smaller than the target count. The screenshot of the flow below is quite self-explanatory and the flow does work as design.

When running the flow, Mule 4 will warn you of a potential infinite recursive loop and it will stop processing after it detects too many nested child contexts.

As you can see, after a depth of 45 nested child contexts, the flow stops running and will throw the exception you see in the screenshot above. Clearly we need another way to run legitimate while loops.
Loops on Mule Using VM Queues
This is what I love about MuleSoft’s support site. You can almost always find the answer. I know I’m biased since I’m a Muley. But facts simply are just are facts. Quick research brought me to this article that describes the exception of the nested context (link). Here, the author recommends using VM queues to trigger the loop.
In my second iteration, I revamped the flow so that the payload itself stores the state of the processing. This makes the flow itself stateless, unlike the earlier iteration where I used flow variables to store the state.

What I really like is the elegance is using VM queues to loop in Mule. In this flow, Mule doesn’t need to spawn any child context. Instead, it just processes any messages that are published to the queue. The loop is triggered by passing the payload back into the input queue as long as the exit condition is not true.

All the FizzBuzz evaluations are done with DataWeave.

Dataweave is also used to update the state of the payload.

The full code can also be found here on my GitLab repo.
Conclusion
This started off a bit of a funny thing that I wanted to do just fill the void of a FizzBuzz implementation using Mule 4. But I ended up also learning how to use VM queues as a way to implement a loop in Mule.
I really appreciate you writing this up. My use case was retrieving an open-ended number of paged results. (The API did not provide a method to query the number of results or pages in advance.) I knew the number of pages was > 50 and I didn’t think resizing the memory was a scalable solution.
I will add one additional thing I ran into — the VM queues are promoted to Amazon SQS queues when you go to production and SQS has an upper bound of 20 seconds on the Consumer timeout. I reconfigured by using a Listener for the final queue instead of a Consumer.
Cool! Thanks for sharing of your use of SQS.