Starting process from a signal : multiple deployments

[magnayn]

Hi!

I have a process definition, which is using the new signal event definition to trigger (5.15.1) the creation of a process instance. I.E:

        <startEvent id="startevent1" name="Start">
            <signalEventDefinition id="start1" signalRef="theSignal"></signalEventDefinition>
        </startEvent>

This is all working lovely. I fire a signal into the engine, a process gets constructed. Boom.

My spring application is configured with this, and other bpmn xml files,  as a deployment resource.

When any of the resources are changed, they are all re-deployed. This means that a second version of my process definition (above) may get deployed.

Where I am creating processes in code, this isn't a problem - it automatically gets the latest Process Definition to use.

However, since both versions of my 'start on a signal process' seem to be active (responding to signals), this means that *2* processes get created per signal - which I don't want (I.E: one for the old ProcessDefinition, one for the new ProcessDefinition, etc). Every redeploy increases this number by 1.

So my question is: What should I do to prevent this? Is there some mechanism on re-deploy to say "only ever create process instances from the very latest versions of process definitions"? Or should I be intercepting somewhere something that controls which Process Instances get created?

[ekolesnikov]

This sounds quite logical because you may want to start multiple processes based on a single event - this is quite handy in service orchestration where external systems can simply report to the workflow engine and return to doing their business.

In your case, you can probably version your events to prevent multiple ones from being executed, or rename event names on old versions.

[trademak]

This is an issue, since a signal start event should only trigger the latest version of a process definition. We'll look into it.

Best regards,

[magnayn]

Thanks - I did some digging myself and I also think it's a bug. I raised a ticket for it
http://jira.codehaus.org/browse/ACT-1978

It looks to me like a relatively simple fix.