Try/Catch disabled?

, , ,
1

Hi folks,

we are getting a weird behaviuor on our webMethods Enterprise 4.6 Enterprise Server platform.

We developed integrations components on different brokers which have a try/catch block on top of all flows.

Something like:

try {
…IC flow…
}
catch (AdapterException catchStepEx) {
…publishStep…
}

This try/catch code has always worked, publishing an Error Document Type each time a NullPointerException arose.

Today it doesn’t happen any more: what we get is the Adapter::Error DocumentType with the NullPointerExpcetion error.

Any idea of what is happening?:confused:

I think that is something we are missing on the Server configuration, since we restored the EnterpriseServer few days ago.

Thank you very much,
Francesco.

2

Francesco,

It sounds as if your adapter is no longer throwing the exception you are catching. Review the IS error logs to determine which exception is being thrown.

When you “restored” Enterprise Server recently how do you know that you restored the correct versions of meta-data and custom adapter code?

Mark

3

By “restoring” I meant that we reinstalled the Enterprise Platform and the Siebel2000 Adapters on a new machine, recreated the Brokers and reimported all the integration we had developed before.

Where can I find the “IS log file” to find the exception which is being thrown?

Thanks again,
Francesco.

4

Not sure about the IS Log file but there is a logging tab on the Manager that you could try.

When you re-imported everything, did you import by integration or did you re-import the entire broker that you had saved?

ES was always a little glitchy. Check the integration in EI and make a simple change and delete it. Forcing the integration to save.

Is your Error Document Type in the publish of the proper Client Group?

-Cort

5

I reimported the ICs Broker by Broker, from the Enterprise Manager.

The problem shouldn’t be the clientgroup of the publish step document in the catch step, since i tried to put a custom script there and it did not work either.

The flow just doesn’t want to go that way :mad: (in other words, the exception is no longer caught).