[JBoss jBPM] - Re: forking tasks
by kukeltje
Ok, basic trial without Seam and no special transaction stuff works
| package net.vankuijk.jbpm;
|
| import java.util.ArrayList;
| import java.util.Arrays;
| import java.util.HashSet;
| import java.util.Iterator;
| import java.util.List;
| import java.util.Set;
|
| import org.apache.commons.logging.Log;
| import org.apache.commons.logging.LogFactory;
| import org.jbpm.JbpmContext;
| import org.jbpm.db.AbstractDbTestCase;
| import org.jbpm.graph.def.ProcessDefinition;
| import org.jbpm.graph.exe.ExecutionContext;
| import org.jbpm.graph.exe.ProcessInstance;
| import org.jbpm.taskmgmt.def.AssignmentHandler;
| import org.jbpm.taskmgmt.exe.Assignable;
| import org.jbpm.taskmgmt.exe.TaskAssignmentDbTest;
| import org.jbpm.taskmgmt.exe.TaskInstance;
| import org.jbpm.taskmgmt.exe.TaskMgmtInstance;
|
| import junit.framework.TestCase;
|
| public class ForkedTaskTest extends AbstractDbTestCase {
| void deployProcessDefinition(String xml) {
| ProcessDefinition processDefinition = ProcessDefinition
| .parseXmlString(xml);
| jbpmContext.deployProcessDefinition(processDefinition);
| newTransaction();
| }
|
| public void testStartStateSwimlaneInitialization() {
| deployProcessDefinition("<process-definition name='testForkedTasks'>"
| + " <swimlane name='gertsGroupSwimlane'>"
| + " <assignment pooled-actors='gertsGroup' />"
| + " </swimlane>"
| + " <start-state>"
| + " <transition name='to_0' to='0' />"
| + " </start-state>"
| + " <task-node name='0'>"
| + " <task name='task 0' swimlane='gertsGroupSwimlane' />"
| + " <transition name='to_fork1' to='fork1' />"
| + " </task-node>"
| + " <fork name='fork1'>"
| + " <transition name='to_11' to='11' />"
| + " <transition name='to_21' to='21' />"
| + " </fork>"
| + " <task-node name='11'>"
| + " <task name='task 11' swimlane='gertsGroupSwimlane' />"
| + " <transition name='to_12' to='12' />"
| + " </task-node>"
| + " <task-node name='12'>"
| + " <task name='task 12' swimlane='gertsGroupSwimlane' />"
| + " <transition name='to_join' to='join1' />"
| + " </task-node>"
| + " <task-node name='21'>"
| + " <task name='task 21' swimlane='gertsGroupSwimlane' />"
| + " <transition name='to_join' to='join1' />"
| + " </task-node>"
| + " <join name='join1'>"
| + " <transition name='end' to='end' />"
| + " </join>"
| + " <end-state name='end' />"
| + "</process-definition>");
|
| ProcessInstance processInstance = jbpmContext.newProcessInstanceForUpdate("testForkedTasks");
| processInstance.signal();
|
| processInstance = saveAndReload(processInstance);
|
| ArrayList actorIDs = new ArrayList();
| actorIDs.add("gertsGroup");
|
| //assertNotNull(processInstance.getTaskMgmtInstance().getTaskInstances());
|
| List tasks = jbpmContext.getGroupTaskList(actorIDs);
| assertEquals(1, tasks.size());
| assertEquals(false, ((TaskInstance) tasks.get(0)).isStartTaskInstance());
| TaskInstance task0 = (TaskInstance) tasks.iterator().next();
| assertEquals("task 0", task0.getName());
| task0.end();
|
| processInstance = saveAndReload(processInstance);
|
| tasks = jbpmContext.getGroupTaskList(actorIDs);
| assertEquals(2, tasks.size());
| ArrayList taskNames = new ArrayList();
| taskNames.add(((TaskInstance) tasks.get(0)).getName());
| taskNames.add(((TaskInstance) tasks.get(1)).getName());
| assertTrue(taskNames.contains("task 11"));
| assertTrue(taskNames.contains("task 21"));
| assertFalse(taskNames.contains("task 12"));
|
| TaskInstance task11 = (TaskInstance) tasks.get(0); //gamble it is the first
| if (!task11.getName().equals("task 11")) {
| task11 = (TaskInstance) tasks.get(1); // ok, it's the second
| }
| task11.end();
|
| processInstance = saveAndReload(processInstance);
|
| tasks = jbpmContext.getGroupTaskList(actorIDs);
| assertEquals(2, tasks.size());
| taskNames = new ArrayList();
| taskNames.add(((TaskInstance) tasks.get(0)).getName());
| taskNames.add(((TaskInstance) tasks.get(1)).getName());
| assertFalse(taskNames.contains("task 11")); //ended
| assertTrue(taskNames.contains("task 21"));
| assertTrue(taskNames.contains("task 12"));
| }
|
| private static final Log log = LogFactory
| .getLog(ForkedTaskTest.class);
|
| }
|
So it I have no clue what is going wrong in your case. Transactions? What if you try to retrieve the tasklist by using the jBPM api directly?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175927#4175927
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175927
17 years, 6 months
[JBoss jBPM] - Re: forking tasks
by kukeltje
hmmm... it should work as expected. No reason why task11 and task21 should not be visible at the same time. What could be the case is that you run into 'caching'. Meaning that the tasklist is loaded when the transition to one task is taken from the fork but not the otherone yet. Refreshing this could clear things up. But if this is the case then I'd expect the first task after the first transition from the fork to be always visible, not randomly one or the other (unless it is non-determenistic which transition is taken first.
Async=true should not be needed here.
I'll try to make a unittest without seam to see if I can reproduce. Or if you already have one that would be great. btw, how are transactions configured?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175895#4175895
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175895
17 years, 6 months
[JBoss jBPM] - forking tasks
by gnagy
Hi,
We have a workflow with a fork, and need to track tasks in each branch. A simplified use case follows:
Start
|
Task0
|
Fork
/ \
Task11 Task21
| |
Task12 |
\ /
Join
|
End
We have a seam ui that uses PooledTaskInstanceList. We use swim lanes too, however the fork is within a single swim lane, so i guess it should not matter.
So we have a page with the pooled task instances. Initially Task0 should be displayed. When the user completes it, 2 tasks should appear: Task11, Task21. Then, if the user completes e.g. Task11, then the following should appear: Task 12, Task21. Etc. The join should continue only if both branches are done.
However, currently only 1 task is shown from either branch, seemingly randomly, e.g. after Task0 the user has only the option to complete Task11, then Task12, then Task21, the end.
I read thought the docs and this forum, and the thing people seem to get hung upon is to perform things concurrently. But we don't really need that, just that the forked tasks appear multiple times in the pooled instance list (or some other list??), so the user can choose what to do next. I tried putting async=true on the fork to no avail.
Any suggestions?
thanks,
Greg
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175883#4175883
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175883
17 years, 6 months
[JBoss jBPM] - Re: Questions about doXslTransform
by dave9739
Hi all,
I found that when bpel process call doXslTransform then the server will produce the following output.
-------------------------------------------------------
2008-09-11 18:35:25,625 ERROR [org.jbpm.bpel.sublang.xpath.XPathExpressionEvaluator] expression evaluation failed
org.jaxen.UnresolvableException: No Such Function doXslTransform
at org.jaxen.SimpleFunctionContext.getFunction(SimpleFunctionContext.java:127)
at org.jaxen.ContextSupport.getFunction(ContextSupport.java:242)
at org.jaxen.Context.getFunction(Context.java:216)
at org.jaxen.expr.DefaultFunctionCallExpr.evaluate(DefaultFunctionCallExpr.java:172)
at org.jaxen.expr.DefaultXPathExpr.asList(DefaultXPathExpr.java:102)
at org.jaxen.BaseXPath.selectNodesForContext(BaseXPath.java:674)
at org.jaxen.BaseXPath.selectNodes(BaseXPath.java:213)
at org.jbpm.bpel.sublang.xpath.XPathExpressionEvaluator.evaluate(XPathExpressionEvaluator.java:80)
at org.jbpm.bpel.graph.basic.assign.FromExpression.extract(FromExpression.java:39)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
........
-------------------------------------------------------
Why jbpm-bpel does not support this function? As jbpm-bpel home page
said
"New services can be rapidly scripted as a function of other services instead of being developed from the ground up. Transforming output from one service into input to another service is made straightforward with XPath and XSLT.
".
However, jbpm-bpel cannot found that functions.
Does anyone know how to make this function works?
Many thanks.
dave
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175828#4175828
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175828
17 years, 6 months
[JBoss jBPM] - Re: Task timer and TaskInstance.dueDate field
by lblaauw
Hey,
Allthough it has been a while since the post below was posted, I am
facing a somewhat simular dilemma...
Basically I also have a timer asociated on a task node. Seems to be
working just fine, but when i get a tasklist the task duedate is not set
to the timer and I agree with the poster of the original message that
the task duedate really should be the Timer duedate wich was asociated
with this task to begin with. Obviously I could 'kludge' some db calls
to fill my own task objects, go through the jobs of the processInstance
and add the timers to my own custom task objects... Dont really want
to do that however since I feel the aproach below makes sense.
Any of the jBPM gurus like to comment ?
Greetings and thanks upfront for your time,
Leo de Blaauw
"p4elka" wrote : Hello
|
| JBPM allow to use timers with task instance, where timer has it's own due date not related to task due date. Timer's due date cannot be changed after timer is created (at least using API provided i.e SchedulerService or JobSession).
| Sometimes it is required to change due date for timer associated with task instance after task instance is created, and I haven't found standard way of doing this in JBPM.
|
| Here is how I think this could be implemented and I would be glad to get your opinion on this.
| I believe that link between task instance due date and task timer due date is missing in current JBPM implementation.
| Task due date should be ignored when timer is associated with task, and task instance should be initialized with timer due date.
| Upon change of task due date, we should look whether task has timer associated and if yes, timer instance should be found and updated with new due date value.
| Another approach could be not to change dates in existing timers but cancel timer and create new one using existing timer declaration.
|
| What do you think ?
|
| Thanks a lot !
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175787#4175787
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175787
17 years, 6 months