How to use FaultTo

[jaroslaw.kijanowski]

Hi,
I've modified the exceptions_faults QS to verify the FaultTo element of a message works. I've added following lines of code to the causesException method in [1] , just before the ActionProcessingException is thrown.

[1] product/samples/quickstarts/exceptions_faults/src/org/jboss/soa/esb/samples/quickstart/exceptions/MyBasicAction.java

 PortReference pr = new PortReference();
 pr.setAddress("jms://localhost/queue/quickstart_FAULT_TO_Alert/");
 pr.addExtension("jbossesb:java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
 pr.addExtension("jbossesb:java.naming.provider.url", "localhost");
 pr.addExtension("jbossesb:specification-version", "1.1");
 pr.addExtension("jbossesb:connection-factory", "ConnectionFactory");
 pr.addExtension("jbossesb:message-selector", "serviceName='ExceptionCaughtService'");
 EPR epr = new EPR();
 epr.setAddr(pr);
 message.getHeader().getCall().setFaultTo(epr);

 throw new ActionProcessingException("BAD STUFF HAPPENED");
 }

I expected that an autgenerated (by the ESB) message was sent to the quickstart_FAULT_TO_Alert queue.

What I get is following warning in the ESB console:

16:39:36,343 INFO [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
16:39:36,343 INFO [STDOUT] JustAnotherAction exceptionHandler:
Via Gateway |BASIC_ACTION| |JUST_ANOTHER_ACTION| |EXCEPTION_HANDLING|
16:39:36,343 INFO [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
16:39:36,344 WARN [ActionProcessingPipeline] No fault address defined for fault message!

How do I define the fault address for the fault message if not via message.getHeader().getCall().setFaultTo(myEPR) ?

[marklittle]

Try ActionProcessingFaultException (I think), and pass back the message. In reality what should happen is that the sender defines the FaultTo and not the receiver. I wouldn't expect the Action to change the contents of the incoming message, which is what I think you're doing.

[kconner]

... and changing it in this manner will have no effect in any case. The FaultTo EPR is cached by the pipeline processor *before* the pipeline is executed.

[jaroslaw.kijanowski]

Ok, I create now an ESB aware message, where I define the FaultTo that way:

PortReference pr = new PortReference();
pr.setAddress("jms://localhost/queue/quickstart_exceptions_faults_receiver");
pr.addExtension("jbossesb:java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
pr.addExtension("jbossesb:java.naming.provider.url", "localhost");
pr.addExtension("jbossesb:specification-version", "1.1");
pr.addExtension("jbossesb:connection-factory", "ConnectionFactory");
pr.addExtension("jbossesb:message-selector", "serviceName='ExceptionCaughtServiceReceiver'");
EPR epr = new EPR();
epr.setAddr(pr);
.
.
.
esbMessage.getHeader().getCall().setFaultTo(epr);
ListenerUtil.tryToDeliver(esbMessage, category, name);

Then, while processing the message, I throw an ActionProcessingException/ActionProcessingFaultException but the fault message still doesn't want to go to the quickstart_exceptions_faults_receiver queue:

18:58:55,337 ERROR [ActionProcessingPipeline] Failed to send error to address EPR: PortReference < <wsa:Address jms://localhost/queue/quickstart_exceptions_faults_receiver/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.initial : org.jnp.interfaces.NamingContextFactory/>, <wsa:ReferenceProperties jbossesb:java.naming.provider.url : localhost/>, <wsa:ReferenceProperties jbossesb:specification-version : 1.1/>, <wsa:ReferenceProperties jbossesb:connection-factory : ConnectionFactory/>, <wsa:ReferenceProperties jbossesb:message-selector : serviceName='ExceptionCaughtServiceReceiver'/> >.
org.jboss.soa.esb.couriers.CourierException: org.jboss.soa.esb.couriers.CourierException: Unknown destination type
at org.jboss.internal.soa.esb.couriers.JmsCourier.deliver(JmsCourier.java:147)


How should I define the EPR?

[marklittle]

Definitely not in the way you're doing. Go back to what I said originally: make your client set the FaultTo on the outgoing message. To easily check this, why not try chaining two ESB instances together and pull the EPR information for FaultTo from one of the To EPRs of the chained quickstart. (Hope that makes sense to you.)

If you want to hand create an EPR yourself, then check the quickstarts. I'd also suggest starting out with one of the more simpler types of EPR, like the File based one.

[marklittle]

I've moved this to the User forum, as it has nothing to do with the ESB design.

[jaroslaw.kijanowski]

1. Thanks for moving this, wasn't sure if this is a bug in moving the mesage to a destination defined by the FaultTo field.

2. "Ok, I create now an ESB aware message" = I went back what you said previously and made my client set the FaultTo. Your explanation was quite clear about the right time of setting the FaultTo and the caching.

3. Chaining two ESBs and copy the "To" filed to the "FaultTo" filed sounds fine, will try that if I won't be able to set the EPR that way I'm tying to do - manually. When I now compare the FaultTo and the To fileds of the message I've created and sent to he ESB, they are almost identical, I just change the serviceName. However I'm not sure if I should do this. That's my question... How should an EPR looks like if I want to address a queue (where the message should go in case of an ActionProcessingException).

4. I've checked the QSs for how to create an EPR, but I haven't found one yet.

[marklittle]

All of the quickstarts probably create their EPRs through the configuration files. That's certainly how many of the unit tests work, although there are a few that do it within the code.

BTW, each of the EPRs has a more implementation specific helper equivalent. So although you can definitely create a valid JMS Epr via the EPR class, why not try using the JMSEpr instead?

[jaroslaw.kijanowski]

The JMSEpr works fine. I've compared the result with my epr and I was missing one attribute (destination-type). So you can create a FaultTo EPR these ways:

 PortReference pr = new PortReference();
 pr.setAddress("jms://localhost/queue/X");
 pr.addExtension("jbossesb:java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
 pr.addExtension("jbossesb:java.naming.provider.url", "localhost");
 pr.addExtension("jbossesb:specification-version", "1.1");
 pr.addExtension("jbossesb:connection-factory", "ConnectionFactory");
 pr.addExtension("jbossesb:destination-type", "queue");
 EPR epr = new EPR();
 epr.setAddr(pr);

or

 JMSEpr epr = new JMSEpr("queue","queue/X","ConnectionFactory");

But you shouldn't do it that way. What is the right way to define an FaultTo EPR?

Maybe it would be possible to do it some day through the gateway?

[marklittle]

You can certainly create an EPR using the base type as you tried to do initially. But the idea behind the derived types such as JMSEpr, is to try to make your life a bit easier.

I can't tell you what the "right" way to define your FaultTo EPR is because that will depend upon your application. You obviously need to make sure that it is valid and points to a service that can do something with the fault message when it arrives, e.g., logs it.

Why do you want to do this through the gateway? Maybe I'm still missing something from your environment.

[jaroslaw.kijanowski]

Why I was thinking of a gateway, is because this is the entrypoint for ESB unaware messages.

In case of ESB aware messages the FaultTo can be created via JMSEpr/FileEpr/FTPEpr/etc...

However when we have a client sending a JMS message/dropping a file/ etc, I'm not sure how setting the FaultTo should be done. I guess one solution may be a "fault-to" property which could be set while defining the bus (in the providers section) or while configuring a particular service.

[marklittle]

You could do it that way, or just rely on the ReplyTo. If no FaultTo is defined, then ReplyTo will be used, or From in the worst case.

[jaroslaw.kijanowski]

Since ReplyTo may be set by default for JMS/JDBC/file drop, this may be a workaround for my issue. However if I want to have seperate queues for replies and faults it's not achievable.

Just to summarize, currently it is not possible to set the FaultTo for esb unaware messages, am I here right?

[marklittle]

Yes, at the moment the bi-directional nature of the gateways is limited in that regard.