##
Aegis Automation Workflows in 5 Minutes - The Tower of Hanoi

The "Aegis Automation Workflows in 5 Minutes" cool-tool blog series shows examples of Aegis workflows which deliver value in as little as 5 minutes development time - all using out of the box activities! Aegis workflows can be forever evolving, and while these workflows fulfill a purpose, you may for example want to extend a workflow from being a simple notification workflow to one which goes further to remediate a problem.

The Tower of Hanoi - isn't that a logic game? At the heart of Aegis is logic, as workflows get larger, logic plays a greater role in ensuring that the workflow behaves correctly. A logic flaw can results in endless loops, endless waits, incorrect objects being accessed, conditions which can never be satisfied etc. So Hanoi may be a game, but it can also be considered a training tool for developing Aegis workflows - if you've done any software programming, chances are you have come across the Tower of Hanoi as a learning exercise.

This 5 minute workflow shows that you can do almost anything with Aegis, including solving maths puzzles to impress your friends and colleagues!

The Tower of Hanoi can be solved using recursion. This is a very simple workflow - understanding the maths will probably take more the 5 minutes, but once you do understand the concept then the workflow is really simple. For info on the puzzle itself and the maths behind it take a look here.

So the first thing to note is we need 2 workflows. The first workflow can be a pre-existing workflow for example and basically requests the second workflow to solve Hanoi, the second workflow is a modular workflow which runs the Hanoi function.

This is the pseudo code for the Hanoi Function ... Note there are variations on this!

where...

Disk = The Disk number, 1 is the smallest, n is the largest and is the number of disks.

Source = The Tower the Disk is on, 1 = Tower1, 2 = Tower2, 3 = Tower3

Target = The Tower the Disk moves to, 1 = Tower1, 2 = Tower2, 3 = Tower3

Temp = The Tower which is temporary storage, 1 = Tower1, 2 = Tower2, 3 = Tower3

So all we need to do is implement that function in Aegis, and output a nice set of instructions to solve the puzzle like this (example using 3 disks) :

Move disk 1, from Tower 1 to Tower 3

Move disk 2, from Tower 1 to Tower 2

Move disk 1, from Tower 3 to Tower 2

Move disk 3, from Tower 1 to Tower 3

Move disk 1, from Tower 2 to Tower 1

Move disk 2, from Tower 2 to Tower 3

Move disk 1, from Tower 1 to Tower 3

This is what the workflow looks like...

You can see that the workflow implements the pseudo code .... If Disk = 1, then follow the top branch, If Disk > 1, follow the lower branch.

In the upper branch, all that is done is that a new move is appended to the list of moves, and then those results are returned to the calling workflow.

In the lower branch, we first calculate (Disk - 1) and then the process starts a new instance of itself. The branch can only continue when a result is returned from that child workflow. Next it appends the next move onto the list and then starts another instance of itself. The results are then returned to the parent process.

In my parent process I have an input form to display the results ..

Cool - So that is 7 moves for 3 disks. How many moves for 10 disks? You can calculate this in advance by calculating

And you are done … hopefully in 5 minutes! Ok, so this one because of the logic involved probably took a bit longer...

The basic implementation of the workflow is attached. Also attached is the 'Hanoi Caller' which request to solve the Tower of Hanoi Puzzle. If you use this place the 'Tower of Hanoi' directly in the Processes folder as this is where it is expected to be found.

This is what the list of workitems looks like :

You can see the caller, and the 7 workitems. Its best practice to update the workitem Subject as it provides some visual representation of what is happening. See what happens when I update the workitem Subject attribute to include the call stack ...

This makes everything a whole lot clearer .. at least in my opinion. We start off trying to solve Hanoi (4,1,3,2) (4 = Disk, 1 = Source Tower, 3 = Destination Tower, 2 = Temp Tower). The Subject field also contains a list of workitems in the order in which they were called. So workitem 250974402, which attempts to solve Hanoi : (1,1,2,3) was called by 250974400, which was called by 250974396, which was called by 250974395 ... which was the first Hanoi call!

Now for the warnings! I set the 'Hanoi Caller' to limit the number of disks to 10, as noted above this will take 1023 moves/workitems. If you increase this value you will eventually run into performance problems and if you go large enough you may crash the system by filling up your message queues or running out of memory. So don't run this in production environment. If you are trying to build your own, again don't test in production - if you hit an endless loop you will end up in trouble!

The Tower of Hanoi - isn't that a logic game? At the heart of Aegis is logic, as workflows get larger, logic plays a greater role in ensuring that the workflow behaves correctly. A logic flaw can results in endless loops, endless waits, incorrect objects being accessed, conditions which can never be satisfied etc. So Hanoi may be a game, but it can also be considered a training tool for developing Aegis workflows - if you've done any software programming, chances are you have come across the Tower of Hanoi as a learning exercise.

This 5 minute workflow shows that you can do almost anything with Aegis, including solving maths puzzles to impress your friends and colleagues!

The Tower of Hanoi can be solved using recursion. This is a very simple workflow - understanding the maths will probably take more the 5 minutes, but once you do understand the concept then the workflow is really simple. For info on the puzzle itself and the maths behind it take a look here.

So the first thing to note is we need 2 workflows. The first workflow can be a pre-existing workflow for example and basically requests the second workflow to solve Hanoi, the second workflow is a modular workflow which runs the Hanoi function.

This is the pseudo code for the Hanoi Function ... Note there are variations on this!

Hanoi(Disk, Source, Target, Temp)

(

IF Disk is the smallest Disk (=1) then

Move Disk from Tower Source to Tower Target

ELSE

Hanoi(Disk - 1, Source, Temp, Target) // Call the function to solve larger disk, note tower order changed

Move Disk from Tower Source to Tower Target

Hanoi(Disk - 1, Temp, Target, Source) // Call the function to solve larger disk, note tower order changed

END IF

)

where...

Disk = The Disk number, 1 is the smallest, n is the largest and is the number of disks.

Source = The Tower the Disk is on, 1 = Tower1, 2 = Tower2, 3 = Tower3

Target = The Tower the Disk moves to, 1 = Tower1, 2 = Tower2, 3 = Tower3

Temp = The Tower which is temporary storage, 1 = Tower1, 2 = Tower2, 3 = Tower3

So all we need to do is implement that function in Aegis, and output a nice set of instructions to solve the puzzle like this (example using 3 disks) :

Move disk 1, from Tower 1 to Tower 3

Move disk 2, from Tower 1 to Tower 2

Move disk 1, from Tower 3 to Tower 2

Move disk 3, from Tower 1 to Tower 3

Move disk 1, from Tower 2 to Tower 1

Move disk 2, from Tower 2 to Tower 3

Move disk 1, from Tower 1 to Tower 3

This is what the workflow looks like...

You can see that the workflow implements the pseudo code .... If Disk = 1, then follow the top branch, If Disk > 1, follow the lower branch.

In the upper branch, all that is done is that a new move is appended to the list of moves, and then those results are returned to the calling workflow.

In the lower branch, we first calculate (Disk - 1) and then the process starts a new instance of itself. The branch can only continue when a result is returned from that child workflow. Next it appends the next move onto the list and then starts another instance of itself. The results are then returned to the parent process.

In my parent process I have an input form to display the results ..

Cool - So that is 7 moves for 3 disks. How many moves for 10 disks? You can calculate this in advance by calculating

*((2^n) - 1)*where*n*is the number of disks. So 10 disks = 1023 moves! This is significant because if you were trying to debug a problem in the workflow, with a large number of disks you could have as many child workflows as there are moves:And you are done … hopefully in 5 minutes! Ok, so this one because of the logic involved probably took a bit longer...

The basic implementation of the workflow is attached. Also attached is the 'Hanoi Caller' which request to solve the Tower of Hanoi Puzzle. If you use this place the 'Tower of Hanoi' directly in the Processes folder as this is where it is expected to be found.

This is what the list of workitems looks like :

You can see the caller, and the 7 workitems. Its best practice to update the workitem Subject as it provides some visual representation of what is happening. See what happens when I update the workitem Subject attribute to include the call stack ...

This makes everything a whole lot clearer .. at least in my opinion. We start off trying to solve Hanoi (4,1,3,2) (4 = Disk, 1 = Source Tower, 3 = Destination Tower, 2 = Temp Tower). The Subject field also contains a list of workitems in the order in which they were called. So workitem 250974402, which attempts to solve Hanoi : (1,1,2,3) was called by 250974400, which was called by 250974396, which was called by 250974395 ... which was the first Hanoi call!

Now for the warnings! I set the 'Hanoi Caller' to limit the number of disks to 10, as noted above this will take 1023 moves/workitems. If you increase this value you will eventually run into performance problems and if you go large enough you may crash the system by filling up your message queues or running out of memory. So don't run this in production environment. If you are trying to build your own, again don't test in production - if you hit an endless loop you will end up in trouble!