Call to external webservice fails: "Null response from service"

[dhaffner]

For the past week, I've been struggling to get a simple "Hello World"-style project to work. I have a simple BPEL process (PartnerHelloBPEL) which makes a call to an external web service (HelloWorldWebService), but this call consistently fails. I'm rather new to SwitchYard, so I could use some help tracking down this error. These are the webservices/clients I'm working with:

HelloSimpleBPEL: project which has a simple BPEL that does not make a call to another web service, which works

HelloSimpleBPELClient: project which contains a quickly thrown together web service client which calls the HelloSimpleBPEL process

HelloWorldServiceClient: thrown together client for the partner web service

HelloWorldWebService: the partner web service

PartnerHelloBPEL: the BPEL with the error which is a copy of HelloSimpleBPEL with the addition of the necessary assigns and the invoke to the partner web service.

This project has previously been the subject of a thread and JIRA issue. Gary Brown suggested that someone on the forum could help me find the source of this error (line 425 in server.log):

12:44:36,136 ERROR [org.switchyard.internal.DefaultHandlerChain] (pool-10-thread-1) org.switchyard.HandlerException was thrown by handler(provider): Unexpected exception handling SOAP Message — Caused by javax.xml.soap.SOAPException: Null response from service

I've attached the server.log file and all 5 projects to this post. I'd be grateful if anyone can spare the time to look into this!

[kcbabo]

Are HelloSimpleBPEL and PartnerHelloBPEL both deployed?  Both applications use the same namespace and this might be an issue with cross-talk between the local and remote services available in each app.  If both are deployed, try changing the namespace of the switchyard and composite elements in switchyard.xml for one of the apps to make it unique.

[dhaffner]

No, I never deploy both at the same time. It's always only HelloSimpleBPEL and HelloWorldWebService that are deployed.

[kcbabo]

I don't see an obvious issue with the SY config.  I deployed HelloWorldWebService and PartnerHelloBPEL and enabled message tracing.  It looks to me like the message content is not being set by the invoke in your BPEL process:

------- Begin Message Trace -------
Service -> {urn:bpel:simple-hello:1.0}HelloWebService
Operation -> sayHello
Phase -> IN
State -> OK
Exchange Context -> 
Message Context -> 
          org.switchyard.transform.TransformSequence : org.switchyard.transform.TransformSequence@1534d8c
          org.switchyard.contentType : {http://company.com/}sayHello
          org.switchyard.messageId : a14f880f-64c4-4dcb-960f-1115d8f92def
Message Content -> 
null
------ End Message Trace -------
16:25:07,292 ERROR [org.switchyard.internal.DefaultHandlerChain] (http--127.0.0.1-8080-1) org.switchyard.HandlerException was thrown by handler(provider): Unexpected exception handling SOAP Message --- Caused by javax.xml.soap.SOAPException: Null response from service
16:25:07,293 INFO  [org.switchyard.handlers.MessageTrace] (http--127.0.0.1-8080-1)

I'm not a BPEL expert, so I'll just have to ask whether the variable definitions and assignment in your BPEL process are correct.  Perhaps Gary can weigh in here.

[ibek]

Hi, I have noticed in PartnerHelloBPEL switchyard.xml that there are wrong paths ... instead of "../HelloService.wsdl" it should be just "HelloService.wsdl". Because of that, the web service wasn't invoked and there was the null response. I didn't try it but I believe everything else is correct.

[kcbabo]

Good idea, Ivo.  I missed that.  I corrected the paths in my copy of the app and it still doesn't work though.  I think the empty message content is the source of the error, but it's possible there is still something else wrong.

I will file a JIRA against the deployer for not catching the bad WSDL path.

thanks,

keith

[objectiser]

Keith Babo wrote:

I don't see an obvious issue with the SY config.  I deployed HelloWorldWebService and PartnerHelloBPEL and enabled message tracing.  It looks to me like the message content is not being set by the invoke in your BPEL process:

------- Begin Message Trace -------
Service -> {urn:bpel:simple-hello:1.0}HelloWebService
Operation -> sayHello
Phase -> IN
State -> OK
Exchange Context -> 
Message Context -> 
          org.switchyard.transform.TransformSequence : org.switchyard.transform.TransformSequence@1534d8c
          org.switchyard.contentType : {http://company.com/}sayHello
          org.switchyard.messageId : a14f880f-64c4-4dcb-960f-1115d8f92def
Message Content -> 
null
------ End Message Trace -------
16:25:07,292 ERROR [org.switchyard.internal.DefaultHandlerChain] (http--127.0.0.1-8080-1) org.switchyard.HandlerException was thrown by handler(provider): Unexpected exception handling SOAP Message --- Caused by javax.xml.soap.SOAPException: Null response from service
16:25:07,293 INFO  [org.switchyard.handlers.MessageTrace] (http--127.0.0.1-8080-1)

I'm not a BPEL expert, so I'll just have to ask whether the variable definitions and assignment in your BPEL process are correct.  Perhaps Gary can weigh in here.

Hi Keith

Checked the bpel process and it looks ok. I'll have to try it again - but just in the middle of investigating another issue at the moment.

How is the message tracing enabled?

Regards

Gary

[kcbabo]

Here's what I see in the debugger in BPEL component's RiftsawServiceLocator.ServiceProxy:

public Element invoke(String operationName, Element mesg,
                Map<String, Object> headers) throws Exception {
            
            // Unwrap the first two levels, to remove the part wrapper
            mesg = WSDLHelper.unwrapMessagePart(mesg);
            
            // Need to create an exchange
            SynchronousInOutHandler rh = new SynchronousInOutHandler();
            Exchange exchange=_serviceReference.createExchange(operationName, rh);
            
            Message req=exchange.createMessage();            
            req.setContent(mesg);
            exchange.send(req);
            

The parameter "mesg" is null when this method is entered.  This parameters as used as the content of the message, which also turns out to be null.  The message with null content is then sent along to the SOAP gateway, which has the following in it's message composer:

if (message != null) {
            // check to see if the payload is null or it's a full SOAP Message
            if (message.getContent() == null) {
                throw new SOAPException("Null response from service");
            }

I would say "Null response from service" is a bit misleading in this case.  We should consider one of the following two alternatives:

1) support an empty SOAP body if payload is null

2) generate a more meaningful error, e.g. "unable to create SOAP Body due to null message content"

#2 seems better to me.

The root cause here still seems to be that the process is not setting the content correctly for the invoke of the web service.

[kcbabo]

You can enable message tracing by adding this to the end of your switchyard.xml (after composite):

        <domain>
            <handlers>
                <handler class="org.switchyard.handlers.MessageTrace" name="MessageTrace"/>
            </handlers>
        </domain>

[ibek]

Keith, yep you are right about the definitions and assigns ... the problem is that AFAIK RiftSaw doesn't support inline initialization of variables

It is BPEL 2.0 standard but Apache ODE and RiftSaw unfortunatelly don't support all the features yet.

And I noticed that output variable is not initialized.

In attachment is fixed process ... .

[kcbabo]

Create the following JIRAs for the other issues I mentioned:

SWITCHYARD-917

SWITCHYARD-918

[objectiser]

Hi Ivo and Keith

Thanks for tracking the problem down, however inline variable initialization should be supported - so I'll do some digging to see what went wrong.

Regards

Gary

[objectiser]

Found out what the problem was - the patch for supporting inline var initialization was applied to 2.3 branch of riftsaw/ode but was originally trying to get the patch applied to ODE directly, but due to some backward compatibility problems in the ODE trunk, the patch hasn't been applied yet.

So rather than wait for the ODE project issue to be resolved, I'll just apply the patch to the 3.x branch.

[dhaffner]

Thank you for helping me resolve this issue! I appreciate your quick response.

[objectiser]

Hi

I was wrong, the inline var initialization has been in the rs3 codebase from the beginning

There were a number of issues - the main being that the variable initialization was incorrect. The variable being initialized is a message type, which could be a multi-part message - however the initialization in the original bpel was assuming that it was initializing one of the parts (i.e. parameters).

If you look at the attached updated process, which should work fine now, it shows how a multi-part message type value can be initialized. This is not actually covered in the BPEL spec, as the 'from-spec' is only intended to be used to assign values for a particular part, so this is just the way riftsaw/ODE handles it.

The other areas were around the assignments to this Request message - it did not use the part name. I've also copied the final assignment from Ivo's version, as this also seemed to cause problems.

Regards

Gary