JCAPSMentor - Java CAPS Unleashed - Basic to Expert Discussions

JCAPSMentor - Basic to Expert Discussions Jcaps, SOA, SUN, Netbeans, Enterprise, Sun System Application Server, Java, J2EE, EAI, JBI, Composite Application Platform Suite, EDI, SeeBeyond, HL7, Singapore

 
  FOLLOW US!
  JCAPSMentor

Visit us at Facebook



 

  Visitors LIVE! Stats
 
  Covering the World!
 
Handling JavaException fault from JCD to Business Process
It is not possible for the business process to have a fault defined for each custom exception that can be thrown in the JCD. The JavaException fault does however have include the Type, Message and Stacktrace fields. The details of the exception that occurs within the JCD are mapped to these fields. When handling the exception in the business process you can check the values of the these fields to determine what subsequent actions need to be followed.

For example:

- If you highlight the JCD in the business process and then select the properties for the JCD you will see that there is a fault field. This could be set to for example 'ns0:JavaException'.

- You can then add an exception handler to the business process ('Catch Named Exception') and configure it to use 'ns0:JavaException'.

- In the exception handler you can then check the values of the Type and Message fields for the fault and process as required.


 
Default acknowledgement mode in JCAPS
The default is AUTO_ACKNOWLEDGE, where the system automatically acknowledges a message once the consumer has processed it. This mode guarantees at most one redelivered message after a provider failure.
In the AUTO_ACKNOWLEDGE mode, the session automatically acknowledges each message consumed by the client. The session thread blocks, waiting for the broker to confirm that it has processed the client acknowledgement for each consumed message.

If a session is closed without the client acknowledging the message or if the message broker fails before the acknowledgment is processed, the broker redelivers that message, setting a JMSRedelivered flag.

When the transaction mode is set to XA, the JMS session becomes part of the existing transaction, and is processed according to the XA two-phase commit protocol. In the first phase, the resource manager sends a query to commit to the receivers and waits for the receivers to respond with a confirmation. In the second phase, the resource manager receives confirmation from all receivers, and commits the message to all receivers. This setting prevents message loss and duplicate messages, even when a system unexpectedly shuts down.



 
Manesh Abhimanyu
Manesh is a Sr. EAI Consultant, at present working in Singapore (Little Red Dot).

His focus is in the areas of SOA, ESB and Enterprise Architecture Management.

Contact him via email (mak2powerATyahoo.co.in)

Menu
Archives
Links
Website developed & maintained by

Manesh Abhimanyu K. (Mak)

Click here to contact Manesh









Free Domain CO.NR