both org.jbpm.workflow.instance.node.WorkItemNodeInstance and org.jbpm.workflow.instance.node.SubProcessNodeInstance explicitly filter out process variables whose values are null.

we have some use cases where we'd like our custom workitemhandlers to still be made aware of those process instance variables even if their values are null.

continued discussion from jbpm5 IRC:


Oct 19 09:05:14 <krisv> jbride: the difference is if you also have a hardcoded value, so assume you set the parameter x hardcoded to "SomeValue", the mapping will then override this value _only if a value is available
Oct 19 09:07:13 <krisv> jbride: where would this make a difference for you (meaning, what's the use case where you would like to see a null value)? when is there a difference between a null value and a value not being there (key not set) for you?
Oct 19 09:14:55 <jbride>        krisv:  thanks.  i imagine there's probably more than one way to approach this ....currently, we have a custom work item handler that invokes a remote database stored procedure using the process instance inbound hashmap. nulls are legit values for this stored procudure.
Oct 19 09:17:24 <krisv> jbride: so the stored procedure has a distinction between a value not being there and a value being null?
Oct 19 09:17:26 <jbride>        krisv:  i'll have to study a little more regarding hard coded values
Oct 19 09:17:36 <jbride>        krisv:  that is correct
Oct 19 09:18:31 <krisv> jbride: maybe I can alter the code to write the value anyway if the value is not predefined (hardcoded)?
Oct 19 09:19:08 <krisv> jbride: or see if we can support the notion of a variable not set vs. a variable with null value