I question if it’s possible to effectively monitor Enterprise Server applications. webMethods gives us reasonable ways to monitor brokers themselves. With simple API programs (and I assume tools such as the webMethods Monitor) we can tell if queues are getting too large, or if adapters are not connected.
On the application side, we can trap errors using try-catch blocks. However, sometimes applications throw errors that we don’t catch. For these untrapped errors, all we get is adapter:errorNotify, which (up to v5, at least), only doesn’t even tell us which adapter gave rise to the error. All you get is an error message, such as:
(316) Could not execute SQL statement “SELECT tri
m(t1.WMEDBT), trim(t1.WMEDTN), trim(t1.WMEDUS), trim(t1.WMAN8), trim(t1.WMDL01),
trim(t1.WMCTYA), trim(t1.WMAN81), trim(t1.WMDL10), trim(t1.WMSTATE), trim(t1.WM
STATEDES), trim(t1.WMCTPE), trim(t1.WMDL02), trim(t1.WMMKT4), trim(t1.WMMKT5), t
rim(t1.WMCTR), trim(t1.WMACFL), trim(t1.WMEDSP), t1.wm_rowid FROM TESTDTA.F0000
194 t1 ORDER BY wm_rowid”.
(42000/904) ORA-00904: invalid column name
java.sql.SQLException: ORA-00904: invalid column name
Here at J&J, we have brokers with many integrations from several organizations within our enterprise that operate completely independently. It may not be easy for a human to tell the source of an error from the information above. And it would be very difficult to automate the process of monitoring such errors. For example, we have an integration that writes all adapter:errorNotify documents to a file. Someone should get an e-mail if this file gets an entry. But who should get the e-mail? We have perhaps 50 developers, scattered across 10 different companies within J&J.
If only had a clean way of determining which integration this error was associated with, I could filter the errors by integration, and establish an owner for each integration.
This is the only issue I’ve found so far with managing applications. As I’ve said, errors that we trap can be handled nicely.
Thanks in advance for any help/thoughts.