We are implementing a standalone Flowable engine for document processing. In our workflow, a user uploads a document, we perform extraction, and then create a new record in the database. After that, the user can take several actions such as edit, hold, reject, or accept. These actions update the document and advance the BPMN process instance.
Since we are not using Flowable forms, we rely on our own UI. When the user submits an action, the request goes to our application. We are comparing two main approaches for updating the document and moving the process forward:
Approach A (Orchestration-Centric):
1. The user’s action triggers an API call to the application, which forwards the complete request (fields, headers, query parameters) along with the action variable to the orchestrator.
2. The BPM engine uses these process variables to determine the path and calls service tasks for each invoice action (hold, reject, accept).
3. The engine then retrieves the updated invoice and decides the next step in the process flow.
Advantages of this approach include a very clear orchestration mechanism and high visibility, as the BPM model reveals all business logic and each system call. However, it can lead to a more complex BPMN design, involves extra network hops (because the engine is standalone), and requires a lot of effort to pass request data around and reconstruct it in each service task. This approach is more common when the BPM engine is embedded.
Approach B (Application-Centric):
1. The user’s action triggers an API call to the application, which updates the invoice in its own database first.
2. The application then calls completeTask(…) on the BPMN engine, sending only the relevant process variables (for example, the action and updated fields) that are needed for the next step.
Its main benefits are consistent state by the time Flowable receives variables, minimal complexity in the BPMN model, and fewer moving parts for orchestration. The tradeoffs include reduced visibility in the BPMN diagram (since updates happen in the application), the need for extra checks to ensure valid actions at each process step, and a potential reliability concern if the resource is updated but the Flowable call fails. This is a popular approach when the BPM engine runs separately.
Given that Flowable is operating as a standalone service (not embedded), which pattern tends to be best for reliability, simplicity, and maintainability? Has anyone successfully scaled the orchestration-centric approach without excessive overhead, or is it more common to treat the application as the system of record and let Flowable know only about the changes? Any real-world experiences or best practices would be greatly appreciated. Thank you.