[ https://jira.jboss.org/browse/JBRULES-2608?page=com.atlassian.jira.plugin... ] Anatoly Polinsky updated JBRULES-2608: -------------------------------------- Attachment: passing-list-process-test.png attaching maven test project + some screenshots to be more explicit. /Anatoly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBRULES-2608?page=com.atlassian.jira.plugin... ] Mauricio Salatino commented on JBRULES-2608: -------------------------------------------- Hi man, how are you? I saw the test that you send to us, and works as expected. The idea of defining an out parameter inside the workitem mappings force you to send the value in the manager.completeWorkItem() parameters. If you don't want that behavior you can remove the mapping and the process variable will be never removed. The concepts of in and out parameters mappings are decoupled, and you should not suppose that the in mappings will be copied automatically to the work item results Map. I will try to explain the idea behind that semantic: 1) You have a work item that it's linked to a WorkItemHandler that it's out side the scope of the process. 2) the drools runtime environment let you copy the values from process variables to workitem variables. This can be used to reduce the scope of the information that is used inside the process and also to provide to your external logic some initial values. As you may know this information it's persisted in the database using a variable persistence strategy. No matter if the workitem is synchronous of asynchronous, this information it's persisted to keep track of the information that the work item receives. 3) if your work item is synchronous (because you decide that) you must fill the results map with all the defined out mappings defined in your process definition (xml). If you not define one of them, the process variable will be filled with null. And makes perfectly sense, because your are saying (with the out mapping) that the work item should send out the defined variables. Beware, the out mappings doesnt mean in anyway that the in mappings will be copied automatically if you don't put nothing in the results. 4) If your work item is asynchronous (because you decide that), the one incharge of completing the work item should add the defined out variables / results in order to be able to replace accordingly the process variables. I think that this definitions makes more sense with a simple example: Imagine that you have a process with a human task only (asynchronous work item). The in mappings defined are used to draw the UI with information that the person assigned to that task needs in order to review/see in order to add more information before completing the task. Because the asynchronous nature of the task, the complete or end button in the UI will have the responsibility to gather all the information in the screen (or at least all the information defined in the out mappings) and call the manager.completeWorkItem(id, results) method to be able to end the Human Task. In the case of an external call (notice the word external in bold), you can call the service using the in mappings values, and then based on the results that you get from the call add to the results Map all the things that you define in the out mappings. As I mention before, the relationships between ins and outs are totally external from the framework responsibility. You are in charge of handling which pieces of information needs to move from the ins to the outs, but the framework will not do that for you. Of course, that we are open to evaluate a real use case that with the previously described functionality cannot be accomplish. If you have one of this use cases, with real information (that give us the semantic of the use case) we will evaluate the best way to achieve it using the semantic defined by the framework. Greetings -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBRULES-2608?page=com.atlassian.jira.plugin... ] Anatoly Polinsky commented on JBRULES-2608: ------------------------------------------- Mauricio, Thanks for the response. I believe there is a slight misunderstanding. Let me try this in a simpler form: GIVEN: "An ArrayList<String> which is a process wide variable" GIVEN: "Three WorkItems" GIVEN: "All workitems need to access this list" GIVEN: "First workitem calls external system and changes/populates this list" GIVEN: "First workitem completes by providing this list as a result parameter" GIVEN: "Second workitem picks this list up (no problem here), does something else, and goes to sleep" [ the changed list is PERSISTED ] GIVEN: "Second workitem is completed externally [ loadStatefulKnowledgeSession => session.getWorkItemManager().completeWorkItem(.. .. ..) ]" PROBLEM: "Third workitem needs to pick up the same list that was PERSISTED and is not able to do so" LOOKING FOR SOLUTION: "To access the (previously persisted) list by the third workitem" Thank you, /Anatoly P.S. Again: "Persistence in computer science refers to the characteristic of state that OUTLIVES the process that created it". The whole point of persisting the variable is that you can RESTORE it later on. At the moment of completing the workitem we rely on the fact that Drools understands what persistence is, and, at that moment of completing the workitem externally, we _do not have_ the list, because, it is PERSISTED in the data store, and we expect Drools to RESTORE it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBRULES-2608?page=com.atlassian.jira.plugin... ] Anatoly Polinsky resolved JBRULES-2608. --------------------------------------- Fix Version/s: 5.1.0.FINAL Resolution: Done -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBRULES-2608?page=com.atlassian.jira.plugin... ] Anatoly Polinsky closed JBRULES-2608. ------------------------------------- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira