And some how some one triggered the signal1 again so I want to block that signal1 from getting triggered because it is already waiting for signal2.
What do you mean with “block”, for it to be ignored, processed after signal 2, processed in some order based on business logic, for example once s1 is received you want to ignore any other s1 for the remainder of the workflow execution?
If you are looking at signal ordering logic we went over this in worksop here. Should be able to extend that lock sample to do any custom ordering logic if you need.
My code flow is like I am having a jms message receiver from there I am signaling to my workflow based on different condition to start further execution.
And my entry point for signalling is that jms receiver only. And it can trigger same signal based on different values and then internally workflow will be having multiple waiting condition based on signals.
Let say on jms receiver I have received a message with condition x and I had triggered a signal (signal1) to workflow based on condition x to get started for execution now in the same workflow execution after signal1 completion it is waiting for another signal(signal2)
till my workflow is waiting for signal2 I wanted that till the signal2 is not completed with its execution I should not accept any signals (say signal3) and I am triggering signals from my jms receiver so how my jms receiver will know that some signalling condition is there which is waiting for its completion and if my jms receiver receives a message with condition y it should not trigger that untill signal2 is in execution state.
Some how I wanted to intimate my jms receiver that hey workflow is waiting for some external signal to get completed if it is in waiting state we should not trigger the next signal. After completion my receiver will get to know that signal has completed its execution we can send next signal.
Could you please help with this scenario in a detailed manner.
There is no way to reject a signal. It is always accepted. The workflow can process them in any order it desires after that. This works for the majority of situations without any problem.
We are working on the synchronous update feature. It would be like a query, but it will be able to change the workflow state. It also would support rejecting updates without writing them to the history.