-
Notifications
You must be signed in to change notification settings - Fork 237
/
process_manager.ex
366 lines (275 loc) · 12.6 KB
/
process_manager.ex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
defmodule Commanded.ProcessManagers.ProcessManager do
@moduledoc """
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.
Use the `Commanded.ProcessManagers.ProcessManager` macro in your process
manager module and implement the callback functions defined in the behaviour:
- `c:interested?/1`
- `c:handle/2`
- `c:apply/2`
- `c:error/3`
### 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](supervision.html))
{:ok, process_manager} = ExampleProcessManager.start_link()
## Error handling
You can define an `c: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 `c: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
defmodule ExampleProcessManager do
use Commanded.ProcessManagers.ProcessManager,
application: ExampleApp,
name: "ExampleProcessManager",
consistency: :strong
end
Please read the [Process managers](process-managers.html) guide for more
detail.
"""
alias Commanded.ProcessManagers.FailureContext
@type domain_event :: struct
@type command :: struct
@type process_manager :: struct
@type process_uuid :: String.t() | [String.t()]
@type consistency :: :eventual | :strong
@doc """
Is the process manager interested in the given command?
The `c: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.
"""
@callback interested?(domain_event) ::
{:start, process_uuid}
| {:start!, process_uuid}
| {:continue, process_uuid}
| {:continue!, process_uuid}
| {:stop, process_uuid}
| false
@doc """
Process manager instance handles a domain event, returning any commands to
dispatch.
A `c: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 `c:handle/2` function can be omitted if you do not need to dispatch a
command and are only mutating the process manager's state.
"""
@callback handle(process_manager, domain_event) :: command | list(command) | {:error, term}
@doc """
Mutate the process manager's state by applying the domain event.
The `c: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.
"""
@callback apply(process_manager, domain_event) :: process_manager
@doc """
Called when a command dispatch or event handling returns an error.
The `c:error/3` function allows you to control how command dispatch and event
handling failures are handled. The function is passed the error (e.g.
`{:error, :failure}`), the failed command (during failed dispatch) or failed
event (during failed event handling), 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 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 as described in
`{:retry, context}` above.
- `{:skip, :discard_pending}` - discard the failed command and any pending
commands.
- `{:skip, :continue_pending}` - skip the failed command, but continue
dispatching 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.
- `{:stop, reason}` - stop the process manager with the given reason.
"""
@callback error(
error :: {:error, term()},
failure_source :: command | domain_event,
failure_context :: FailureContext.t()
) ::
{:retry, context :: map()}
| {:retry, delay :: non_neg_integer(), context :: map()}
| {:skip, :discard_pending}
| {:skip, :continue_pending}
| {:continue, commands :: list(command), context :: map()}
| {:stop, reason :: term()}
alias Commanded.Event.Handler
alias Commanded.ProcessManagers.ProcessManager
alias Commanded.ProcessManagers.ProcessRouter
@doc false
defmacro __using__(opts) do
quote location: :keep do
@before_compile unquote(__MODULE__)
@behaviour ProcessManager
{application, name} = ProcessManager.compile_config(__MODULE__, unquote(opts))
@opts unquote(opts)
@application application
@name name
def start_link(opts \\ []) do
module_opts = Keyword.drop(@opts, [:application, :name])
opts = Handler.start_opts(__MODULE__, module_opts, opts, [:event_timeout, :idle_timeout])
ProcessRouter.start_link(@application, @name, __MODULE__, opts)
end
@doc """
Provides a child specification to allow the event handler to be easily
supervised.
## Example
Supervisor.start_link([
{ExampleProcessManager, []}
], strategy: :one_for_one)
"""
def child_spec(opts) do
default = %{
id: {__MODULE__, @name},
start: {__MODULE__, :start_link, [opts]},
restart: :permanent,
type: :worker
}
Supervisor.child_spec(default, [])
end
@doc false
def __name__, do: @name
end
end
@doc false
defmacro __before_compile__(_env) do
# include default fallback functions at end, with lowest precedence
quote generated: true do
@doc false
def interested?(_event), do: false
@doc false
def handle(_process_manager, _event), do: []
@doc false
def apply(process_manager, _event), do: process_manager
@doc false
def error({:error, reason}, _command, _failure_context), do: {:stop, reason}
end
end
def compile_config(module, opts) do
application = Keyword.get(opts, :application)
unless application do
raise ArgumentError, inspect(module) <> " expects :application option"
end
name = Handler.parse_name(module, Keyword.get(opts, :name))
{application, name}
end
end