Bug 1126152 - VariableInstanceLog returns a String for the getValue
Summary: VariableInstanceLog returns a String for the getValue
Alias: None
Product: JBoss BPMS Platform 6
Classification: Retired
Component: jBPM Core
Version: 6.1.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ER2
: 6.1.0
Assignee: Maciej Swiderski
QA Contact: Radovan Synek
Depends On:
TreeView+ depends on / blocked
Reported: 2014-08-02 16:49 UTC by Samuel Mendenhall
Modified: 2018-12-09 18:16 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed:
Type: Feature Request

Attachments (Terms of Use)

Description Samuel Mendenhall 2014-08-02 16:49:08 UTC
The following code snippet demonstrates the issue where the var.getValue() returns a String instead of the Object instance.
The process variables modelled as VariableInstanceLog class
public class VariableInstanceLog implements Serializable, AuditEvent {
      private String variableId;
      private String value;
which stores variable's value as a String regardless of its object type

Attempt to retrieve back the variables of instantiated processes with RemoteRestAPI
Map<String, Object> variables = null;
List<VariableInstanceLog> varList = auditLogService.findVariableInstances(pid);
for (VariableInstanceLog var : varList) {
        variables.put(var.getVariableId(), var.getValue());

Looking at the source code for the VariableInstanceLog https://github.com/droolsjbpm/jbpm/blob/388beee7f8977920ee68829833685340dc15a2c5/jbpm-audit/src/main/java/org/jbpm/process/audit/VariableInstanceLog.java  it is only ever going to return a string.  

The request is to change this to return the Object instance, I assume that would require changes to the mapping so the actual object could be hydrated, or some mechanism so a custom implementation isn't require to toStringing the object to a value.  Essentially the requirement is an API to fetch the object itself instead of just the string representation of the Object.

Case ref: #01167393

Comment 2 Samuel Mendenhall 2014-08-02 19:18:59 UTC
Also note that this behavior is both for AuditService locally and obtained from RemoteRestRuntimeFactory

Comment 9 Kris Verlaenen 2014-11-04 19:15:28 UTC
No, it is not our intention to support variable value recreation based on the variable instance log.  Pluggable variable persistence could be used for this purpose.  Setting to MODIFIED so (the new feature) custom variable persister configuration on execution server can be verified by QE.

Comment 10 Radovan Synek 2015-03-25 19:53:26 UTC
Verified with BPMS-6.1.0.ER6 that using custom marshalling strategy configured via deployment descriptor inside kjar, variables can be persisted outside the process instance.

may I drop there a link to your example project you pointed me to? It illustrates the usage of marshalling strategies and deployment descriptors pretty well, Anton told me he could use an example like that.

Comment 11 Maciej Swiderski 2015-03-26 10:07:48 UTC
sure thing, use it as you like if you find it helpful

Comment 12 Radovan Synek 2015-03-26 10:13:41 UTC
(In reply to Maciej Swiderski from comment #11)
> sure thing, use it as you like if you find it helpful


Anton, take a look at [1], I have tested the same approach, the difference is Maciej's version is nicer and cleaner.

[1] https://github.com/mswiderski/bpm-projects/tree/master/jpa-project

Comment 13 Anton Giertli 2015-03-26 13:36:22 UTC

what approach would you recommend if I wanted to retrieve variable value for a process instance which has *ended* already.

For running process instance I am using:

Map<String,Object> params = new HashMap<String,Object>();
Person p = new Person();
params.put("processVar1", p);

WorkflowProcessInstance w = (WorkflowProcessInstance) ksession.startProcess("com.sample.bpmn.hello",params);

Person x = (Person)w.getVariable("processVar1");
System.out.println("var name:"+x.getName());

And I don't need to care about JPAPlaceholderResolverStrategy at all.

But what about completed? There is no relationship between entity Person and the process instance. So why would I ever wanted to use JPAPlaceholderResolverStrategy if for running process instance I can just use the approach above and for completed process instance it doesn't help me at all - of course unless I make sure that in my Entity class I also put variable name, and process instance id as attributes. And then I implement some custom querying logic, let's say in JPQL - but that seems like huge amount of work.

I guess I am confused because I don't understand the value proposition of this JPAStrategy - mainly because the entity stored in database has absolutely no relationship with the Process Instance which persisted it and there is no out-of-the-box jBPM API which can help me to get this entity.

Can you please give me some use cases / scenarios (I don't mean code) where we should recommend this option to customers?

I understand what this strategy does - I don't understand what it's good for.


Comment 14 Maciej Swiderski 2015-03-26 14:11:48 UTC
Anton, main use case (in general regardless of the type of the strategy) is that it shall be used when process instance is not owner of the data. That means if data can be changed outside of the process instance then you should use variable persistence strategy.

Moreover process instance id or variable name should not be part of the variable you persist externally - that simply breaks the idea of decoupled data. Imagine case where you have order entity that is stored in some order management db/system. Then why would you like to "corrupt" it with some internals of process engine/process definition that uses that data?

So to recap, use variable persistence strategy when you have some other systems/components that are considered master system of that data and process instance must have access to always latest version of that data to properly process it. At the same time process instance can modify that data as that is primary responsibility of process instance - produce some results.
Then don't expect that you will be able o find such data from within process instance same way you would for process variables owned by process instance, this is because strategy is all about persist and load operations, it does not provide any searching capabilities. If you need those you would have to extend the logic by custom listeners that can store (in any way) relationship between process instance and given data. Though not sure that makes much sense....

Hope this helps

Note You need to log in before you can comment on or make changes to this bug.