Toolbox.Incident (toolbox v1.1.0)
Module extends Toolbox.Workflow and abstracts how regular incident behaves.
Wraps around Toolbox.Workflow
and adds some additional callbacks to manage incident in asset
map. This module works very much like regular workflow, but some additional properties can be
specified. Contrary to a regular workflow, this automatically generates OAs to manage the incident
in asset map and therefore syncs the general state of this workflow with the incident asset.
Start by creating a definition (see new/0
, add_transition/2
and build/1
) which describes the
workflow of the incident. Then, you can create a new instance based on that definition with
new_instance/6
.
Link to this section Summary
Functions
Adds a new transition to incident workflow definition.
Uses given incident workflow definition and message to update state of given instance.
Creates new blank incident workflow definition
Creates new incident instance for given workflow.
Link to this section Functions
add_transition(wf, params)
@spec add_transition(Toolbox.Workflow.t(), Keyword.t()) :: Toolbox.Workflow.t()
Adds a new transition to incident workflow definition.
Incident workflow transition can be defined by:
- from (source status)
- to (target status)
- when (predicate used to select transition which will be executed)
- there can be multiple when definitions in list, all definitions are connected with && relation
- possible when definitions:
{Module, function}
, where function accepts transition, instance and message as args, returns boolean{:timeout, timeout}
, where timeout is defined in milliseconds (transition is then automatically executed when time elapses the specified value){:=, [path, to, state, key], value}
(transition is executed if the specified field of state reaches the specified value)
- then (callback used to update workflow instance state during transition execution)
- there can be multiple then definitions in list, all definitions are executed in given order
- possible then definitions:
{Module, function}
, where function accepts transition, instance and message as args, and returns{:ok, state()}
to update the instance state
- side_effects (callback used to generate output actions during transition execution)
- there can be multiple definitions in list, all definitions are executed in given order
- possible definitions:
{Module, function}
, where function accepts transition, instance and message as args, and returns{:ok, [OA | Msg | OtherSideEffect]}
- update_history_entry (callback used to modify transition execution history entry stored in
asset map)
- there can be multiple definitions in list, all definitions are executed in given order
- this is usually used to interpolate description texts, or to add additional attributes to history
- possible definitions:
{Module, function}
, where function accepts history entry, transition, instance and message as args and returns{:ok, history_entry}
- update_possible_transition (callback used to modify possible future transitions stored in
asset map)
- there can be multiple definitions in list, all definitions are executed in given order
- the callback is executed for each possible future transition
- note this only modifies the items of
future
attribute of the incident asset, this has no effect on definition transitions - possible definitions:
{Module, function}
, where function accepts possible transition, transition, instance and message as args, and returns{:ok, future_transition}
- user_actions (specifies all possible user actions from the target state)
- a map of user actions that should be enabled once the transition is executed and incident is in the target state
- user actions are automatically deleted if not present in the next transition
- keys are strings
- values are
{module, function}
, this specifies the function to be called to generate the user action token (since tokens are not known in advance, they are generated by the specified function)- the function takes
transition, instance, message
as arguments and is expected to return{:ok, binary_token}
to register the user action token
- the function takes
- upsert_attributes (specifies additional attributes to be added to the incident asset)
- list of callbacks to compute the additional attributes
- each callback produces a map of additional attributes and this is merged into a single map where the latter has priority over the former
- attributes cannot override attributes handled by this workflow incl. user actions, only other attributes can be added
- possible definitions:
{Module, function}
, where function accepts transition, instance and message as args, and should return{:ok, attribute_map}
When a message is evaluated the callbacks above are run in the following order.
when
callbacks are evaluated to see if the current transition is ready to be executed. If not the next transition is tried.then
callbacks are evaluated to update the instance state.user_actions
is evaluated, all callbacks specified inside are executed and all user action tokens are calculated.update_history_entry
callbacks are evaluated to update the new history entryupdate_possible_transition
callbacks are evaluated to update the new possible future transitionsupsert_attributes
callbacks are evaluated to gather additional attributesside_effects
callbacks are evaluated to acquire the list of all additional output actions
All text bearing attributes (such as subject
, name
, description_before
,
description_after
) has access to incident metadata dictionary. This dictionary contains these,
keys:
id
, which contains incident idtransition
, transition attributes dictionary containingfrom
,to
,severity
keysstate
, dictionary containing user defined statemessage
, altworx message which triggered given transition
Metadata can be accessed via interpolation defined as {{}}
, e.g. {{state.foo.bar}}
,
{{message.body.foo}}
.
append_create_incident_output_actions(tran, inc_inst, msg)
@spec append_create_incident_output_actions( Toolbox.Workflow.Transition.t(), Toolbox.Workflow.Instance.t(), Toolbox.Message.t() ) :: {:ok, [Toolbox.Scenario.OutputAction.t()]}
append_update_incident_output_actions(tran, inc_inst, msg)
@spec append_update_incident_output_actions( Toolbox.Workflow.Transition.t(), Toolbox.Workflow.Instance.t(), Toolbox.Message.t() ) :: {:ok, [Toolbox.Scenario.OutputAction.t()]}
build(wf)
@spec build(Toolbox.Workflow.t()) :: {:ok, Toolbox.Workflow.t()} | {:error, :transition_from_required} | {:error, :transition_to_required} | {:error, :description_after_required} | {:error, :description_before_required} | {:error, {:bad_callback, {atom(), atom()}}} | {:error, :multiple_init_statuses} | {:error, {:user_actions_invalid | :upsert_attributes_invalid, reason :: String.t()}}
handle_message(wf, inc_inst, msg)
@spec handle_message( Toolbox.Workflow.t(), Toolbox.Workflow.Instance.t(), Toolbox.Message.t() ) :: {:ok, [Toolbox.Scenario.OutputAction.t()], Toolbox.Workflow.Instance.t()} | {:terminated, [Toolbox.Scenario.OutputAction.t()], Toolbox.Workflow.Instance.t()} | {:error, :not_built_yet} | {:error, :status_mismatch}
Uses given incident workflow definition and message to update state of given instance.
If no configured workflow transition matches, nothing will happen = instance state will remain the same.
Order of callback execution:
- when definitions of transitions in definition order
- then definitions of matching transition
- update history entry definitions of matching transition
- update possible transition definitions of matching transition
- side effects definitions of matching transition
new()
@spec new() :: Toolbox.Workflow.t()
Creates new blank incident workflow definition
new_instance(wf, status, id, state, msg, params)
@spec new_instance( Toolbox.Workflow.t(), Toolbox.Workflow.status(), String.t(), map(), Toolbox.Message.t(), Keyword.t() ) :: {:ok, [Toolbox.Scenario.OutputAction.t()], Toolbox.Workflow.Instance.t()} | {:terminated, [Toolbox.Scenario.OutputAction.t()], Toolbox.Workflow.Instance.t()} | {:error, :unknown_status} | {:error, {:user_actions_invalid | :upsert_attributes_invalid, reason :: String.t()}}
Creates new incident instance for given workflow.
params
can be used to specify additional transition-like parameters. For available options see
add_transition/2
.
update_incident_history_entry(history_entry, tran, inc_inst, msg)
@spec update_incident_history_entry( map(), Toolbox.Workflow.Transition.t(), Toolbox.Workflow.Instance.t(), Toolbox.Message.t() ) :: {:ok, map()}
update_incident_possible_transition(pos_tran, tran, inc_inst, msg)
@spec update_incident_possible_transition( map(), Toolbox.Workflow.Transition.t(), Toolbox.Workflow.Instance.t(), Toolbox.Message.t() ) :: {:ok, map()}
update_incident_state(arg1, inc_inst, arg3)
@spec update_incident_state( Toolbox.Workflow.Transition.t(), Toolbox.Workflow.Instance.t(), Toolbox.Message.t() ) :: {:ok, map()}
update_user_actions(transition, instance, msg)
@spec update_user_actions( Toolbox.Workflow.Transition.t(), Toolbox.Workflow.Instance.t(), Toolbox.Message.t() ) :: {:ok, map()}