Workflow or FileWatcher Methods

The Workflow or FileWatcher method is primarily designed for purging record history and record versions.

You can limit the scope to:

  • A repository
  • All repository for an enterprise
  • All repositories for all enterprises

You can initiate the purge using FileWatcher. A sample out-of-the-box purge configuration is supplied, consisting of a purge workflow (wfin26purgev3).

The out-of-the-box FileWatcher configuration is set up to watch out for a trigger file in a specific directory (Work/purge). The trigger file is a 0-byte file. You can initiate the purge by creating a 0-byte file in the incoming directory configured in FileWatcher. For more details on FileWatcher, refer to FileWatcher in TIBCO MDM Customization Guide.

All other input parameters are specified in the FileWatcher configuration file to control the data retention period and the purge scope. The following parameters define the interval for which data should be retained:

  • RetentionUOM: specifies a month or a day.
  • RetentionUnits: specifies the number of months or days from the current date. Any data beyond this date is subject to purge – any number greater than 0.
Note: Record versions purge does not retain version 1 if it is prior to the retention period and versionToRetain value.

Purge configuration using FileWatcher can specify the following additional inputs:

  • The PurgeEnterpriseOption parameter controls the scope of the purge. Specify this parameter only if the purge scope is for all enterprise and set the value to ALL. It does not accept any other value.
    • If ALL is specified, purge is executed for all. The credential specified must belong to the TIBCOCIM enterprise.
    • If the PurgeEnterpriseOption parameter is not specified, purge is limited to the enterprise of the credential configured in the FileWatcher.
    • If a repository name is specified, purge is limited to history and data of specified repository and also automatically restricted to the current enterprise and only one repository is specified.
  • The DeleteRecordVersions parameter is to indicate if record versions should be deleted. This parameter takes values Y, N, Yes, No. 
If Y or Yes, the old record version is deleted.
  • The DeleteRecordVersionsForce parameter works similar as the DeleteRecordVersions option but does not check the status of ProductLog. It purges the record version even if the ProductLog status is INPROGRESS. With the DeleteRecordVersions option, the purge ignores the record version if its product status is INPROGRESS.
  • The Interval parameter to identify only the changed records.

Filewatcher initiates the purge workflow (wfin26purgev3.xml) with the following steps (when doctype=purge):

  • UpdatePurgeEvent - This activity starts the purge workflow.
  • InitiatePurgeHistory - This activity is used for deleting history.
  • InitiatePurgeRecordVersion - This activity is used for deleting record versions. Having DeleteRecordVersions set to Y in FileWatcher initiates record versions purge activity. Otherwise, by default, FileWatcher initiates History Purge.
  • PurgeSuccessEmail - This activity is used for sending a success email on initiating a successful purge.
  • PurgeErrorEmail - This activity is used for sending an error email on initiating an unsuccessful purge.
  • SetStatusToSuccess - The status of the Purge event is set to success.
  • SetStatusToError - The status of the Purge event is set to error.
  • SetStatusToCancel - The status of the Purge event is set to cancel.
    Note:
    • Purge should be run when there are no other activities going on. The Application is fully functional but performance degrades. Any incoming messages are processed slowly.
    • Purge may remove the events associated with an event. When this happens, when the user clicks on the Associated Events link in the Event Details screen, an error is displayed.
    Purge Workflow