In my process, I have created a variable with table name and column name combination like below:
sample variable name : loan.customerName
But when I try to resolve this variable in gate or service task mapping I am getting below error :
org.camunda.bpm.engine.ProcessEngineException: Unknown property used in expression: ${loan.customerName}
Cannot resolve identifier ‘loan’.
On troubleshooting, documentation suggests not to use . as a part of variable name.
Is there a way to escape this . to treat my variable name as whole instead of property.?
I’m not aware of a way to escape the variable name so that . can be part of the variable name.
Using . as part of a variable name is not a good practice. It will cause issues in almost every programming language, and will cause you frustration later when you’re trying to use complex variables (think of a complex variable “loan” that has components “amount”, “issuer”, “customerName” … how do you remember when loan.customerName is the simple variable or the component of the complex variable)
2 Likes
Hello @kalpeshdlad ,
I like the response of @GotnOGuts , you should not use „.“ as part of a variable name as it is a reserved character in expression evaluation.
If you are bound to this in some way (dependencies towards other teams, …), you could use ${execution.getVariable(„loan.customerName“)}. This is a kind of escaping you are asking for.
Jonathan
3 Likes
Thank You for suggestion.
I understand risk you are trying to highlight. The reason I have keep variable name like this because its easy to identify/distinguish properties where it belong. For me “loan.customerName” nothing but a primitive type only, e.g. String.
I will have no case where I want to store object itself and want to access its component like “loan.customer.firstName”. For me, this will be again String variable only.
Given that do you think I will face more issue in other places as well other than mapping to Service task or I can overcome this syntax issue in someway.?
I want to understand if using this variable naming convention will be issue or I am ok with understanding that I will not be storing complex variable at any time.
I would strongly recommend against that.
You will likely run into issues in multiple places, since “.” is a reserved character in almost every programming language. When you try to start building the Service Task workers, you will have to try to figure out how to escape the variable names there as well. There will likely be issues when trying to pass variables back and forth.
Simply put, it is not good practice to use “.” in a variable name.
1 Like