Commanded v1.2.0 Commanded.ProcessManagers.ProcessManager behaviour View Source

Macro used to define a process manager.

A process manager is responsible for coordinating one or more aggregates. It handles events and dispatches commands in response. Process managers have state that can be used to track which aggregates are being orchestrated.

Process managers can be used to implement long-running transactions by following the saga pattern. This is a sequence of commands and their compensating commands which can be used to rollback on failure.

Use the Commanded.ProcessManagers.ProcessManager macro in your process manager module and implement the callback functions defined in the behaviour:

Please read the Process managers guide for more detail.

Example

defmodule ExampleProcessManager do
  use Commanded.ProcessManagers.ProcessManager,
    application: ExampleApp,
    name: "ExampleProcessManager"

  def interested?(%AnEvent{uuid: uuid}), do: {:start, uuid}

  def handle(%ExampleProcessManager{}, %ExampleEvent{}) do
    [
      %ExampleCommand{}
    ]
  end

  def error({:error, failure}, %ExampleEvent{}, _failure_context) do
    # Retry, skip, ignore, or stop process manager on error handling event
  end

  def error({:error, failure}, %ExampleCommand{}, _failure_context) do
    # Retry, skip, ignore, or stop process manager on error dispatching command
  end
end

Start the process manager (or configure as a worker inside a Supervisor)

{:ok, process_manager} = ExampleProcessManager.start_link()

init/1 callback

An init/1 function can be defined in your process manager which is used to provide runtime configuration. This callback function must return {:ok, config} with the updated config.

Example

The init/1 function is used to define the process manager's application and name based upon a value provided at runtime:

defmodule ExampleProcessManager do
  use Commanded.ProcessManagers.ProcessManager

  def init(config) do
    {tenant, config} = Keyword.pop!(config, :tenant)

    config =
      config
      |> Keyword.put(:application, Module.concat([ExampleApp, tenant]))
      |> Keyword.put(:name, Module.concat([__MODULE__, tenant]))

    {:ok, config}
  end
end

Usage:

{:ok, _pid} = ExampleProcessManager.start_link(tenant: :tenant1)

Error handling

You can define an error/3 callback function to handle any errors or exceptions during event handling or returned by commands dispatched from your process manager. The function is passed the error (e.g. {:error, :failure}), the failed event or command, and a failure context. See Commanded.ProcessManagers.FailureContext for details.

Use pattern matching on the error and/or failed event/command to explicitly handle certain errors, events, or commands. You can choose to retry, skip, ignore, or stop the process manager after a command dispatch error.

The default behaviour, if you don't provide an error/3 callback, is to stop the process manager using the exact error reason returned from the event handler function or command dispatch. You should supervise your process managers to ensure they are restarted on error.

Example

defmodule ExampleProcessManager do
  use Commanded.ProcessManagers.ProcessManager,
    application: ExampleApp,
    name: "ExampleProcessManager"

  # stop process manager after three failures
  def error({:error, _failure}, _failed_command, %{context: %{failures: failures}})
    when failures >= 2
  do
    {:stop, :too_many_failures}
  end

  # retry command, record failure count in context map
  def error({:error, _failure}, _failed_command, %{context: context}) do
    context = Map.update(context, :failures, 1, fn failures -> failures + 1 end)

    {:retry, context}
  end
end

Idle process timeouts

Each instance of a process manager will run indefinitely once started. To reduce memory usage you can configure an idle timeout, in milliseconds, after which the process will be shutdown.

The process will be restarted whenever another event is routed to it and its state will be rehydrated from the instance snapshot.

Example

defmodule ExampleProcessManager do
  use Commanded.ProcessManagers.ProcessManager,
    application: ExampleApp,
    name: "ExampleProcessManager"
    idle_timeout: :timer.minutes(10)
end

Event handling timeout

You can configure a timeout for event handling to ensure that events are processed in a timely manner without getting stuck.

An event_timeout option, defined in milliseconds, may be provided when using the Commanded.ProcessManagers.ProcessManager macro at compile time:

defmodule TransferMoneyProcessManager do
  use Commanded.ProcessManagers.ProcessManager,
    application: ExampleApp,
    name: "TransferMoneyProcessManager",
    router: BankRouter,
    event_timeout: :timer.minutes(10)
end

Or may be configured when starting a process manager:

{:ok, _pid} = TransferMoneyProcessManager.start_link(
  event_timeout: :timer.hours(1)
)

After the timeout has elapsed, indicating the process manager has not processed an event within the configured period, the process manager is stopped. The process manager will be restarted if supervised and will retry the event, this should help resolve transient problems.

Consistency

For each process manager you can define its consistency, as one of either :strong or :eventual.

This setting is used when dispatching commands and specifying the consistency option.

When you dispatch a command using :strong consistency, after successful command dispatch the process will block until all process managers configured to use :strong consistency have processed the domain events created by the command.

The default setting is :eventual consistency. Command dispatch will return immediately upon confirmation of event persistence, not waiting for any process managers.

Example

Define a process manager with :strong consistency:

defmodule ExampleProcessManager do
  use Commanded.ProcessManagers.ProcessManager,
    application: ExampleApp,
    name: "ExampleProcessManager",
    consistency: :strong
end

Dynamic application

A process manager's application can be provided as an option to start_link/1. This can be used to start the same process manager multiple times, each using a separate Commanded application and event store.

Example

Start an process manager for each tenant in a multi-tenanted app, guaranteeing that the data and processing remains isolated between tenants.

for tenant <- [:tenant1, :tenant2, :tenant3] do
  {:ok, _app} = MyApp.Application.start_link(name: tenant)
  {:ok, _handler} = ExampleProcessManager.start_link(application: tenant)
end

Typically you would start the event handlers using a supervisor:

children =
  for tenant <- [:tenant1, :tenant2, :tenant3] do
    {ExampleProcessManager, application: tenant}
  end

Supervisor.start_link(children, strategy: :one_for_one)

The above example requires three named Commanded applications to have already been started.

Link to this section Summary

Functions

Get the identity of the current process instance.

Callbacks

Mutate the process manager's state by applying the domain event.

Called when a command dispatch or event handling returns an error.

Process manager instance handles a domain event, returning any commands to dispatch.

Optional callback function called to configure the process manager before it starts.

Is the process manager interested in the given command?

Link to this section Types

Specs

command() :: struct()

Specs

consistency() :: :eventual | :strong

Specs

domain_event() :: struct()

Specs

process_manager() :: struct()

Specs

process_uuid() :: String.t() | [String.t()]

Link to this section Functions

Get the identity of the current process instance.

This must only be called within a process manager's handle/2 or apply/2 callback function.

Example

defmodule ExampleProcessManager do
  use Commanded.ProcessManagers.ProcessManager,
    application: MyApp.Application,
    name: __MODULE__

  def interested?(%ProcessStarted{uuids: uuids}), do: {:start, uuids}

  def handle(%IdentityProcessManager{}, %ProcessStarted{} = event) do
    # Identify which uuid is associated with the current instance from the
    # list of uuids in the event.
    uuid = Commanded.ProcessManagers.ProcessManager.identity()

    # ...
  end
end
Link to this function

parse_config!(module, config)

View Source

Link to this section Callbacks

Link to this callback

apply(process_manager, domain_event)

View Source

Specs

Mutate the process manager's state by applying the domain event.

The apply/2 function is used to mutate the process manager's state. It receives the current state and the domain event, and must return the modified state.

This callback function is optional, the default behaviour is to retain the process manager's current state.

Link to this callback

error(error, failure_source, failure_context)

View Source

Specs

error(
  error :: {:error, term()},
  failure_source :: command() | domain_event(),
  failure_context :: Commanded.ProcessManagers.FailureContext.t()
) ::
  {:continue, commands :: [command()], context :: map()}
  | {:retry, context :: map() | Commanded.ProcessManagers.FailureContext.t()}
  | {:retry, delay :: non_neg_integer(),
     context :: map() | Commanded.ProcessManagers.FailureContext.t()}
  | :skip
  | {:skip, :discard_pending}
  | {:skip, :continue_pending}
  | {:stop, reason :: term()}

Called when a command dispatch or event handling returns an error.

The error/3 function allows you to control how event handling and command dispatch and failures are handled. The function is passed the error (e.g. {:error, :failure}), the failed event (during failed event handling) or failed command (during failed dispatch), and a failure context struct (see Commanded.ProcessManagers.FailureContext for details).

The failure context contains a context map you can use to pass transient state between failures. For example it can be used to count the number of failures.

You can return one of the following responses depending upon the error severity:

  • {:retry, context} - retry the failed command, provide a context map or Commanded.ProcessManagers.FailureContext struct, containing any state passed to subsequent failures. This could be used to count the number of retries, failing after too many attempts.

  • {:retry, delay, context} - retry the failed command, after sleeping for the requested delay (in milliseconds). Context is a map or Commanded.ProcessManagers.FailureContext as described in {:retry, context} above.

  • {:stop, reason} - stop the process manager with the given reason.

For event handling failures, when failure source is an event, you can also return:

  • :skip - to skip the problematic event. No commands will be dispatched.

For command dispatch failures, when failure source is a command, you can also return:

  • :skip - skip the failed command and continue dispatching any pending commands.

  • {:skip, :continue_pending} - skip the failed command, but continue dispatching any pending commands.

  • {:skip, :discard_pending} - discard the failed command and any pending commands.

  • {:continue, commands, context} - continue dispatching the given commands. This allows you to retry the failed command, modify it and retry, drop it or drop all pending commands by passing an empty list []. Context is a map as described in {:retry, context} above.

Link to this callback

handle(process_manager, domain_event)

View Source

Specs

handle(process_manager(), domain_event()) ::
  command() | [command()] | {:error, term()}

Process manager instance handles a domain event, returning any commands to dispatch.

A handle/2 function can be defined for each :start and :continue tagged event previously specified. It receives the process manager's state and the event to be handled. It must return the commands to be dispatched. This may be none, a single command, or many commands.

The handle/2 function can be omitted if you do not need to dispatch a command and are only mutating the process manager's state.

Specs

init(config :: Keyword.t()) :: {:ok, Keyword.t()}

Optional callback function called to configure the process manager before it starts.

It is passed the merged compile-time and runtime config, and must return the updated config.

Link to this callback

interested?(domain_event)

View Source

Specs

interested?(domain_event()) ::
  {:start, process_uuid()}
  | {:start!, process_uuid()}
  | {:continue, process_uuid()}
  | {:continue!, process_uuid()}
  | {:stop, process_uuid()}
  | false

Is the process manager interested in the given command?

The interested?/1 function is used to indicate which events the process manager receives. The response is used to route the event to an existing instance or start a new process instance:

  • {:start, process_uuid} - create a new instance of the process manager.
  • {:start!, process_uuid} - create a new instance of the process manager (strict).
  • {:continue, process_uuid} - continue execution of an existing process manager.
  • {:continue!, process_uuid} - continue execution of an existing process manager (strict).
  • {:stop, process_uuid} - stop an existing process manager, shutdown its process, and delete its persisted state.
  • false - ignore the event.

You can return a list of process identifiers when a single domain event is to be handled by multiple process instances.

Strict process routing

Using strict routing, with :start! or :continue, enforces the following validation checks:

  • {:start!, process_uuid} - validate process does not already exist.
  • {:continue!, process_uuid} - validate process already exists.

If the check fails an error will be passed to the error/3 callback function:

  • {:error, {:start!, :process_already_started}}
  • {:error, {:continue!, :process_not_started}}

The error/3 function can choose to :stop the process or :skip the problematic event.