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.

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:

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.

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.

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.

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:

For more information about guidelines on checkpoints, see the Windchill Enterprise Systems Integration Administration Guide - Oracle Applications.

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:

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.

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

¹ When BusinessWorks flow returns to the point where it was called, it continues to process normally. In some cases however, this may cause erroneous processing such as sending a second PostResult message. It is, therefore, recommended that these codes are used with caution.

² Reserved for internal use - used when the logging process fails.

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.