[jBPM Development] - is async execution considered inactive?
by mwohlf
Hi guys,
I have a (pretty hackish) process definition with custom task activities implemented as java classes, these activities basically just create a default task, the relevant part of the process definition looks like this:
| <custom class="net.package.CustomTaskActivity" name="custom01">
| <on continue="async" event="forward">
| <mail class="net.package.CustomMailProducer" >
| <field name="tmplName"><string value="templatename"/></field>
| </mail>
| </on>
|
| <transition name="forward" to="custom01"/>
| <transition name="toCreateBusinessKey" to="custom02"/>
| </custom>
|
the forward transition is supposed to be a loop just creating the same task activity for a different user, this is handled in a custom task implementation.
The Problem is when i take the "forward" transition I get an exception telling me the Execution is not active:
| org.jbpm.api.JbpmException: execution[ChangeRequest.15] is not active: async
| at org.jbpm.pvm.internal.model.ExecutionImpl.checkActive(ExecutionImpl.java:999)
| at org.jbpm.pvm.internal.model.ExecutionImpl.take(ExecutionImpl.java:447)
| at org.jbpm.jpdl.internal.activity.TaskActivity.signal(TaskActivity.java:140)
I checked the code and according to my understanding it all boils down to the implementation of the ScopedInstanceImpl.isActive() method:
public boolean isActive() {
| return Execution.STATE_ACTIVE_ROOT.equals(state)
| || Execution.STATE_ACTIVE_CONCURRENT.equals(state);
| }
|
My question is: Why isn't there a check for Execution.STATE_ASYNC? Is an async continuation considered to be not active?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4259092#4259092
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4259092
16 years
[jBPM Development] - Re: Extension of schema and Task-objects
by kukeltje
This is indeed what I used something similar for in jBPM 3. It's not that difficult since you can retrieve the processdefinition in xml as a resource from the deployment and use xpath on it for retrieving the additional attributes.
What I did (amongs other things) was adding an attribute to a task with the average duration (different from the duedate). Without extending the database, I was able to use this.
Otoh, in jBPM 4 it is much easier to extend an activity then it was in jBPM 3 since there is no database model to be extended. Just extend the activity and change the activities xml config file and you are done. The two solutions can coexist without any problem, although I think the activities config file was more for new node types than extending existing ones.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258982#4258982
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258982
16 years
[jBPM Development] - Re: making references to usercode more consistent in jpdl
by kukeltje
Some small remarks:
- I agree with your latest two posts
- What is the advantage of having a method attribute with a class on decision, condition etc... There should be well defined interfaces like execute and decide that need to return the correct type. Adding methods is not needed there imo.
- With expr I'd ditch the method completely in favour of the normal EL notations for it.
- <decision handler-ref="xxx" is exactly the same as <decision ...><handler expr="#{xxx}" would not be my choice. I'd give the handler a name and have the handler-ref point to that name. Unless that is what you mean if xxx is the name of the handler in the jbpm context. Then what you state is what I mean as well.
- What is the '' element?
- The ref on condition should also be handler-ref like on decision, or the other way around, just be concise
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258980#4258980
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258980
16 years
Status of history
by Ronald van Kuijk
Guys,
A lot of questions about the history come up in the forum. It just gives
many users the feeling that it is incomplete. Now that is true in a kind
of way. Not all relevant things are put in the history, are accessible
and more.
https://jira.jboss.org/jira/sr/jira.issueviews:searchrequest-printable/te...
One user even stated that since he was new to BPM and did not have all
the knowledge, it might "not be as important" as he thought it was.
Some of the issues are targeted at 4.3, one to 4.2 and most are not
targeted. Might be interesting to have someone write an (short) blog
entry about the status, why, how, when etc... of the history.
Ronald
16 years
[jBPM Development] - Re: Extension of schema and Task-objects
by sebastian.s
Hello Ronald,
thanks for your answer.
"Ronald" wrote :
| I personally would also opt for a nice api to retrieve additional attributes on existing elements (activities)
|
I am especially interested in this, too: storing information with tasks and retrieving them later on so I would love to see something like this. IHMO opinion it's a common use case that you deal with a task list in your own application or client and you are in need of additional information what the task is about and how to represent and deal with it in your program. The possibility of having custom attributes in a convient way without the need of extending or implementing would make a thing like this a lot more easier.
For example: You could define use-case-specific task types because you know that in your processes you got 3 different kinds of users tasks, for example. So you could always determine the type of a task to display a proper form to input data or you react in a different way in your application.
I hope you get the idea of my example. I'd love to hear what you think about my thought.
Cheers!
Sebastian
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258938#4258938
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258938
16 years
[jBPM Development] - Re: making references to usercode more consistent in jpdl
by tom.baeyens＠jboss.com
Guys, a question: Does it make sense to combine an expr with injections when specifying user code ?
imo it does not. if you specify an event-listener or custom activity behaviour. if you obtain the user code object by resolving an expression, i think it would be highly unlikely for users to want to inject things in it after resolution. since it is resolved as an expression, it doesn't live in the process or the deployment scope. and hence the object lives in another scope like the process instance, process engine, some web beans context maybe. if your object is resolved from these other contexts, it would seem very strange if the process execution would inject values in it.
so my conclusion is that we'll have more robust software if we explicitely remove injections in case an expr attribute is used to refer to user code.
wdyt ?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258928#4258928
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258928
16 years
