userTask disable persistence

Flowable Engine
1

Hey Guys,

I’m having a requirement where I would to run bigger volumes of work flow (multi million ) using userTask or async tasks. The only concern I have is about persistence , i.e userTask persist the state in DB as part of work flow during its synchronous execution. Is there a way to disable persistence of userTask or any other alternative custom task ? As DB persistence could be real performance bottle neck.

Thanks,
Jay.

2

Hi Jay,

There are plenty of possibilities. For example:

  1. Custom persistence layer implementation, (http://www.jorambarrez.be/blog/2015/09/17/pluggable-persistence-in-activiti-6/)
  2. taskSkipExpression which allows to skip task, (https://github.com/flowable/flowable-engine/blob/818799b98cc9edb3c2dbd3c7ef370495791c1033/modules/flowable-engine/src/test/java/org/flowable/examples/bpmn/servicetask/JavaServiceTaskTest.java)
  3. Custom user task activity behaviour, (https://github.com/flowable/flowable-engine/blob/f104f3cd303e5697e72f3e44ce1b59463a036f6f/modules/flowable-engine/src/test/java/org/flowable/standalone/parsing/CustomActivityBehaviorFactoryTest.java)
    …

I can not imagine why do you need user task without persistence. When user have to complete task it must be persisted somewhere.

Regards
Martin

3

Hi Martin,

Thanks for your quick reply, I’m very new to Flowable engine , So can you please point me to an example or elaborate on your solution ?

Thanks in advance,
Jay.

4

Hi Jay,

Do you have some throughput numbers (concurrent “users”, tasks/sec, etc), and a hint of the kind of processes that would be running? As Martin says, it would be unusual to have millions of user tasks persisting at about the same time. May be more understandable with service tasks in a systems automation/orchestration use case. That’s why knowing a bit more about what you’re trying to achieve helps.

Cheers
Paul.

5

Hi PHH,

The process that would be driving the work flow is an IOT based application which has event drive approach from multi channels , So there could be millions of events triggering workflow execution and each work flow could contain both serviceTask & userTasks.

Hope I could clarify my requirement.

Thanks,
Jay.

6

Hi Jay,

When events start new process instances the bottleneck won’t be the persistence layer, but users who will handle the tasks. You can have a look on benchmark tests (e.g. http://www.jorambarrez.be/blog/2016/07/20/message-queue-async-executor-benchmark/) when you want to execute asynchronously.

Regards
Martin

7

Hi Martin,

The test results looks very promising, It has made me vouch for Flowable as my workflow engine.

Yes , I agree uses are bigger bottle neck than the persistence , Let me rephrase my requirement as I have used a wrong terminology. I want to use asyncTask(Example could be a Java Task ) but I don’t want it’s state to be persisted by Flowable when it is moved to wait state during it’s life-cycle.

You have suggested multiple workaround above which is really good to know, I just want a example implementation or a doc reference to the same.

Thanks,
Jay.

8

Hi,

I missed to add , We are following BPMN model for process creation .

Looking forward for your suggestions.

Thanks,
Jay.

9

Hi Jay.

I added links to tests and blog to my first comment. I still do not have clear picture what you want to achieve. Non persisted wait state seems really strange to me.

Regards
Martin

10

Hi Martin,

Please refer to below link and that’s what I mean by disabling persistent, currently POC is running for activiti but does not work for flowable , I tried doing the same using flowable 6.0 but it fails as few classes defer.

http://www.jorambarrez.be/blog/2015/09/17/pluggable-persistence-in-activiti-6/

Thanks,
Jay.

11

Hi Jay.

That’s exactly the first link in my answer. What exactly does not work there. @joram is active on this forum too. If there is anything missing just point it out.

Regards
Martin

12

The code we’re talking about here was nothing more than a proof of concept … and only the (very) simple test example was made to work. It would need quite a bit of effort to make such a thing ‘real’. There is also no attention being given to transactions/concurrency nor scalability at all.

If the use case is to support multi-million process instances, i don’t believe it’s a good choice to go.
Databases these days are quite performant … i’d say give the default implementation a go and see how far you can jump (disable history if you dont need that)?

13

Thanks Guys for your suggestions, I will take Joram’s suggestion.

Thanks,
Jay.