Heads Up - Bonita BPM 7.0 UI designer - great idea, poor implementation

Hi,

First of all thank you for taking the time to provide such detailed feedback.

You will find below some solutions and workarounds to your questions.

Sometimes you’ve spotted some limitations that Bonitasoft has also identified and already plans to address.I will try to provide some insights about ongoing discussion and possible solutions that will come up in future releases.

User profile for process based application development

First I’ll clarify the expectation we have for our users about their technical skills.

Bonita BPM version 7 provides an environment to develop process based applications. For this, two different user profiles are expected to be involved:
Business analysts
Developers

We expect business analysts to be able to do BPMN modeling and (eventually also) some UI mockups.

Meeting end users’ expectations in terms of richness and dynamic user interfaces is a big challenge. Software that can be used by non-technical users usually has strong limitations when it comes to customization, and leads to creation of user interfaces too far away from what end users need and want (as we learned, is the case with Bonita BPM 6).

So, with UI Designer, we created an extensible tool for developers to build UIs that meet the final business analysts and user expectations, to help real adoption of the new application. We expect business analysts to work and collaborate with developers by designing mockups with the UI Designer.

Benefits of the new architecture

The new architecture with a clear separation between UI, process definition and business data model is something that bring key benefits in collaboration and evolution of applications.

Once contract and data models are defined, the UI designer and process developer can work independently. This makes collaboration a lot easier compared to a solution that bundles user interface and process definition together and more or less simultaneously.

Also the loosely coupled architecture bring new capabilities for live update after deployment. This is something that really sets the Bonita BPM solution apart - by enabling the system administrator to adapt of a deployed process to an evolving execution context. You can for example easily deal with situations such as: a change in company organization, evolution of information systems, various UI evolutions (because of the use of contracts), and more. With such capabilities you avoid risky and costly deployment of a whole new application.

Roadmap and releases

I’d like to share some information about the way we handle roadmap and releases.

A minor release (e.g. 7.0 to 7.1) happens every 3 to 6 months. Such releases add new features and improvements in a backwards-compatible manner. This is a key opportunity for us to evolve the platform based on your feedback.

A maintenance release (e.g. 7.0.2 to 7.0.3) happens every month (on the first Thursday of each month). Usually this release is all about bug fixes. But from time to time it might includes improvements that present a low risk of regression. Based on feedback, since the launch of version 7, we have decided to include some UI Designer enhancements in maintenance releases to quickly remove and improve current limitations.

Answers to individual points

And to address the individual points you report:

a.1 ctrl+z / undo & ctrl+y / redo

We agree that this is a major limitation in the current UI Designer. This feature is in our roadmap and should come in a future release. We are working to include this improvement in a release before the end of the year.

a.2 forms and data

When you create a form you should separate two different scenarios: data you want to display to the end user, and data that the end user needs to send for process instantiation/execution.

Data to display

Data that you can display to the end user usually comes from a business variable declared in the process definition. To bind a widget with a business variable attribute you need to know the name of the business variable and the name of the attribute.

For example, if a business variable is named “vacationRequest” with an attribute named “startDate”, you can get the business variable value using this URL: ../{{context.vacationRequest_ref.link}}, store the result in a form variable (e.g. myVar) and bind to the widget myVar.startDate.

As you can see there is no need to run the whole process. What you need is to have the UI Designer and Studio side-by-side so you can check for the names of business variables, and you need your business data model so you can look at object attribute names.

Note that if needed you can actually call the REST API to get business variable value without running a process instance.

Data to submit

When it comes to the submission of data for process instantiation or user task execution you need to use a form variable (i.e. a JavaScript variable) with a JSON object. JSON objects have associated names and values. Name needs to be set with the name declared in the “contract” and value is the actual value to send to the process (usually set by a widget).

Again here you don’t need to run the process, you simply need to take a look at the contract in the Studio.

Note that Studio provide a tool to generate the form based on contract definition.

I agree that making sure that you create a form that complies with the contract can be tricky as it relies on a specific naming convention between your form variable and contract input names. In a future version, we plan to provide completion on the context variable and on the variables used to fill up the contract. This means you should get something even easier to use than version 6.

a.3 process variables

Currently, you can update process variables using contract inputs in an operation.

If you want to display some process variables in a form, call some REST APIs, store the results in form variables and use them in your form widgets. An example is available on the community website.

Note that for most common use cases we recommend using business variables over process variables. We added this new feature to allow better performance for search operation (which rely on DB indexes), lifecycles independent of process instances (this allows several process instances/definitions to collaborate on shared data). This recommendation hasn’t changed since v6: process variables are recommended for flow conditions as their data become useless when the process ends.

a.4 form validator

Here is a list of replacements for each of these previously existing validators:

• Email: “email” type on “input” widget
• Length: you can use properties “min length” and “max length” on “input” widget
• Date: will be natively embedded in date widget in a future version
• Double, Float, Integer and Long: use “number” type on “input” widget or implement your custom validation based on a JavaScript form variable and enable a condition on submit button.
• Phone number / Groovy expression / Character: you can create any custom validation using JavaScript form variables or create a custom widget (this is the best option for easy reuse across several pages)

Currently our advice is that you should create a custom widget that lets you embed the validation directly into the widget definition. This solution lets you reuse easily a widget and its associated validation.

Another option is to use the JavaScript form variable to define your own custom logic depending on widget value and use this form variable to enable or disable the submit button.

Our aim is to provide out-of-the-box validation (similar in rendering to version 6) but with more flexibility and better performance. As this default validation will run on the client side (JavaScript), response time will be shorter (more reactive) and you will be able to debug it right from your web browser (browser development tool).

In the meantime, we plan to provide a doc page to describe how to properly use the current validation mechanism and how to extend it. This should be ready next month.

a.5 validation error message

See a.4

a.6 missing widget

You can check this table that compares widget in version 6 and in UI Designer in version 7. As you can see only the Rich Text Area widget is missing. This one is in our backlog and should come in a future version.

a.7 forms and pages management

I agree that in UI Designer the long flat list of forms and pages make it very difficult to locate a form based on information such as which process uses it. The best recommendation for now is to start from the process and choose to edit the form.

When you delete a process definition, associated forms are not deleted because a single form might be used by multiple process definitions.

A future version will bring improvement on this point, to categorize forms and pages based on which processes and steps use them.

a.8 share custom widget

Note that collaboration using shared repositories is a feature of our Subscription edition.

a.9 newForm default name

Default form names should become contextual in future release.

a.10 delete a form

This should be covered at the same time as a.7.

One temporary workaround is to edit the form (from Studio, click on “pencil” icon). In the editor window of UI Designer, rename the form (e.g. “to delete”), then go to the home page and locate the form and delete it.

a.11 list of forms in Studio

This item should be addressed at the same time as a.7 and a.10.

a.12 form not deleted when deleting process definition

See answer on a.7.

b.1 different type of variables

The basic rules to remember is: use business variables as much as you can.

Note that documentation generation is not the current top priority, but ifwe do some update here, I will make sure that we take care of including business variables.

b.2 collaboration in a large company

A use case like this is covered by Subscription edition features.

b.3 requirement for UI developer

I would say that training on AngularJS is a plus. I agree that a developer profile is a prerequisite for implementation of dynamic forms. However, a profile without a development background should still be able to build a UI mockup.