Error Processing in exteNd Composer: Simplifying Maintenance and Debugging
Articles and Tips: article
Lead Consulting Engineer
Novell, Inc.
mthibault@novell.com
Bob Burgess
Lead Consulting Engineer
Novell, Inc.
bburgess@novell.com
04 Jun 2003
This AppNote details a method of capturing errors while processing exteNd Composer components and subcomponents. This method also provides a convenient method to display the execution order of the components for easier debugging and maintenance of a system.
|
Topics |
exteNd Composer, error handling, debugging, network application development |
|
Products |
Novell exteNd Composer |
|
Audience |
network application developers |
|
Level |
intermediate |
|
Prerequisite Skills |
familiarity with the exteNd Composer development environment |
|
Operating System |
n/a |
|
Tools |
none |
|
Sample Code |
yes |
Introduction
If you've built at least one component in exteNd Composer, you've probably realized how easy it is to capture a system error and send the results to a log file. Composer provides a number of methods to handle this situation with actions such as the Try/On Error or Raise Error and logging options. These actions make it very easy to capture an error condition and then send it to a log file.
However, a production situation often requires the use of multiple components. That is when a number of error processing questions arise; among them might be the following:
How can I best manage the error processing of these related components?
How do I propagate the error up to the calling component?
How or where is it best to record or log the error?
Which components completed processing before the error occurred?
Should the execution process even continue after an error is encountered?
Where in the process is the most time spent processing?
This AppNote presents an efficient method to address these process/error management issues. It is designed for consultants and developers familiar with the exteNd Composer development environment who want a flexible method of recording process errors and component execution paths.
The sample project referenced in this AppNote is available for download at http://www.novell.com/coolsolutions/tools/15527.html.
Methodology
When managing the error processing of multiple components, there is a need for an error handling methodology, as opposed to just using the available exteNd Composer actions like Try/On Error and Raise Error. The base element of this suggested methodology is the XML template called ResultsOutput. Using this template as the output document for all of the components provides a mechanism to organize the error information. The XML template is shown in Figure 1.
Figure 1: ResultsOutput XML template used for component's output documents.
Within each component are references to two XML Map components that first initialize the component's output results (using the ResultsOutput template) and if an error occurs then a follow-up component is called to post the error. The initializing component is called InitializeErrorArea and is used to set up the XML document with default error codes. The follow-up LogError XML Map component is then called to capture the error information and, if desired, post it to a log file.
Within each component is at least one Try/On Error action that contains the subcomponent reference. Note that the subcomponents we are talking about here are the components that contain the business logic, as opposed to the InitializeErrorArea or LogError components. After the subcomponent's call reference are a number of Map actions that propagate the subcomponent's output results to the calling component's output document.
Following the Map actions is a Raise Error action used to determine whether an error should be processed. If the condition is evaluated to TRUE in the Raise Error action, the processing jumps to the On Error section of the Try/On Error action.
Within the On Error section of the Try/On Error action are a few more Map actions to post the error information to the calling component's output document. The last action within this section is the call to the LogError XML Map component, which is used to capture the error information to a log file.
Figure 2 shows a general schema of how this methodology is implemented within any calling business logic component.
Figure 2: General schema of the process/error capture methodology.
Running the Sample Project
The sample project dsecribed in this section demonstrates this process/error capture methodology. Its initial component is a single Web Service called TopLevelComponent. It calls three subcomponents called Level2a, Level2b, and Level2c. Each of these components calls the next level, similarly named as Level3x, and finally these components call a fourth set of subcomponents. All of the components are nearly identical to each other, except for the subcomponents they reference.
Figure 3 shows a diagram of the component execution path.
Figure 3: Component hierarchy in the sample project.
To quickly understand this sample project, it is probably easiest to just execute the TopLevelComponent Web Service and review the results in the component's output document. If you accept the default input document information, a system error will occur within the business subcomponent called Level3b. A sample of this input document is shown in Figure 4.
Figure 4: Input document for the TopLevelComponent Web Service.
After executing the TopLevelComponent Web Service, you will notice the output document will contain information about this object that includes such items as component name and execution times, along with system and application error information. An added benefit of this output information is the start and stop execution times for each component. This information is very handy to have when looking for processing "hot spots" and resolving execution time issues.
In the system error message field, you'll see an execution path of the components called at the time of the system error. Of course, in this case it is a simulated error as a result of the input document. If you further expand the document, you'll also see the subcomponents called and information for each. A sample output document is shown in Figure 5.
Figure 5: Sample output document showing an error in Level3b.
In this sample project, when an error occurs the results are also written to a log file. Of course, the results could also be sent to a database or any other location desired, but for simplicity the error is sent to a log file. An example of this log file entry is shown in Figure 6.
Figure 6: Sample output of log file written by XML Map component LogError.
System Versus Application Errors
The sample project can handle two types of errors that might occur: system and application errors. It might be useful to first define the difference between system and application errors:
A system error is a major failure of the exteNd Composer process and is caused by situations such as an incorrect XML request or an improperly- handled null value. The overall exteNd Composer process stops and error information is propagated to the calling component's output document.
An application error is a business rule-type failure, such as when the tax input value was less than 15%, but it is supposed to be over 20%. The process may continue, but that is a business rule decision. Whether the ExteNd Composer process continues or not is predetermined within the component's logic.
The sample project provides an easy demonstration of catching and processing a system type. An application-specific error can also be easily processed with this sample. This code will handle most of what you need with only a few minor modifications.
To make the changes, one might add additional Try /On Error actions to catch application-specific errors. If the process is to stop immediately, one could cause system errors to occur using a Raise Error action. If the process is to continue, one might just map the appropriate application errors to the component's output document as needed and allow the process to continue.
You might notice in the code that there are "For Each Loops" used to check for multiple occurrences of application errors. This might seem strange at first, but there are situations where this can occur such as in processing 3270 screens which sometimes return multiple errors. This allows a complete set of information to be captured.
Conclusion
On the surface, this error handling methodology seems to make the code more complicated. But through real life experiences, we have found it to be a most valuable strategy to include in all exteNd Composer projects. As a developer, you now have the necessary error codes and performance parameters to:
Debug your code more rapidly
Tune your code to achieve the desired performance results
Identify back-end and/or network trouble areas
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.