Revision Management allows automatic purging of object revisions to limit the total number of revisions retained. Multiple revision management event processors can be configured, which enables the number of revisions to differ based on the object type. It is strongly recommended that all STEP systems have this event processor set up as a means of managing the STEP database size.
Deleted objects (objects in the recycle bin) are ignored during processing.
The Parameters and Event Triggers sections below contain important information on settings that should be considered when creating an event processor using this processing plugin.
Prerequisites
This section of documentation describes configuration steps for this specific processor, but that is only one part of configuring an event processor. For the full set of instructions on configuring an event processor, refer to the Event Processors topic.
Parameters
Each of the relevant parameters for the Event Processor Wizard 'Configure Processing Plugin' step are described below. Any additional wizard parameters with importance for this plugin are also included in this topic.
To access the 'Configure Processing Plugin' parameters as shown below, the Revision Management processing plugin must be selected within the Select Processor parameter during the wizard step 'Configure Event Processor.'
Once the Revision Management processing plugin has been selected, click the Next button, and the wizard step 'Configure Processing Plugin' will display.
-
Purge Across Workspaces: select 'Yes' to purge object revisions across all workspaces or 'No' (the default) for only the execution workspace. More revisions can typically be removed if the analysis and removal is done across workspaces, but this method takes more time. When this option is enabled, the 'Processing time' and 'Keep initial revision' settings will have no effect.
Important: The event processor fails if both the 'Purge across workspaces' and the 'Keep initial revision' are set to 'Yes.'
-
Days to Keep: uses calendar days to determine the age of a revision, and keeps only those that are less than the number of days specified. Consider setting this to 1 for most implementations.
-
Number to Keep: maximum number of revisions remaining after processing. Consider setting this to 1 for most implementations.
-
Processing time: determines the maximum number of seconds that the processor will run on each object. Must be set to 30.
Note: Setting 'Processing time' to any number other than 30 results in a Runtime Exception when events are processed.
-
Keep Initial Revision: select Yes to keep the first revision even if it falls outside all other conditions. Common setup is to keep the initial revision if you want to know when an object was initially created. If this option is set to No, the first revision will be deleted.
Important: A revision is deleted when it meets at least one of the conditions set in the Days to keep, Number to keep, and Processing time parameters. These parameters work as an 'OR' statement to determine the revisions to permanently remove.
For example, considering the values in the image above, a revision is deleted if:
-
The revision being processed is at least 731 days old, or
-
More than 100 revisions will remain after deletion of the revision being processed, or
-
The processor has not run for 30 seconds on the revision being processed.
-
Event Triggers
Select the object type(s) that should have revisions deleted according to the configured limits.
Note: The revision management event processor does not search the database and remove the revisions of all objects when the revision management event processor criteria are met. Instead, the revision management event processor does remove revisions only according to the criteria set of a single object when an event is triggered for the object.
If a different number of revisions is needed based on the object type, create an additional event processor with the necessary configuration limits.
Additionally, set Triggering Attributes, Reference Triggering Types, and/or Miscellaneous Triggering Types as necessary. Event Triggering Definitions are the same in Event Processors as they are in an OIEP. For details about the triggers, refer to the OIEP - Event-Based - Event Triggering Definitions Tab in the Data Exchange documentation here.
By default, events are triggered on the Approved workspace. Derived event functionality is available for triggering events prior to approval, as defined in the Derived Events topic in the System Setup documentation.
