task-assign event fired before task-create event

[cfau]

Which is the correct event order?

I need the task-create event were fired before the task-assign event, so the Task Assign Action Handler could view the Task Create Action Handlers efects.

Is this thinking correct?

The TaskMgmtInstance.createTaskInstance() performs:

taskInstance.assign(executionContext);

before:

taskInstance.create(executionContext);

Is that the correct order?, Could a task be assigned before it was created?

[icyjamie]

Actually, it is implemented vice-versa (see sourcecode) and I also think create should occur before assign, otherwise you run into some causality-problem: How could you assign someone to something if it is not been notified to be created?

[kukeltje]

you could see it the other way around ;-). IF some task is created, you at least know who to create it for. What is the use of a task that is not assigned... just joking. I agree with you

[icyjamie]

Well, the assigned could be deferred. (Resource patterns, you know :-))

[cfau]

Thanks folks.

I already changed the code of TaskMgmtInstance.createTaskInstance() to do the create before the assign to have "the hoped" semantics.

carlos

[icyjamie]

This is still implemented in 3.1b2. Should I report this as a bug?

James

[kukeltje]

Yes, why not. Seems reasonable to me. If Tom disagrees he'll let you know there. But your 'could be deferred' remark made me think. How should this be used? allowing an empty string as an actorID?

[tom.baeyens]

i noticed this today myself and a jira issue is already created for it.

regards, tom.

[icyjamie]

Look at the resource patterns (on www.workflowpatterns.com .

Initially a work item comes into existence in the created state. This indicates that
the preconditions required for its enablement have been satisfied and it is capable of
being executed. At this point however, the work item has not be allocated to a
resource for execution and there are a number of possible paths through these states for individual work items.

It is not always possible to know the right actor from the beginning (even not the right pool).
Or it could be so computing-intensive that you let another thread or process handle the assignments async-like. This process could even "listen" for the created event, and queue it for pooling/assignment.
"created" should mean: the basic stuff is there, if you want to intervene, go ahead. Maybe it should have another wording in the case of jBpm, like "ready", but then we lack the "created" event, and some implementations will really need it.

[icyjamie]

damn, I meant http://www.workflowpatterns.com