hello tolitius, i know its a bit complicated here..... but still you must have sorted it out yourself the three things are as follows when a process waits for some HumanTask or WorkItem WorkItem is available in ExceuteWorkItem parameter as workItem.getId(); form workItem itself u can also get processinstance id as workItem.getProcessInstanceId(); and the sessionId is what i m keeping u as homework.... feel free to ask more questions regards ----- Keep Working >>:working: KiranP -- View this message in context: http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WOR... Sent from the Drools - User mailing list archive at Nabble.com.

Hi guys, If you have the session and the process ID you can get the work item ID using something like: ((WorkItemNode)processInstance.getNodeInstances().iterator().next()).getWorkItemId(); If you need to fire an event, sometimes you need the process instance id and sometimes not, it depends on how you define the event (external or internal). You should store related with you businessID the sessionId and the processId. On Fri, Mar 26, 2010 at 2:21 AM, tolitius <webakaunt(a)gmail.com&gt; wrote: -- - http://salaboy.wordpress.com - http://www.jbug.com.ar - Salatino "Salaboy" Mauricio -

1) calling ((WorkItemNode) processInstance.getNodeInstances() will return the list of current Node Instances inside the process. This means that you can retrieve for each of them the name and compare to know which one do you want to complete. 2) A session can contain multiple process instances inside it. it depends on the information that you want to store inside each session. Depending on your use case is how you will divide: one process Instance per session, multiple process instances per session, etc. On Fri, Mar 26, 2010 at 9:34 AM, tolitius <webakaunt(a)gmail.com&gt; wrote: -- - http://salaboy.wordpress.com - http://www.jbug.com.ar - Salatino "Salaboy" Mauricio -

Hi, 1) if you have subprocesses and you ask for your node instances in the Parent Process you will get a Node of type SubProcessNode, you will not get all the work items related inside it. You need to use the sub process id and then get all the node instances inside it to see which work items needs to be completed 2) yes it is accuarate. You always need a session, because the ProcessInstances lives inside a session. On Fri, Mar 26, 2010 at 1:11 PM, tolitius <webakaunt(a)gmail.com&gt; wrote: -- - http://salaboy.wordpress.com - http://www.jbug.com.ar - Salatino "Salaboy" Mauricio -

if you have multiple work items and all running in parallel, let's say workItemA, workItemB and workItemC, you must choose which you want to complete. So you basically iterate to over all the NodeInstance inside a process and end the one that you select. On Fri, Mar 26, 2010 at 2:48 PM, tolitius <webakaunt(a)gmail.com&gt; wrote: -- - http://salaboy.wordpress.com - http://www.jbug.com.ar - Salatino "Salaboy" Mauricio -

no, I'm not saying that.. the business layer needs to be aware of the Activity name that it's trying to complete :) It's probably my mistake, I think I use WorkItem as Activity name.. but it should be Activity1, Activity 2 and Activity3. So then you will check by that names to know which work item you should choose.. sorry for that.. my mistake. On Fri, Mar 26, 2010 at 4:14 PM, tolitius <webakaunt(a)gmail.com&gt; wrote: -- - http://salaboy.wordpress.com - http://www.jbug.com.ar - Salatino "Salaboy" Mauricio -

You should basically only know the workItemId. Whenever you have some task that needs to be executed externally (and could take some time), a new work item will be created. When that work is finished, the work item manager should be notified (using manager.completeWorkItem(workItem.getId(), null)). If you need to know what work needs to be completed, you should probably make sure that your work item handler knows this. For example, our work item handler implementation for human tasks creates a new task in the database every time a human task work item needs to be executed (and stores the associated work item id in the db as well). That allows a user to ask the human task service for all tasks that still need to be executed. If the user completes the task, the manager is also signaled that the work item has been completed (using manager.completeWorkItem). So while you could use the code fragments that other have provided in related mails already, I'm not sure you actually need those, as the handler should be storing most info and signal the completion of the work item using the work item id. Kris Quoting tolitius <webakaunt(a)gmail.com&gt;: http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WOR... Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Kris, Salaboy, I am just looking for the best approach to establish a relationship between the business "Activity" and the Drools Flow "Workitem". So according to Kris (thank you), WorkItemHandler would have a reference to a WorkItemId that can be persisted before the workflow gets suspended [goes to the "wait state"]. So let me try to ask my question again: "businessService is passing a documentId to the workflowService.resumeWorkflow( documentId )...", can the workItemID be persisted using a Variable Persistence, so when the flow resumes, I can just do processInstance.getVariable( "workItemId" ) [or whatever the API to get variable is]? If NOT, is there a place within the Drools Flow tables, I can persist this WorkItemID [besides the VariableInstanceInfo]? Thank you, /Anatoly P.S. These are two questions -- View this message in context: http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WOR... Sent from the Drools - User mailing list archive at Nabble.com.

I understand it is persisted (with WS handler out of the box), what I need to be able to do is to find _this particular_ WorkItemID once the flow is resumed not relying on WS handler. WS implementation of Human Task handler, persists workItemID and have a task associated with it, therefore, when the task gets completed, the framework knows how to find that workItemId, since it is associated with _that_ particular task. But let's say I am not using WS human task handler, and I have my own workItemHandler. What I need to be able to do is having SESSION_ID and PROCESS_INSTANCE_ID to find that _particular_ workItemId, that causes the flow to wait. I understand I can get all the node instances, and all the subflow node instances, etc.. iterate over all the workitems... But instead what I want to be able to do is something similar to: processInstance.findWorkItemsInWaitState() where it gives me [most of the time a single, but can be] a list of only those work items that _currently_ cause the flow to wait. And if I do not do any kind of parallel processing (true async parallel processing), it is always going to be just that one work item that I need. Is that something I can do, or do I need to come up with a different approach (one of which I talked before [saving a work item id as a flow variable])? Thank you, /Anatoly -- View this message in context: http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WOR... Sent from the Drools - User mailing list archive at Nabble.com.

what do you mean I can take both approaches? processInstance.findWorkItemsInWaitState() is not even an API that Drools Flow provides. So that is exactly my question: "is there something similar that the framework already provides?". Because I am looking at "processInstance" and/or "ksession.getWorkItemManager()", they have no knowledge of which particular workitem causes the flow to wait. Thank you, /Anatoly -- View this message in context: http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WOR... Sent from the Drools - User mailing list archive at Nabble.com.

So, is there something similar: processInstance.findWorkItemsInWaitState() that the framework provides? -- View this message in context: http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WOR... Sent from the Drools - User mailing list archive at Nabble.com.

I see. So "When the process is in a wait state I must have a mechanism to continue", why not have framework help me? What is the rationale behind that? Thank you, /Anatoly -- View this message in context: http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WOR... Sent from the Drools - User mailing list archive at Nabble.com.

Yes, but even without WS-HT, framework has WORKITEMINFO, with WORKITEMID... It just seems so natural for a workflow (or how many buzzzy people call it a "BPM solution") to KNOW which elements of the flow are in the wait state, without any custom built components. Don't you think? -- View this message in context: http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WOR... Sent from the Drools - User mailing list archive at Nabble.com.

yes, but: 1. It is too low level to be a true clean / simple client API. Instead of something as simple as: "process.findWorkInProgress()" developers need to know to: a. cast the processInstance, b. get a hold of NodeInstances c. iterate over them d. filter out what nodes are in progress e. query DB for the data associated with those nodes 2. There is no "one view" to all the wait nodes, because of the sub-processes, so this solution gets even hairier when there are multiple subflows, subflows within subflows, etc.. That is why it is rather odd that you think these low level APIs are enough. /Anatoly -- View this message in context: http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WOR... Sent from the Drools - User mailing list archive at Nabble.com.

good to get a full response instead of "copy this / yes, you can do that / etc..". actually, I am not sure what I am agreeing with you on :) And it is not about agreeing, it is about me getting Drools Flow approach, since the documentation is very high level. Where I would really throw forces to make it low-level, that would be documentation, but not a product APIs. That is a definite differences in opinions. Think about other good frameworks, like Spring and Hibernate for example. If I had to do 6 low level calls to get a reference to a bean in Spring, I would never even consider using it, would go for CDI http://jcp.org/en/jsr/detail?id=299 right away. (but no, it is as simple HIGH LEVEL as Autowire or implement a certain (Aware) interface) If I had to create 15 queries and write my high level APIs on top of the Hibernate's low level APIs to make them flexible enough, I would rather use iBatis, or just GORM (but no I can use a nice HIGH LEVEL Criteria API) The point is there should be a healthy balance between the framework and the client. Now, I am not saying Drools Flow does not have that balance, what I am saying help me learn Drools Flow in a way that I can use its full power. And I am SURE that there is a better way in Drools Flow to find all waiting workitems. Maybe not by a single HIGH LEVEL API call ( not YET :) ), but surely not through some low level NodeInstance hooks. And as far as Java World, Asgard http://en.wikipedia.org/wiki/Asgard_%28Stargate%29 World, and many other worlds, clean and simple is always stronger, than weakly-typed, convoluted and low-level. /Anatoly -- View this message in context: http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WOR... Sent from the Drools - User mailing list archive at Nabble.com.

Mauricio, getThePersonAndTheDocumentThatIWant is a business concern. Specifically it relates to Documents and People my argument is that API such as: process.findWorkitemsInWaitState (maybe a bit better worded) is a framework concern, since a WAIT_STATE and a WORK_ITEM are workflow [not necessarily Drools ] DSL. Not business. Do you see what I mean? I don't see me not following your suggestions, and I appreciate the discussion, I just don't understand why the WAIT_STATE is not a framework concern. /Anatoly -- View this message in context: http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WOR... Sent from the Drools - User mailing list archive at Nabble.com.

By the way, Wait States are Node Instances, that are currently inside the ProcessInstance. Right? On Fri, Apr 2, 2010 at 7:14 PM, Mauricio Salatino <salaboy(a)gmail.com&gt; wrote: -- - http://salaboy.wordpress.com - http://www.jbug.com.ar - Salatino "Salaboy" Mauricio -

not sure where you are going with this, but ok: public interface ProcessInstance extends EventListener { int STATE_PENDING = 0; int STATE_ACTIVE = 1; int STATE_COMPLETED = 2; int STATE_ABORTED = 3; int STATE_SUSPENDED = 4; // <<<<<<<<<<< //.... } So does WorkItem: public class WorkItemImpl implements WorkItem, Serializable { private static final long serialVersionUID = 400L; private long id; private String name; private int state = 0; // <<<<<<<<<<<<<<<<<<<<<<<<<< private Map<String, Object> parameters = new HashMap<String, Object>(); private Map<String, Object> results = new HashMap<String, Object>(); private long processInstanceId; // .... } And yes, it is framework concern from both angles. /Anatoly -- View this message in context: http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WOR... Sent from the Drools - User mailing list archive at Nabble.com.

my point exactly. "state" IS there in framework's ProcessInstance AND in framework's WorkItem, hence it IS a framework concern [it is a framework DSL]. Therefore it needs to be addressed by straightforward clean and simple APIs. /Anatoly -- View this message in context: http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WOR... Sent from the Drools - User mailing list archive at Nabble.com.

Anatoly, I've not been able to check the user list for about a week, and it seems you have been wondering about this issue for a while, so let me try to summarize a little. I'm sure I won't be able to answer all questions in one email, but I'll give it a shot ;) First of all, your use case seems to be that you want to write your own handler for managing human tasks, and that is just fine, the system is implemented to support this. That said, what you are trying to do is (from an architectural perspective) probably quite similar to how we implemented the default human task service implementation (and handler associated with it). So recommendations to take a look at that are probably very good ones, you might not be able to reuse code directly, but understanding how that works might give you a better understanding of your own use case as well. So how does it work? It's actually not that difficult. A work item is created when some unit of work needs to be executed externally (either synchronously or asynchronously, like for example a human task that needs to be performed by a human actor). That work item is then handed to the work item handler for execution. The work item handler should simply notify the session when that work item has been completed using ksession.getWorkItemManager().completeWorkItem(..). How you do that is totally up to you. But let's take a look at a human task service as an example. Basically, what usually happens is, when a work item is passed along for executing, some kind of user task is created somewhere (in a persistent manner) so that, whenever the human actor uses some kind of human task client to access his task list, the task will show up there. Since you decided to not use the default implementation, you're completely free in deciding how to do that. There is however one important integration point, as the engine needs to know when the task has been completed (to continue the flow). So you need to make sure that, if the human actor somehow indicates that the task has been completed, that you notify the session that the task has been completed using ksession.getWorkItemManager().completeWorkItem(workItemId, results). Only one question left I think: what is this ksession and what is the workItemId? First about the ksession: this all depends on your architecture, basically how many independent instances of the engine are you running? For example, if you use a centralized process engine, you for example only have one session (executing all processes), which is active all the time. That session is for example registered in JNDI, can be accessed as a web service, or whatever. If you have multiple sessions (like for example on session per active user), than the session you are looking for could either be already active (in which case you have some session pooling mechanism, so you should use that) or you should recreate the session from the state that was persisted in the database last time it was active. To do that, you need the session id. The session id is usually linked to the context (e.g. if you have one session per user, user-id and session-id are linked and should be stored somewhere for lookup in case the session needs to be restored). Next, the work item id. This is simple, as whenever a work item needs to be executed, it has a unique id. When it has been completed, you need to use that id to tell the engine to continue. So how do we know this workItemId? There are numerous options: a) Set workItemId as a property of the user task. This is what we do in our implementation, we just create a human task and that object contains the workItemId, so whenever the task is completed, we simply take the associated workItemId and tell the engine. Now it seems that your use case would not allow you to store the workItemId as part of the user task that you are creating (you seem to indicate that this would be a terrible choice, to add low-level data like this to your domain objects, but you shouldn't see it like that, your domain objects don't need to know what it means, it's just a way to add correlation data). Too bad, as that is the easy solution, but still, no harm done. b) In this case, I assume that your user task object has some kind of unique id as well. So we need to make sure that we can map that unique task id back to the workItemId. Since you refuse to put the correlation info in your domain objects, two alternatives are left: put it in the work item (our model) or put it in neither of the models but store the correlation external to both models * In theory it is possible to simply store the unique task id as a (result) parameters of the work item, so it gets stored as part of the work item object. If a task has been completed, you should look up the work item that has a task id parameter equal to the one that has been completed, and then complete that work item. Problem with this approach is that it is not a common use case (at least, from what we've seen so far), so our implementation does not provide a simple interface you can use to do that. It is possible though, and if you're interested, we can try to assist you (if you're willing to contribute back ;)) * Another simple alternative is to simply store the mapping external, just create a simple table that maps the work item id to the task id. And use this table to look up workItemId if a task has been completed. Not exactly the most difficult job to implement that in a work item handler I assume. If you cannot store the workItemId as correlation data in your domain model, this would probably be my second best choice. Again, if you're interested, we can try to assist you (if you're willing to contribute back ;)) So, I don't think you really need a "processInstance.getActiveWorkItemNodes()" method. Because, even if you had that, you would still need to know the processInstanceId (and if you know that, might just as well include the workItemId there as well) and you still wouldn't be able to figure out which one it is you actually need if there are multiple active. But even if this method would be all you ever needed, sure, the api is all there to do what you need. You probably want to hide the details by using a utility class, but the info is there. Do we provide this out of the box? Currently, no, sorry. We try to follow the 80/20 rule, hoping our implementation supports 80% of the use cases. The other 20% can use the lower level api to do what they need. And it's so easy to use a utility class or wrap the current implementation that it might not even be worth the effort. As the use case of the next user is always slightly different, so we would end up with a zillion of similar methods to inspect runtime state, while we already provide access to this as a POJO tree (though, coming to think of it, a visitor pattern could definitely work out here). But, again, if you're interested, we can try to assist you (if you're willing to contribute back ;)) Finally, try to be patient, and be gentle to the people that are trying to help you on this list ;) Most of them do it in their spare time and for free. Simply repeating questions several times won't necessarily help, people will try to help you if they can, and if no-one seems to know the answer, there's always the option to come and chat to the developers on our irc channel ;) I also noticed you are trying to help other people, and that is much appreciated. And if you have feedback on how to improve our "high-level Drools Flow" documentation, I'm all ears ! Kris Quoting tolitius <webakaunt(a)gmail.com&gt;: http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WOR... Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

@Kris, good to see that you take a lot of time to answer in a comprehensive way Anatoly's questions. I never have time to sit down and write such a cool mail during or after 10 hours work. I'm still don't agree with him, that is our responsibility to include more high level "cleaner" APIs inside the framework, as you said before this kind of things really varies from one implementation from the other. As far as I saw in all the implementations that I worked for, they all want to have a layer (thin or not) to abstract the framework APIs, and that exactly where all those mappings, and looping using Flow APIs. Talking about ENTITIES and DOMAIN objects, probably we are mixing things here. A Human Task or something similar will be related with the Process and how we can express them, so having a work item ID information as part of the framework or another module information is still good for me. I've seen it in my implementations and it never look as a problem. By the way, if you store variables, the only thing that you will get out-of-the-box is loading that variables back, but you still need to look for them, or hardcode a special variable name. As far as repeating questions, Mark post a funny link with the mailing list rules :) On Fri, Apr 9, 2010 at 1:06 AM, tolitius <webakaunt(a)gmail.com&gt; wrote: -- - http://salaboy.wordpress.com - http://www.jbug.com.ar - Salatino "Salaboy" Mauricio -

"Manual DAO call vs. Variable Persistence": point taken. Thank you Kris. -- View this message in context: http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WOR... Sent from the Drools - User mailing list archive at Nabble.com.

Hi Ed, Cool, are you planning to implement your own work Item? What will be the main functionality of your work item? Sound to complex to implement that pattern just to keep the relationship. Did you see the WSHT module? On Fri, Apr 2, 2010 at 4:09 PM, Ed Staub <estaub(a)telcordia.com&gt; wrote: -- - http://salaboy.wordpress.com - http://www.jbug.com.ar - Salatino "Salaboy" Mauricio -

Yes, creating a new WorkItem to handle those correlations is a good place to start. On Fri, Apr 2, 2010 at 5:47 PM, Ed Staub <estaub(a)telcordia.com&gt; wrote: -- - http://salaboy.wordpress.com - http://www.jbug.com.ar - Salatino "Salaboy" Mauricio -