Fault Handling in Sonic 8.0(.1)

Posted by sedge on 13-Jan-2011 18:21

I am new to Sonic (noit familiar with 7.x) and I am trying to understand Fault Handling. I understand the concept of the layered fauilt handling provided by Sonic 8.0 but some of the detail of how to use Fault Handlers well still eludes me. Can anyone help out with references or examples for:

- Best Practises (Specific to Fault Handling in Sonic 8.0)

- How to locate and use Fault information in a Fault Handler

- How do use Fault Handlers with Sonic Connect (Both Web Services and Clients).

Our application needs to be quite Fault Tolerant and not just shunt messages off to the RME (Although I'm sure the RME will have it's place).

Thanks

Steve

All Replies

Posted by mnair on 13-Jan-2011 19:20

Hi Steve,

1. An entire chapter (6) is devoted to fault handling in the "Sonic Workbench: ESB Developer's Guide" at:

http://documentation.progress.com/output/Sonic/8.0.1/Docs8.0/online_help/esb_dev.pdf

You will find references to fault handler samples in here.

2. Also check the 'RESTful Services Guide' and the 'Web Services Guide' for some details on the use of fault handling with Sonic Connect. You can access all these from:

http://documentation.progress.com/output/Sonic/8.0.1/Docs8.0.htm

3. While making REST/WS invocations you can define a fault handler on the step or the process or at the appropriate level in any of the parent processes in the call hierarchy. In the case of WS a fault is generated by SC when it receives a SOAP Fault. In the case of REST any message with HTTP response code greater than 300 is treated as a fault.

If you are exposing then make use of the Fault step in the ESB process.

1) Make sure the ESB Message header "SonicESB.Fault.Name" is set or set the 'Error Name' parameter on the Fault step.  If it is not set, no SOAP Fault will be generated.  The value of the header will be used to check for (ESB) Fault Message mapping.  (It looks for the Fault Message mapping by the Fault Name value).  If there is no message mapping, the default is to bind XQ Message part as Fault part.  It basically just like normal non-fault message mapping.

2) Set the ESB Message header "SonicESB.Fault.String" or set the 'Error Message' parameter on the Fault step.  Its value will be the SOAP Fault's Fault String.

3) Set the ESB Message header "SonicESB.Fault.Code" or set the 'Error Code' parameter on the Fault step.  Its value will be the SOAP Fault's Fault Code.

4) Sonic Connect will bind the ESB message part name (actually, it will check for Fault Message Mapping parameter first as mention in #1) that matches the Fault part name of the SOAP Fault (defined in WSDL) as the SOAP Fault Detail.

Currently there are these limitations:

1) We only support Soap Fault with one message part.
2) If there are two deferent Soap Faults defined in WSDL both have the same part name, it is non deterministic which Soap Fault will be bound.

Thanks

-Mahesh

Posted by sedge on 13-Jan-2011 21:08

Thanks Mahesh

The learning curve is a steep one. I had previously seen the to documents you referred to in 1) and 2) and your answer prompted me to look at them again. I have also looked again at the Fault Hnadler sample in the  Sample.ESB Project.

The documentation has no samples and the Sample Fault Handler code is a very trivial example and does not address "How to locate and use the Fauilt information in a Fault Handler"

I have:

- Created a Fault Handler

- Created an ESB Process and  assigned the Fauilt handler to it

- Added a "Fault" step to the Process and assigned values to Error Name, Error Code and Error Message.

- Added the Process to ESB Process Tracking

When I run the process in a Scenario and look in ESB Process Tracking, I see the Fault Handler being called but I don't see any of the Fault Information in any of the message parts or headers.  

Where do I see information about the Fault and make use of it in the Fault Handler?

Regards

Steve

Posted by sedge on 13-Jan-2011 23:00

Found it!

The Error Name, Code and Message go into the JMS Headers as:

- SonicESB.Fault.Code    

- SonicESB.Fault.String     (message)

- SonicESB.Fault.Name    

I assume that each time there is another Fault that these three are replaced by the current fault headers.

Steve

Posted by mnair on 14-Jan-2011 10:55

Hi Steve,

1. I had a question about your setup. Just trying to make sure you are using this feature correctly.

You said that you added a Fault step. Did you add this to the Fault Handler process or the main ESB process?

A  Fault step is used to generate a faultbox message and you typically use  it in a branch in an ESB Process to explicitly create faults. A good  example is exposing an ESB process over SOAP or REST.

The Rethrow  step is most commonly used in a fault handler to rethrow (escalate) the  fault. But you can also use a Fault step to always throw a Fault, as  specified in the step.

2. A Fault handler is invoked in two cases:

-  Faultbox message: The XQMessage is sent to the faultbox and this  message is accessible in the steps in the FaultHandler process.

-  RME: In the RME message, the first part contains the RME part with  additional context (RME Error Code, Process name, step name, etc.). When  you are in the fault handler the information in the RME message part is  available as message headers (SonicESB.RME.Code, SonicESB.RME.Message, etc.). The remaining parts of the XQMessage is  accessible from the FaultHandler process.

3. When an explicit fault is thrown using the Fault step then the  fault information is made available in the message as headers  (SonicESB.Fault.Code, SonicESB.Fault.String, SonicESB.Fault.Name). This is primarily used  by services like Sonic Connect to generate the protocol specific fault  responses from this fault message. Users can also set these headers  explicitly using message mapping in the fault step. If these headers are  already defined then in the message then this takes precedence over the Fault node parameters.

Thanks

-Mahesh

Posted by mnair on 14-Jan-2011 10:59

The Fault step parameters are copied over to message headers  (SonicESB.Fault.Code, SonicESB.Fault.String, SonicESB.Fault.Name) ONLY if these headers are not already present. The reason for this behavior is to give higher precedence to any message mapping actions performed by the user.

So if multiple fault steps get executed as part of an escalation then the values defined in the fault step parameters get copied over only if the headers are not already present.

Thanks

-Mahesh

Posted by sedge on 16-Jan-2011 16:40

Thanks for your advice Mahesh.

I just created a simple ESB Process and attached a Fault Handler to it, then added a single "Fault" Step. I just did this so I could see what was happening. I assume that is what you meant by a "Faultbox". This is my unerstanding of Fault handling now.

- In the on ramp process I can attach a Fault Handler as a global catch all.

- In a sub process I can attach a fault handler for that specific process.

     - If the sub process can't handle the Fault it can issue a Fault which will be trapped by the Fault handler in the next higest process (that has a Fault handler attached).

- In any Process Step I can attach a Fault Handler for that Step.

     - If that Fault handler can't handle the fault it can issue a Fault and the next highest Fault Handler will trap it.

- If there is no Faiult Handler specified for an on ramp process Sonic handles the Fault by default and either resubmits the message (for Sonic Connect) or send it to the process RME.

This looks like a very similar methodology to Exceptions and Try/Catch in .NET and Java. I'd be interested if there are any significant differences that I should be on the lookout for?

In my (simple) Fault Handler I could see the Fault Code, Fault Name aand Fault String that my Fault Step had sent. From your previous response it appears safe to assume that those same Message Headers are available if Sonic issues a Fault, like an unexpected exception thrown form  Service Type.   

We will use Sonic Connect a lot in our Sonic Implementation since almost all our interfaces are Web Services (not REST). The next task is to understand what Sonic does when:

- A POST to s Web Service from a Sonic Connect Client fails

- How to throw a Fauilt in a Web Service end point that is returned to the sender as a SOAP Fault.

Regards

Steve

Posted by mnair on 17-Jan-2011 21:51

Hi Steve,

[I] Restating some of the basics of this feature

The fault handling feature works for both Faultbox and RME messages. The term fault is used here to refer to both these types of messages.

A fault is generated in the following cases:

- A service executing as a step in the process throws an unhandled exception that results in a rejected message.

- A service explicitly addresses the message to the faultbox using the ctx.addFault() API

- User explicitly uses the Reject step in the process

- User explicitly uses the Fault step in the process

A fault handler can be defined on a:

1. Step: The fault handler catches faults thrown by this step

2. Process: The fault handler catches faults thrown by any step in the process or any escalated faults from any nested processes

We do not support nested fault handlers in the 8.0.x release.

If no fault handlers are found and the fault gets escalated to the top most process then the message is:

1. Sent to the RME of the top most process if the fault is an RME

2. Otherwrise it is sent to the Faultbox destination of the top most process

[II] The semantics of fault handling are similar to the exception handling semantics in programming languages like Java.

Once a message arrives at a fault handler there are four possible scenairos (most of this is covered in the docs):

(a) Continue

The fault handler has successfully caught the fault and the required action (typically audit the error, notifiy, etc.) has been taken.

To acheive this, the fault handler process exits normally (an Exit step). Processing continues from the appropriate next step in the original call stack.

- If the fault handler that catches the fault is defined on a step then the execution starts from the next step in this process. If this was the last step in the process then the message is sent to the exit step; thus if this step is in a sub-process then the next step in the parent process is executed.

- If the fault handler that catches the fault is defined on a process then execution starts from the step that follows the step in the parent process that invoked this process. If this is the top-most process then the message is just sent to the exit endpoint.

(b) Rethrow

The fault handler process determines that it cannot handle the fault and wishes to rethrow the fault.

To acheive this, you can use:

- Rethrow step to just rethrow the fault (most common and recommended)

- Reject step: This will result in an RME message being escalated even if the original fault was not one

- Fault stepe: This will result in a Faultbox message being escalated even if the original fault was not one

(c) Resubmit

The fault handler process determines that it has fixed the error and wishes to retry the operation that caused the error.

To acheive this, you should use the Resubmit step.

The Resubmit step has a 'Resubmit to Fault source' parameter. If set to true then the step that threw the fault is the one that is always retried.

If set to false (which is also the default) then:

- If the fault handler that catches the fault is defined on a step then this step is retried. This could be the step that threw the fault or a sub-process step on one of the parent processes.

- If the fault handler that catches the fault is defined on a process then the entire process is executed again.

(d) Terminate

The fault handler process determines the error is fatal and the process instance should be terminated. A good example is a fatal security fault.

To acheive this, you should use the Terminate step.

(e) Fault handler throwing a fault or RME

This results in termination of the fault handler and escalation of the fault from the fault handler.

[III] The Fault Code/Name/String are populated only when you explicitly use the Fault step.

[IV] Any resubmits must be explicitly done by the ESB developer. This is to clarify your comment on resubmits from Sonic Connect. To retry an invocation from Sonic Connect you have to explicitly use a fault handler with a resubmit step.

[V] Sonic Connect turns all SOAP Faults in to faultbox messages and any unhandled exceptions in to RME messages. Thus you should define a fault handler on the Sonic Connect step and handle these appropriately.

I had sent some instructions earlier on how to return faults for an ESB process exposed as a SOAP web service.

Cheers

-Mahesh

Posted by sedge on 08-Feb-2011 23:01

Hi Mahesh

I've been reading up and testing Fault Handling again. Can I clarify a use case?

Sonic Connect Web Service

     Implemented by Process_1

Process_1

          Fault Handler:     Fault_Handler_1

          Step:                    Subprocess:     Process_2

Process_2

          Fault Handler:     Fault_Handler_2

          Step                    Java Service Type     Validate_1

                                        Fault Handler:     Fault_Handler_3

Fault_Handler_1

          Removes the SonicESB.Fault headers

          Adds an error message to the Web Service Response Message

          Exit

Fault_Handler_2

          Removes the SonicESB.Fault headers

          Adds an error message to the Web Service Response Message

          Rethrow

Fault_Handler_3

          Sets up a web service response message

          Adds an error message to the Web Service Response Message

          Rethrow

This is what happens:

- A Message arrives at the Web Service

- Process_1 is invoked

- Process_2 is is invoked

- Validate_1 is invoked and sets a FaultEnv

- Fault_Handler_3 is invoked

- Fauilt_Handler_1 is invoked

- The response is returned to the Web Service client with Messages from Fault_Handler_3 and Fault_Handler_1.

Is this as expected?

I expected, from what I read, that when Fault_Handler_3 executed the Rethrow that the Fault would be escalated to the Fault Handler for Process_2, Fault_Handler_2.

Thanks

Steve

Posted by mnair on 09-Feb-2011 23:51

Hi Steve,

Fault_Handler_2 should have been called. I found the issue and can confirm that there is a defect here. The fix will be available in the next release.

But if you can't work around it then please go through the official patch process.

Thanks

-Mahesh

Posted by cwiseman on 18-Apr-2011 12:35

Mahesh, Steve - I found this post extremely helpful for handling faults in Sonic 8.0.1, especially with SonicConnect services exposing web services and needing to respond with a SOAP Fault to the client making the request.

That said, I'm having difficulty getting an uncaught exception in a custom service inside a process to invoke the associated process fault handler.  Here is what I have:

SonicConnect Service

-> Operation Invoked - A process with XCBR service which routes the incoming request to two specific processes (one process responds to client, the other process just processes in parallel without dependency)

  -> Each process independently checks security and will not process because there is a security problem - a custom EsbSecurityException is thrown (but not trapped explicitly in the custom service)

    -> Both processes custom services note the message is rejected in the container log file, but the fault handler processes associated with each process containing the custom services are not invoked.

I simply want my Fault Handler process and custom fault handler service to get the exception message, populate the SonicESB.Fault.Name, String, and Code header properties and allow the SonicConnect service to respond with a generated SOAP Fault based on these properties.  However, the fault handlers are not being invoked.

The only other piece of information I could add is that the custom services, inside of each of the processes with the associated process level fault handler processes, are instances of a Spring Delegate.  The service type takes a bean id init parameter.  The bean id creates a class which implements XQServiceEx and extends several other classes which ultimately allow us to process the envelope, etc.

Apr 18, 2011 12:32:12 PM com.progress.sonic.esb.service.connect.security.interceptor.SonicConnectSecurityInInterceptor addPropsToEsbContext
INFO: Service Connect Security Context properties : {TLSX509SubjectDN=CN=city,OU=Unknown,O=CITYRMS,L=City,ST=VA,C=US, HTTPBasicAuth=null, AIPropagatedIDLong=null, TLSX509SubjectFirstCN=city, AIPropagatedID=null, PrincipalName=city, PrincipalSource=TLSX509SubjectFirstCN, HTTPDigestAuth=null}
Apr 18, 2011 12:32:27 PM com.progress.sonic.esb.service.connect.security.interceptor.SonicConnectSecurityInInterceptor addPropsToEsbContext
INFO: Service Connect Security Context properties : {TLSX509SubjectDN=CN=county,OU=Unknown,O=COUNTYRMS,L=County,ST=VA,C=US, HTTPBasicAuth=null, AIPropagatedIDLong=null, TLSX509SubjectFirstCN=county, AIPropagatedID=null, PrincipalName=county, PrincipalSource=TLSX509SubjectFirstCN, HTTPDigestAuth=null}
2011/04/18 12:32:27.921 [ERROR] (FaultServiceImpl.save:108) - Unexpected runtime error occurred.
com.mycompany.esb.webservice.sonic.security.EsbSecurityException: Unauthorized request from jurisdiction "County" with agency "COUNTYRMS".
    at
com.mycompany.esb.webservice.sonic.AbstractSonicCustomService.validateX509Security(AbstractSonicCustomService.java:233)
    at
com.mycompany.esb.webservice.sonic.ProcessLocalCustomService.processEnvelope(ProcessLocalCustomService.java:94)
    at
com.mycompany.common.progress.sonic8.impl.AbstractAvailableMessagesCustomService.service(AbstractAvailableMessagesCustomService.java:49)
    at
com.mycompany.esb.webservice.sonic.ProcessLocalCustomService.service(ProcessLocalCustomService.java:76)
    at
com.mycompany.esb.webservice.sonic.ProcessLocalCustomService$$FastClassByCGLIB$$e23e25e5.invoke()
    at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:191)
    at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:692)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
    at
com.mycompany.common.spring3.transaction.ExceptionDecoratorTransactionInterceptor.invoke(ExceptionDecoratorTransactionInterceptor.java:208)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:625)
    at
com.mycompany.esb.webservice.sonic.UnitStatusUpdateProcessLocalCustomService$$EnhancerByCGLIB$$311d9f3d.service()
    at
com.mycompany.common.progress.sonic8.impl.SonicCustomServiceSpringDelegate.service(SonicCustomServiceSpringDelegate.java:184)
    at com.sonicsw.xqimpl.service.ServiceMessageHandler.callService(ServiceMessageHandler.java:477)
    at com.sonicsw.xqimpl.service.ServiceMessageHandler.handleMessageImmediate(ServiceMessageHandler.java:422)
    at com.sonicsw.xqimpl.service.XQDispatcher.onMessageImmediate(XQDispatcher.java:880)


[11/04/18 12:32:27] ID=dev_ESBTest (severe) [Dispatch] Exception calling service ProcessLocalService: message rejected
[11/04/18 12:32:27] ID=dev_ESBTest (severe) Trace follows...
com.mycompany.esb.webservice.sonic.security.EsbSecurityException: Unauthorized request from jurisdiction "County" with agency "COUNTYRMS".
    at
com.mycompany.esb.webservice.sonic.AbstractSonicCustomService.validateX509Security(AbstractSonicCustomService.java:233)
    at
com.mycompany.esb.webservice.sonic.ProcessLocalCustomService.processEnvelope(ProcessLocalCustomService.java:94)
    at
com.mycompany.common.progress.sonic8.impl.AbstractAvailableMessagesCustomService.service(AbstractAvailableMessagesCustomService.java:49)
    at
com.mycompany.esb.webservice.sonic.ProcessLocalCustomService.service(ProcessLocalCustomService.java:76)
    at
com.mycompany.esb.webservice.sonic.ProcessLocalCustomService$$FastClassByCGLIB$$e23e25e5.invoke()
    at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:191)
    at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:692)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
    at
com.mycompany.common.spring3.transaction.ExceptionDecoratorTransactionInterceptor.invoke(ExceptionDecoratorTransactionInterceptor.java:208)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:625)
    at
com.mycompany.esb.webservice.sonic.ProcessLocalCustomService$$EnhancerByCGLIB$$311d9f3d.service()
    at
com.mycompany.common.progress.sonic8.impl.SonicCustomServiceSpringDelegate.service(SonicCustomServiceSpringDelegate.java:184)
    at com.sonicsw.xqimpl.service.ServiceMessageHandler.callService(ServiceMessageHandler.java:477)
    at com.sonicsw.xqimpl.service.ServiceMessageHandler.handleMessageImmediate(ServiceMessageHandler.java:422)
    at com.sonicsw.xqimpl.service.XQDispatcher.onMessageImmediate(XQDispatcher.java:880)

2011/04/18 12:32:27.984 [ERROR] (FaultServiceImpl.save:108) - Unexpected runtime error occurred.
com.mycompany.esb.webservice.sonic.security.EsbSecurityException: Unauthorized request from jurisdiction "County" with agency "COUNTYRMS".
    at
com.mycompany.esb.webservice.sonic.AbstractSonicCustomService.validateX509Security(AbstractSonicCustomService.java:233)
    at
com.mycompany.esb.webservice.sonic.ProcessResponseCustomService.processEnvelope(ProcessResponseCustomService.java:94)
    at
com.mycompany.common.progress.sonic8.impl.AbstractAvailableMessagesCustomService.service(AbstractAvailableMessagesCustomService.java:49)
    at
com.mycompany.esb.webservice.sonic.ProcessResponseCustomService.service(ProcessResponseCustomService.java:76)
    at
com.mycompany.esb.webservice.sonic.ProcessResponseCustomService$$FastClassByCGLIB$$8816a637.invoke()
    at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:191)
    at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:692)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
    at
com.mycompany.common.spring3.transaction.ExceptionDecoratorTransactionInterceptor.invoke(ExceptionDecoratorTransactionInterceptor.java:208)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:625)
    at
com.mycompany.esb.webservice.sonic.ProcessResponseCustomService$$EnhancerByCGLIB$$be1f41f.service()
    at
com.mycompany.common.progress.sonic8.impl.SonicCustomServiceSpringDelegate.service(SonicCustomServiceSpringDelegate.java:184)
    at com.sonicsw.xqimpl.service.ServiceMessageHandler.callService(ServiceMessageHandler.java:477)
    at com.sonicsw.xqimpl.service.ServiceMessageHandler.handleMessageImmediate(ServiceMessageHandler.java:422)
    at com.sonicsw.xqimpl.service.XQDispatcher.onMessageImmediate(XQDispatcher.java:880)


[11/04/18 12:32:27] ID=dev_ESBTest (severe) [Dispatch] Exception calling service ProcessResponseService: message rejected
[11/04/18 12:32:27] ID=dev_ESBTest (severe) Trace follows...
com.mycompany.esb.webservice.sonic.security.EsbSecurityException: Unauthorized request from jurisdiction "County" with agency "COUNTYRMS".
    at
com.mycompany.esb.webservice.sonic.AbstractSonicCustomService.validateX509Security(AbstractSonicCustomService.java:233)
    at
com.mycompany.esb.webservice.sonic.ProcessResponseCustomService.processEnvelope(ProcessResponseCustomService.java:94)
    at
com.mycompany.common.progress.sonic8.impl.AbstractAvailableMessagesCustomService.service(AbstractAvailableMessagesCustomService.java:49)
    at
com.mycompany.esb.webservice.sonic.ProcessResponseCustomService.service(ProcessResponseCustomService.java:76)
    at
com.mycompany.esb.webservice.sonic.ProcessResponseCustomService$$FastClassByCGLIB$$8816a637.invoke()
    at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:191)
    at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:692)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
    at
com.mycompany.common.spring3.transaction.ExceptionDecoratorTransactionInterceptor.invoke(ExceptionDecoratorTransactionInterceptor.java:208)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:625)
    at
com.mycompany.esb.webservice.sonic.ProcessResponseCustomService$$EnhancerByCGLIB$$be1f41f.service()
    at
com.mycompany.common.progress.sonic8.impl.SonicCustomServiceSpringDelegate.service(SonicCustomServiceSpringDelegate.java:184)
    at com.sonicsw.xqimpl.service.ServiceMessageHandler.callService(ServiceMessageHandler.java:477)
    at com.sonicsw.xqimpl.service.ServiceMessageHandler.handleMessageImmediate(ServiceMessageHandler.java:422)
    at com.sonicsw.xqimpl.service.XQDispatcher.onMessageImmediate(XQDispatcher.java:880)

Posted by cwiseman on 08-Jun-2011 10:14

I thought I would complete this thread for the benefit of those that end up here with their topic searches.

The SonicConnect fault handling had a bug that would not push messages into the designated fault handler upon getting uncaught exceptions.  Support and development are aware of this and we're hoping this will be fixed either in a hot fix or the new 8.5 GA release scheduled for August.

Posted by JamesTulledge on 23-Jun-2011 14:51

Hello,

I'm having problems using a CBR (CBR & XCBR) within the Fault Handling Process itself.  Are the CBR objects allowable within the Fault Handling Process?  I've attached the xar file (esbFaultHandler.xar) for your review.  Below is a log snippet from the MF container that i get each time i send a message through the system.  Thanks.

Jim Tulledge

[11/06/23 15:34:24] (info) Restarting...
[11/06/23 15:34:28] (config)

    Sonic Management
    Release 8.0.1 Build Number 196
    Copyright (c) 1999-2010 Progress Software Corporation.
    All rights reserved.

    Local host: 7V95XL1 (Windows 7 - 6.1)

    Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
    Sun Microsystems Inc. (home C:\Program Files (x86)\Java\jdk1.6.0_24\jre, version 1.6.0_24)
    Java HotSpot(TM) Server VM (build 19.1-b02, mixed mode)

    Configured Arguments : -Xms64m -Xmx512m
    Configured Properties:

[11/06/23 15:34:28] (info) "Domain1.ctEsbFaultHandler" starting...
[11/06/23 15:34:29] (info) Management connection (re)established (Socket[addr=/127.0.0.1,port=2506,localport=56287])
[11/06/23 15:34:29] (info) Loaded ID=AGENT
[11/06/23 15:34:30] ID=esbFaultHandler (info) esbFaultHandler initializing...

    Sonic ESB Professional Developer Edition [Serial Number: 999999999]
    Release 8.0.1 Build Number 197
    Copyright (c) 2001-2010 Progress Software Corporation.
    All Rights Reserved.


[11/06/23 15:34:31] ID=esbFaultHandler (info) [ESBService] Initializing Deployed process `pTestFaultHandler`
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ESBService] Initializing Service `sFaultHandlerProto`
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ESBService] Initializing Service `sReplaceInvalidChars`
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ESBService] Initializing Service `sFaultHandlerXform`
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ESBService] Initializing Service `sFaultHandler_CBR`
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ESBService] Initializing Service `dev.Prototype`
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ESBService] Initializing Service `sSendRMEToQueueVerif`
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ESBService] Initializing Service `sSendRMEToBPMVerif`
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ESBService] Initializing Service `dev.Transform`
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ESBService] Initializing Service `sSendFaultToQueueVerif`
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ESBService] Deployed process `pTestFaultHandler` initialized: 1 thread(s) listening on Endpoint pTestFaultHandler.Entry
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ESBService] Service `sFaultHandlerProto` initialized: 1 thread(s) listening on Endpoint sFixPayload_Proto.Entry
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ESBService] Service `sReplaceInvalidChars` initialized: 1 thread(s) listening on Endpoint sReplaceInvalidChars.Entry
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ESBService] Service `sFaultHandlerXform` initialized: 1 thread(s) listening on Endpoint sFaultHandlerXform.Entry
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ESBService] Service `sFaultHandler_CBR` initialized: 1 thread(s) listening on Endpoint sFaultHandler_CBR.Entry
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ESBService] Service `dev.Prototype` initialized: 1 thread(s) listening on Endpoint dev.Prototype.Entry
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ESBService] Service `sSendRMEToQueueVerif` initialized: 1 thread(s) listening on Endpoint sSendRMEToQueueVerif.Entry
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ESBService] Service `sSendRMEToBPMVerif` initialized: 1 thread(s) listening on Endpoint sSendRMEToBPMVerif.Entry
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ESBService] Service `sSendFaultToQueueVerif` initialized: 1 thread(s) listening on Endpoint sSendFaultToQueueVerif.Entry
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ESBService] Service `dev.Transform` initialized: 1 thread(s) listening on Endpoint dev.Transform.Entry
[11/06/23 15:34:31] ID=esbFaultHandler (info) Initializing PrototypeService...
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ sReplaceInvalidChars ] Initializing ...
[11/06/23 15:34:31] ID=esbFaultHandler (info)

         ReplaceInvalidChars
          Version  1.0. build 0

[11/06/23 15:34:31] ID=esbFaultHandler (info) [ sReplaceInvalidChars ]Parameter Name = origStr
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ sReplaceInvalidChars ]Parameter Value = &
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ sReplaceInvalidChars ]Parameter Name = replaceStr
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ sReplaceInvalidChars ]Parameter Value = &
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ sReplaceInvalidChars ] Initialized ...
[11/06/23 15:34:31] ID=esbFaultHandler (info) Initializing PrototypeService...
[11/06/23 15:34:31] ID=esbFaultHandler (info) Actional instrumentation is disabled for this container
[11/06/23 15:34:31] ID=esbFaultHandler (info) Initializing Mitigation context factory class: com.sonicsw.xqimpl.actional.lg.visitor.StabilizerHelper
[11/06/23 15:34:31] (info) Loaded ID=esbFaultHandler
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ sReplaceInvalidChars ]Starting...
[11/06/23 15:34:31] ID=esbFaultHandler (info) [ sReplaceInvalidChars ]Started...
[11/06/23 15:34:31] ID=esbFaultHandler (info) Container's ESB (JMS) Connection: jms_defaultConnection
[11/06/23 15:34:31] ID=esbFaultHandler (info) Container's HTTP Routing Connection: http_defaultConnection
[11/06/23 15:34:31] (info) ...startup complete
[11/06/23 15:34:32] ID=esbFaultHandler (info) Attempting to (re)establish connection: jms_defaultConnection
[11/06/23 15:34:34] ID=esbFaultHandler (info) Connection to endpoint 'pTestFaultHandler.Entry' (re)established for connection 'jms_defaultConnection' at 7V95XL1:2506

[11/06/23 15:34:49] ID=esbFaultHandler (severe) Trace follows...
com.sonicsw.esb.itinerary.engine.ItineraryException: Error creating process instance
    at com.sonicsw.esb.itinerary.engine.XQProcessInstanceGenerator.retrieveProcessInstance(XQProcessInstanceGenerator.java:97)
    at com.sonicsw.esb.itinerary.engine.ItineraryEngine.getProcessInstance(ItineraryEngine.java:236)
    at com.sonicsw.esb.itinerary.engine.ItineraryEngine.executeProcess(ItineraryEngine.java:321)
    at com.sonicsw.esb.itinerary.engine.ItineraryEngine.handleToken(ItineraryEngine.java:190)
    at com.sonicsw.esb.itinerary.engine.ItineraryEngine.handleMessage(ItineraryEngine.java:180)
    at com.sonicsw.xqimpl.endpoint.container.EndpointContextContainer.onMessage(EndpointContextContainer.java:95)
    at com.sonicsw.xq.connector.jms.JMSEndpoint$JMSEndpointListener.onMessage(JMSEndpoint.java:580)
    at progress.message.jimpl.Session.deliver(Session.java:3060)
    at progress.message.jimpl.Session.run(Session.java:2463)
    at progress.message.jimpl.Session$SessionThread.run(Session.java:2855)
Caused by: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character 'r' (code 114) excepted space, or '>' or "/>"
at [row,col {unknown-source}]: [12,305]
    at com.ctc.wstx.sr.StreamScanner.throwUnexpectedChar(StreamScanner.java:648)
    at com.ctc.wstx.sr.BasicStreamReader.handleNsAttrs(BasicStreamReader.java:2965)
    at com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2936)
    at com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2848)
    at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1019)
    at com.sonicsw.esb.itinerary.engine.XQProcessInstanceGenerator.getESBProcess(XQProcessInstanceGenerator.java:380)
    at com.sonicsw.esb.itinerary.engine.XQProcessInstanceGenerator.getProcessDefFromPart(XQProcessInstanceGenerator.java:171)
    at com.sonicsw.esb.itinerary.engine.XQProcessInstanceGenerator.getESBProcess(XQProcessInstanceGenerator.java:157)
    at com.sonicsw.esb.itinerary.engine.XQProcessInstance.(XQProcessInstance.java:137)
    at com.sonicsw.esb.itinerary.engine.FaultProcessInstance.(FaultProcessInstance.java:34)
    at com.sonicsw.esb.itinerary.engine.XQProcessInstanceGenerator.retrieveProcessInstance(XQProcessInstanceGenerator.java:91)
    ... 9 more

Posted by mnair on 24-Jun-2011 21:19

Hi Jim,

The issue in your case seems to be related to the quotes in the process description of the pFaultHandler process. Replace "rethrows" with 'rethrows' in the process description and re-run your tests. I have filed a defect (SNC00081369) to track this issue.

Let me know if you have further questions.

Thanks

-Mahesh

Posted by JamesTulledge on 27-Jun-2011 09:24

Thank you very much, Mahesh. What you said did the trick! Thank you again.

Regards, Jim Tulledge

This thread is closed