-
1. Re: Migration from 4.3 to 5.2
tdtappe Apr 26, 2012 11:41 AM (in response to tdtappe)In addition to what I said already maybe I should explain in more detail what I like to achieve. Because I would like to know how this should be done with jBPM 5.2 (BPMN).
In my app I create some object (like an order). I then start some process on this object. The process might detect that some further processing is possible (sending an email, print the order, etc). So it's done. But sometimes for further processing some conditions have to meet. Then the process has to wait until the conditions are fulfilled. As the objects (the orders) can be edited in the app at every time I want to notify the process after a modification to check for further processing. If further processing is possible the process proceeds until the next condition has to be fulfilled (or the process ends).
This worked fine with jBPM 4.3 working with state nodes and decisions. After each modification I signaled the process (with a null signal). The process then checked whether a further processing was possible or it stayed in "wait mode".
-
2. Re: Migration from 4.3 to 5.2
swiderski.maciej Apr 27, 2012 1:51 AM (in response to tdtappe)1 of 1 people found this helpfulHeiko Tappe wrote:
It took me quite a while to get things started with 5.2 (embedded in my app deployed on JBoss 7.1.1). But now I am able to start processes (including jpa 2.0 persistence - hibernate 4).
Great to hear
Heiko Tappe wrote:
One thing that's missing is: how can signal a specific process instance? With 4.3 I can start a process and bind it to a specific key (startProcessInstanceByKey). Later I can use a query (createProcessInstanceQuery) to find the suitable process instance and then signal it.
Is there something similar for 5.2?
It uses process instance id as a correlation, as far as I know there is no business key concept yet. Once you know process instance id you can use session's signalEvent method to move the process from "wait state".
Heiko Tappe wrote:
BTW, is there some general migration guide? Explaning/comparing for instance some use cases for 4.3 and 5.2?
Besides this forum and other people experience I don't think so
Heiko Tappe wrote:
In my app I create some object (like an order). I then start some process on this object. The process might detect that some further processing is possible (sending an email, print the order, etc). So it's done. But sometimes for further processing some conditions have to meet. Then the process has to wait until the conditions are fulfilled. As the objects (the orders) can be edited in the app at every time I want to notify the process after a modification to check for further processing. If further processing is possible the process proceeds until the next condition has to be fulfilled (or the process ends).
This worked fine with jBPM 4.3 working with state nodes and decisions. After each modification I signaled the process (with a null signal). The process then checked whether a further processing was possible or it stayed in "wait mode".
It is possible with BPMN as well using intermediate events and gateways. Moreover it is even more advanced thanks to integration with drools so instead of signaling the process whenever your business object changes you could use conditional events and use rules for that, as soon as you business object changes just insert/update it in the session and if condition is met event will be triggered. There are much more options with BPMN compared to jpdl in 4.x
HTH
-
3. Re: Migration from 4.3 to 5.2
tdtappe May 4, 2012 4:26 AM (in response to swiderski.maciej)Thanks Maciej. I went for the Drools approach with conditional events. And it works
Well - kind of. The problem is: how does the rule refer only to those facts that belong to this process?
Did I make myself clear enough?
For instance one of my conditions looks like this:
Order(tasksComplete == true)
But of course this fires for each process instance as long as there is at least ONE order fact in the whole knowledge base that has its tasks completed.
It probably should look something like this (pseudo code):
Order(tasksComplete == true, id = process.getVariable("orderId"))
I know that some time ago I saw some thread somewhere about a similar topic. But I can't find it any longer
IIRC it was about inserting the WorkflowProcessInstance as a fact and include it into the LHS of the rule!?
Is this the way to go? And how exactly would I have to do it?
-
4. Re: Migration from 4.3 to 5.2
salaboy21 May 4, 2012 6:13 AM (in response to tdtappe)1 of 1 people found this helpfulExactly, you need to mix and match your process variables with your facts so the right facts are evaluated:
WorkflowProcessInstance( $orderId: variables[“orderId”])
Order( tasksComplete == true, id == $orderId )
-
5. Re: Migration from 4.3 to 5.2
tdtappe May 4, 2012 6:21 AM (in response to salaboy21)I see. And how do I have to put the process instance into the knowledge base?
-
6. Re: Migration from 4.3 to 5.2
salaboy21 May 4, 2012 6:26 AM (in response to tdtappe)ProcessInstance processInstance =
ksession.createProcessInstance(“myprocess”);ksession.insert(processInstance);
-
7. Re: Migration from 4.3 to 5.2
tdtappe May 4, 2012 6:40 AM (in response to salaboy21)Oops, missed that one
Thank you so much!
-
8. Re: Migration from 4.3 to 5.2
tdtappe May 4, 2012 7:24 AM (in response to tdtappe)Hmm... not yet
First: WorkflowProcessInstance($orderId: variables[“orderId”]) does not seem to be correct syntax. It's complaining about unknown "variables". "variable" doesn't work either.
But I don't get any errors with WorkflowProcessInstance($orderId: getVariable(“orderId”))
I that Ok?
Second: Obviously processes that should stay in wait mode proceed when a different process fires on some conditional. Just like it was before introducing WorkflowProcessInstance stuff.
Any idea?
-
9. Re: Migration from 4.3 to 5.2
tdtappe May 7, 2012 5:33 AM (in response to tdtappe)As for the second item:
Being quite a newbie to drools/jbpm stuff I might not have the right understand of things... but thinking about it: isn't it logical that every process proceeds if the condition described above resolves to true? It's just looking for a match in the knowledge base: a process with a variable "orderId" and an order with that id and tasksComplete being true. Of course there is only one match but it will fire for every process.
If there was a "then" part and it would depend on the "then" part which process to proceed then it could be done this way. But whithout!?
-
10. Re: Migration from 4.3 to 5.2
tdtappe May 7, 2012 8:36 AM (in response to tdtappe)Now I am totally puzzled...
For testing purposes I created two separate knowledge bases and sessions. In each session I started a process instance of the same process definition. Each process gets different orders as facts for the conditional intermediate catch event. After the catch event a script task follows.
If I now trigger the rules for process 1 by updating the knowledge base (order 1) BOTH script tasks are executed (BTW, twice for process 1 and once for process 2).
Checking the state (active node instances) of each process afterwards shows:
- process 1 ended (no process instance found in session with that id) - so that was expected
- process 2 is still in wait mode on the conditional catch event
-
11. Re: Migration from 4.3 to 5.2
swiderski.maciej May 7, 2012 8:45 AM (in response to tdtappe)could you please provide your example as test case together with process definition (bpmn2) so I could take a look at it and play around for a while.
-
12. Re: Migration from 4.3 to 5.2
tdtappe May 7, 2012 8:55 AM (in response to tdtappe)Ok, now I am quite sure that it must be related to JPA persistence. Turning persistence off shows an absolutely expected behaviour. At least for having two separate knowledge bases and sessions. Inspecting it in more detail... I will report back.
-
13. Re: Migration from 4.3 to 5.2
tdtappe May 7, 2012 9:34 AM (in response to swiderski.maciej)Ok, I will try. Right now there's a lot of stuff in my test app because at the time I started there were several things I needed to test (JBoss 7.1.1, Seam 3.1, Hibernate 4, jBPM, Drools).
In the meantime - can you tell something about the topic I raised in blog item 9? Is it maybe necessary to have separate knowledge bases?
-
14. Re: Migration from 4.3 to 5.2
tdtappe May 7, 2012 9:38 AM (in response to tdtappe)Switching back to only one knowledge base and session but without persistence it still seems not to be possible to proceed only one process. Which raises the question whether there is still something wrong with my java code or process definition. Or if it's necessary to have separate knowledge bases for each process instance.