Skip to content

Workflow Instance clean up

Edvard Fonsell edited this page Mar 5, 2020 · 1 revision

Workflow instance clean-up is a maintenance process that has currently 3 modes of operation: archiving, deleting from archive tables and deleting from production tables.

Archiving

Archiving moves finished workflow instances that have been inactive for some time period from production to archive tables. The purpose of archiving is to avoid growing the production tables infinitely to maintain nFlow performance. State variables and actions are also moved.

Archiving moves data from tables nflow_workflow, nflow_workflow_action and nflow_workflow_state to tables nflow_archive_workflow, nflow_archive_workflow_action and nflow_archive_workflow_state. The archive tables contain exactly the same columns as the production tables.

Archiving before 7.0.0

Prior to 7.0.0, workflows hierarchies were always archived as one unit. If any workflow in the hierarchy had been modified after the olderThan limit, the hierarchy was not be archived. The hierarchy was also be counted as one regarding the batchSize limit, regardless of how many child workflows it had. In some cases, this kind of archiving performed very badly.

Deleting from archive tables

Available since 7.0.0. Deletes workflow instances after some time period from archive tables permanently. The purpose is to eventually delete old data. Also archived state variables and actions are deleted.

Deleting from production tables

Available since 7.0.0. Deletes workflow instances that have been inactive for some time period from production tables permanently. The purpose is the same as with archiving, but this can be used if there is no need to archive the data until it is deleted. Also the state variables and actions are deleted.

Enabling clean-up process

nFlow does not automatically perform archiving, it must be either enabled via configuration, enabled programmatically or triggered manually via Java or REST API.

Configuration

See Configuration

Enabling clean-up programmatically

See MaintenanceWorkflowStarter for an example. You can add as many instances with different configurations as you need (for example different configurations for each workflow type).

Triggering via Java API

Create the configuration using MaintenanceConfiguration.Builder and pass it to MaintenanceService.cleanupWorkflows.

Triggering via REST API

Post MaintenanceRequest to /v1/maintanance.