I would kindly like to bring to your attention a use case that I have to deal with in relation to the development of a Web Application that must manage document procedures.
The architecture proposed for the solution is based on the paradigm: event-driven microservices on Kafka.
The main objects of the practice are:
- A “contacts” page, a sort of header that describes an “investigation” activity to be started.
- A series of reports or implementing decrees that legitimately justify this investigation.
- A set of procedural requests that define the nature of the investigation to be carried out.
Once the “package” has been correctly defined, consisting of the elements 1) >> 2) >> 3), the execution of the procedural requests can begin.
This output will be provided by some external implementation services (external to the WEB application)… but this is not of interest at the moment.
The WEB application will have to manage different “cases” of practices to be carried out, i.e. various types of requests for investigations: each type of practice will be satisfied by a Workflow that describes the various “executive” paths that conduct the practice from a bottom-up point of view initial state S0 to a final state Sf. according to established congruence rules: that is, each path, each instance of crossing the Workflow is obviously a semantically valid instance for the purposes of carrying out the practice.
The difficulty I am encountering lies in the fact that these WorkFlows cannot be automated in the true sense of the word, that is, if I understand correctly, they are not easily “choreographed” or orchestrated as they involve, during their life cycle, possible interactions between different human operators who decide, on their own behalf, the behaviors to apply.
I’ll try to explain myself better:
-
A case is created by an account operator, it is then validated by a superuser operator who can decide whether to pass it directly to the next processing state or return it to the operator who generated it so that he can review it to support the revision wishes indicated by the superuser .
-
At the same time the account operator who produced it can review it and reintroduce it into the validation cycle by the superuser OR put it in “idle” status for subsequent evaluations/reviews OR even reject it. (This is an example of a hypothetical workflow…)
As you can see, the Workflow is not entirely “automatable”…
basing it on mechanisms of conditional switches, forks, joins, deterministic subworkflows but, in some of its sections, the behavior is decided by the “subjective” behavior of the human operator who can also decide on the basis of momentary choices, not necessarily dictated by defined rules.
Therefore, considering this case and - wanting to adhere to the principles of balanced orchestration with choreography through the use of Camunda and BPMN tools, could you kindly help me outline an “architectural skeleton” to achieve my goal, I mean a flow implementation of work that leverages the balance between orchestration and choreography?
Thanks in advance to all of you who would like to discuss this issue.
Best !