Long Time Archive

For the long-time archive, there are specialized tables in the Orchestra schema (orc_lta*). The LTA tables can be located in a separate database. To accomplish this, the entire Orchestra schema along with all SQL scripts must be created within the database. The database connection should be configured in the environment settings. Locate the group database and adjust the parameters labeled archive.* (database).

If the LTA is active, only the metadata from processes and messages will be stored in the LTA tables. The actual processes and messages will be stored as a zip file in the file system. This approach facilitates easier searching of data in the monitor.

Housekeeping settings for the LTA specify how long the data will be preserved. After this retention period, the data will be deleted from both the file system and the LTA tables.

Orchestra creates the following folder structure in the target directory:

/messagestore
/messagestoreCompressed
/process
/processCompressed

Each folder contains a similar structure: Year/Month/Day/Hour. For example, the folder 2017/03/17/12 indicates that the data from March 17, 2017, at 12:00 PM is stored within it.

The compressed folders are intended to prevent overwhelming the file system with numerous small zip files. Older folders from a single hour will be recompressed for this purpose.

The LTA is utilized across all scenarios; it cannot be restricted.

For further information, see Edit User - assign access rights.

Configuration

This section provides configuration examples. Basic information can be found in the environment settings section, while the groups referenced here are linked in their respective contexts.

Database

The LTA requires a database connection. As mentioned earlier, the LTA can be stored in a database distinct from the runtime database. Create a comprehensive Orchestra database using the provided scripts. The six key LTA tables are essential for this setup. Below is an example configuration for an LTA database. The parameters are discussed in detail here: database.

<group name="database">
  <parameter name="archive.db.typ" value="MYSQL" choice="ORACLE|MSSQL|MYSQL|Derby|PostgreSQL"/>
  <parameter name="archive.url" value="jdbc:mysql://127.0.0.1:3306/orc4562"/>
  <parameter name="archive.user" value="0008425555424d5a535400066e756c6c71710000000889a33d5384fcd75a"/>
  <parameter name="archive.pwd" value="0008425555424d5a535400066e756c6c71710000000889a33d5384fcd75a"/>
</group>

General Settings

<group name="longtimearchive">
  <parameter name="mode" value="inactive" choice="active|inactive"/>
  <parameter name="file.path" value="c:/temp/longtimearchive"/>
  <parameter name="automaticDeletion" value="true"/>
  <parameter name="deleteCorruptZipFiles" value="false"/>
  <parameter name="compressAfter" value="7,DAY"/>
  <parameter name="compressLimit" value="24"/>
</group>

warning

If you access the archived processes in the monitor, it leads to increased latency as the large zip file must be decompressed first, followed by the decompression of the searched process.

Housekeeping Settings

These parameters configure the duration for which processes and messages remain in the LTA:

<group name="Housekeeping">
  <parameter name="LongtimeArchive.cleanup" value="30,DAY"/>
  <parameter name="LongtimeArchive.polling" value="30,MINUTE"/>
  <parameter name="LongtimeArchive.limit" value="5000"/>
  <parameter name="LongtimeArchive.starttime" value="00:00"/>
  <parameter name="LongtimeArchive.endtime" value="23:59"/>
</group>

With the additional housekeeping settings, you can configure how long processes and messages are retained in the runtime version before being moved to the LTA:

<parameter name="ProcessCleanup.SUCCESS.cleanup" value="5,HOUR"/>
<parameter name="ProcessCleanup.FAILURE.cleanup" value="50,HOUR"/>
<parameter name="MessageStore.cleanup" value="30,MINUTE"/>

info

In current versions, messages are retained as long as the corresponding process. Thus, the parameter MessageStore.cleanup is no longer necessary. Retaining messages for 30 minutes is sufficient; extending this duration could result in unnecessary prolonged storage in the runtime database, while reducing it might lead to premature message release for certain databases.