How to set java object as variable

Camunda 7 Topics Discussion & Questions
1

Hello

I have a bpmn process where I would like to use an Java object as a variable. In the bpmn process I would like to set the object value in the process. When I try to set in the process the Camunda create a new variable instead of set the existing value.

Here is my object:
public class Test implements Serializable {

private static final long serialVersionUID = 1L;
private String first;

public String getFirst() {
	return first;
}

public void setFirst(String first) {
	this.first = first;
}

}

Here is my example code:
Test test = new Test();
test.setFirst(“first”);

	Map<String, Object> variables = new HashMap<String, Object>();
	variables.put("test", test);
	
	String id = pe.getRuntimeService().startProcessInstanceByKey("test", variables).getProcessInstanceId();

I have attached the BPMN as well.

Do you have any idea how can I set the object with a the BPMN?

I found a workaround with a script task I can create a test object and set into the map but I would like to use a simple variable mappings if it is possible.
test.bpmn (3.7 KB)

Thanks in advance: Gábor

2

I think you’re looking for a feature Camunda provides via their CDI support:

see @BusinessProcessScoped beans

from their user-guide: “Support for @BusinessProcessScoped beans (CDI beans the lifecycle of which is bound to a process instance)”

3

Hello

I use Spring but the DI is the same :slight_smile: . I can use the variables from
Java. My problem is that in BPMN I am not able to set the java beans ony if
I use Groovy.
If I use def test = new Test() … execution.setVariable("test“, test).It
is working but if I use execution.setvariable(“test.first”, example), the
Camunda will create a new variable as test.first as String and not set the
test object.

Regards: Gábor
2016.11.13. 15:13 ezt írta (“Gary Samuelson” forum@camunda.com):

4

Though Spring is similar… I’ve completely switched over to the CDI model for Java development - includes Camunda.

So, in a scenario using CDI - goal being process instance scoped objects:

NOTE: I’m doing most of this example free-hand - there may be typos.

Define a java-bean using @BusinessProcessScoped…

@BusinessProcessScoped
@Named("myProcessScopedBean")

As a ‘sanity’ check… I include a constructor with a log (during early development) just to make sure it’s working correctly.

public MyProcessScopedBean() {
		super();
		LOGGER.info("*** MyProcessScopedBean created");
	}

Then, from within your process model, call on the bean as an expression:

#{myProcessScopedBean.setSomeValueProperty(execution,"someValue")}

Camunda should find the bean, and then it’s up to the bean itself to add your value. If the bean isn’t available, then it’s created per each process instance. I tend to always pass in the DelegateExecution context - but, this is a matter of preference since it’s also available via one of the other built-in Camunda services (I think it’s RuntimeService - if I’m remembering correctly).

// inside the bean: basic setter
public void setSomeValueProperty(String someValueProperty) {
	this.someValueProperty = someValueProperty;
}

Now, on the other hand, If I’m directly managing process variables within the bean, I use the following:

// NOTE: example setting JMS reply-to temp' queue
@Inject @ProcessVariable("jMSReplyToName")
private Object jMSReplyToName;

One slight catch when injecting process variables is that I haven’t been able to directly set values - don’t know why. But, workaround is:

execution.setVariable("yetAnotherProcessVariable", "foo");

Getting the value is easy. I only use the “setVariable” workaround as needed. Not sure if this represents a bug or simply my error).

Camunda, or container, will passivate the objects as needed. And, for this reason I tend to avoid using BusinessProcessScoped beans. This avoidance based on my concerns regarding scalability. I also like using CDI or any event infrastructure for that matter… And, I prefer to avoid worrying about objects streaming back-and-forth, into/out of stores. This is a matter of preference - my preference. There are good reasons for using objects (the obvious being general object-oriented design principles).

To summarize, I prefer basic Camunda’s Process Variables for passing context/values between task implementations (as a general rule - there’s also singletone for such things as config/timer/etc…). Structured data (i.e. JSON) follows JSON-infrastructure such as Jackson. If you’re considering scaling to server clustering, it’s something to keep in mind.