Insight in the number, type and severity of errors that happen in a test or production environment is crucial to resolve them, and to make a stable ADF application that is less error-prone. Application errors (and their stack traces) are often hard to retrieve or take a lot of time to find. Project teams commonly depend on the reports of end-users and testers, and they typically do not report all errors or provide insufficient information about them. Operational teams do not always have the time to monitor for errors in the WebLogic console or the Enterprise Manager or to wade through large log files to manually piece together what happened. To address this issue, errors are collected by the ADF Performance Monitor. Development, QA and operational teams can drill down to the error messages, their type, severity, and their stack traces to quickly troubleshoot errors and make the application more stable.
Logging test and production errors
The ADF Performance Monitor logs errors with all relevant detail information. This information helps to discover, analyze, reproduce and resolve errors that happen frequently on test and production environments. Detailed information like exception message, timestamp, user ID, button/link clicked on, application server URI, and session is important to get insight into the errors and to resolve them. Additionally, the ADF developer can view the error stacktrace and ADF request callstack – allowing the developer to quickly troubleshoot these errors. In this example 42 errors have been collected during the selected time range (week) – for example errors like JboExceptions, SQLExceptions, NullPointerExceptions, ControllerExceptions, SQLIntegrityConstraintViolationExceptions, TxnValExceptions, e.g.
Developers can drill down to these errors, their type, severity and messages. The stacktrace can be viewed to analyze the root cause of the error – in this case a java.sql.SQLIntegrityConstraintViolationException:
Also the ADF request call stack can be viewed to understand more of the error‘s root cause. We can see that in this case just before the error occurred a PLSQL procedure was called that seems to be the cause: pagf001_api.maak_ctt_specifiek:
The ADF Performance Monitor logs errors at several extension points – one is with a custom DCErrorHandler:
More details are available on the AMIS site.