Time after time (broke timers don't work)

I was going to start this post with comparisons on versions of "time after time" - by Cyndi Lauper. Her original was great.

I know Pink has done a version.?

I think my favorite is Matchbox 20.

Then I realized that maybe not everyone has even heard of Cyndi Lauper.

And that song that I was going to reference was written in 1984. So before some of my readers were born.? So they might not have the same attachment and affection for the song as I do.

So may not work as a great intro to IIB timer nodes.

It might be more appropriately titled - "Broke timers don't work".

So not a node that teams always use, but it does come up from time to time.

They are, as the name would suggest, generally triggering asynchronous processes (usually) outside the flow that is being developed.

Which makes them challenging to test and develop test cases for. specially if the flow triggers an event "10 minutes from now". That would be challenging to write a integration test for.

To make sure that teams are making use of the nodes in a logical way, and to help with the testing challenge, we added some new rules to support them.

So an example of this would be the process when someone opens a new back account.

In our "open back account" flow, we have a "TimeoutControl" that is triggered to notify the marketing department to send out a mug, using an event (unique identifier) of "SendMug".

Our "send a mug" flow, which is triggered by the "SendMug" event (unique identifier), then starts and sends out a mug to our new customer.

For this to work, both flows need to communicate using the "SendMug" unique identifier.

The two nodes we are looking at is the "TimeoutNotification" node, which is what process should run when the event is triggered.

To help make sure this works as expected, for the "TimeoutNotification" node we added this rule:

R465 - TimoutNotification node Unique Identifier never defined in TimeoutControl (WMB)

So this indicates that we when scanned through the source code, we couldn't find anything that will trigger this node. So the logic or process that you want this node to execute will never run.

The other node that is required is the "TimeoutControl" node. This is the process that generates the event to run the login defined above.

For this, we have a new rule?

R466 - TimoutControl node Unique Identifier not used by TimoutNotification (WMB)

So this indicates that the event that we are going to generate does not trigger any process.

The final rule that we added is:

R467 - Multiple TimeoutNotifications for the same Identifier (WMB)

This one may be a little less obvious.

If we have a timer event generated and we want to things to happen, we can have two notifications ?

It might be a little confusing but no harm right ?

It would be confusing to have processing events split across flows. But it would also not work as expected.

The main reason for this is that the timeout node events are based on the use of an internal queue - "SYSTEM.BROKER.TIMEOUT.QUEUE".?When an event is generated, this queue would only have a single event on it, so once consumed, the second notification?would not be triggered.

So the logic of having two TimeoutNotifications is broken.

I hope that you enjoyed this post and maybe even reminisced a bit.

More information on our products and on pricing can be found on our website:

https://bettercodingtools.com

You can also reach me via email at:

[email protected]

Or contact me via the contact page on our website:

www.bettercodingtools.com/contact

Regards

Richard