Custom Event Tasks (Wait States)?

[ryanberg1]

It appears that in this release, the only task that can be created with a custom ActivityBehavior is the serviceTask.  How would we go about creating custom EventActivityBehaviors (for example a custom wait state which waits for specific event data)?  I've tried creating a custom ActivityBehavior that implements EventActivityBehavior and having it back a serviceTask, but this generates a class cast exception upon the sending of the event because the ServiceInvocationActivityBehaviour class that is instantiated does not implement EventActivityBehaviour.

Please advise.

Thank you!
-Ryan

[jbarrez]

Good point. The current release indeed checks if it's an ActivityBehavior, but there is no reason why it shouldn't be an EventActivityBehavior.

I'll add a Jira to fix it for the next release. Thanks for pointing this out!

[ryanberg1]

Just as a quick follow up..  Is it your intention that any/all custom task activities should be implemented as a service task? Or will there be support in the future for extending other task activity types such as ReceiveTaskActivity, UserTaskActivity, etc…

[jeff1]

hi, ryan,
similar to jbpm4-pvm, activiti pvm is very easy to create whatever custom task activities programmatically, but I don't know how to plug in with activiti, since the activiti-bpmn parsing mechanism is not yet pluggable(maybe it is so several weeks ago, but I'm not sure now); on the other hand, I think this is the extension policy that whether tom or joram allow us to do so, if they nodded approval, it's easy

[ryanberg1]

Thanks Jeff,

Yes I see that if I were to build my process flows programatically it is very easy to plug in custom behaviors that extend/implement the base behavior classes/interfaces.  My question was really more about what you touched on, and that is whether or not we will be able to specify a behavior implementation for other tasks in the BPMN xml definition.

-Ryan

[jeff1]

hi, ryan,
bpmn2 has defined its own execution semantics, so for each activity type, the behavior is specified. But of cause bpmn2 is so huge and aimed to fit most scenarios, so it is more 'abstract' than 'concrete', also there will inevitably be some requirements can not be satisfied exist.
hence, we need customized, maybe a newly defined task type, or extend the existed task type.
btw, what does bpmn2:serviceTask do is simply calling an operation, whether the endpoint reference of the operation is java-binded or webservice-binded, both the callees are something outside the bpmn2 process but not something extended bpmn2. a custom wait state which waits for specific event data looks more like a bpmn2:receiveTask but not a service task.
I don't know whether I have misunderstood what you mean or not.