Bonita 7 / Initialize contracts attributes



Contracts seem to be the expected way to define how data are exchanged between a process and forms. Operations let handle post-processing, after a form is submitted, and pass back incoming values into process state variables (business objects or just variables).

But I've not found any way to initialize contracts attributes from process variables before a form is call.

Any idea ?




Submitted by yannick.lombardi on Thu, 06/25/2015 - 10:57

I have the same problem. I try to initialize a field with my variable by adding the value of my business variable in the json but it doesn't work.

I try this for my formInput :

  "businessVariable" : {
    "name" : "{{}}"

It display {{}} instead of the value.

Submitted by ephemeris.lappis on Thu, 06/25/2015 - 11:43

I've also tried to set it the same way, and it doesn't work... I've tried to dot it using an intermediary variable set by external API, but the input JSON seems to be evaluated before, and thus no way to get the process variable value to set contracts elements...

No more ideas ? :(

2 answers

This one is the BEST answer!

Hello @ephemeris.lappis and @yannick.lombardi !

You can initialize a contract input with a UI Designer form as follows.

UI Designer variables
formOutput | return { 'c_text': $data.varText.value }; | Javascript expression
task | ../API/bpm/task/{{taskId}} | External API
taskId | id | URL parameter
varText | ../API/bpm/caseVariable/{{task.caseId}}/varText | External API

Text input configuration
Value | varText.value

where: - "c_text" is the contract input name - "varText" is the Pool's variable name

Basically use the bpm/caseVariable REST resource to get a Pool's variable value. Then use this variable as a form's widget value.

Hope this helps.


Submitted by ephemeris.lappis on Thu, 06/25/2015 - 13:15

I'm afraid it doesn't help :(

What you describe seem to force the contract's output field value with the process variable value, and this is actually what it does when the form is submitted, since the input field is ignored...

What I try to do is to set the input field, form the contract, with the process variable, when the form input is initialized before the form is displayed and filled...

Perhaps I've not understood...

Submitted by Truc on Thu, 06/25/2015 - 13:54

Hi, what I described should do the following: - given a process variable "varText" with current value "Hello world!" - given a task "Step 1" with contract input "c_text" - "Step 1" is mapped to UI Designer form "MyTaskForm" - "MyTaskForm" contains an editable text input widget which initial value is the current value of "varText" - when I submit "MyTaskForm" to execute "Step 1" the new value of my text input is sent as contract's "c_text" input

Here's the form's configuration ("MyTaskForm"):


I may have misunderstood what you are trying to achieve.

Submitted by yannick.lombardi on Thu, 06/25/2015 - 14:17

@trucngn I try your solution but now I can't edit the content of the "c_text" field. It is initialised with the value from my process variable but when I run the process I can't edit the value in the field. In the UI Designer, I check the "no" box for Read-Only. I don't understand why I can't edit the content of this field.

EDIT : Now it works. I had a javascript error.

Submitted by Truc on Fri, 06/26/2015 - 14:16

Hello @ephemeris.lappis, Did the screenshot help? If you managed to achieve what you expected (it looks OK for @yannick.lombardi) you may probably mark this question as Resolved? Thanks.

Submitted by ephemeris.lappis on Tue, 06/30/2015 - 09:20


No, I have still problems to make it work.

I've added this to variables :

mvRequest       ../API/bpm/caseVariable/{{mvTask.caseId}}/request       External API     
mvTask  ../API/bpm/task/{{taskId}}      External API     

And I've tried to use a request field that may have been filled on previous iterations of the same task to initialize the binding of the input widget :


But I have an exception in the logs, that says that the case variable is not found :

GRAVE: Error while getting case variable
org.bonitasoft.web.toolkit.client.common.exception.api.APIException: Error while getting case variable

Perhaps what you say only work for plain process variable, and not for business objects ? In ly case, "request" is a business object with several attributes, and "answer" is the field that may be given multiple times depending on iterations...

Thanks for you help.

Submitted by Truc on Tue, 06/30/2015 - 09:39


If you need to retrieve a business object then use the context resource. The context resource will give you a link to the business object. (@see the userTask context resource documentation)

If you need to retrieve a pool variable then use the caseVariable resource. (@see the caseVariable resource documentation)

Submitted by ephemeris.lappis on Tue, 06/30/2015 - 10:07

Hello again !

I've changed it with that set of variables, using the context's "request" business object :

context /bonita/API/bpm/userTask/{{taskId}}/context     External API     
formInput       {
 "answer" : "",
 "ok" : false
 }      JSON     
formOutput      return { 'answer': $data.myRequest.answer, 'ok': $data.formInput.ok };  Javascript expression    
myRequest       ../{{}} External API     
taskId  id      URL parameter    

And the widget is set with :


It seems to work : Yes !

But I'm not very sure I've understood all what is done "under the hood"...

First, the syntax to access the reference of the process business object "" is not trivial.. Second, at the end of the form, I've an operation that set the "request.answer" with the form's contract "anwser". Is it actually needed, or the value is directly set by the form ?

Thanks for your help.

I'll mark the question as answered !



the basic concept is that a task (or a process) is offering a context to the form (read only) and the form is submitting values to a task (or process) contract.

Your form can leverage all the context information and must respect the contract at submission. So far, the context is not extensible. By default, it is exposing the business data and teh documents. We plan in a coming release to make it configurable so that you can add any entry of your choice. From a best practise perspective, make sure you do not put too much process data in the context because it make you loosing most of the added value of this context/contract feature. The idea behind this feature is to ease collaboration between process developers and views developers. Once the contract & context are defined, bot of developers can work on their task and change whatever they want as long as context & contract remain unchanged. Now you easily see that too much process variables breaks this concept because any change during the process development will impact the context and as a consequence break the collaboration.

Hope this helps, Charles