[jboss-user] [jBPM Users] - Re: workflow design about wait states
Thanks. Guess I'll look in to some other ways of doing this if possible. Might have to rethink things I feel. Thanks for the links though because they are useful to read up and gain some more knowledge of all these things. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255543#4255543 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255543 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
The aggregator is the join, but the 'concept' is non-blocking in the technical level. The thing is that when you start a process, it continues to the first node that is a waitstate and returns the control to the user then. In normal cases this is the jBPM fork. In your cases you'd want that to be the join, or even the 'leaving the join (e.g. the end node) In general it is an interesting question, although we should not try to duplicate things that are already in JBoss ESB. Since afaik a blocking scatterer/gatherer is available in the ESB. Implementing a custom join (look at the source of the JoinActivity.java (http://fisheye.jboss.org/browse/~raw,r=5490/JbpmSvn/jbpm4/trunk/modules/jpdl/src/main/java/org/jbpm/jpdl/internal/activity/JoinActivity.java) with e.g. a Thread.sleep(..) and removing the 'waitForSignal()' would make it blocking but could have other implications. So in the end, I think you implementing a Thread.sleep(..) for now is best I think. But do not forget to e.g. implement timer like in the link I gave you. For this specific use-case, jBPM does not provide what you need out of the box and in the end you have to do some similar things like you would with old-school multi-threading or using jms for this (http://www.ibm.com/developerworks/websphere/library/techarticles/0802_nasser/0802_nasser.html) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255519#4255519 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255519 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
"kukeltje" wrote : So you want a front-end thread to be blocking for (mostly) parallel executed jobs in the backend? Ar you sure? How long will these jobs be running? Is the process fully ended after these jobs like in your definition that was posted? | | So basically http://www.eaipatterns.com/BroadcastAggregate.html is what you want? | The jobs will be running for different periods of time but anywhere between 2 and 8 seconds. But there could be problems with comms etc and it could take longer or we could retry etc so the job would take longer in them circumstances. And yes... unfortunately we are sure! lol. But yes that pattern looks spot on. Is there an "Aggregator" of sorts in JBPM? Or would that be the Join node in a way. "kukeltje" wrote : | And I assume there are multiple return variables since having multiple parallel jobs working on the same variable is kind of dangerous. | Yes multiple return variables (each fork changing its "own" object) which is then read back at the front-end once its been updated. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255509#4255509 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255509 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
Shoot, forgot my last 'paste' of a link: See http://www.infoq.com/articles/boris-lublinsky-jboss-jbpm for a good explanation/example/... (although it is jBPM 3) but the idea is the same. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255501#4255501 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255501 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
So you want a front-end thread to be blocking for (mostly) parallel executed jobs in the backend? Ar you sure? How long will these jobs be running? Is the process fully ended after these jobs like in your definition that was posted? So basically http://www.eaipatterns.com/BroadcastAggregate.html is what you want? I'd look into using some kind of ajax polling to check if they are finished. And I assume there are multiple return variables since having multiple parallel jobs working on the same variable is kind of dangerous. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255500#4255500 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255500 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
Perhaps I'm missing something... This is an example of how my application will
start of the workflow. My comments in the code explain what I need to happen.
I'm using the same process definition previously posted.
I need the workflow to start and then this method to wait until a signal is
recieved from the workflow before reading the variable back out the
executionService.
| @WebMethod
| public String request() {
| try {
| InitialContext ctx = new InitialContext();
| this.processEngine =
(ProcessEngine)ctx.lookup("java:/ProcessEngine");
|
| ExecutionService execService = (ExecutionService)
| this.processEngine.get(ExecutionService.class);
|
| //kicks off workflow (1)
| ProcessInstance processInstance =
execService.startProcessInstanceByKey("process", variables);
|
| //between above the line and this line, we need a wait of some
sort but depending on how long
| //the workflow takes to complete...
|
| //should not be read until the workflow is complete
| myObject =
(MyObject)execService.getVariable(processInstance.getId(), "myObjectDetails");
|
|
| result = "My Object Details: " + myObject.getDetails();
|
| } catch (Exception e) {
| e.printStackTrace();
| }
|
| return result;
| }
|
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255466#4255466
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255466
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
Personal remark: Executing the nodes in a fork one after another did not pose any problem to me so I just do it this way, without the sleeps (basically just like your test is now) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255464#4255464 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255464 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
1: Correct 2: No, not necessarily. Yes, with manually firing the jobs and doing nothing in addtion you are right. But... You could always do one of two things if you really think it is important (keep in mind that a fork is 'parallel on the BUSINESS level', not by definition multi-threaded (although sometimes they are processed that way) - Start a new threads where you manually fire the jobs - Switch back to the jobExecutor in these case (preferred) with multiple threads (5 is the default afaik) But as you can read from Jorams post (and what I forgot to explain to you) is that in addition to this you have to make sure the unittest thread is not ended before both jobs are finished and the join is reached. This can be done by one long Thread.sleep(..), or by having a loop which tests if the execution is in a specific state or if it is ended and if not, sleep a short time and test again. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255462#4255462 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255462 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
I'd just like to confirm a few things. In my application my classes don't don't have to call waitForSignal and the join will still wait for all forks to come together before carrying on? And would I be correct in saying that it is therefore not possible to test async nodes in a fork realistically? i.e. There is no way to start two nodes at the same time in a unit test? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255457#4255457 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255457 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
Stupid me, I already mentioned firing the jobs manually (see the test), just forgot to disable the jobexecutorAAHH In your real process it is not needed to have the waitForSignal, if you do not want them to explicitly wait for a signal. The reason is that the JobExecutor is started then in a different way and not ended like it is when the unittest ends. So basically your test is correct, just disable the jobexecutor in the config. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255402#4255402 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255402 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
Thanks for that. That explains things perfectly :) So I can assume, when I deploy this in Jboss (i.e. not running from a junit test) then I won't have this problem as the Join will then ensure all activities are present before carrying on? As long as I have the waitForSignal in my classes as expected? I think with this approach things are very much clearer. Apologies for letting this run for 4 pages :) But thanks for your help and explanations to understand this. Not just have to find some time for that blog ;) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255333#4255333 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255333 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
The issue here is that you have multiple threads, the JUnit thread and the JobExecutor thread(s). The process is started in the JUnit thread until the custom activities in the fork are encountered. Jobs are created and put in the database. These jobs will be picked up by the JobExecutor threads somewhere in the future. However, the JUnit thread is still running and reaches the end of the method call. The JUnit framework will now kill its ThreadRunner, which also kills all spawned processes (Jobexecutor threads). The join activity can never ensure here that all threads have finished, for the simple reason that the join is potentially never even reached (if the JUnit thread finished quickly). If you want to control your unit test, you must disable the job executor in your config and fire the jobs yourself. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255329#4255329 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255329 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
For completion purposes I'll post my unittest and processdefinition again:
My unit test with changes suggested.
| package org.workflow.test.forum;
|
| import java.util.List;
| import java.util.Map;
|
| import org.jbpm.api.Execution;
| import org.jbpm.api.ProcessInstance;
| import org.jbpm.api.activity.ActivityBehaviour;
| import org.jbpm.api.activity.ActivityExecution;
| import org.jbpm.api.activity.ExternalActivityBehaviour;
| import org.jbpm.api.job.Job;
| import org.jbpm.test.JbpmTestCase;
|
| public class ProcessTest extends JbpmTestCase {
| String deploymentDbid;
|
| protected void setUp() throws Exception {
| super.setUp();
| deploymentDbid = repositoryService.createDeployment()
|
.addResourceFromClasspath("org/workflow/test/forum/process.jpdl.xml")
| .deploy();
| }
|
| protected void tearDown() throws Exception {
| repositoryService.deleteDeploymentCascade(deploymentDbid);
| super.tearDown();
| }
|
| public void testProcess() {
| ProcessInstance processInstance =
executionService.startProcessInstanceByKey("process");
| Execution executionInOne =
processInstance.findActiveExecutionIn("custom one");
| assertNotNull(executionInOne);
| processInstance =
executionService.signalExecutionById(executionInOne.getId());
|
| String processInstanceId = processInstance.getId();
|
| List jobs = managementService.createJobQuery()
| .processInstanceId(processInstanceId)
| .list();
|
| assertEquals("Job size doesn't equal 2",2, jobs.size());
|
| Job job = jobs.get(0);
|
| managementService.executeJob(job.getId());
|
| job = jobs.get(1);
|
| managementService.executeJob(job.getId());
|
| processInstance =
executionService.findProcessInstanceById(processInstanceId);
|
| Execution executionInFour =
processInstance.findActiveExecutionIn("custom four");
| assertNotNull("ExecutionInFour Is Null",executionInFour);
| processInstance =
executionService.signalExecutionById(executionInFour.getId());
|
|
| if(executionService.findProcessInstanceById(processInstanceId) !=
null) {
| assertFalse("ProcessInstance.isEnded() is not
false",processInstance.isEnded());
| }else {
| assertNull("processInstanceID not
null",executionService.findProcessInstanceById(processInstanceId));
| }
|
| }
|
| public static class CustomOne implements ExternalActivityBehaviour {
| private static final long serialVersionUID = 1L;
|
| public void execute(ActivityExecution execution) throws Exception {
| System.out.println("Executing");
|
| System.out.println(execution.getActivityName());
|
| execution.waitForSignal();
| }
|
| public void signal(ActivityExecution execution,
| String signalName,
| Map parameters) {
| execution.take(signalName);
| }
| }
|
| public static class CustomTwo implements ActivityBehaviour {
| private static final long serialVersionUID = 1L;
|
| public void execute(ActivityExecution execution) throws Exception {
| System.out.println("Executing");
|
| System.out.println(execution.getActivityName());
|
| execution.takeDefaultTransition();
| }
|
| public void signal(ActivityExecution execution,
| String signalName,
| Map parameters) {
| execution.take(signalName);
| }
| }
|
| public static class CustomThree implements ActivityBehaviour {
| private static final long serialVersionUID = 1L;
|
| public void execute(ActivityExecution execution) throws Exception {
| System.out.println("Executing");
|
| System.out.println(execution.getActivityName());
|
| execution.takeDefaultTransition();
| }
|
| public void signal(ActivityExecution execution,
| String signalName,
| Map parameters) {
| execution.take(signalName);
| }
| }
|
| public static class CustomFour implements ExternalActivityBehaviour {
| private static final long serialVersionUID = 1L;
|
| public void execute(ActivityExecution execution) throws Exception {
| System.out.println("Executing");
|
| System.out.println(execution.getActivityName());
|
| execution.waitForSignal();
| }
|
| public void s
[jboss-user] [jBPM Users] - Re: workflow design about wait states
If you changed the last thing, can you repost your unittest (assuming the processdefinition did not change) then I'll give it a try here. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255289#4255289 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255289 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
"kukeltje" wrote : I do not get your remark regarding "as expected" Referring to me suggesting that I was unsure that the process was actually completing "kukeltje" wrote : | Small other question (which might not be related) why do you reassign processInstance a new value each time? | No reason other it was probably cut and paste from other unit tests. "kukeltje" wrote : | And you might try to change the interface of tow and three to ActivityBehaviour (since there is no 'waitForSignal' anymore. You can remove the signal method then and the 'takeDefaultTransition()' can be removed as well if there is just one outgoing transition. | I've done this just not repeat posted the unit test. "kukeltje" wrote : | Oh and make the error messages in the asserts more explicit (you can add a string as message, that way you can easily see in the logging which assert it was) Good point. Will do this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255283#4255283 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255283 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
I do not get your remark regarding "as expected" Small other question (which might not be related) why do you reassign processInstance a new value each time? And you might try to change the interface of tow and three to ActivityBehaviour (since there is no 'waitForSignal' anymore. You can remove the signal method then and the 'takeDefaultTransition()' can be removed as well if there is just one outgoing transition. Oh and make the error messages in the asserts more explicit (you can add a string as message, that way you can easily see in the logging which assert it was) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255274#4255274 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255274 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
As expected...
| if(executionService.findProcessInstanceById(processInstanceId) != null) {
| assertFalse(processInstance.isEnded());
| }else {
| assertNull(executionService.findProcessInstanceById(processInstanceId));
| }
|
| 11:48:43,264 FIN | [BaseJbpmTestCase] === starting testProcess
=
| 11:48:43,389 FIN | [BaseJbpmTestCase] using ProcessEngine 78236
| log4j:WARN No appenders could be found for logger
(org.hibernate.cfg.Environment).
| log4j:WARN Please initialize the log4j system properly.
| 11:48:44,530 FIN | [ProcessDefinitionImpl] creating new execution for
process 'process'
| 11:48:44,545 FIN | [DefaultIdGenerator] generated execution id process.363
| 11:48:44,545 FIN | [ExecuteActivity] executing activity(20045467)
| 11:48:44,545 FIN | [ExecuteActivity] executing activity(custom one)
| Executing
| custom one
| 11:48:44,561 FIN | [Signal] signalling activity(custom one), signalName=null
| 11:48:44,561 FIN | [ExecuteActivity] executing activity(fork)
| 11:48:44,561 FIN | [DefaultIdGenerator] generated execution id
process.363.custom two
| 11:48:44,561 FIN | [ExecutionImpl] created execution[process.363.custom two]
| 11:48:44,561 FIN | [JobExecutorMessageSession] sending message
ExecuteActivityMessage
| 11:48:44,576 INF | [JobExecutorThread] starting...
| 11:48:44,576 INF | [JobExecutorThread] starting...
| 11:48:44,576 INF | [JobExecutorThread] starting...
| 11:48:44,576 INF | [DispatcherThread] starting...
| 11:48:44,576 FIN | [DefaultIdGenerator] generated execution id
process.363.custom three
| 11:48:44,576 FIN | [ExecutionImpl] created execution[process.363.custom
three]
| 11:48:44,576 FIN | [JobExecutorMessageSession] sending message
ExecuteActivityMessage
| 11:48:44,576 FIN | [AcquireJobsCmd] start querying first acquirable
job...
| 11:48:44,576 FIN | [AcquireJobsCmd] locking jobs []
| 11:48:44,576 FIN | [GetNextDueDateCmd] getting next due date...
| 11:48:44,576 FIN | [GetNextDueDateCmd] next due date is null
| 11:48:44,576 FIN | [DispatcherThread] DispatcherThread will wait
for max 600ms on org.jbpm.pvm.internal.jobexecutor.jobexecu...@1417690
| 11:48:44,576 FIN | [DispatcherThread] DispatcherThread woke up
| 11:48:44,576 FIN | [AcquireJobsCmd] start querying first acquirable
job...
| 11:48:44,592 FIN | [AcquireJobsCmd] locking jobs [519]
| 11:48:44,592 FIN | [DispatcherThread] pushing jobs on the queue
[519]
| 11:48:44,592 FIN | [DispatcherThread] added jobs [519] to the queue
| 11:48:44,592 FIN | [AcquireJobsCmd] start querying first acquirable
job...
| 11:48:44,592 FIN | [JobExecutorThread] took job(s) [519] from queue
| 11:48:44,592 FIN | [AcquireJobsCmd] locking jobs [520]
| 11:48:44,592 FIN | [DispatcherThread] pushing jobs on the queue
[520]
| 11:48:44,592 FIN | [DispatcherThread] added jobs [520] to the queue
| 11:48:44,592 FIN | [AcquireJobsCmd] start querying first acquirable
job...
| 11:48:44,592 FIN | [JobExecutorThread] took job(s) [520] from queue
| 11:48:44,608 FIN | [AcquireJobsCmd] locking jobs []
| 11:48:44,608 FIN | [ExecuteJobCmd] executing job
ExecuteActivityMessage[519]...
| 11:48:44,608 FIN | [ExecuteJobCmd] executing job
ExecuteActivityMessage[519]...
| 11:48:44,608 FIN | [GetNextDueDateCmd] getting next due date...
| 11:48:44,608 FIN | [GetNextDueDateCmd] next due date is null
| 11:48:44,655 FIN | [ExecuteActivity] execution[process.363.custom two]
executes activity(custom two)
| 11:48:44,655 FIN | [JobExecutorMessageSession] sending message
ExecuteActivityMessage
| 11:48:44,655 FIN | [ExecuteJobCmd] executing job
ExecuteActivityMessage[520]...
| Executing
| custom two
| 11:48:44,670 FIN | [DispatcherThread] DispatcherThread will wait
for max 600ms on org.jbpm.pvm.internal.jobexecutor.jobexecu...@1417690
| Executing
| custom three
| Executing
| custom two
| 11:48:44,670 FIN | [ExecuteJobCmd] executed job ExecuteActivityMessage[519]
| 11:48:44,670 FIN | [ExecuteActivity] execution[process.363.custom
three] executes activity(custom three)
| 11:48:44,670 FIN | [JobExecutorMessageSession] sending message
ExecuteActivityMessage
| 11:48:44,670 FIN | [ExecuteJobCmd] executed job
ExecuteActivityMessage[520]
| 11:48:44,670 FIN | [ExecuteActivity] execution[process.363.custom two]
executes activity(custom two)
| 11:48:44,670 FIN | [JobExecutorMessageSession] sending message
ExecuteActivityMessage
| 11:48:44,670 FIN | [ExecuteJobCmd] executing job
ExecuteActivityMessage[520]...
| 11:48:44,670 FIN | [ExecuteJobCmd] executed job
ExecuteActivityMessage[519]
| 11:48:44,670 FIN | [DispatcherThread] DispatcherThread woke up
| 11:48:44,670 FIN
[jboss-user] [jBPM Users] - Re: workflow design about wait states
your processinstance is really ended if retrieving it from the executionservice by id (processinstance id) is null. If it is not null isEnded() on the processInstance will return false. So you can add that at the end of your test. anonymous wrote : Attempting to put this in to my "proper" workflow with more custom nodes is still showing errors. Where? How? Errors? Please, otherwise we can't help View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255155#4255155 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255155 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
I've added...
| processInstance =
executionService.findProcessInstanceById(processInstanceId);
|
| Execution executionInFour =
processInstance.findActiveExecutionIn("custom four");
| assertNotNull(executionInFour);
| processInstance =
executionService.signalExecutionById(executionInFour.getId());
|
...to my unit test.
Now I'm not getting any exceptions and the output looks like this:
| 15:14:34,393 FIN | [BaseJbpmTestCase] === starting testProcess
=
| 15:14:34,518 FIN | [BaseJbpmTestCase] using ProcessEngine 78236
| log4j:WARN No appenders could be found for logger
(org.hibernate.cfg.Environment).
| log4j:WARN Please initialize the log4j system properly.
| 15:14:35,675 FIN | [ProcessDefinitionImpl] creating new execution for
process 'process'
| 15:14:35,675 FIN | [DefaultIdGenerator] generated execution id process.277
| 15:14:35,675 FIN | [ExecuteActivity] executing activity(16408563)
| 15:14:35,675 FIN | [ExecuteActivity] executing activity(custom one)
| Executing
| custom one
| 15:14:35,690 FIN | [Signal] signalling activity(custom one), signalName=null
| 15:14:35,690 FIN | [ExecuteActivity] executing activity(fork)
| 15:14:35,706 FIN | [DefaultIdGenerator] generated execution id
process.277.custom two
| 15:14:35,706 FIN | [ExecutionImpl] created execution[process.277.custom two]
| 15:14:35,706 FIN | [JobExecutorMessageSession] sending message
ExecuteActivityMessage
| 15:14:35,706 INF | [JobExecutorThread] starting...
| 15:14:35,706 INF | [JobExecutorThread] starting...
| 15:14:35,706 INF | [JobExecutorThread] starting...
| 15:14:35,706 INF | [DispatcherThread] starting...
| 15:14:35,706 FIN | [DefaultIdGenerator] generated execution id
process.277.custom three
| 15:14:35,706 FIN | [ExecutionImpl] created execution[process.277.custom
three]
| 15:14:35,706 FIN | [JobExecutorMessageSession] sending message
ExecuteActivityMessage
| 15:14:35,722 FIN | [AcquireJobsCmd] start querying first acquirable
job...
| 15:14:35,722 FIN | [AcquireJobsCmd] locking jobs []
| 15:14:35,722 FIN | [GetNextDueDateCmd] getting next due date...
| 15:14:35,722 FIN | [GetNextDueDateCmd] next due date is null
| 15:14:35,722 FIN | [DispatcherThread] skipped wait because new
message arrived
| 15:14:35,722 FIN | [AcquireJobsCmd] start querying first acquirable
job...
| 15:14:35,722 FIN | [AcquireJobsCmd] locking jobs [390]
| 15:14:35,722 FIN | [DispatcherThread] pushing jobs on the queue
[390]
| 15:14:35,722 FIN | [DispatcherThread] added jobs [390] to the queue
| 15:14:35,722 FIN | [JobExecutorThread] took job(s) [390] from queue
| 15:14:35,722 FIN | [AcquireJobsCmd] start querying first acquirable
job...
| 15:14:35,722 FIN | [AcquireJobsCmd] locking jobs [391]
| 15:14:35,722 FIN | [DispatcherThread] pushing jobs on the queue
[391]
| 15:14:35,722 FIN | [DispatcherThread] added jobs [391] to the queue
| 15:14:35,722 FIN | [AcquireJobsCmd] start querying first acquirable
job...
| 15:14:35,737 FIN | [ExecuteJobCmd] executing job
ExecuteActivityMessage[390]...
| 15:14:35,737 FIN | [AcquireJobsCmd] locking jobs []
| 15:14:35,737 FIN | [GetNextDueDateCmd] getting next due date...
| 15:14:35,737 FIN | [GetNextDueDateCmd] next due date is null
| 15:14:35,737 FIN | [DispatcherThread] DispatcherThread will wait
for max 600ms on org.jbpm.pvm.internal.jobexecutor.jobexecu...@cd4544
| 15:14:35,737 FIN | [ExecuteJobCmd] executing job
ExecuteActivityMessage[390]...
| 15:14:35,784 FIN | [JobExecutorThread] took job(s) [391] from queue
| Executing
| custom two
| Executing
| custom two
| 15:14:35,784 FIN | [ExecuteJobCmd] executing job
ExecuteActivityMessage[391]...
| 15:14:35,784 FIN | [ExecuteActivity] execution[process.277.custom two]
executes activity(custom two)
| 15:14:35,784 FIN | [JobExecutorMessageSession] sending message
ExecuteActivityMessage
| 15:14:35,784 FIN | [ExecuteJobCmd] executed job ExecuteActivityMessage[390]
| 15:14:35,800 FIN | [ExecuteActivity] execution[process.277.custom two]
executes activity(custom two)
| 15:14:35,800 FIN | [JobExecutorMessageSession] sending message
ExecuteActivityMessage
| 15:14:35,800 FIN | [ExecuteJobCmd] executed job
ExecuteActivityMessage[390]
| 15:14:35,800 FIN | [ExecuteActivity] execution[process.277.custom
three] executes activity(custom three)
| 15:14:35,800 FIN | [JobExecutorMessageSession] sending message
ExecuteActivityMessage
| 15:14:35,800 FIN | [ExecuteJobCmd] executed job
ExecuteActivityMessage[391]
| 15:14:35,800 FIN | [DispatcherThread] DispatcherThread woke up
| 15:14:35,800 FIN | [AcquireJobsCmd] start querying first acquirable
job...
| Executing
| c
[jboss-user] [jBPM Users] - Re: workflow design about wait states
Thanks for that Ronald, be a huge help if you can see what I'm doing wrong.
So I changed the async nodes (custom one and two) to takeDefaultTransition().
| package org.workflow.test.forum;
|
| import java.util.List;
| import java.util.Map;
|
| import org.jbpm.api.Execution;
| import org.jbpm.api.ProcessInstance;
| import org.jbpm.api.activity.ActivityExecution;
| import org.jbpm.api.activity.ExternalActivityBehaviour;
| import org.jbpm.api.job.Job;
| import org.jbpm.test.JbpmTestCase;
|
| public class ProcessTest extends JbpmTestCase {
| String deploymentDbid;
|
| protected void setUp() throws Exception {
| super.setUp();
| deploymentDbid = repositoryService.createDeployment()
|
.addResourceFromClasspath("org/workflow/test/forum/process.jpdl.xml")
| .deploy();
| }
|
| protected void tearDown() throws Exception {
| repositoryService.deleteDeploymentCascade(deploymentDbid);
| super.tearDown();
| }
|
| public void testProcess() throws Exception {
| ProcessInstance processInstance =
executionService.startProcessInstanceByKey("process");
| Execution executionInOne =
processInstance.findActiveExecutionIn("custom one");
| assertNotNull(executionInOne);
| processInstance =
executionService.signalExecutionById(executionInOne.getId());
|
| String processInstanceId = processInstance.getId();
|
| List jobs = managementService.createJobQuery()
| .processInstanceId(processInstanceId)
| .list();
|
| assertEquals(2, jobs.size());
|
| Job job = jobs.get(0);
|
| managementService.executeJob(job.getId());
|
| job = jobs.get(1);
|
| managementService.executeJob(job.getId());
|
| Execution executionInFour =
processInstance.findActiveExecutionIn("custom four");
| assertNotNull(executionInFour);
| processInstance =
executionService.signalExecutionById(executionInFour.getId());
| }
|
| public static class CustomOne implements ExternalActivityBehaviour {
| private static final long serialVersionUID = 1L;
|
| public void execute(ActivityExecution execution) throws Exception {
| System.out.println("Executing");
|
| System.out.println(execution.getActivityName());
|
| execution.waitForSignal();
| }
|
| public void signal(ActivityExecution execution,
| String signalName,
| Map parameters) {
| execution.take(signalName);
| }
| }
|
| public static class CustomTwo implements ExternalActivityBehaviour {
| private static final long serialVersionUID = 1L;
|
| public void execute(ActivityExecution execution) throws Exception {
| System.out.println("Executing");
|
| System.out.println(execution.getActivityName());
|
| execution.takeDefaultTransition();
| }
|
| public void signal(ActivityExecution execution,
| String signalName,
| Map parameters) {
| execution.take(signalName);
| }
| }
|
| public static class CustomThree implements ExternalActivityBehaviour {
| private static final long serialVersionUID = 1L;
|
| public void execute(ActivityExecution execution) throws Exception {
| System.out.println("Executing");
|
| System.out.println(execution.getActivityName());
|
| execution.takeDefaultTransition();
| }
|
| public void signal(ActivityExecution execution,
| String signalName,
| Map parameters) {
| execution.take(signalName);
| }
| }
|
| public static class CustomFour implements ExternalActivityBehaviour {
| private static final long serialVersionUID = 1L;
|
| public void execute(ActivityExecution execution) throws Exception {
| System.out.println("Executing");
|
| System.out.println(execution.getActivityName());
|
| execution.waitForSignal();
| }
|
| public void signal(ActivityExecution execution,
| String signalName,
| Map parameters) {
| execution.take(signalName);
| }
| }
|
| }
|
|
With the same workflow as before I get custom four node as showing output but
still get null when the unittest attempts to find execution in this node.
| 13:58:02,975 FIN | [BaseJbpmTestCase] === starting testProcess
=
| 13:58:03,100 FIN | [BaseJbpmTestCase] using Process
[jboss-user] [jBPM Users] - Re: workflow design about wait states
Nice test now, I'll try to see what happens on my side later today. But I think it is related to the fact that you made the nodes not only be carried out in async, but also made it waitstates AFTER the 'execute' method is ended. (by using the waitForSignal). In your testcase you have to signal both states then. But if you replace the waitForSignal() with a take() (as mentioned earlier) then the custom node automatically continues and should pass the join. Without the customFour, your process is most likely still not ended (you can check that by building it in your test) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255086#4255086 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255086 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
Okay so I took your advice and went back to basics. What I'm finding is if i
have a node after the join (in my my case a custom node), the Unit test fails
to find the execution in this. With a join going straight to an end it is ok.
My workflow:
|
|
| http://jbpm.org/4.0/jpdl";>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I can't figure out how to test the custom four node. Without this things are
working as expected but to me it seems like my unit test stops at the join and
doesn't signal the workflow to carry on?
| package org.workflow.test.forum;
|
| import java.util.List;
| import java.util.Map;
|
| import org.jbpm.api.Execution;
| import org.jbpm.api.ProcessInstance;
| import org.jbpm.api.activity.ActivityExecution;
| import org.jbpm.api.activity.ExternalActivityBehaviour;
| import org.jbpm.api.job.Job;
| import org.jbpm.test.JbpmTestCase;
|
| public class ProcessTest extends JbpmTestCase {
| String deploymentDbid;
|
| protected void setUp() throws Exception {
| super.setUp();
| deploymentDbid = repositoryService.createDeployment()
|
.addResourceFromClasspath("org/workflow/test/forum/process.jpdl.xml")
| .deploy();
| }
|
| protected void tearDown() throws Exception {
| repositoryService.deleteDeploymentCascade(deploymentDbid);
| super.tearDown();
| }
|
| public void testProcess() throws Exception {
| ProcessInstance processInstance =
executionService.startProcessInstanceByKey("process");
| Execution executionInOne =
processInstance.findActiveExecutionIn("custom one");
| assertNotNull(executionInOne);
| processInstance =
executionService.signalExecutionById(executionInOne.getId());
|
| String processInstanceId = processInstance.getId();
|
| List jobs = managementService.createJobQuery()
| .processInstanceId(processInstanceId)
| .list();
|
| assertEquals(2, jobs.size());
|
| Job job = jobs.get(0);
|
| managementService.executeJob(job.getId());
|
| job = jobs.get(1);
|
| managementService.executeJob(job.getId());
|
| Execution executionInFour =
processInstance.findActiveExecutionIn("custom four");
| assertNotNull(executionInFour);
| processInstance =
executionService.signalExecutionById(executionInFour.getId());
| }
|
| public static class CustomOne implements ExternalActivityBehaviour {
| private static final long serialVersionUID = 1L;
|
| public void execute(ActivityExecution execution) throws Exception {
| System.out.println("Executing");
|
| System.out.println(execution.getActivityName());
|
| execution.waitForSignal();
| }
|
| public void signal(ActivityExecution execution,
| String signalName,
| Map parameters) {
| execution.take(signalName);
| }
| }
|
| public static class CustomTwo implements ExternalActivityBehaviour {
| private static final long serialVersionUID = 1L;
|
| public void execute(ActivityExecution execution) throws Exception {
| System.out.println("Executing");
|
| System.out.println(execution.getActivityName());
|
| execution.waitForSignal();
| }
|
| public void signal(ActivityExecution execution,
| String signalName,
| Map parameters) {
| execution.take(signalName);
| }
| }
|
| public static class CustomThree implements ExternalActivityBehaviour {
| private static final long serialVersionUID = 1L;
|
| public void execute(ActivityExecution execution) throws Exception {
| System.out.println("Executing");
|
| System.out.println(execution.getActivityName());
|
| execution.waitForSignal();
| }
|
| public void signal(ActivityExecution execution,
| String signalName,
| Map parameters) {
| execution.take(signalName);
| }
| }
|
| public static class CustomFour implements ExternalActivityBehaviour {
| private static final long serialVersionUID = 1L;
|
| public void execute(ActivityExecution execution) throws Exception {
| System.out.println("Executing");
|
| S
[jboss-user] [jBPM Users] - Re: workflow design about wait states
No, there is not transition *named* join, there only is a transition *to* join. And take() without any param should also work. It takes the default one if there is only one (duh.. ;-)) You do not need a sleep at all since the join should only continue if *all* incoming transitions are triggered. I think you misunderstood Joram (or he misunderstood you) Can you make a unitest with everything embedded like in http://www.jboss.org/index.html?module=bb&op=viewtopic&t=158424 so the actionhandlers are inner classes etc... Just start, fork, two custom nodes (async) , one join and one end. Lets first get that working (and include it as an example eventually in jBPM. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254880#4254880 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254880 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
This was my original problem... in real world I wont know how long to sleep
for. I need to read the objects back but only once they have all been updated
after a certain amount of time (which could be 2 seconds or 20 seconds).
When I use take("join"), I get org.jbpm.api.JbpmException: there is no
transition join in activity(validate red request). But there is.
I use takeDefaultTransition() (no sleep in my unit test) I get
StaleObjectStateException because my unit test and my workflow are out of sync.
This was pointed out my JBarrez in one of my previous posts. The sleep in my
unit test solved this problem.
If I don't use continue="exclusive" in the join, then my workflow doesn't
continue past the join... just stops.
Do you know how the waitForSignal() and takeDefaultTransition() methods are
affected (if at all) when used async? Using them normally like in the examples
they work fine.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254794#4254794
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254794
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
probably you have to do a sleep in your unit test to give the custom nodes time to fully finish... Or what would probably be better is to have the classes do a take() in the execute and let the join be the 'wait for all branches to finish' (that is what it is for). The aforementioned sleep is not needed then. And why do you use the continue="exclusive" on the join? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254787#4254787 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254787 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
Would love to write a blog entry about this, get more involved with jboss and
jbpm is my ultimate aim. I need to know what I'm talking about first! ;)
Unfortunately... with work pressures etc its not always possible. We'll see...
Taking the "async" out it works fine, I can see the nodes and assert which one
they should be in. When the custom nodes run in async, the unit test runs to
completion quicker than the actual workflow completes (or vice versa not sure).
So when I do:
| Execution execution = processInstance.findActiveExecutionIn("validate one
request");
| assertNotNull(execution ); //FAILS
| String executionId = execution .getId();
| executionService.signalExecutionById(executionId);
|
The assertion fails. In my custom class I have the following line
| public void execute(ActivityExecution execution {
| //my code
| execution.waitForSignal();
| }
|
|
| public void signal(ActivityExecution execution,
| String signalName,
| Map parameters) {
| execution.take(signalName);
| }
|
|
and they all implement ExternalActivityBehaviour. I have no idea what state
these are in now.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254772#4254772
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254772
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
It is if the 'others' are not resposive or sometimes react negatively if I mention simple things like 'look at the examples'. But if they are all like you, it is not that depressing. In fact this thread would be nice for others to read as well who like to do things like this. Would be e.g. nice if you could write a blog entry about this once it works. The errors you ran into/made and how they were solved. I understand you know how unitests should work, but you focusses on not having an execution in 'wait´ while the focus should have been on 'where are they then?'. If you'd have seen they were still in the custom nodes, maybe it sould have been quicker to get to the cause... ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254761#4254761 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254761 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
Hi Ronald, Okay that is starting to make sense now. I know how the Unit Tests should work, but what I was missing was leaving the node when they finished. I didn't know this had to be done. Thanks again for pointing me in the right direction... and your patience. I know it must be frustrating sometimes! :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254747#4254747 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254747 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
I never said you should remove async in your final version I just metioned it as one of the things to try in finding the cause. And that should be possible shouldn't it? Correct, the custom node class async but once it is finished it does nothing. If you want it to leave the node, you have to add execution.take(); If you do not want it to leave directly after it finished in the execute, add a execution.waitForSignal() and implement the signal(...) method. Again, see the examples. The way you do in now, your process is in an undefined state. And if in a unit test you manually execute the async jobs (see the examples again) you can check in what custom nodes the executions are in. That is how you should use unittests. The examples are very good for this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254731#4254731 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254731 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
"kukeltje" wrote : | | You use async but do you have a job executor in your unit test? If not, the jobs are never executed and your custom nodes are never executed | | They are executed. I can see that in the output as well as in the objects when I retrieve them. Using the job executor before didnt work correctly as the jobs were being executed sync not async. Here's a bit of the output to show the job executing | 12:33:44,091 FIN | [BaseJbpmTestCase] === starting testSimple = | Parsing process Request | 12:33:45,419 FIN | [ExecuteActivity] executing activity(evaluate parse result) | process ID: PROCESS_ID 001 | 12:33:45,451 FIN | [ExecuteActivity] executing activity(find providers) | Finding Providers | 12:33:45,451 FIN | [ExecuteActivity] executing activity(fork) | 12:33:45,466 FIN | [DefaultIdGenerator] generated execution id process.112.validate one | 12:33:45,466 FIN | [ExecutionImpl] created execution[process.112.validate one] | 12:33:45,466 FIN | [JobExecutorMessageSession] sending message ExecuteActivityMessage | 12:33:45,466 INF | [JobExecutorThread] starting... | 12:33:45,466 INF | [JobExecutorThread] starting... | 12:33:45,466 INF | [DispatcherThread] starting... | 12:33:45,466 INF | [JobExecutorThread] starting... | 12:33:45,466 FIN | [DefaultIdGenerator] generated execution id process.112.validate two | 12:33:45,466 FIN | [ExecutionImpl] created execution[process.112.validate two] | 12:33:45,466 FIN | [JobExecutorMessageSession] sending message ExecuteActivityMessage | 12:33:45,482 FIN | [DefaultIdGenerator] generated execution id process.112.validate three | 12:33:45,482 FIN | [ExecutionImpl] created execution[process.112.validate three] | 12:33:45,482 FIN | [JobExecutorMessageSession] sending message ExecuteActivityMessage | 12:33:45,482 FIN | [AcquireJobsCmd] start querying first acquirable job... | 12:33:45,482 FIN | [AcquireJobsCmd] locking jobs [] | 12:33:45,482 FIN | [GetNextDueDateCmd] getting next due date... | 12:33:45,482 FIN | [GetNextDueDateCmd] next due date is null | 12:33:45,482 FIN | [DispatcherThread] DispatcherThread will wait for max 600ms on org.jbpm.pvm.internal.jobexecutor.jobexecu...@171194d | 12:33:45,482 FIN | [DispatcherThread] DispatcherThread woke up | 12:33:45,482 FIN | [AcquireJobsCmd] start querying first acquirable job... | 12:33:45,482 FIN | [AcquireJobsCmd] locking jobs [109] | 12:33:45,482 FIN | [DispatcherThread] pushing jobs on the queue [109] | 12:33:45,482 FIN | [DispatcherThread] added jobs [109] to the queue | 12:33:45,482 FIN | [JobExecutorThread] took job(s) [109] from queue | 12:33:45,482 FIN | [AcquireJobsCmd] start querying first acquirable job... | 12:33:45,498 FIN | [ExecuteJobCmd] executing job ExecuteActivityMessage[109]... | 12:33:45,498 FIN | [AcquireJobsCmd] locking jobs [110] | 12:33:45,498 FIN | [DispatcherThread] pushing jobs on the queue [110] | 12:33:45,498 FIN | [DispatcherThread] added jobs [110] to the queue | 12:33:45,498 FIN | [AcquireJobsCmd] start querying first acquirable job... | 12:33:45,498 FIN | [AcquireJobsCmd] locking jobs [111] | 12:33:45,498 FIN | [JobExecutorThread] took job(s) [110] from queue | 12:33:45,498 FIN | [DispatcherThread] pushing jobs on the queue [111] | 12:33:45,498 FIN | [DispatcherThread] added jobs [111] to the queue | 12:33:45,498 FIN | [AcquireJobsCmd] start querying first acquirable job... | 12:33:45,498 FIN | [JobExecutorThread] took job(s) [111] from queue | 12:33:45,498 FIN | [AcquireJobsCmd] locking jobs [] | 12:33:45,513 FIN | [ExecuteJobCmd] executing job ExecuteActivityMessage[111]... | 12:33:45,513 FIN | [ExecuteJobCmd] executing job ExecuteActivityMessage[110]... | 12:33:45,513 FIN | [ExecuteActivity] execution[process.112.validate one] executes activity(validate one request) | 12:33:45,560 FIN | [GetNextDueDateCmd] getting next due date... | 12:33:45,576 FIN | [GetNextDueDateCmd] next due date is null | 12:33:45,576 FIN | [DispatcherThread] DispatcherThread will wait for max 600ms on org.jbpm.pvm.internal.jobexecutor.jobexecu...@171194d | 12:33:45,576 FIN | [ExecuteActivity] execution[process.112.validate two] executes activity(validate two request) | 12:33:45,576 FIN | [ExecuteActivity] execution[process.112.validate three] executes activity(validate three request) | 12:33:46,169 FIN | [DispatcherThread] DispatcherThread woke up | 12:33:46,169 FIN | [AcquireJobsCmd] start querying first acquirable job... | 12:33:46,169 FIN | [AcquireJobsCmd] locking jobs [] | 12:33:46,169 FIN | [GetNextDueDateCmd] getting next due date... | 12:33:46,169 FIN | [GetNextDueDateCmd] next due date is nu
[jboss-user] [jBPM Users] - Re: workflow design about wait states
"mmusaji" wrote : I'm working on a unit test, appreciate your feedback so far. I tried to do this before but because of the fork the unit test would always fail as the unit test thread would continue and fork would not be complete. So? Your unittest fails because the behaviour of your app is not what you expect... Great, that is what unittests are for :-) You use async but do you have a job executor in your unit test? If not, the jobs are never executed and your custom nodes are never executed If you look at the examples in the source you can find these things out. As always, ttry to minimize the testcases. e.g. if you remove async on the custom nodes it might work. So you are more closer to the cause. That is debugging/troubleshooting etc ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254716#4254716 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254716 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
Why doesn't this forum have an edit option!!!?
| public class ValidateOneRequest implements ActivityBehaviour {
|
| private static final long serialVersionUID = 1L;
| OneDetails oneDetails;
|
| public void execute(ActivityExecution execution) throws Exception {
| Thread.sleep(2000);//simulate a delay in processing.
| OneDetails oneDetails=
(OneDetails)execution.getVariable("oneDetails");
| oneDetails = update(oneDetails); //update the object in some way
(change a name)
| execution.setVariable("oneDetails", oneDetails);
| }
| }
|
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254712#4254712
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254712
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
My classes in the custom nodes do very little. I don't understand how these
would have an impact on wait state which is after they execute.
| public class ValidateOneRequest implements ActivityBehaviour {
|
| private static final long serialVersionUID = 1L;
| ExperianDetails experianDetails;
|
| public void execute(ActivityExecution execution) throws Exception {
| Thread.sleep(2000);//simulate a delay in processing.
| OneDetails oneDetails=
(OneDetails)execution.getVariable("oneDetails");
| oneDetails = update(oneDetails); //update the object in some way
(change a name)
| execution.setVariable("oneDetails", oneDetails);
| }
| }
|
I'm working on a unit test, appreciate your feedback so far. I tried to do this
before but because of the fork the unit test would always fail as the unit test
thread would continue and fork would not be complete.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254711#4254711
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254711
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
and if possible, make a unittest as described in the sticky post in this forum all in one, and minimize it as far as possible (e.g. to legs in a fork, and an end direct after the wait) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254709#4254709 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254709 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
in what nodes do you have executions? Please make e.g. a full unit test where you demonstrate that the custom nodes are entered, left etc... And what do your classes on the custom nodes do? If they are almost identical, post one of them. I get the impression you do things wrong in there. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254708#4254708 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254708 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
Previous one did not have wait state. I was referring to it once I'd added but here it is. | | | http://jbpm.org/4.0/jpdl";> | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254704#4254704 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254704 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
then there is no execution in wait... where in your definition do you go to wait? I do not see that... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254701#4254701 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254701 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
I understand what you said earlier Ronald, having trouble implementing this in
a Junit test.
I've added a state in my workflow which will wait until signal recieved. Its
after the join in the above example. I wont paste the whole workflow again,
hope that's ok.
My Unit test is
public void testSimple() throws Exception {
|
| ProcessInstance processInstance =
executionService.startProcessInstanceByKey("process", variables);
| String processInstanceId = processInstance.getId();
|
| String executionId =
processInstance.findActiveExecutionIn("wait").getId();
|
| processInstance = executionService.signalExecutionById(executionId,
"continue");
| }
Problem is I always get null pointer exception as no execution is found in
"wait". I presume what is happening is similar to a problem I had before when
the async processes from fork carry on, my unit test in a seperate thread
carries on and the wait state isn't there yet.
Any suggestions?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254695#4254695
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254695
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
Thanks again Ronald. I think I know what you mean. I'll investigate further. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254671#4254671 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254671 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
Yep, and you can e.g. pass e.g. the specific id then to your remote service and use it to signal this specific id when finished, or store it in your domainmodel as a reference, etc... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254668#4254668 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254668 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
Your comment about signalling the state made me look at the "StateChoiceTest" in the examples. Is this what you meant? Because I think this might work. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254664#4254664 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254664 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
Hi
Okay so here's my workflow.
|
|
| http://jbpm.org/4.0/jpdl";>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is my WebMethod. This is what starts the process when a request is
recieved and will give a better idea of what I'm trying to achieve. I hope.
@WebMethod
| public String request() {
| try {
| InitialContext ctx = new InitialContext();
| this.processEngine =
(ProcessEngine)ctx.lookup("java:/ProcessEngine");
|
| ExecutionService execService = (ExecutionService)
| this.processEngine.get(ExecutionService.class);
|
| ProcessInstance processInstance =
execService.startProcessInstanceByKey("process", variables);
|
| System.out.println("ProcessInstanceID: " +
processInstance.getId());
| //we need a signal cos we have no idea how long the return from
the providers will take in real life
| Thread.sleep(3000);
|
| //if I check this too early then I don't get the right details back
| oneDetails =
(OneDetails)execService.getVariable(processInstance.getId(), "oneDetails");
| result = "OneDetails: " + oneDetails.getDetails();
|
| } catch (Exception e) {
| e.printStackTrace();
| }
|
Please explain further about signalling the specific state... which state? The
one that is waiting for the processes in the fork to complete?
My Unit test which is attempting to signal the wait state is below. This isn't
working at all at the moment.
| public void testSimple() throws Exception {
|
| ProcessInstance processInstance =
executionService.startProcessInstanceByKey("process", variables);
| String processInstanceId = processInstance.getId();
|
| Execution waitExecution =
processInstance.findActiveExecutionIn("wait");
| executionService.signalExecutionById(waitExecution.getId());
|
| OneDetails oneDetails = (OneDetails
)executionService.getVariable(processInstanceId, "oneDetails ");
| }
|
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254663#4254663
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254663
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM Users] - Re: workflow design about wait states
anonymous wrote : Is this the right way of going about this problem? No, the best way is to show us code, preferably a full unit test (see the first post in this forum). including simulation on how the event-listener is triggered etc... (why an event-listener and not just signal the specific state)? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254594#4254594 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254594 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
