cancel
Showing results for 
Search instead for 
Did you mean: 

Effective error handling in Adapter Module

Former Member
0 Kudos

eX(i)perts..

Can anybody share the effective error handling strategies inside adapter modules?

Specifically looking for

1. Module parameters configuration related error handling

2. Business logic failure owing to incorrect data.

-- Amol

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Amol,

Regarding Business Logic Error, u can throw module Exception and Write user defined details in AuditLog, so that it will be visible in RWB Details option in Adapter Engine Monitoring.

Are u looking for Alerting from Adapter Modules too?

Regards,

Sudharshan

Answers (2)

Answers (2)

former_member184154
Active Contributor
0 Kudos

What I usually do is:

- fatal error: log to audit and throw exception, so that the message hangs

- others (info, warning, recoverable errors) just log to audit

I am currently figuring out how to avoid the channel retry over the same file (for instance) when I know there's an error that requires human handling...

Alex

Former Member
0 Kudos

Alex,

my question was exactly for the situation you've described..

<i>I am currently figuring out how to avoid the channel retry over the same file (for instance) when I know there's an error that requires human handling...</i>

Would love to hear what you did for this..

thanks

former_member184154
Active Contributor
0 Kudos

Ah, too bad... So far I'm only swearing

But I'll let you know.

former_member184154
Active Contributor
0 Kudos

Ok, I resolved to move (rename) the file to a .err

This is no sharp solution, I know, for many reasons: first of all, in an EJB, you should never manipulate files directly with java.io.* package.

But... I think this problem is really releated to File/Ftp apdater only... (maybe jms as well)... Imagine the same story in a SOAP channel... Once data are received, that's it. No way the channel can poll again...

Btw, I have also investigated the ModuleException() constructor that supports the "cause" argument, passing RecoverableException, FormatException, etc. which sounded interesting but with no effect on the "file problem".

Anyway, should someone come up with a standard and more elegant solution, I'd really like to know.

Alex

Former Member
0 Kudos

I have suggestion ..

instead of renaming the file from within the module(EJB)..why don't you let XI do that for you...

What i mean is if the module is failing donot throw an exception, however set the file name specific adapter identifier to have the .err name, which you can use it in receiver determination check and have the file written out by a recevier channel?

this is in case of a file...in other cases, set some variable which can be accessed at runtime and then this message would be handled by an excpetion receiver....

Thanks.

Message was edited by:

Renjith Andrews

former_member184154
Active Contributor
0 Kudos

Mmh, interesting solution. A little bit time resource consuming maybe, but standard and effective. Thanx.

Alex

Former Member
0 Kudos

These are excpetion cases.....

so even if it takes up XI resource for processing this message ( which XI would have to process if it were correct in the first place...so it is not an unaccounted usage) i would always prefer the standard method...!!

Thanks.

Former Member
0 Kudos
Former Member
0 Kudos

Chilla,

I am aware of how Adapter modules are developed...

also ..please enlighten me how the following is related to my question..may be I failed to understand

<b>Some weblogs for JAVA mapping for IDoc mapping

/people/prasad.ulagappan2/blog/2005/06/29/java-mapping-part-i

/people/prasad.ulagappan2/blog/2005/06/29/java-mapping-part-ii