Bonita 7 / Are business objects (BDM) accessible in the process overview page

Hello.

My first test process with Bonita 7 uses a business object to model its main data elements, and uses contracts for tasks pages. In all the tasks pages, the business object is available, using a variable of type “external API” like “…/{{context.request_ref.link}}” where “request” is my process object, and forms fields can refer to the needed elements through the variable.

This seems to work in all pages, except for the “overview page” of the process. I’ve tried to use the same form in a human task and for the overview page to check its validity, and fields are displayed with their current value in the task, but appear empty in the overview.

Is it a known limitation, or a bug ? In the first case, how can I display the data state of my process in the portal if the business object is not available to do it ?

Thanks for your help.

Regards.

1 Like

Hello @ephemeris.lappis,

If I understand well you are using the same form as overview page and as task form right?
Then I think the problem is that the “context” variable has to be retrieved differently.

  • On a task form, “context” should be retrieved with …/API/bpm/userTask/{{taskId}}/context
  • On an overview page (case level), “context” should be retrieved with …/API/bpm/case/{{caseId}}/context or …/API/bpm/archivedCase/{{caseId}}/context (“caseId” being the id URL parameter on an overview page).

So you could probably use 2 separate forms, one for tasks and one for overview.
Or for instance use the “_p” URL parameter used by Bonita BPM Portal (_p=DisplayCaseForm or _p=performTask) and build the right External API URL for context.

Hope this helps.

Hi! I am working with Bonita BPM Community 7.1.2 version.
When I run in the portal a process I can not see the over view page with the Administrator profile. It shows the error: “403 forbidden”. Where I have to configure the permissions of the page?
Why this version does not autogenerate the overview page?
Thank you very much!
Regards!

Ah the infamous first page of a process dilemma…

I don’t speak for BonitaSoft here but I suspect it’s the same as 6. The first page (overview as you call it) is not actually a part of the process case. Its function is only to describe the underlying process which will start with step1.

For example, you start the process, you get the overview and based on the description (that you provide) you decide either to proceed and the case is created, or cancel and no case is created.

Can you imagine how many people start something and on reading the first step decide this is not what they want? If the case were started without the overview page there could be thousands of hanging cases…

Well that’s my thinking anyway.

The way to stop this page is to start the process and assign it programatically, via script etc. Then when the user takes the task, they go straight to step1 bypassing the overview page.

regards

In my understanding, the overview page is the one that is used in the portal’s administration pages to display the process state, not for starting new instances. In previous versions of Bonita, administration pages show processes data. It seems that 7.0 does not, and a overview page, if I’m right, must be designed and configure for that.

Perhaps I’m wrong ?

I may be having a simular issue of no access to the business object inside a connector SQL.

[http://community.bonitasoft.com/answers/bpm7-how-pass-variable-business-model-instance-database-connector]
[http://community.bonitasoft.com/answers/bpm7-how-pass-variable-business-model-instance-database-connector]: http://community.bonitasoft.com/answers/bpm7-how-pass-variable-business-model-instance-database-connector

@ephemeris.lappis apologies - yes I see what you mean now, I got confused because not once did you say administration in the original question. To me it read as the process pool page…

Someone from Bonita should clarify this answer I think…

Hello.

In deed, the form variable is defined with the API call I’ve seen in Bonita’s example : “…/{{context.request_ref.link}}”, since the context is supposed to be provided by the engine to the form.

I understand that perhaps the API call may be different for archived cases. But in my case, as I said, I use the same form for a task and the overview, but this last doesn’t work even for live processes.

I will try to create a duplicate form for my overview, changing the context variable setting (/bonita/API/bpm/userTask/{{taskId}}/context) with one of the API URL you say… I understand that this overview should use a different URL depending on the state of the process : live or archived. Is it right ?

The remaining question is : why Bonita 7 doesn’t provided anymore a default data view as previous versions did to inspect processes state along their life, from the start and from task to task, until their ending ?

I’ve done some new tests with you URL (…/API/bpm/case/{{caseId}}/context), using the same expression to access my variable (…/{{context.request_ref.link}}), but nothing…
I’ve tried to change the URL with “/bonita/API/bpm/case/{{caseId}}/context”, since the task URL doesn’t use a relative URL, but it doesn’t work…
What did I forget ?

Hm… I guess you defined the “caseId” variable as “taskId” (ie. taking the “id” URL parameter)?
Then is the “context” variable populated? Any relevant HTTP request error observed?

Yes, the logs trace an exception :

Caused by: org.bonitasoft.engine.core.process.instance.api.exceptions.SFlowNodeNotFoundException: Flow node instance with id 19 not found

I don’t know what the 19 is, but according to the portal page, the process case id should be 24…

My form variables are :

context /bonita/API/bpm/case/{{caseId}}/context External API
formInput { } JSON
formOutput return { }; Javascript expression
myRequest …/{{context.request_ref.link}} External API

and the widget bindings are like : “data:myRequest.iterations” where “iterations” in this example is an attribute of my business object, which is displayed as expected when the context is found in a task form…

More ideas ? It seems that we’re going the right way ! :wink:

Thanks for the details. I’m confident we’re on the right way :slight_smile:

I can’t see the “caseId” variable declaration in your latest comment. Is it that you omitted in the comment or in the code as well? You have to declare a caseId | id | URL parameter variable too.

Also any request errors you might want to check are captured in your browser’s development tools where network activity is traced. At this point I am not expecting to get relevant information in Bonita web application logs.

That’s it !
I’ve just understood what you mean and my error : the “caseId” variable is not set in the default form, and it must be set, instead of the “taskId”, using the URL parameter “id”.
I’ve added it, and remove the taskId, and the URL is now correct, the context retrieved and widgets filled as expected with my variable attributes…
Thanks a lot.

What I’ve not understood : what happens when my case is terminated : should I change the context URL to look for archived cases ?
In truth, Bonita should handle this itself with no need for us to make overview pages for each phase of the processes lifecycle…

Regards.