When coding any iWay Service Manager exit component,
you must adhere to the following guidelines:
- All code must be reentrant. The code can run on multiple
threads. Avoid use of monitor locks unless they are required.
- Avoid over tracing. Only issue traces that are required to understand
and debug a problem. Use only the provided trace levels to issue
trace or log messages. Properly categorize the trace levels (for
example, DEBUG, DEEP, PARSE, and so on). For more information on
the supported trace levels, see Tracing.
Never use System.out tracing, since the server cannot capture or
control these traces. For a RuntimeException, include the stack
trace, otherwise do not include the stack trace. Such traces are
cumbersome and add to trace volume.
- Only use classes and methods that are documented in this manual
or in the released Javadoc. iWay Software does not guarantee other
interfaces.
- Always use only the documented metadata functions in the component
to pass metadata to the system. Never use your own configuration
files, which cannot be managed. The value in a configuration element
can, of course, be stored in an external file using iFL functions
such as _property() or _file() to retrieve the information.
- Always query the server for information related to the environment,
such as the current context (for example, iwayhome, the configuration
name, and so on). This information is available through direct calls
to the manager class and is also stored in special registers. Never
rely on system environment values for such information, since different systems
and application servers may maintain that information in an idiosyncratic fashion.
- Never use System.exit() regardless of the problem you encounter.
Handle errors carefully. If you catch an exception, you must recover
from the error and not continue processing bad documents. An exception
caught by the engine is handled automatically by terminating the
transaction.
- If you need to issue an exception, use the XDException class
or a subclass of XDException. This allows the server to recognize
logical errors. Never simply issue Exception(). If you trace an
exception, try to avoid tracing the stack trace except for a runtime
exception. The actual trace should be sufficient to track down the
logical (non-runtime exception) issue.