Slow Record Saving Troubleshooting - Precisely_EnterWorks - EnterWorks - 11.0

Overview

This page contains tips for determining why saving a record is slow.

Turn on Logging

1. In the classic UI, navigate to the System > Log Level Settings.
2. In the Web Application Logger section, set the Facade Component to FINEST.
3. Create a test record in the repository.
4. Check the logs in the Enterworks/logs/EnableServer/webMaster*.log file. This log will contain detailed information about the actions EPIM takes to store the record.
5. Search for the keyword storeItem. The entries for storeItem Enter and storeItem Exit will indicate the start and end of the processing. The time between these entries represents how long it took to store the record, which you can measure in seconds.
6. Look for log entries related to external trigger calls, such as Change Notification. Once you find these, go to the CN_Registry repository to see the configuration for these triggers.
   Tip: Once you've completed this step, remember to revert the logging level back to SEVERE.

Examine Profile Rules

Open the profile editor for the repository and go to the Rules Listing. Look for the Bulk Callout rules and check the SQL configured in the rule. Make sure there are proper indexes on any attributes used in the where clause.

Examine User Preference

Once the record is saved, it is validated (this is the rule examination step) and the repository listing page is refreshed based on the user's preferences. Make sure there are proper indexes on any attributes involved in the sort clause.

Examine CN_Registry Repository

This repository, located in the Change Notification folder, contains configurations for "triggers" that run when repository records are created or updated. To find your repository, look in the CN_Repository_Name column—there may be multiple entries.

In the Transformation tab, you will find a list of Transformation Rules. For each entry, note the CN_Transformation_Rule_Name. These rules are defined in the CN_Transformation_Registry repository, and you should review each rule to identify any potentially "expensive" SQL queries.

In the Target tab, the CN_Target_Value_Source_SQL attribute contains the SQL executed when a rule is triggered. Ensure that proper indexes are applied to any attributes used in the WHERE clause or in joins across repositories.

Additionally, check the CN_Condition_SQL attribute in the Condition tab for any SQL that might also require optimization.