[dward]

Uwe, there were other things I found wrong in Andi's example which could cause your issue as well.  Please see my latest instructions to him, and check out the sample application I attached (marked "GOOD"). And apply the same fixes to your application.  If you still have a problem, please attach your entire project so I can properly debug.  Thanks.

[andi.scharfstein]

David,

it works! Awesome, thank you so much

In the end, you were right about the mapping causing the issue. I have tried (and succeeded!) to reproduce your results and have found that I needed to map both contentInput and contentOutput for the whole process to work. What's more, the process variables have to have these exact names, although I really don't see why this should be the case (for the record, this was the error that put up the hardest resistance as I thought nothing of calling them contentIn and contentOut and did quite a bit of experimentation before I ran out of things to try other than renaming).

The interface definitions are irrelevant as long as you provide the methods you want to call (sorry about the confusion, I was using "test()" in both cases, "start()" remained as an artefact of earlier experiments).

I also had to install a newer snapshot of the 0.8 runtime than I had been using, but it works with the current version.

This has been quite a wild ride, I'm really impressed with your efforts and that you stayed on board for the whole time - I think if we ever meet on a conference or something, I owe you a beverage of your choice . Let's hope that future questions I will be asking can be dealt with using less resources...

Ah, one more thing:

I had to change your switchyard.xml from this: <action type="START_PROCESS"/> to this: <action operation="start" type="START_PROCESS"/>. 
Without an operation, it won't map to anything! (Well, it will. It will map to "default", but that's not what's in your interface.)

I think this error wasn't in my original project, because the Java interface only exported one method (the "test()" method), so it defaulted to that operation. If I am not mistaken, you upped the complexity yourself when you added the start() method to that interface, because suddenly it didn't know what to default to anymore. Not that it matters now

Cheers

Andi

[dward]

The way I thought it was supposed to work was we start the process with "start", then the task handler inside the process calls the remote web service's "test" operation.  So, yeah, if this wasn't the intent, I did indeed up the complexity.  Cool to see that it still works even with that extra complexity, though...

The whole "contentInput" and "contentOutput" naming rigidity is something that happened between 0.6 and 0.7, however I am most likely going to re-introduce configuration attributes that allow these names to be overridden.  When the whole BPM and Rules configuration mass-change occurred, I didn't think we'd need those anymore, but as it turns out, we probably do.

Glad it's all working for you now.  Thanks for your patience throught his process. Go community!

[ubm]

David, sorry for my late feedback. Now I used Andis information to study this switchyard issue. It's not exactly my concern, but it was still very helpfull. Thanks again for your help.

Uwe