[jboss-jira] [JBoss JIRA] Commented: (JBRULES-2608) Variable Persistence Overwrites NULL Values over Persisted Values

[Mauricio Salatino (JIRA)]

    [ https://jira.jboss.org/browse/JBRULES-2608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12543594#action_12543594 ] 

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 

> Variable Persistence Overwrites NULL Values over Persisted Values
> -----------------------------------------------------------------
>
>                 Key: JBRULES-2608
>                 URL: https://jira.jboss.org/browse/JBRULES-2608
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions: 5.1.0.FINAL
>         Environment: N/A
>            Reporter: Anatoly Polinsky
>            Assignee: Mauricio Salatino
>         Attachments: difference-between-first-and-second-work-item.png, drools-vp-jira.zip, passing-list-process-test.png, passing-list-process.png
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Drools Flow
> =========
>    For non-String variables (Serializ..ble, Entities, etc..), Drools overwrites NULLs when a (JPA) process is resumed ( a workitem is completed ).
>    1. Here is a use case: a List ( ArrayList ) is passed to the process in start as a parameter 
>    2. First work item sees ( maps in ) the List, and can work with it inside the work item handler
>    3. First work item does not complete: process goes to sleep.
>    4. When the session is reloaded, the first work item is completed
>    5. All the persisted variables ( including the "list" ) are restored
>    6. Second work item is taking in the list ( it maps in )
>    7. However at this point it is NULL
>    It seems that when the context is closed, after resolving variables, the following (WorkItemNodeInstance):
>             VariableScopeInstance variableScopeInstance = ( VariableScopeInstance )
>                     resolveContextInstance( VariableScope.VARIABLE_SCOPE, mapping.getValue() );
>     does no longer have the restored variables, and rather NULLs, since internally variables are compared with a "result map" that was passed to the previous work item.
>     This means that persisted variables are restored internally, but then overwritten internally by NULLs.
> /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