JBPM process instance signal in ESB 4.5

[archi3315]

Hi, I was using jboss ESB 4.4 -I was publishing a service to my clients that does a signal with the BpmProcessor command "SignalCommand". This command was removed in the new version of ESB; I was looking at the sample bpm _orchestation3 which does the signal with groovy script, but this has not a good performance. I need a faster way to do it because I have a lot of traffic and concurrent clients which do signal to different instances of the same process at the same time.

Thanks in advance,
archi

[camunda]

There were already some discussions about the SignalCommand making sense or not. The ESB guys see it as "the ESB should be responsible of signalling by the JbpmCallback to enable the correlation to always work correctly".

I think, that having the SignalCommand makes sense, even if you have to take care of correlation yourself.

Maybe you can describe your use case to add arguments for the re-inclusion of the SignalCommand :-)

[camunda]

Workaround couldalso be to extend the BpmProcessor or to add your own action to signal a process instance...

[archi3315]

Thank you very much.
Yes, I have no choice, I have to develop my SignalCommand. The new version of Jboss ESB has a lot of good things, but I think that the SignalCommand is really necessary. A lot of business processes requires to wait until an external program finish to work. In my case I interact with an SMSC (sms central) to send a text message to a cellphone. When the user responses that message the SMSC notifies me (that's the signal) and I have to do the next step in the process. So I think SignalCommand is very useful and necessary.

[ericcart]

Please, I need more specific information about "the ESB should be responsible of signalling"... How ?

If there's no direct action to signal .... Should I write all actions with the associated signals ? Calling a helper like:

 public static void SignalExecute(Long tokenId, String transition)
 {
 SignalCommand command = new SignalCommand();
 command.setTokenId(tokenId);
 if (null!=transition)
 command.setTransitionName(transition);
 CommandExecutor commandExecutor = CommandExecutor.getInstance();
 commandExecutor.getJbpmCommandService().execute(command);

 }

I think It's easier to write my Action and after the execution call a Signal Action. Which is the problem ? Speed and efficiency ?


Thanks,
Eric

[kconner]

The SignalCommand was never safe to use as it blindly continued the task from which ever location it happened to be in. Sending a response to the BpmProcessor will signal the process and handle it in a safe manner.

Is there any reason you cannot have this driven by the process/BpmProcessor? What is it about your application that means this will not work?

[camunda]

The SignalCommand was never safe to use as it blindly continued the task from which ever location it happened to be in.

You can set an "expectedState" on the SignalCommand, which solves this problem.

The problem with the BpmProcessor currently is, that it doesn't easily work if not all components play correctly with it. And a sophisticated correlation framework for all use cases is still missing in the ESB.

Image: Calling async system which somehow sends back JMS message with ONLY the tokenId. You cannot change that system to include any other information. What to do on the ESB instead of sending a signal to jbpm with that tokenId?

I was in quite some projects (even without ESB) using SignalCommands a lot and never faced serious problems (basically avoided by the "expectedState").

Cheers
Bernd

[camunda]

P.S: Maybe we should create an example/prototype for the use case we are discussing so we can move the discussion to a well-grounded floor backed on code?

I would do that, but unfortunately I am quite busy till next week and then I am on vacation (without laptop ;-))...

[kconner]

"camunda" wrote:
You can set an "expectedState" on the SignalCommand, which solves this problem.

No, it doesn't. This was discussed on the other thread.

"camunda" wrote:
The problem with the BpmProcessor currently is, that it doesn't easily work if not all components play correctly with it.

If you mean it doesn't work with components that do not provide all the information then yes, that would be a fair comment. But then not providing all the information means you are not guaranteed to be safe.

"camunda" wrote:
And a sophisticated correlation framework for all use cases is still missing in the ESB.

We are certainly in need of a correlation framework for the EPRs, so that you can send out a single token representing each EPR.

"camunda" wrote:
Image: Calling async system which somehow sends back JMS message with ONLY the tokenId. You cannot change that system to include any other information. What to do on the ESB instead of sending a signal to jbpm with that tokenId?

If you work on that basis then you have no guarantees as to what is being signalled. The token could be anywhere, having followed any number of transitions.

"camunda" wrote:
I was in quite some projects (even without ESB) using SignalCommands a lot and never faced serious problems (basically avoided by the "expectedState").

I have been in a number of projects where basic concurrency issues were ignored, but I would still not recommend it.

At the end of the day there are a couple of pieces of information that need to be checked for a token before a signal can be safely undertaken in all circumstances.

- You need to check the node and make sure it is where expected
- You need to have some form of iteration count to handle loops

Without these you have no guarantees as to the state of the process nor what effect the signal will have on it.

Kev

[camunda]

Kevin wrote:

If you mean it doesn't work with components that do not provide all the information then yes, that would be a fair comment. But then not providing all the information means you are not guaranteed to be safe.

yeah, but normally this is reality, isn't it?

With the looping you have a point, but I haven't faced too much looping problems in business processes that far yet.

Thing is, what to do if you only have the tokenId and need to signal, aware that it is "not safe"? I start seeing people coding there own SignalAction for the ESB, and that's not a very nice option...

[kconner]

But this is where the correlation stuff comes in, provide a token (in the abstract, not jBPM, sense) which can then represent the EPR needed to signal the process again.

You could then pass this to your external service and retrieve the EPR when a response is returned.

As for loops, well that will obviously depend on the process but it is something that I have seen often.