Debug Failed Processes

You can gather error information to help support teams debug the cause of scheduling and activation failures or stuck changes. Here’s some useful information:

View Debugging Information

• You can access important debugging information in the Enterprise Scheduler Service (ESS) log and database tables (EGO_CHANGE_ERRORS and EGO_VERSIONS_BATCH_THREADS).
• Debugging information is centralized in a single error table (EGO_CHANGE_ERRORS). The error details column (ERROR_DETAIL) captures the entire stack trace.

  A message is triggered when a change order is automatically canceled due to threads that didn’t start. The CLOB field in the EGO_CHANGES_ERRORS table logs details of change lines that were automatically canceled for this reason.

• The service server name and the execution ID are available in the threads table (EGO_VERSIONS_BATCH_THREADS) and the error table (EGO_CHANGE_ERRORS) as columns to help in debugging when changes get stuck in the scheduled status.

Configure Time Interval Between Enterprise Service Scheduler Jobs

• In case of Enterprise Scheduler Service errors, the application attempts to reprocess the stuck and unprocessed change lines.

  You can configure the time interval between Enterprise Service Scheduler jobs.

  In the Enterprise Manager, click ESSAPP > Configuration > Application Properties.

• FirstRetryInterval: Number of minutes after the Enterprise Scheduler job ends with an error, you want the first attempt to reprocess change lines.
• FollowOnRetryBaseInterval: Number of minutes after the first attempt to reprocess change lines, you want the second attempt to reprocess change lines. The application initiates 5 such attempts based on this interval until lines are reprocessed.

  For example, let’s say a change had 10 lines and lines 3 to 10 failed to complete. You’ve set FirstRetryInterval as 15 and FollowOnRetryBaseInterval as 30. In this case, the job will reprocess lines 4 to 10 instead of canceling them. The first attempt is made 15 minutes after the lines failed. The second attempt is made 30 minutes after the first attempt failed.

• To avoid errors during activation, a preprocess syncs effectivity dates in the following tables:

  EGO_VERSIONS_B

  EGP_ITEM_REVISIONS_B

  EGP_SYSTEM_ITEMS_B

  EGO_ITEM_EFF_B

  EGO_ITEM_EFF_TL

  EGP_ITEM_RELATIONSHIPS_B

  EGP_COMPONENTS_B

  EGO_ITEM_REVISION_EFF_B

  EGO_ITEM_REVISION_EFF_TL

  EGO_ITEM_SUPPLIER_EFF_B

  EGO_ITEM_SUPPLIER_EFF_B

  EGO_ITEM_SUPPLIER_EFF_TL

  EGO_ITEM_ASSOCIATIONS

  The error details are accessible even after scheduling logs are purged

Note: To debug change order validation errors directly in implementation logs, you must enable the profile option named Enable Change Debugging (ORA_EGO_CHANGE_DEBUG_MODE) by using the Manage Administrator Profile Values task.

View Process IDs When Scheduled Process Fails

When a rule fails validation, both the error tables and logs show an appropriate error message providing more details.

A process ID appears in the Enterprise Scheduler Service log and change affected objects tab, when a scheduling process fails.

You can use the process ID to query errors and debug the failed process from the EGO_CHANGES_ERRORS table.

Here’s a sample query:

Select * from fusion.ego_change_errors where request_id=[process ID];

Here’s how you debug failed processes:

1. Navigate to the change order's Affected Objects tab.

2. Locate the Activation Process ID and Subprocess ID columns and copy the process ID that failed.

   Scroll to the column, if required.

   Depending on the profile option Enable Change Debugging, here's how you query debugging information.

3. If the profile option Enable Change Debugging is enabled:

   Use the process ID to query the EGO_CHANGES_ERRORS table for debugging information.

4. If the profile option Enable Change Debugging is disabled:

   For failed scheduled process, use the Scheduling Process ID to query the EGO_CHANGES_ERRORS table for debugging information.

   For failed activation process:

   • Use the View Scheduled Processes page, to search by Activation Process ID.

   • In the hierarchy view, you can find the ID of the subprocess that resulted in an error. To view the error details, click View Log.

   • Using the subprocess ID, query the EGO_CHANGES_ERRORS table for debugging information.

     Note: You can create a BI data model with similar queries to view data in the EGO_CHANGES_ERRORS table.

Validations Skipped During Scheduled Status

The following validations are skipped during scheduled status to improve change resiliency and performance:

• Needs Approval: The Needs Approval validation (where Severity level is set to Needs Approval in Manage Item Rule Sets task) is skipped during the scheduled status. This prevents problems resulting from updates made to attribute name, API name, or prompt of an extensible flexfield attribute while the change order was in progress.
• Extensible Flexfield Value Sets: The validations on extensible flexfield attribute value sets to check whether the values are deactivated or end dated in a change order are skipped during the scheduled status.
• Extensible Flexfield Attributes: The validations to check the compulsory extensible flexfield attributes during the scheduled status are skipped. This prevents problems resulting from addition of compulsory flexfield attributes to the change order.