is it possible to access process parameters from instantiation form

1
0
-1

Hi,

I'm trying to initialize some lists in my instantiation form using process parameters.

I've tried to use the Rest API :

../API/bpm/processParameter/{{processId}}/myProcessParameter1

To retrieve the process ID, I tried to use :

../API/bpm/process?f=name={{nomProcessus}}?f=version={{versionProcessus}}

with

nomProcessus as a string = liaison TE ATA 2 ou LLO fibre dédiée

and versionProcessus as a string = 1.7

but I get no data.

Am I doing something wrong or is it impossible?

7 answers

1
-1
-1
This one is the BEST answer!

The process Id is actually available using the url parameter "id", it is the same I get from the correct API call (thanks Adrien!) : ../API/bpm/process?p=0&c=1&f=name={{processName}}&f=version={{processVersion}}

After some tests, it seems the problem I had was related to some other problems in my form. The current steps I tried in the beginning are working now, after I did many modifications:

  1. Create a variable named "processId" with the type URL parameter : id
  2. Create a variable named "myParameter" with the type External API : ../API/bpm/processParameter/{{processId}}/myParameter
  3. Get the value of the parameter by using {{myParameter.value}}

1
+1
-1

So this thread has lots of good pointers and good ideas but none really answered properly and I have been struggling getting it work.
To answer the question:

is it possible to access process parameters from instantiation form

The answer is:

Yes ! Read on

I ran some testing and here is the conclusion and some explanation about the confusion.

When you let Bonita generate a form, it tries to be helpful and it is in most cases but NOT for the init form.

You should NOT try to search your process by name, that will only lead to issues later on.

The ONLY thing you have is a form parameter called id. The generated form declares it and use it to fetch the task and taskId and processId from that. THIS IS WRONG.

What you want is a new variable:

  • name: processId
  • value: id
  • type: URL parameter

To debug, in your form, you may add a text field with the content:

  • processId: {{processId}}

When you start your process, the init form should show up and it should show something similar to:

processId: 8277182323322251349

If you do not get that, no need to move on, try finding what you did wrong. You may use a blank new test form to troubleshoot.

Now say you have a foobar process parameter you need to access. You will create a new variable for that (you can also use 2 but if you get it to work with one, you will likely manage the rest):

  • name: foobar
  • type: External API
  • value: ../API/bpm/processParameter/{{processId}}/foobar

You may add a text field to debug with the content foobar json: {{foobar | json}}

WARNING: Beware that the foobar variable does NOT contain (directly) the VALUE of your parameter, it is a JSON object that contains the value you want under the value property.

Let's add another debugging field: foobar {{foobar.value}}

And here you go, you now accessed a process parameter only with the provided id (which is the PROCESS ID and not the TASK ID in the specific case of an init form), without using smelly name based query and retrieved a random process parameter.

1
0
-1

Hello,

You can use the RestApiContext, it returns all the information, and all parameters definition + parameter value.

In the instantiation form, give the processDefinitionId (it's the id behind the URL parameters).

Best

1
0
-1

1
0
-1

Hi,

I think the approach is not valid. I explain it.

If what you want is to populate some lists on your forms, I would use BDM, kind of MasterData or ReferencialData.

ProcessParameters does not allow lists, so you will be limited to a comma separated string of N caracters (I think 255)

Cheers

Comments

Submitted by chevdor on Mon, 06/01/2020 - 20:34

If we could access the processId and reach the parameters, you could still run a query based on one or more params to fetch your list from the database.

1
0
-1

Hello,

The answer of Miguel is correct if you are only interested by the definition of the parameter, if you want to retrieve its value at runtime it won't be enough.

Your solution is the right one, but I think that you failed something when you tried to retrieve the process definition id.

In a form generated by the Bonita Studio, a variable `task` is created by default, it represents the instance of the task associated to this form.
This variable `task` is a Json object, it contains the process definition id.

So, to easily retrieve a process parameter named `myParameter` from a form:

  1. Create a new variable with the type External API named `myParameter`
  2. Insert the following API call : `../API/bpm/processParameter/{{task.processId}}/myParameter`
  3. get the value of your parameter by using {{myParameter.value}}

Adrien

Comments

Submitted by torea_1402565 on Wed, 04/01/2020 - 20:43

Thanks Adrien, but it seems the variable task is not created or created empty.

Is it because I'm in the instantiation form?

Submitted by torea_1402565 on Wed, 04/01/2020 - 20:52

For the other forms, i'm using the url parameter "id", which is the task id, to get the task details with the api.

But for the instantiation form, the id in the url does not seem to be a task id, or a process id.

Submitted by adrien.lachambre on Thu, 04/02/2020 - 12:49

Yes, sorry about that, I forgot that on the instantiation form you do not have this quick access.

You can't retrieve any task or case ID from this instantiation form, because the case hasn't been instantiated yet.

So you'll have to retrieve the process definition id by yourself.
The correct API call is:

../API/bpm/process?p=0&c=1&f=name={{processName}}&f=version={{processVersion}}

Keep in mind that you will have to update this call each time you will update the process version. If you plan to do it often, then I suggest you to remove the version filter in the API call, to retrieve like 50 results (c = 50) and then to retrieve the last version with some javascript.

Adrien

Submitted by chevdor on Mon, 06/01/2020 - 20:23

I am reading this thread and I don't see a satisfactory answer yet.

The option to use:

../API/bpm/process?p=0&c=1&f=name={{processName}}&f=version={{processVersion}}

cannot work. Here is why:

Say you have deployed 3 processes: pA, pB and pC. Each process has his own set of parameter values. They may have the same parameters or not, after all, there are different processes. Those processes use the same init form.

Now what processName would we use above? pA or pB or pC ?

What is needed here is to fetch the process parameters *related to the form that is about to start the process*. I understand we cannot use taskId since there is no task yet. Are there other ideas?

1
-1
-1

Hi,

You can retrieve process definition information (including process definition parameters) through the DesignProcessDefinition object. See below (extracted from the documentation on this topic):

Retrieve the design for a process

Process design can be retrived client side.

  • URL
    /API/bpm/process/:processId/design
  • Method
    GET
  • Success Response
    The process design object. The JSON returned is a representation of the DesignProcessDefinition instance of the given process id.
    • Code: 200

Hope it helps

best

Comments

Submitted by torea_1402565 on Wed, 04/01/2020 - 20:35

Thanks Miguel but the problem is that I cannot get the process Id.

Submitted by Pierre-yves Monnet on Tue, 06/02/2020 - 17:19

Hello,

On a instanciation form, the ID in the URL is the process definition ID

On a task, the ID is the taskId

on a case overview, the ID is a caseID

on a archive case overview, I don't remember if the ID is the caseID or the 'archive case ID' (when the case is archived, it receive a new ID in the archive table)

So, you can use this REST API when you are in the process instantiation form. If you want to reuse the same form for the instanciation, tasks and overview, it's become more complexe and you have to do some javascript to access the processID.

That one of the advantage of the REST API CONTEXT : you give it to her the ID, and it will find for you all the information (processID, CaseID, TaskID, taskName, processName, processVersion and more than that). REST API CONTEXT study what is the value behind the ID. If you want to avoid any ambiguity, give it to it the URL : then the REST API know if the form is called in a process instantiation, a task, a case overview.

With that, you can really build one form for all your process, because that what you want to do in general to speed up your development and reduce your maintenance.

Hope this help,

Notifications