At every customer I work with I have the ethernal fight between UX / UI flows and the BPM processes flows on how the user should work when BPM is used:
The BPM calculates who is the person to review a particular buyer
A User Task is assigned to the reviewer calculated
The user submits its review and the system perform a sanity check
From BPM perspective, I always want the BPM to enforce the rules (obviously) and generate a new User Task accesible from the task list that they can check which rules failed and to re-submit their task. .
However, from the UI perspective they want a more real-time interaction where when the user submits the user task, then the rules are executed and informed back to the user directly staying in the “same” User Task UI.
What we could do:
A) Execute the same rule from UI and BPM (twice times) for achieving this behaviour
B) When submitting the User Task (complete task) make an active listening to the BPM process to check its progress executing the sub-sequent activities and then reply synchronously back to the end user with the rules failed and the new task_id
C) More advance solution based on Web Socket real-time communication
The purpose of this topic is for the community to share which are your experiences or how do you usually tackle this common use case where the UI / UX needs to behave more real-time instead of the behaviour of submit and a new task will appear in your task list.
If the client’s requirement is to have the result of the business rules evaluation showing up in the form (the same activity “user task”) then I believe the best practice would be to call the DMN evaluation REST API from within the UI separately (no link is defined between BPMN definition and DMN definition)
As an example:
Discount Policy is defined as DMN definition and the total amount is required as input. In this case, the user expects to see the resulting price reflected every time a change is made to the shopping cart.
Thanks @hassang for the time of sharing your feedback.
I partially agree with you, but maybe I did not explained my use case perfectly.
In my case the DMN is a critical business rule to be enforced before some critical updates happens in the system in subsequent steps of the process (which I did not reflected in the BPM example).
I want to avoid backdoors where a Camunda API completeTask or Cockpit complete overpasses critical rules because the DMN is only invoked in the UI.
In addition, I have the feeling that if I make the UI to be the only one calling the DMN (and not the BPM) that we are tightly coupling the UI to enforce critical decision which should be part of the business layer.
We are already exposing the DMNs to the UI so they can already enforce some rules prior submission to the BPM. But, I had the feeling that we are wasting resources and performance by doing it twice. My thinking to avoid this situatio was in a way that when a User Task is submitted / completed through our REST API facade we active listen the rules enforced in the BPM and provide a feedback back from the BPM (instead of making the particular call from the UI) to avoid the duplicate calls.
In my current project we are doing option A) for now, that’s why I wanted to see other people cases.
One option to consider is being quite dynamic about how to call the rules and move a little bit of the enforcement to the front end. With a model like this:
In this example you can imagine that the front end has two buttons Complete and Validate
Complete by default could be deactivate until a variable from the DMN table returns with a required result. It would be the responsibility of the user to click the validate button without actually moving the state away from the task they’re on. Instead it would trigger the DMN table which should update the context variables and display new info to the user.
I believe usually the option you went with is the best option in your case because following the option of providing feedback from BPM using the same UI can lead to more complexity in cases where new tasks (new Ids) are created as a result of business rule task being completed or you can follow the solution suggested by @Niall which can to some extend solve your problem.
Hi, @dmerchang . I have also been seeing those situations for a long time.
What If we just put BPM/BPMN/Camunda aside and ask ourselves what the UX/UI requirement really is?
The user wants to complete the task and then take another action based in the result of the flow that follows that activity. That includes one validation - it could be the case of multiple validations instead, maybe some long-running ones, maybe with other intercalated human-tasks.
I guess this user needs to access information that exceeds the scope of one single Task Form. Is it really about a "same User Task UI* " or something else that wraps them?
Keeping Camunda aside, the user what they want is that when they perform a certain action on the task UI then the business rule validations blocks the submission of the task itself and the interaction is completely in the same screen.
UI / UX requirements are:
When submitting a task, if there is any business rule which will make the task to comeback to the user, then enforce it and communicate back to the user in the same screen if they can submit or not that particular task.
So basically we have an endpoint exposed which is SubmitParticularTask which basically have two steps, execute the business rule and then execute the completion of the task in this case.
I guess this user needs to access information that exceeds the scope of one single Task Form. Is it really about a "same User Task UI* " or something else that wraps them?
I do not know if I fully understand this sentence. I think there is nothing beyond the Task. They open the Task from the task list, they make changes to the data and submit. During the submit, there are certain tasks that will require certain business rules to be enforced.
Traditional behaviour would be, you submit, bpm executes the subsequent steps on the process and if there is a business rule breach the a new task is generated with the list os issues.
Current user desire is, you submit and you have a validation which blocks your submit, or keeps you in the same UI task. But, the rule is tighly-coupled to the business process and we want the business process explicitly show/enforce the rules. If tomorrow we decide to uncouple our Facade API for the UI, then the process will still run and enforce the corresponding rules which are necessary.
