incubator-kie-kogito-runtimes
incubator-kie-kogito-runtimes copied to clipboard
apache
Adding new bpmn at runtime
Hello! I'm new at the kogito framework. There is a requirement for the system that I will have to develop - to load bpmn processes at runtime. I have not found any tutorials on this topic. Does kogito support such a feature or not?
Hi @PullDakar , I confirm that this scenario is not supported by kogito. We have something similar for DMN here https://github.com/kiegroup/kogito-apps/tree/master/jitexecutor , but not for processes.
@cristianonicolai @tiagodolphine @fjtirado is this feasible to achieve? Can we open a JIRA to track this down?
I think (but I have not tested) that, if he is running on quarkus dev mode from any IDE (or console), he can add a new bpmn to an existing project (resource directory) and this will be automatically compiled and available to work with as it was created before the quarkus is run.
I think (but I have not tested) that, if he is running on quarkus dev mode from any IDE (or console), he can add a new bpmn to an existing project (resource directory) and this will be automatically compiled and available to work with as it was created before the quarkus is run.
Hi @fjtirado , I think your idea might be ok for development purposes but not for production systems.
@r00ta yes, thats why I mention quarkus dev mode ;) Honestly, for production environment, it would be a long discussion to assess if a requirement to add things on fhe fly is really useful (all the places where I have worked always establish a "window" to upload new content, during that window the machine being updated is not functional)
We'd love to use kogito as a service component in a multi-tenant SaaS application. These sorts of issues mean we are swimming up stream. It doesn't just seem to be a problem of loading a bpmn JIT from a DB but so much about the ecosystem seems to be driven around design time decisions rather than run time.
@treyhyde Kogito was designed to leverage build time. This means that the resource files (such as BPMN) are processed during build/compilation phase, the code for the process is generated and exposed in the API.
For this particular use case, can you share more?
I'd say that to add a BPMN file in runtime to work with, the interface and domain model should be preemptively defined (so other actors in the architecture could interact with it).
Having this in mind, what I would do is to define a CI/CD workflow to process that file with Kogito, generate and deploy the service to be accessible via REST.
Mind sharing a little bit more?
Sure, we want to allow customers to manager real life business processes and cases in a less bespoke way. BPMN and CMMN are good fits at a high level We'll have canned prescriptive processes and then customers will build their own processes either via a UI in which they don't realize they are building them or directly via a BPMN editor.
My thought was, start with the prescriptive processes where certain things could be known at design time (like the process flow) but other things wouldn't be like which tenant they are in, groups, users, details of decisions, etc. It would be impractical to have every user configuration go through a CI/CD process before it is testable. In any case, if we were to build, say 100,000 process flow definitions either automatically or manually it starts to fall apart quickly with the design time strategy. So options are to adopt tools like kogito assuming we can fix them for SaaS use cases or just start with lower level constructs like jBPM and build our own version of kogito that is build for runtime decision making. I'm afraid the fundamental design decisions in Kogito around design time assumptions would make this hill too big to climb and we'd have a shorter path by reinventing the wheel.
@ricardozanini Here is a little more about a use-case that requires the dynamic loading of business process and it aligns with @treyhyde's concept at a high-level. A multi-tenant web application that is offered as a SaaS product has a registration business process that combines various manual and service tasks. The core model objects for this business domain are predefined. However, every organization on this multi-tenant platform can define their own registration workflow. An organization may decide that 5 out of 10 domain objects have to be entered by the end user during the registration vs another that may choose 8 out of 10.
@AmareshKulkarni, for this use case, I would create a new service for each tenant and not only one for all tenants. So it will scale better IMO.
@treyhyde, I see. I can see arguments about building and have a unique deployment for each iteration, but also I can see one individual "runner" loading process on demand. . We are working on ways to have such a worker runner node that will receive the process and expose an endpoint based on its ID to be executed. I don't have much to share now, but it's something on our radar.
I can see arguments about building and have a unique deployment for each iteration
The thought crossed my mind... > 100k HA deployments will blow up pretty much anything and just make the economics be several orders of magnitude off. Even as ksvc's (which would be my preference anyway), it would have a pretty extreme cost as the kube API tends to handle > 1000 "anythings" pretty poorly. Even if that worked, that's assuming all the customers are idle... if any small set of customers is active (let's say 10k), we're back into economics that just don't work.
Thanks for the mentions and considerations @AmareshKulkarni, @ricardozanini. We really like kogito in theory between the knative, CloudEvents, etc as it resembles the way I would build it if I was starting from scratch... but we're pushing that boulder up hill when it comes to model time decision making. Code / customers will be building the models interactively, dynamically, constantly. (and never in a BPMN editor) I believe it would be the ideal scenario for an IT shop that absolutely had to DIY. But... It's quickly dropping off our list. ATM, Flowable is a much better fit if we decide to go down the BPMN, CMMN route.
Thanks for the input, @treyhyde. I think the runner we are working on will fit your demand as well. Unfortunately, I'm not sure about the timing. As soon as I have something, I'll share it with you.
Hi @ricardozanini, any updates on the new runner? I've been eagerly tracking this issue :)
@patstevens4 unfortunately, no. We are focusing right now on other priorities, I'm sorry. :(
Interpreted mode is something to think about in the future in BPMN2. keep marked for the future
