0 Replies Latest reply on May 14, 2012 10:22 AM by steljboss

    Handling the ESB AbstractActionPipelineProcessor Lifecycle

    steljboss
    steljboss May 14, 2012 10:22 AM
      • I have a synchronous ESB aware client which fires a call to the ESB.
      • The ESB solution goes through a series of a services (eg. Serv1 (OneWay) --> Serv2(OneWay) --> Serv3-WS (RequestResponse) ) and hits a WS at the other end via the soapui org.jboss.soa.esb.actions.soap.SOAPClient OOB action.
      • When that service is not there the org.jboss.soa.esb.actions.soap.SOAPClient throws an exception and the AbstractActionPipelineProcessor lifecycle kicks in calling backwards the processException of the previous action (side note: not sure if it'd be possible to somehow call the processException of the SOAPClient).
      • At this point as I don't wish to throw the exception back to the client but rather compose the normal message with a body containing some objects in certain locations and return it in the form my client expects it (plus with some additions to indicate the cause of the error) I pass the message to another service re-copying the message to ensure all the addressing is not lost and pass it to the Failures Service which will do the errorEnhancement and return it to the client.
      • However, despite the ESB containing the SOAPClient call to WS being in a service with mep=OneWay I am beaten back to the client by the ESB Lifecycle and an error message with cause "soapUI Client Service invocation failed" is returned.

       

      Q1. Is it possible to stop the lifecycle? (The normal flow can be stopped with return null rather than a valid message but the lifecycle does not rely on the message)

      Q2. When the return to the client is via the lifecycle and not via my Failures service (most usually than not) I used to get an error due to a serialization problem with the error relating to serializing the soapui error, as described in the discussion below, I resolved it by including the soapui-1.7.1.jar in my .esb (am I doing something silly here?)

      https://community.jboss.org/thread/148223

      Q3. I would be willing to return an exception to the client rather than the whole message through another service following that way the ESB lifecycle  BUT

      when I try to reset the Throwable within the processException so that it contains something useful (eg. an errorcode) it has no effect and also the same applies if I change the Fault part of the message as when I get the exception on my synchronous client I no longer have the message and nor do I have the exception I tried to re-set (eg. Exception("errorcode1"). Therefore, I am not sure how I would add my ERROR CODE/DESCRIPTION in the message fault cause so that I can utilise it at the caller end.

       

      Any thoughts on the above would be appreciated.

       

      Regards,

      Stelios