Is it possible to access the Process Engine Services from my Delegation Code ?
Yes it is.
If you are using Spring and delegate expressions on your services tasks, its simply a matter of auto wiring any service you need.
Will
1 Like
First of all, thank you for the quick reply.
May I politely ask you for an example ?
No matter what i tried, i always get a NPE.
Can you elaborate on your setup? For instance, are you using the spring boot starter or attempting to integrate with the Task app?
If you’re compiling your own spring boot app, then it’s simply a matter of setting the delegate expression and making your delegate an @Component:
If you’re trying to integrate with the Task app, It takes a little more effort. You have to crate an auto-configuring jar that you then add to the task app’s libs.
1 Like
Here’s a link to the docs regarding adding custom beans to the prebuilt apps:
https://flowable.org/docs/userguide/index.html#custom-bean-deployment
1 Like
Thank you! That helped a lot in combination with this post: Get HistoricProcessInstance in PROCESS_CREATED event
So basically, for a student project, i´m trying to build multiple microservices which all have their own processengines, but one microservice which handles the userTask’s. All are using the same database.
I set the async-executor-activate = true to avoid an interbreeding of the different processengines. Now i’m facing the problem, that the “Task”-microservice cannot find the Task.
I´m considering to use multitenancy, but want to allow the “Task”-microservice to have access to the tasks of other tenants. Is this possible ?
BR
Marko
The traditional way to have Flowable orchestrate micro services is by communicating with HTTP or over message queue (possibly with CAML).
I don’t think multi tenancy will help your use case. Any Flowable instance connected to the same database will consider itself a node in the same cluster and try to execute jobs. You might get something out of marking all of your service tasks as async and disabling the async executor on the user facing service (i assume it’s the task app). But any microservice that has the async executor turned on would need to be able to handle any service task.
That may be sufficient for your project, but you’d only have two services: the Task app & the one executing your service tasks. It would also violate the resource isolation principle of a 12 factor app, since multiple services would be sharing a database.
1 Like
Since I’m not trying to type this out on my phone anymore, let me expound a bit more. Flowable keeps its state consistent using database transactions. Some elements will trigger a wait state, places where execution must wait for some outside event. The database transactions are comprised of all of the things between two wait states, so each must be executed within a single instance of the engine. Two two of things that trigger a wait state are user tasks and asynchronous service tasks.
The reason a user task triggers a wait state is obvious, the process must wait on the user. Async tasks are a little different, instead they place a job in the job queue and wait for an async executor to be free to pick it up. This is where it things get complicated for your use case, any instance of the engine connected to the same database with a running async executor can pick up the job and run it through the next wait state. If the job fails the it gets placed back on the queue for an automatic retry (3 times by default). If the job fails all of its retries it gets placed into a dead letter queue.
This is why two services can be made to work. With the one handling user tasks turning off the async executor and the one handling the async service tasks having it enabled.
A bit more on tenants:
Tenants are intended to keep two organizations’ processes and data logically separated while still running on the same set of process engines. Starting a process with a tenant id ensures that it will only access deployed processes available to that tenant. Querying using a tenant id restricts results to that tenant as well. There are also some interesting things you can do where all tenants have access to the processes deployed to the default tenant, but override specific processes with tenant specific ones.
Will
2 Likes