Purging of runtime logs and data

You can control how long logs, processed documents, components, and temporary data are held on your basic runtime, runtime cluster, or private runtime cloud.

While a runtime is running and executing processes, it stores detailed logs and processed documents locally. You can view them on the Process Reporting page. A runtime also stores temporary data in nested directories named /tmp, /tmpdata, and /doccache.

The default for storing logs, processed documents, components, and temporary data on your runtime is 30 days. However, you can reduce the number of days to conserve disk space on your local machine. Purged logs, processed documents, components, and temporary data are permanently deleted and cannot be recovered. If you want to maintain a longer history of documents for audit purposes, consider these approaches:

Use connector operation archiving.
Write data received and/or sent to another location as part of your process.
Use runtime-level processed document archiving. Note that an extra-cost, companion option is available with processed document archiving, whereby document metadata is stored for an additional 18 months. To have this option enabled for your account, contact your representative.

note

The /work directory contains primarily runtime data rather than temporary data. For that reason, most of /work directory is not subject to the purge settings for a basic runtime, runtime cluster, or private runtime cloud. The /as2 subdirectory is the only /work directory that is purged and it follows the Processed documents purge schedule.

The settings that control purging are on the Account Properties panel, which you can access from Runtime Management > Settings & Configuration > Account Properties.

Name	Description
Purge History After x Days	Sets the number of days following process execution that purging of logs, processed documents, components, and temporary data occurs. The number of days is calculated based on the time that a file was most recently modified; it is not based on the actual day on which the file was modified. You should never set your purge history to a value that is less than the longest amount of time that you expect a process to run successfully. However, a Purge History setting of any value can remove current files if a process runs longer than expected. The default is 30 days. The maximum is 9999. An integer less than or equal to 0 disables purging. Note: This setting for a runtime cloud determines the default purge schedule for accounts that own basic runtimes attached to that runtime cloud. Accounts can individually set more frequent purge schedules. However, if an account sets a purge schedule less frequent than the default, that account’s setting is ignored.If you enable processed document archiving for a local basic runtime or runtime cluster or a private runtime cloud, the archive directory you designate is not purged.
Purge Data Immediately	If this setting is on, processed documents, component and temporary data will be purged immediately after a process execution ends. This setting does not affect when logs will be purged. If this setting is on, it overrides the like-named process option. If this setting is off, the process option takes precedence. If you select this option, also set Purge History After x Days to an integer greater than 0, such as 1. This will not only purge your data right away, but it will also run an extra cleanup process on a daily basis. Note: If you are a runtime cloud owner set the purge data to: - ON — the setting affects all basic runtimes attached to this runtime cloud. Accounts that own basic runtimes attached to this runtime cloud can turn off their runtime’s setting, but it is overridden by the runtime cloud’s setting. - OFF — accounts with a runtime attached to the runtime cloud can set purge as needed for their runtime and the runtime’s setting is not overridden by the runtime cloud’s setting. A change to this setting takes effect immediately — you do not need to restart the runtime cloud.

Name

Description

Purge History After x Days

Sets the number of days following process execution that purging of logs, processed documents, components, and temporary data occurs. The number of days is calculated based on the time that a file was most recently modified; it is not based on the actual day on which the file was modified. You should never set your purge history to a value that is less than the longest amount of time that you expect a process to run successfully. However, a Purge History setting of any value can remove current files if a process runs longer than expected.

The default is 30 days. The maximum is 9999. An integer less than or equal to 0 disables purging.

Note: This setting for a runtime cloud determines the default purge schedule for accounts that own basic runtimes attached to that runtime cloud. Accounts can individually set more frequent purge schedules. However, if an account sets a purge schedule less frequent than the default, that account’s setting is ignored.If you enable processed document archiving for a local basic runtime or runtime cluster or a private runtime cloud, the archive directory you designate is not purged.

Purge Data Immediately

If this setting is on, processed documents, component and temporary data will be purged immediately after a process execution ends. This setting does not affect when logs will be purged. If this setting is on, it overrides the like-named process option. If this setting is off, the process option takes precedence.

If you select this option, also set Purge History After x Days to an integer greater than 0, such as 1. This will not only purge your data right away, but it will also run an extra cleanup process on a daily basis.

Note: If you are a runtime cloud owner set the purge data to:
- ON — the setting affects all basic runtimes attached to this runtime cloud. Accounts that own basic runtimes attached to this runtime cloud can turn off their runtime’s setting, but it is overridden by the runtime cloud’s setting.
- OFF — accounts with a runtime attached to the runtime cloud can set purge as needed for their runtime and the runtime’s setting is not overridden by the runtime cloud’s setting. A change to this setting takes effect immediately — you do not need to restart the runtime cloud.

Basic runtimes do not run a purge process immediately after they restart. Instead, purging occurs at the runtime’s next scheduled purge interval. If a runtime starts or restarts at the time at which its purge process is scheduled to run, the purge process will not run until its next purge interval. Purging can occur only when the runtime is online and communicating with the platform.

note

High-level information about each process execution, such as its name, time, date, etc., is logged on the and appears at the top of the Process Reporting page. This information is purged automatically after 30 days. The platform’s purging schedule cannot be modified.

Multi-threaded purging

By default, the purging process uses a single thread when purging logs and data. The default value for the Purge Manager Threads property (com.boomi.container.purge.numPurgeThreads) can vary depending on how the Purge Manager is run.

If Purge Manager is run from a runtime, the default is 1. If Purge Manager is run from the Runtime Maintenance Server, the default is 10.

On runtime clouds that process large amounts of data, single-threaded purging can take a long time. To take advantage of multi-threaded purging, you can set the number of threads to a value greater than 1.

Independent purge schedules

You can set independent purge schedules for logs, processed documents, temporary data, and test or browse components. Independent schedules, where specified, override the schedule set with Purge History After x Days. To specify independent purge schedules, edit the runtime or Account properties on the Advanced tab of the Properties panel:

Logs — Purge Schedule for Logs property (com.boomi.container.logs.purgeDays)
Processed documents — Purge Schedule for Processed Documents property (com.boomi.container.data.purgeDays)
Temporary data — Purge Schedule for Temporary Data property (com.boomi.container.temp.purgeDays)

caution
The Purge Manager does not delete files from the local OS temporary directory (e.g., /tmp on Linux or C:\Windows\Temp). This property only controls the purging of Boomi-specific temporary data stored within the runtime installation directory, such as the /tmp, /tmpdata, and /doccache folders.
Components — Purge Schedule for Components property (com.boomi.container.component.purgeDays)

Purging when local storage Is enabled

If you have a runtime cluster or runtime cloud with local storage enabled (the Working Data Local Storage Directory property [com.boomi.container.localDir=] is set to a local directory), the local and shared data is purged as follows:

In the default setup, the purging process runs in the runtime cloud. Data stored in local directories is purged by the nodes in the runtime cluster. Data stored in shared directories is purged by the head node only.
If you set the purging process to run separately from the runtime cloud via an external purging process (by setting the Purge Manager property [com.boomi.container.config.runPurgeManager] on the Account Properties panel to “FALSE”), data stored in local directories is purged only by the nodes in the runtime cluster, and not by the external process. Data stored in shared directories is purged only by the external process, and not by the head node.