Error Handling and Notification
Errors in the Windchill ESI system are handled in a closed-loop manner. This means that each error is logged and handled in some way.Windchill PDMLink users are actively notified and given the opportunity to view the errors, fix the cause of each of these errors, and then resubmit the transaction for further processing.
Overview of Error Handling Process
The Windchill ESI business logic contains a custom error-handling process. This process is called in-line after an error is detected by the TIBCO BusinessWorks application. Once started, the process evaluates the type of error and determines the action needed to handle the error including whether to:
• Send a subtransaction PostResult message to Windchill PDMLink
• Send an overall PostResult message toWindchill PDMLink
• Halt the process or continue from the point where the error occurred
The logging flags determine whether an error is logged. The severity of an error is determined via the error handling codes. An error code that stops all processing will have a severity of 0 (fatal). Severity 0 errors will always be logged. An error code that continues processing will have a severity of 1 (error). Severity 1 errors will be logged if the appropriate logging flags are enabled.
Windchill PDMLink users are actively notified and given the opportunity to fix the source of failures. However, in cases where there is not enough data to provide these notifications, presenting a possible risk of inconsistencies in the data betweenWindchill PDMLink and the distribution target, a higher-level customized notification such as an email message to the administrator or a call to a pager can be sent.
Once the error is handled, the process thread for that error terminates naturally. The error handling process uses the ESIError schema as an input. It must be populated with the required information when the error-handling service is invoked. For more information on the ESIError schema see
XML Schemas.
Types of Errors
Errors in the EAI components of a Windchill ESI system can be grouped into the following three types:
• BusinessWorks Processing Errors
Errors detected by TIBCO's BusinessWorks application in the EAI components, are handled by the BusinessWorks error-handling process. When these types of errors occur, normal processing stops and the error is logged in the BusinessWorks Process Engine log with information such as when, where, and what type of error occurred.
• Functional ERP Errors
Errors occurring in an ERP system are handled as part of normal processing and are not recorded by the error handling process or written to an error log. Instead, all errors as well as successes are recorded in the Transaction Management Log.
• System Errors
When engines, adapters, or servers fail, TIBCO Administrator sends an error message to the error handling process and attempts to automatically restart the failed program or alert an administrator of system performance problems.
The majority of errors are in anticipated circumstances. In these cases the Windchill ESI business logic processes the error in a prearranged way. In some cases, the code may fail in situations that were not anticipated. Errors of this type are handled in a predetermined way. In all cases, the Windchill ESI business logic calls the error handling process, which determines whether a PostResult message is sent to Windchill, whether or not to write to the log while error handling, and whether to halt the process or continue from the point where the error occurred
Checkpoints are used to store information about the status of jobs so that they can, after they fail, be restarted from that point on without causing data duplication or data corruption. Checkpoints are used in the following locations:
◦ After receiving a response fromWindchill PDMLink.
◦ After receiving the status of an object published to an ERP system from the EAI application.
For more information about guidelines on checkpoints, see the Windchill Enterprise Systems Integration Administration Guide - Oracle Applications (Windchill Enterprise Systems Integration 管理指南 - Oracle Applications).
Error Handling Codes
The Windchill ESI business logic uses a five-digit message code each time it invokes the error handling process. This code is used to look up a handling code which determines the behavior of the error handling process. Error handling has several handling codes and each code has permutations of actions which include the following options:
• Send subtransaction messages or do not send subtransaction messages
• Send overall messages or do not send overall messages
• Stop processing or continue processing
Fatal messages (severity "0") are always logged in the Windchill ESI business logic log. Error messages (severity "1") are logged when the corresponding logging flag is set to true. The 5-digit code that was originally used to determine the handling code is also used to determine the message that appears in the log.
The following table gives a high-level overview of each code:
|
Code/ Action
|
Severity
|
Send Sub- transactions Messages to Windchill
|
Send Overall Transaction Messages to Windchill
|
Continue Processing
|
Stop Processing
|
|
0
|
None
|
|
|
|
X
|
|
1
|
0
|
|
|
|
X
|
|
2
|
0
|
|
X
|
|
X
|
|
3
|
0
|
X
|
X
|
|
X
|
|
4
|
1
|
X
|
|
X
|
|
|
5
|
1
|
|
|
X
|
|
The following table provides additional information about each error code:
|
Error Code Number
|
Windchill PDMLink Notification
|
Final Action
|
|
0
|
No Windchill PDMLink notification
|
Processing stops.
|
|
1
|
No Windchill PDMLink notification
|
Processing stops.
|
|
2
|
Windchill ESI sends a PostResult message toWindchill PDMLink for the overall release transaction.
|
Processing stops.
|
|
3
|
Windchill ESI sends a PostResult message toWindchill PDMLink for the subtransaction as well as for the overall release transaction.
|
Processing stops.
|
|
4
|
Windchill ESI sends a PostResult message toWindchill PDMLink for the subtransaction.
|
Continues processing and returns to where the error handler was called.
|
|
5
|
NoWindchill PDMLink notification.
|
Continues processing and returns to where the error handler was called.
|