Name

OpenXPKI::Server::Workflow::Activity

Description

Base class for OpenXPKI Activities. Deriving from this class is mandatory if you use the extended flow control features.

Configuration parameters

To use the flow control features, you can set several parameters in the workflow configuration. The retry params can be set in either the activity or in the state block. If both are given, those in the state block are superior. The autofail parameter is allowed only in the state block.

retry_count: Integer value, how many times the system will redo the action after pause is called. If the given value is exceeded, the action stops with an error state.
retry_interval (default 5 minutes): The amount of time to sleep after pause is called, before a new retry is done. The value needs to be parsable as a relative OpenXPKI DateTime string. Note that this is a minimum amount of time that needs to elapse, after which the watchdog is allowed to pick up the job. Depending on your load and watchdog settings, the actual time can be much greater!
If you want different delays for the retries you can give a comma seperated list of numbers. When the action is retried e.g. the third time, the third item of the list is used as delay. Each item is interpreted as a number of minutes, integer or decimals are allowed. If the list has to fewer items than max_retires, the last value from the list is used for the remaining retries.
retry_random (optional): Integer value, interpreted as percentage value (e.g. 25 = 25%), spreads the wakeup time by the given percentage. E.g. the retry_interval is 20 Minutes and the random_factor is 25%, the next wakeup is scheduled between 15 and 25 minutes.
autofail: If set to "yes", the workflow is moved directly to the FAILURE state and set to finished in case of an error. This also affects a retry_exceeded situation!

Functions

init

Is called during the creation of the activity class. Sets $self->{PKI_REALM} to CTX('session')->data->pki_realm

Sets $self->workflow() as a reference to the current workflow.

pause

immediately ends the execution of current action. this is achieved via throwing an exception of class OpenXPKI::Server::Workflow::Pause. before that, $self->workflow()->pause() will be called, which stores away all necessary informations.

get_max_allowed_retries

returns the number of max allowed retries (normally defined in config). default: 0

set_max_allowed_retries($int)

sets the number of max allowed retries

get_retry_interval

returns the retry interval (relative OpenXPKI DateTime String, normally defined in config). default: "+0000000005"

set_retry_interval($string)

sets the retry interval (relative OpenXPKI DateTime String e.g. "+0000000005")

get_reap_at_interval

returns the reap_at interval (relative OpenXPKI DateTime String). default: "+0000000005"

set_reap_at_interval($string)

sets the reap_at interval (relative OpenXPKI DateTime String, e.g. "+0000000005")

get_retry_count

Return the value of the retry counter.

wake_up

Hook method. Will be called if Workflow::execute_action() is called after proc-state "pause". The current workflow is given as argument.

NOTE The hook methods are executed on a dedicated instance of the action class so you can NOT share data with the execute method via $self, use the workflow context object to share data if needed.

resume

Hook method. Will be called if Workflow::execute_action() is called after proc-state "exception" or "retry_exceeded". The current workflow is given as first argument, the process state to recover from as second.

runtime_exception

Hook method. Will be called if Workflow::execute_action() is called with an proc-state which is not appropriate (e.g. "finished" or "running") The current workflow is given as argument.

_get_service_config_path

Helper to retrieve a config path from the parameter or autocreate from interface/server. Expects the name of the node inside the server config that should be used as fallback (single item as string or nested path as arrayref), if config_path is not explicitly set in the action parameters.

Parameter mapping

Parameters in the yaml configuration of the activity that start with _map_ are parsed using template toolkit and imported into the namespace of the action class.

The prefix is stripped and the param is set to the result of the evaluation, the value is interpreted as template and filled with the context:

  action_name:
    class: .....
    _map_my_tt_param: my_prefix_[% context.my_context_key %]

If you just need a single context value, the dollar sign is a shortcut:

  action_name:
    class: .....
    _map_my_simple_param: $my_context_key

The shortcut syntax also supports retrieval of subkeys from nested objects:

  action_name:
    class: .....
    _map_my_simple_param: $my_context_key.key_in_hash

The values are accessible via the $self->param call using the basename.

Activity configuration example

If "my_context_key" has a value of foo in the context, this configuration:

  action_name:
    class: .....
    _map_my_simple_param: $my_context_key
    _map_my_tt_param: my_prefix_[% context.my_context_key %]

Is the same as:

  action_name:
    class: .....
    my_simple_param: foo
    my_tt_param: my_prefix_foo

Note that the square bracket is a special char in YAML, if you place it at the beginning of the string, you must put double quotes around, e.g.

    _map_my_tt_param: "[% context.my_context_key %]"