SwitchYard service task ... calling soap service with no errors, but no reaction

[ubm]

Hello,

I've extended the quickstart sample "bpm-service" by adding a SwitchYard service task to the "hold-branch" which for its part should call a (non-SwitchYard) remote soap service.

Additionally I've defined an "on entry action" and an "on exit action" ... both times a "System.out.println("...")". A call to the bpmn-service triggering the "hold-branch" always works fine (no errors), those "actions" result in a console output. MY PROBLEM: I get no soap call!!! Any ideas what's missing?

I'm working with Eclipse Juno, "switchyard-as7-0.7" sources and 0.8.0 SwitchYard tooling. The call to my soap test service is a call to localhost, port 8080.

Thanks to all for the help.

[dward]

Uwe,

Are you sure there's no errors in the log?  My gut reaction was to ask you to double-check there's a service reference and interface defined for that external web service call, but in looking at the code, if there wasn't, an IllegalStateException would have been thrown.

My second thought is that a SwitchYardServiceWorkItemHandler is not being registered properly, but then the previous Inventory, Shipping and BackOrder work wouldn't be completed.  Actually, can you still just double-check that?  That in your <implementation.bpm> element, you have a <workItemHandlers>

<workItemHandler class="org.switchyard.component.bpm.work.SwitchYardServiceWorkItemHandler" name="SwitchYard Service"/></workItemHandler>

</workItemHandlers> defined?

Another thing you can do is use Apache TCPMon to create a proxy in between SwitchYard and your actual external web service.  You can then monitor the http request/responses, and see if - maybe - your external web service is indeed being called, but not showing up on that end for some reason.

Finally, if all the above doesn't work, perhaps you can provide us with a standalone, small, test project so we can take a closer look.

Thanks,

David

[ubm]

Hi David,

and many thanks for your answer.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The log messages of a call to the "hold branch" are:

09:42:04,766 INFO  [stdout] (http-localhost-127.0.0.1-8080-2) ********** Inventory incoming messageId: 208809e3-b34f-4765-9488-66666f2b013f **********

09:42:04,791 INFO  [stdout] (http-localhost-127.0.0.1-8080-2) On entry

09:42:04,794 INFO  [stdout] (http-localhost-127.0.0.1-8080-2) On exit

... seems ok.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A "workItemHandler" is defined like that (in switchyard.xml):

<bpm:workItemHandlers>

  <bpm:workItemHandler class="org.switchyard.component.bpm.work.SwitchYardServiceWorkItemHandler" name="SwitchYard Service"/>

</bpm:workItemHandlers>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Using WireShark shows no traffic over http or tcp to or from the desired soap service. For this

test I put the soap service on a remote server and not on localhost.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It would be great if you could have a look at my sample sources. I zipped two projects together:

A (very) simple "Hello World" test soap service with no parameters and void return type. And the

modified bpm-service-sample.

The control project is "bpm-service", the wsdl file for the inserted test soap call

is \bpm-service\src\main\resources\wsdl\TestSoapService.wsdl.

No need to use exactly my "Hello World" sample ;-)

To trigger the bpm-workflow I used soapUI like this:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:switchyard-quickstart:bpm-service:1.0">

   <soapenv:Header/>

   <soapenv:Body>

      <urn:submitOrder>

         <orderId>42</orderId>

         <itemId>cowbell</itemId>

         <quantity>1000</quantity>

      </urn:submitOrder>

   </soapenv:Body>

</soapenv:Envelope>

You can download the zip file under:

http://www.microjup.de/transfer/SwitchYardTest.rar

Looking forward to your answer

Uwe

[andi.scharfstein]

+1 on this issue. I have been trying to get a similar scenario to run, so far without success.

My scenario consists of an external SOAP service that is referenced in the SwitchYard service and called by various means. First I tried a static Camel route, which proved no problem at all. I can see the calls coming through at the remote endpoint and receive the expected result back at the SwitchYard service.

Then I tried replacing the Camel implementation using a very simple BPMN definition. Basically, it's just a SwitchYard Service Task wedged between start and end point. This task calls the reference to the remote endpoint by its SwitchYard name and tries to issue a call, but I never see it coming through. However, since I am accessing the complete SwitchYard service using a SOAP binding, I am getting back a SOAP envelope that contains (among other stuff) the following line:

<processInstanceId xmlns="urn:switchyard-component-bpm:bpm:1.0">1</processInstanceId>

What I am seeing is that the process instance id is incremented every time I access the SwitchYard service. I assume this is expected behaviour, but I am reporting it just in case.

Basically, I am at my wit's end - it's not giving me any errors, but it's not doing anything useful, either. Can anyone verify that calling SOAP references through a SwitchYard Service Task in fact works as intended?

[dward]

Uwe,

Thanks for the sample app. I just finished up a bunch of other work, so I should have time to look at this tomorrow.  Thanks again.

David

[dward]

Andi, I will be looking at this tomorrow (see my note to Uwe), however just a quick note for you... The processInstanceId will continue to increment each time you invoke the bpm component with a START_PROCESS action type.  The reason you get that back in a response header is to allow you send it back in with a subsequent request header if you need to perform a different action (say, SIGNAL_EVENT or ABORT_PROCESS_INSTANCE) on a pre-existing process instance.

[dward]

Uwe,

Okay, I figured out what's going on.  There's two different parts to this:

PART 1: The reason you didn't get an error:

The default behavior of the SwitchYardServiceWorkItemHandler is, when encountering a fault, to still complete the work item.  This is for backwards compatibility.  If you want it to not complete the work item (and thus not continue the process), then on the SwitchYard Service node in your flow, set the CompleteAfterFault property to false (an Expression equal to false).

I do feel it would be useful if the fault that was encountered showed up in the log, so I will change this.

The reason it doesn't do anything about the fault is because no fault-handling behavior was defined.  You have two options for this:

1. Signal an event in your process, that, when triggered, will execute an error-handling flow.  To do this, on your SwitchYard Service node, set the FaultSignalId property to whatever will trigger the right event in your process.  Note that it is not there by default.  The tooling incorrectly calls the property FaultEventType.  Please change this to FaultSignalId.  This will get fixed in the tooling.
2. Set a variable to evaluate in a gateway later on in your flow.  To do this, on your SwitchYard Service noe, set the FaultResultName property to a variable (make sure that all variables are also mapped at the process level), then check for that fault variable in a subsequent gateway.  Evaulate it, and split to a success flow or error flow.

PART 2: What you can do to fix the error:

I was able to recreate the problem myself.  I attached a debugger, and found the fault, which said,

     "org.switchyard.exception.SwitchYardException: Cannot convert from 'org.switchyard.quickstarts.bpm.service.data.Order' to 'org.w3c.dom.Node'.  No registered Transformer available for transforming from 'java:org.switchyard.quickstarts.bpm.service.data.Order' to 'java:org.w3c.dom.Node'.  A Transformer must be registered."

I didn't know this previously, but when a service reference to an external web service is invoked, a custom payload (in my case, an Order object) needs to get converted to a DOM Node.  However, if you don't have a Transformer registered to do this tranformation, the above fault will occur.  So.... What I ended up doing is registering a transformer in my switchyard.xml that does this.  This is what it looked like, but you can do it using jaxb vs. java if you want:

    <xform:transform.java class="org.switchyard.quickstarts.bpm.service.data.Transformers" from="java:org.switchyard.quickstarts.bpm.service.data.Order" to="java:org.w3c.dom.Node"/>

I was then able to see my debug from the external web service finally being invoked.

I hope this is helpful.  Thanks again for your patience!

David

[dward]

I've added a jira to make enhancements: SWITCHYARD-1276 .

[dward]

Work has been completed on the above jira.  Please see my comment for details on what's changed.

[ubm]

Hi David,

thanks for the time you spent on this issue. I'll try to realize your propositions and give a feedback.

Uwe

[andi.scharfstein]

David, thanks from my side as well. I have a few requests for clarification if you don't mind:

PART 1: The reason you didn't get an error:

1. Signal an event in your process, that, when triggered, will execute an error-handling flow.  To do this, on your SwitchYard Service node, set the FaultSignalId property to whatever will trigger the right event in your process.  Note that it is not there by default.  The tooling incorrectly calls the property FaultEventType.  Please change this to FaultSignalId.  This will get fixed in the tooling.

I have to admit that as a newcomer to BPMN2, that is still a little vague to me. Specifically, I currently have no idea what the "right event" in my process should be and how to connect it to the SwitchYard Task (I mean, it can't just float freely in space, can it?). A pointer to some relevant documentation or a code sample would be appreciated, currently I am not sure where to start looking.

PART 2: What you can do to fix the error:

I didn't know this previously, but when a service reference to an external web service is invoked, a custom payload (in my case, an Order object) needs to get converted to a DOM Node.

In my case, I didn't specify a custom payload - it's all just integers. Do you happen to know if I still need to define a transformer? I tried implementing one, but I am unsure of the typing involved, and I don't get any feedback from the engine since I didn't manage to implement part 1 of your suggestions. I suppose attaching a debugger is only an option if your IDE is already set up for SwitchYard development?

I'm also struggling setting up a JAXB transformer, I tried adding a simple transformation from the response type of my SOAP call ("{http://imexmock.esb.swr.ard.de/}testResponse") to "java:int", but it fails on deployment:

10:48:57,184 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.unit."bpm-soap.jar".SwitchYardService: org.jboss.msc.service.StartException in service jboss.deployment.unit."bpm-soap.jar".SwitchYardService: java.lang.IllegalArgumentException

    at org.switchyard.as7.extension.services.SwitchYardService.start(SwitchYardService.java:85)

    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_11]

    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_11]

    at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_11]

Caused by: java.lang.IllegalArgumentException

    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:616) [rt.jar:1.7.0_11]

    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:565) [rt.jar:1.7.0_11]

    at org.switchyard.transform.jaxb.internal.JAXBUnmarshalTransformer.<init>(JAXBUnmarshalTransformer.java:61)

    at org.switchyard.transform.jaxb.internal.JAXBTransformerFactory.newTransformer(JAXBTransformerFactory.java:61)

    at org.switchyard.transform.jaxb.internal.JAXBTransformerFactory.newTransformer(JAXBTransformerFactory.java:46)

    at org.switchyard.transform.TransformerRegistryLoader.newTransformers(TransformerRegistryLoader.java:195)

    at org.switchyard.transform.TransformerRegistryLoader.registerTransformers(TransformerRegistryLoader.java:92)

    at org.switchyard.deploy.internal.Deployment.registerTransformers(Deployment.java:251)

    at org.switchyard.deploy.internal.Deployment.doInit(Deployment.java:113)

    at org.switchyard.deploy.internal.AbstractDeployment.init(AbstractDeployment.java:142)

    at org.switchyard.as7.extension.deployment.SwitchYardDeployment.start(SwitchYardDeployment.java:103)

    at org.switchyard.as7.extension.services.SwitchYardService.start(SwitchYardService.java:78)

    ... 5 more

Not sure what I'm doing wrong here. Thanks for your patience so far and for any additional insight you can provide!

[dward]

I have to admit that as a newcomer to BPMN2, that is still a little vague to me. Specifically, I currently have no idea what the "right event" in my process should be and how to connect it to the SwitchYard Task (I mean, it can't just float freely in space, can it?). A pointer to some relevant documentation or a code sample would be appreciated, currently I am not sure where to start looking.

You might want to study up on BPMN2 and jBPM to learn more about events. They are not the most obvious concept, for certain.

Actually, yes, they can "float freely in space" in your BPMN2 process flow.  Just like a start event, a signaled event doesn't need a node preceding it to flow to it.  Obviously, they need something after it in order for something useful to happen, though.  This is why many people design their error flows starting with an event.  That way, they can re-use one error-handling flow from multiple places withing their main process flow.  This is opposed to having to do a multiple gateway splits in a process, just to check a success/failure outcome in all those places.

This thread has been a bit of a "kick in the pants" for me, as it is now obvious that I should add a "Fault Handling" section in the SwitchYard BPM docs, so thank you.   In the meantime, I do have a couple BPMN2 processes you can look at, from our JUnit test suite.  I strongly suggest you install the BPMN2 modeler into eclipse when you review these files, per the instructions here.

Example using an event / signal id to trigger an error flow:

BPMWorkTests-FaultEventProcess.bpmn

Example using a gateway / split to handle an error:

BPMWorkTests-FaultResultProcess.bpmn

The JUnit test that runs them both:

BPMWorkTests.java

In my case, I didn't specify a custom payload - it's all just integers. Do you happen to know if I still need to define a transformer? I tried implementing one, but I am unsure of the typing involved, and I don't get any feedback from the engine since I didn't manage to implement part 1 of your suggestions. I suppose attaching a debugger is only an option if your IDE is already set up for SwitchYard development?

Well, if the missing transform is from java.lang.Integer to org.w3.dom.Node (which is what I suspsect), then yes, you will still need to define a transformer.

If you update your maven project to use SwitchYard 0.8.0-SNAPSHOT, then the stack trace should now be logged at ERROR level, so you can be informed of the typing that is necessary to transform from/to.

IF you need to stick with 0.7.0-Final, then debugging is still an option.  To do this:

1. Eclipse: Preferences / Maven / [x] Download Artifact Sources
2. Eclipse: Debug Configurations / Remote Java Application / Connection Properties / Host=localhost , Port: 1044
3. JBoss AS7: edit bin/standalone.conf , add these to your JAVA_OPTS:
   • -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044
4. Start up JBoss and attach to it with Eclipse
5. Set a break point in SwitchYardServiceWorkItemHandler.java, where it gets the fault., and debug the cause, which will tell you the missing transform.

I'm also struggling setting up a JAXB transformer, I tried adding a simple transformation from the response type of my SOAP call ("{http://imexmock.esb.swr.ard.de/}testResponse") to "java:int", but it fails on deployment:

...

Not sure what I'm doing wrong here.

I will admit I'm not an expert on the jaxb transformation capabilities of SwitchYard.  Maybe someone else on my team can chime in here to help with that part.  I've only ever used (the more manual) java transforms.  An example of this is here.  You can see that it's much more code, and much less elegant, than the jaxb mechanism.

Thanks for your patience so far and for any additional insight you can provide!

You're welcome.  Hope this latest response of mine helps get you further along.

[dward]

This thread has been a bit of a "kick in the pants" for me, as it is now obvious that I should add a "Fault Handling" section in the SwitchYard BPM docs, so thank you.

FYI, I've added documentation to the bottom of the BPM Services page to better explain the Fault Handling configuration options of the SwitchYardServiceWorkItemHandler.

[ubm]

... using the fault handler works fine :-)

Now, I'll try to realize the right transformer ...

[andi.scharfstein]

David,

many thanks for your generous assistance in this matter. As for the BPMN event handling, I acknowledge that my knowledge in this area is sorely lacking, and I am working on rectifying that. The examples you supplied will be a huge help in that process, I'm sure. I still have one or two questions about the SwitchYard side of things, though:

1. You strongly recommended installing the Eclipse BPMN 2.0 Modeller, which of course I already did a while ago. The instructions you linked state that you have to use release 0.1.0, which is no longer up to date. I'd like to inquire about the status of your efforts to integrate with the current version. I vaguely recollect seeing a JIRA task about using standard tasks instead of a custom SwitchYard service task implementation, is this correct? Are you going to implement it so we can switch to a newer version of the modeller plugin, or are there more pressing things to be done first?

2. If you update your maven project to use SwitchYard 0.8.0-SNAPSHOT, then the stack trace should now be logged at ERROR level, so you can be informed of the typing that is necessary to transform from/to.

   I don't quite see how this is possible if you are referring to the dependency artifacts handled by Maven for the project. I updated those dependencies, but saw no change in the logging output which makes perfect sense from my point of view, as I am still deploying into a 0.7.0-FINAL runtime which isn't affected by the maven dependencies (or is it? Maybe I'm just confused). When debugging, I see the updated 0.8.0-SNAPSHOT source code, but the execution is jumping to nonsensical lines in there which leads me to believe that it's out of sync with regard to the actual runtime (which, again, seems to make sense to me). Am I misunderstanding something?

Thanks again!