Creating a Sequencer in AF?

[Nathan-P]

I have an actor framework project that I'm trying to clean up, and its current state feels like a spagettii code mess of messages being sent between all the actors, so it's hard to see the sequence of events that makes the system run. I'm wanting to clean it up, but I'm having a hard time figuring out how to cleanly document/describe/execute/modify a sequence of events/messages in an actor system.  

In my research I found this article, but it's pretty old, and wanted to know if there are some more up-to-date references or design patterns I should be looking at?

https://forums.ni.com/t5/Actor-Framework-Discussions/Sequencial-steps-in-an-actor-design/td-p/345484...

How are you implementing synchronous sequences among asynchronous actors?

Cheers,

Nathan

[BertMcMahan]

Do you need each sequence step to be an actor? Or could they just be regular old objects? Usually my sequencers don't need each individual sequence step to have its own message handling capability, with the exception being a potential "abort" step.

For a very simple example, you could have a "Sequence step" object with dynamic dispatch "Setup", "Run", and "Teardown" methods that you could override with specific tests.

[justACS]

I actually have a sequencer actor in a current project.  It's a little primitive - no branching, looping, or nested sequences yet, and I need to rework how I dispatch steps before I can have those things, but I know what I need to do.

The sequencer is the top level actor, though I don't think it needs to be per se.  It is a state pattern actor, using the State Actor class available on the Tools Network.  That gives me access to pre- and post-step operations, as well as step-specific data.  Steps also have an Action.

Simple steps breeze past pre-step, execute their Action methods (by sending messages to nested actors), and then transition to the next step.  Those actually work for most of your interactions with your nested actors.  For steps that need a response, send the message to the nested actor from the pre-step, and then wait.  The nested actor can send an announcement when it has done the thing that invokes Step:Action.

The latter type of step may have a fair amount of conceptual (if not actual) coupling with its corresponding nested actor, but you should be able to keep the nesteds decoupled.

I'm using it on a pretty small system, but it should scale, at least to the point where you're probably better off using TestStand.

[justACS]

At some point, I do plan to make my sequencer available as a community package, maybe after I get branching and looping done.

[Nathan-P]

Do you need each sequence step to be an actor?

---

No, the individual steps don't need to be actors themselves.  My system is setup where the actors are long-lived, where I launch them, and keep them running for the life of the application. If it helps, they are hardware actors, representing the hardware resources I need to sequence.

Thus I have top level "coordinator" actor, which contains the logic, and a bunch of nested actors, and I want to run through a sequence, which sends messages and awaits responses from those nested actors before moving to the next step. Or handle branching the sequence when a nested actor throws an error up through "Handle Error.vi" (for example).  

At the moment, this "coordinator" actor, just sends a message, and then when it gets the response, the message .do sends the next message, etc. and this results in a very long chain of messages being sent, and I have to hunt through each message sent and received to know where I'm at in the sequence. This is what I'm wanting to clean up.

---

For a very simple example, you could have a "Sequence step" object with dynamic dispatch "Setup", "Run", and "Teardown" methods that you could override with specific tests.

---

Yes, so this would involve making an OOP-based command pattern, where you execute each step. But how would you integrate this inside of an actor?