Plugin Class¶
In Ocelescope, plugins are implemented as Python classes that inherit from the base Plugin
class provided by the ocelescope
package. These classes follow a standardized structure to ensure compatibility across the platform.
Each plugin class must be defined at the top level of the module. It cannot be nested inside another class or function. Additionally, each ZIP archive can contain only one plugin class.
A plugin consists of two main components:
- Metadata: Provides descriptive information about the plugin, such as its name, version, and description.
- Plugin methods: Define the functional logic of the plugin. Each method must conform to a fixed number of inputs and outputs as expected by the system.
Metadata¶
Plugin metadata is defined using class variables within the plugin class. These variables provide descriptive information about the plugin and are required for proper registration and display within the Ocelescope system.
The metadata includes:
name
: A short, human-readable name for the plugin.description
: A brief explanation of what the plugin does.version
: A version string (e.g.,"1.0.0"
).
An example plugin with metadata | |
---|---|
Methods¶
Plugin methods are functions that can be executed within Ocelescope. They are defined as methods of the plugin class and must be decorated with the @plugin_method
decorator. This decorator also attaches metadata to the method, making it discoverable and usable by the system.
Once the plugin is loaded in the frontend, plugin methods become available for execution. A user interface form is automatically generated based on the method's defined inputs.
Structure of a plugin method | |
---|---|
Inputs¶
A plugin method can accept the following types of inputs:
-
Any number of OCEL objects
These are instances of theOCEL
class provided by theocelescope
package. -
Any number of Resources
A detailed explanation of resources will be provided in a later section. -
One structured input object
This object allows for parameterized user input via a generated frontend form. While currently referred to asPluginInput
, this name may change. Only one such input object is allowed per plugin method.
OCEL Inputs¶
OCEL inputs are passed to plugin methods as instances of the OCEL
class provided by the ocelescope
package. These inputs represent event logs and are selected by the user through the frontend interface.
In the UI, OCEL inputs appear as dropdown (select) fields, allowing users to choose from the available logs in the current session.
OCEL inputs can also be annotated with the OCELAnnotation
to provide additional metadata, including:
- Label: A custom name shown in the frontend
- Description: A brief explanation of the input's purpose
- Extensions: A list of required OCEL extensions that must be present in the selected log
Resource Inputs¶
Resource inputs are passed to plugin methods as instances of the Resource
class, in a similar way to OCEL inputs. These inputs represent external data or files that the plugin may need to operate on.
In the frontend, users can select or upload resources, which are then made available to the plugin.
Resource inputs can be annotated with the ResourceAnnotation
to provide additional metadata, including:
- Label: A custom name displayed in the UI
- Description: A short explanation of what the resource is used for
Configuration Inputs¶
Structured configuration inputs are defined by creating a subclass of the PluginInput
class from the ocelescope
package. This class contains all parameter fields required by the plugin method that are not OCEL logs or Resources.
While the class can have any name, it must be assigned to the variable input
in the plugin method. This tells Ocelescope which input schema to use when generating the frontend form.
Each plugin method may use only one structured input.
Basic Input Fields¶
Basic input fields allow users to enter simple configuration values such as text, numbers, selections, or booleans. These fields are defined as attributes of the input class and use Pydantic’s Field()
function to add metadata and constraints.
The most commonly used types are:
- Strings: Free text or selectable options
- Numbers: With optional minimum and maximum bounds
- Booleans: Shown as switches or checkboxes in the UI
Example: String Input | |
---|---|
Example: Constrained Number Input | |
---|---|
Example: Selection from Options | |
---|---|
Example: Boolean Switch | |
---|---|
OCEL-Dependent Selection Fields¶
Sometimes, the available options in an input field depend on the contents of an OCEL log — for example, selecting activity types, object types, or attribute names. These are called OCEL-dependent selection fields.
You can define them using the OCEL_FIELD
helper from the ocelescope
package. This creates a dynamic dropdown field populated from the specified OCEL input.
Each OCEL_FIELD
must include:
field_type
: the type of OCEL data to pull (e.g.,"event_type"
or"object_type"
)ocel_id
: the name of the OCEL input parameter this field depends on
Example: Selecting Object Types from an OCEL
This allows the plugin form to stay in sync with the selected OCEL log, ensuring users can only choose valid options.
Dynamically Computed Fields¶
In some cases, the valid options for a field depend on other inputs or data passed to the plugin — including the selected OCEL log, Resources, or previously selected values. These are called dynamically computed fields.
To define a dynamic field, use the COMPUTED_SELECTION
helper from the ocelescope
package. This creates a selection field whose options are calculated by a Python function at runtime.
Each COMPUTED_SELECTION
must specify:
provider
: the name of a static method (or regular method) on the input class that returns the list of options.
Provider function accepted arguments
Argument | Description |
---|---|
inputs | Dictionary of current form values |
OCEL logs | Selected OCEL(s) passed to the method |
Resources | Resource instances available to the method |
Example: Dynamic Attribute Selection Using Activities and Resource File
This makes your input fields fully dynamic and context-aware — adjusting to the current OCEL log, user selections, and even external resources.
Outputs¶
Plugin method outputs in Ocelescope are defined using standard Python type hints.
Ocelescope inspects these type hints to understand what the method returns and automatically makes the results available for other plugin methods in the session.
A plugin method can return:
- A single OCEL or Resource (e.g.,
OCEL
,PetriNet
) - A list of OCELs or Resources (e.g.,
list[OCEL]
,list[PetriNet]
) - A tuple containing any combination of the above (e.g.,
tuple[OCEL, PetriNet, list[OCEL]]
)
All returned OCELs and Resources are automatically saved in the session and can be used by future plugin methods.
Example: Returning Multiple Results | |
---|---|