“Manager” and “clerk” are optional, Provide users with choices. There is no gateway. The “apply user” node selects one of the nodes instead of the other. For example, if “manager” is selected, there is no need to deal with “clerk”.
@luoce As @Niall suggested you should use Data based XOR gateway followed by first usertask. Based on the input from first usertask, it will make decision on the xor gateway which route it should take.
Because I hope this is a function of a process engine, and it doesn’t need to be reflected in the business form
Although I know that it is more appropriate to cooperate with XOR gateway according to form elements, I have encountered many such user needs. They want the system to tell them the possible nodes in the next step (which may be multiple), and the staff can manually select the nodes in the next step.
I have been able to show the next possible node to the staff through the current usertask, but I have not found a good way for the staff to manually select the function of the next node.
Does camunda plan to provide such functional support?
I tried some methods, such as adding a parameter to the performdefaultoutgoingbehavior () method of the bpmnactivitybehavior class, which determines the direction of the outgoing sequence flow. If this parameter is encountered, it will flow directly according to the guidance of the parameter.
But it doesn’t seem elegant, and it destroys the original nature of the engine. In this process, I also encountered other problems in the case of multi instance, parallel gateway and exclusive gateway. Therefore, I come to the forum for help, hoping to get different solutions.
Read the source code of the engine, if you encounter multiple instances, parallel gateway, it will involve more processing
For multi instance tasks, it will judge whether the tasks of the current node have been completed, and it will also process the related listeners, etc. If I add a parameter to the performdefaultoutgoingbehavior () method, I will pass this parameter in all the processing logic, and the process will become very complicated. In addition, there are many ways to change the state (including cache state) in taskentity and executionentity, which means that I can’t change the state in memory externally.
It may be ridiculous, but that’s what I’m trying to do. But now there are many problems that I can’t go any further.
So, the process engine doesn’t and probably shouldn’t be used in the way you’re trying to use it. Mostly because what you’re trying to do in “showing the potential paths for a user” gets incredibly complicated very quickly.
For instance take into account the following scenarios
Parallel tasks? How would the user know, how would selection works?
What about automated tasks? can a user select them or not?
What about events like timers or messages? How would a user deal with those.
Boundary events on tasks.
Things in BPMN can get very, very complicated and in order to ensure that your model remains testable, maintainable and dynamic you should really do your best to make sure that no task needs to know much about what has happened before it or after with. It just should be expecting some data and producing some data.
The four questions you mentioned are exactly what I met in the process of trying. Here is my opinion:
For parallel tasks, multiple process directions can not be set by convention, because the users who execute the tasks may have different opinions, which will lead to the confusion of the next process
Automation task is still a node, I think it can be selected
Timer and message class, I haven’t thought of a way
Border incident, my God, this problem is a disaster
So, I think you are right that the engine should be used in the way described in the document
I’m very glad you can give me some suggestions. I’ve decided to shelve this issue for a while. When I have a new discovery, I’ll discuss it with you. At least I need this function.
