An Orchestrator executes a set of, possibly dependent, Tasks.
The simplest implementation of a State with DistinctIds.
The simplest implementation of a State with DistinctIds. The is the default state used by a DistinctIdsOrchestrator.
It is not a case class so the user can extend it and implement more complex states.
This class holds all the settings that parameterize akkastrator.
This class holds all the settings that parameterize akkastrator.
By default these settings are read from the Config obtained with ConfigFactory.load().
You can change the settings in multiple ways:
new Settings(yourConfig)However it will be more succinct to pass your config directly to your akkastrator:
context.actorOf(Props(classOf[YourAkkastrator], yourConfig))
object YourSettings extends Settings() { override val saveSnapshotEveryXMessages = 1000 } context.actorOf(Props(classOf[YourAkkastrator], YourSettings))
A task corresponds to sending a message to an actor, handling its response and possibly mutate the internal state of the Orchestrator.
A task corresponds to sending a message to an actor, handling its response and possibly mutate the internal state of the Orchestrator.
The answer(s) to the sent message must be handled in behavior. behavior must invoke finish when
no further processing is necessary or terminateEarly if the received message will prevent subsequent
tasks from executing properly.
The pattern matching inside behavior must invoke matchId to ensure the received message
is in fact the one that this task its waiting to receive.
The internal state of the orchestrator might be mutated inside behavior.
This class is very tightly coupled with Orchestrator and the reverse is also true. Because of this you can only create instances of Task inside an orchestrator.
TaskBundle: Variable number of tasks Fixed destination Different messages
An Orchestrator executes a set of, possibly dependent,
Tasks. A task corresponds to sending a message to an actor, handling its response and possibly mutate the internal state of the Orchestrator.The Orchestrator together with the Task is able to:
NOTE: the responses that are received must be Serializable.
In order for the Orchestrator and the Tasks to be able to achieve all of this they have to access and modify each others state directly. This means they are very tightly coupled with each other. To make this relation more obvious and to enforce it, you will only be able to create tasks inside an orchestrator.
If you have the need to refactor the creation of tasks so that you can use them in multiple orchestrators you can leverage self type annotations like so: