Revision Control Recommendations

This is one of the data gathering methodologies and recommendations for functional performance improvement. The full list is defined in the Performance Recommendations topic.

'Revisions' in STEP are historical versions of objects. A revision represents a historical 'snapshot' of an object. Major data objects in STEP (i.e., products, assets, classifications, entities, etc.) are under revision control. This means that previous versions of an object can be viewed, compared, and revived.

For more information, refer to the Revisions topic (here) and the Generating Revisions topic (here) in the System Setup documentation.

Storing many revisions can have a negative impact on system performance. Use the following recommendations to keep the number of revisions under control and to remove unnecessary revisions.

Optimizing performance in revision control involves the following steps and each is defined below:

  • Setting the revision threshold
  • Maintaining object revisions
  • Maintaining integration endpoint revisions

Setting the Revision Threshold

By default, revisions on objects are created when a user makes a change to the object and the number of hours set in the threshold is exceeded (starting when the object was first touched after the last revision was made).

This is particularly useful in cases where an object is primarily maintained by a single user and would only be made by that user choosing to do so manually. The threshold functionality ensures that changes are recorded, without creating an excessive number of revisions, which can have a negative effect on system performance.

In workbench, the revision threshold parameter is in the System Setup 'Users & Groups' node under the Revisability Settings flipper. For details about this threshold, refer to the Revisability Settings topic within the System Setup documentation here.

To avoid excessive creation of the revisions, keep the default setting (168 hours) for the threshold parameter.

Maintaining Object Revisions

As the revision history grows, it impacts the time it takes to retrieve the front revision of the object, including its name, attribute values, and references. This may have a negative effect on the system performance.

To reduce poor system performance due to excessive revisions, define a revision policy as follows:

  1. Manually delete revisions that are no longer needed. This creates a baseline for ongoing maintenance.
  2. Automatically purge old revisions via one or more event processors to keep the number of revisions under control (i.e., schedule the event process to run monthly, and to delete revisions older than one month).

For details about purging old revisions manually, refer to the Maintaining Revisions topic in the System Setup documentation here.

For details about purging old revisions automatically, refer to the Creating an Event Processor topic (here) and the Revision Management Processing Plugin Parameters and Triggers topic (here) in the System Setup documentation.

Maintaining Integration Endpoints Revisions

Integration endpoints (IIEP and OIEP) with revisions in the thousands (or more) can have a negative impact on system performance and IEPs open very slowly. Typically, this is a result of the IEP poller being started by a different user than the one configured in the IEP.

Identify IEPs with different users

  1. Run the Administration Portal Healthcheck for pollers started by a different user than the one configured in the IEP to identify the scenario.
  1. From the Start Page, click the System Administration button and supply the login credentials.
  2. On the Healthcheck tab, open the Data Error section and select the 'Pollers started by a different user than the one configured in the IEP' test.
  3. Click the Run Selected Tests button ().
  4. When the 'Last Run' column for the test shows today's date / time, review the results in the Detected Problems area at the bottom of the screen.

For more information, refer to the Healthcheck topic in the Administration Portal documentation here.

Update IEPs to resolve different users

  1. Log in to the workbench and open an IEP that was reported in the Healthcheck above.
  2. Identify the user on the IEP and, if necessary, log in to workbench again as that user.
  3. Disable the IEP.
  4. Enable the IEP again to set the same user under Revisions (on the Status tab) and the User parameter.

Purge old IEP revisions

After verifying the excessive number of revisions will no longer be created, remove the old IEP revisions that exist in the database.

Use the 'Purge old revisions' option to delete revisions for 'Inbound Integration Endpoint Type' and 'Outbound Integration Endpoint Type' as defined in the Generating Revisions topic (here) in the System Setup documentation.

Important: Purging a large number of revisions on IEPs can require an index rebuild in the database. Contact your database administrator or contact Stibo Systems.