GSP
Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Support
Contact Us
Online Help
Handbooks
Domain Status
Man Pages

FAQ
Virtual Servers
Pricing
Billing
Technical

Network
Facilities
Connectivity
Topology Map

Miscellaneous
Server Agreement
Year 2038
Credits
 

USA Flag

 

 

Man Pages
OpenXPKI::Server::Workflow::Activity(3) User Contributed Perl Documentation OpenXPKI::Server::Workflow::Activity(3)

OpenXPKI::Server::Workflow::Activity

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

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!

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.

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.

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

sets the number of max allowed retries

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

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

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

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

Return the value of the retry counter.

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.

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.

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.

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.

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 %]"
2022-05-14 perl v5.32.1

Search for    or go to Top of page |  Section 3 |  Main Index

Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with ManDoc.