"Event driven workflow engine" in Akka - any experiences?

[Bertil Muth]

Hi everybody.

I am quite new to Akka and already fascinated.
Now I am thinking of creating an extension to my own project to enable it to be distributed.

The idea is to have a kind of "Workflow Engine" that is event driven.
So basically: receive an event from a user, and if a condition is fulfilled, execute an action (depending on state).
The action could be realized by a service or more general: a component.
The components could be distributed in an Akka cluster.
The way the engine reacts to an event over time changes.

I already have the event-driven Workflow Engine in my project, but it runs locally on one machine, in one thread.

I thought about using an Akka Finite State Machine or even a PersistentFSM. Would that be a good choice?
Has anybody try to build something similar? Have you used one FSM Actor per user?

If you have built something similar, I would be interested in your approach.

Regards,

Bertil

[Frédéric Gendebien]

I am currently re-designing a Rule-Based Event driven Orchestrator using Akka/Scala following the paper from RamCloud (Rule-Based DCFT). This looks very similar to what you describe.

I don't use FSM but PersistentActor even if I have doubt for a while, I am pretty convince that we don't need it.

[Paweł Kaczor]

See an example of distributed workflow (saga) implementation using akka-ddd (https://github.com/pawelkaczor/akka-ddd) framework:

https://github.com/pawelkaczor/ddd-leaven-akka-v2/blob/master/headquarters/write-back/src/main/scala/ecommerce/headquarters/processes/OrderProcessManager.scala

 

Best Regards,

Pawel Kaczor

[Bertil Muth]

Thank you very much for your response.

I have a question, as I am just learning the framework and I am more familar with Java than Scala.

The "trick" to dealing with Akka Persistence seems to be
that the Actor itself encapsulates state, and the transition is done by replacing the old state with a new state
in the function that is a parameter to the persist method. That way, you can replay it later when restarting the actor.
Is this a good enough summary (sorry if I am using the terms not precisely)?

That would mean that developing such an application could be quite different from developing a local application,
where state is spread over many objects. (Or rather, the only way to change state in another object would be that
the other object is an Actor as well and it receives an event that is raised. But what if it does not receive the event
during replay? Wouldn't that corrupt the overall state of the application?)

Is that description correct?

Thanks.

[Rob Crawford]

That would mean that developing such an application could be quite different from developing a local application,
where state is spread over many objects. (Or rather, the only way to change state in another object would be that
the other object is an Actor as well and it receives an event that is raised. But what if it does not receive the event
during replay? Wouldn't that corrupt the overall state of the application?)

I'm not sure what better minds think of this, but I've avoided raising events for other actors or systems to consume during

restart. The classic is the "paid" event for an order -- it's essential for the order to realize the amount due's been paid as it's

recovering, but if it emits the "paid" event again, will something else count the order as having been paid twice?

I've taken the approach that if an actor needs to recover state after a restart, it's responsible for that. So I have a case where

a CQRS pattern has both the "command" actors and the "query" actor doing even persistence. The "query" actor replays

all the events it's seen from the "command" actors, so there's no double-counting. 

[Justin du coeur]

On Fri, Oct 20, 2017 at 8:22 AM, Bertil Muth <Berti...@hood-group.com> wrote:

That would mean that developing such an application could be quite different from developing a local application,
where state is spread over many objects. (Or rather, the only way to change state in another object would be that
the other object is an Actor as well and it receives an event that is raised. But what if it does not receive the event
during replay? Wouldn't that corrupt the overall state of the application?)

In such a situation, that other Actor would typically *also* be Persistent.  That's kind of the point of Actor-centric design: each Actor is responsible for its own bit of state.  I find that it's not at all unusual to have a lot of different Persistent Actors... 

[Bertil Muth]

I see. That makes sense. Would that mean that actors whose state depends on each other need to be children of the same parent, in order to resurrect all of them when one of them goes down? Or how is this potential inconsistency problem solved? Should their state be independent?

[Justin du coeur]

I'm not sure I see the problem.  Each one is persisting its *own* state -- its parent is pretty much irrelevant.  When one goes down, you bring it back up (theoretically to the same state again) when you need it.

Mind, I use Persistence more or less exclusively in conjunction with Sharding, so the down/up thing is pretty much transparent -- it is *normal* (indeed, deliberate) for these Actors to be taken down when they go idle, and they simply spring back to life again when they are next accessed.  Since each one returns to its most recent state, there isn't much of a consistency issue.  (Save when messages have gone astray, and that is something you *always* have to be prepared for in Akka -- you should always design around the assumption of unreliable delivery.)

On Sat, Oct 21, 2017 at 4:35 AM, Bertil Muth <Berti...@hood-group.com> wrote:

I see. That makes sense. Would that mean that actors whose state depends on each other need to be children of the same parent, in order to resurrect all of them when one of them goes down? Or how is this potential inconsistency problem solved? Should their state be independent?

--
>>>>>>>>>>      Read the docs: http://akka.io/docs/
>>>>>>>>>>      Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>      Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscribe@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[davids...@gmail.com]

Hi Frederic,

is it maybe possible to share your redesign Orchestrator using Akka/Scala?

Thanks

David