How do I return BPM SIGNAL_EVENT Result output to the SOAP client?

[dustin.barlow]

Consider the following Switchyard 1.0 project diagram:

The "ServiceProcessComponent" is a BPM Implementation whose interfaces is as follows:

public interface ServiceProcess {
    Payload submit(Payload payload);
    Payload signalTest1(Payload payload);
}

The ServiceProcess interface is promoted and a SOAP binding is used.

The BPM portion of the switchyard.xml:

<bpm:implementation.bpm persistent="false" processId="ServiceProcess">
    <bpm:manifest>
        <bpm:resources>
            <bpm:resource location="ServiceProcessComponent.bpmn" type="BPMN2"/>
        </bpm:resources>
    </bpm:manifest>
    <bpm:operations>
        <bpm:operation name="submit" type="START_PROCESS">
            <bpm:inputs>
                <bpm:input from="message.content" to="Parameter"/>
            </bpm:inputs>
            <bpm:outputs>
                <bpm:output from="Result" to="message.content"/>
            </bpm:outputs>
            </bpm:operation>
            <bpm:operation eventId="Signal_1" name="signalTest1" type="SIGNAL_EVENT">
            <bpm:inputs>
                <bpm:input from="message.content" to="Parameter"/>
            </bpm:inputs>
            <bpm:outputs>
                <bpm:output from="Result" to="message.content"/>
            </bpm:outputs>
        </bpm:operation>
    </bpm:operations>
</bpm:implementation.bpm>

The BPM Diagram for the ServiceProcessComponent looks like this:

When the "submit" process is invoked via the SOAP client, the BPM  "ServiceOne Task" fires and calls the "ServiceOneBean".   The "ServiceOneBean" receives a Payload object and then returns a new Payload object that gets asynchronously marshaled by Switchyard back to the calling SOAP client in the SOAP response.  The BPM process flow then goes into a Converging gateway pausing the process flow until a signal is received.

The SIGNAL_EVENT is then triggered by the SOAP client by calling the "signalTest1" operation.  The BPM "ServiceTwo Task" is then triggered and receives a Payload object and then returns a new Payload result.  The BPM process moves on through the Converging gateway into the final "ProcessCompleteTask" which simply logs a message.  The BPM process then ends.

The SOAP client receives an HTML error page.  In the server log I see a SOAP error that states that the result Payload object cannot be null.

As shown in the above Switchyard XML, I've mapped the "Result" to the "message.content".

I then confirmed that I have mapped the output of the "ServiceTwo Task" to ServiceProcess/Result.

I then go into the BPM diagram to see if I can map the output of the signal to the ServiceProcess/Result target.  All I see is that I can map the Incoming Signal Data.

Is it possible and how do I configure Switchward to return some sort of an acknowledgement/payload back to the SOAP client when the client is calling a method that invokes a BPM SIGNAL_EVENT?

[dward]

On the SwitchYard side, you would configure outputs for that SIGNAL_EVENT operation just as you would any other operation.  However, obviously you would need to have a process-level variable mapped in the bpmn to return...

I'm going to email the maintainer of the Eclipse BPMN tooling and have him take a look at this forum thread so he can respond.  I would have expected there to be a "Map Outgoing Signal Data To:" on that last screenshot of yours too.

[dward]

Sorry I responded too quickly. It's unnecessary to have any kind of outgoing signal data from that event node. It's your ServiceTwo task (after the event) that has to have the output mapped back into the process.  And it looks like you've done that.  In short, it looks like what you have "should" work.

Can you please attach your project so that I may debug it?

[dustin.barlow]

Attached the project.

[dustin.barlow]

David, just checking in to see if you were able to download the project and try it out?

[dward]

Dustin,

I found the problem.  It is a bug in SwitchYard.  Your project itself is fine.  I have already created a jira and submitted a pull request with the fix.  This should be available in SwitchYard 2.0 / Fuse Service Works 6.1.

[SWITCHYARD-1964] bpm signal_event returns null when completing existing process - JBoss Issue Tracker

Thanks for the reproducer app; that was very helpful.

Best,

David

[dustin.barlow]

Thank you for looking into it.  Sorry to hear that it is a bug since I was planning to use this pattern in a new project I'm working on.

Is there any workaround that I could do aside from just returning null instead of Payload?

Also, my plan it to have multiple signals modeled the same way within a single process, so does this bug only occur if the signal event results in the BPM process completing?

I would also be interested to know if in the case that I have more than one of these signals (I am attempting to orchestrate multiple async service calls to outside servers), is the payload returned to the signalling client the payload of the BPM Task that is fired as a result of that signal?  In other words, if I have two or more of these converging gateways within a single process, I would want the return payload to the client to be whatever the final task is before it hits another converging gateway or if it the last task in the BPM process.

[dward]

No workaround I can think of off-hand. I do apologize for this. I don't know how this slipped past. But there's a JUnit test in there now with the fix, so it shouldn't get missed again.

Yes, this bug only occurs when the signal event results in the process instance completing.  Other signal events should be fine.  The problem is that the in-memory process instance "goes away" after the signal event occurs (since the process completed), but the code was trying to fetch the process instance for the return variables after that.  What the fix does is get a handle on the process instance first, then signal the event, then get the variables from the already in-hand process instance.  I hope that makes sense?

I don't think I follow your last paragraph.  But the return payload to the client is not based on which task finished last.  It is based on the your mapping of process-level (process instance) variable at the bpm component level.  The only way this would be based on "which task finished last" is if each of the tasks overwrites that process instance variable, in which case, the last one wins.

[dustin.barlow]

Yes, what you said in terms of the process variable's life-cycle and the fix makes sense.

You also answered my not so clear question about which BPM task's output actually gets returned in the event there are more than one tasks executed after the signal event is received or if there are multiple signals defined in the process that all fire different tasks.  I had guessed that it should be the last task's version of the output mapping if the tasks are all sharing the same global process variable/message.  I just wanted to confirm.

I also assume that the original Parameter passed in on the process start is also available to downstream tasks that are triggered later on by a signal event?  Or do I need to map the inbound Parameter to a global variable so it's retained for other tasks to reference?

[dward]

The only way an original input parameter is available downstream in the process is if it is mapped to (and thus stored as) a process instance variable in the bpmn. By default, SwitchYard will give this to jBPM as "Parameter", but the name can be overridden. And of course you have to define it in the bpmn file as a process-scoped variable.

[dustin.barlow]

I actually found a workaround.

I added an Intermediate Timer Event that pauses for 5 seconds right before the End process.  Seems to work in getting back the final signal payload before the process exits.  It's certainly a hack, but it at least lets me move forward with the basic pattern.

[dward]

Won't be necessary after the fix, bug glad you have an interim workaround.