nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Asynchronous / Long Running Activities

dstone_dalet_co

Hi,

We are developing a product which uses the Activiti Engine (5.17). We have implemented a number of activities that execute long lived jobs within our system. The prototype versions of these activities were implemented using a script or JavaDelegate based task which submits the job and blocks until the job is complete. This works OK for demo purposes but is obviously not fit for production.

I understand the Activiti Engine supports log lived jobs (asynchronous) but I'm not clear on how these should be implemented.

We have identified at least 2 different approaches to this problem:

1. Use a BPMN ReceiveTask with an Activiti "start" listener:
- "start" listener submits the job;
- ReceiveTask is executed and goes into a wait state;
- job service signals Activiti engine when job is complete;
- Activiti engine signals / wakes the ReceiveTask and it completes;
- process continues…

1. Use a BPMN ServiceTask with a TaskActivityBehaviour extended class:
- TaskActivityBehaviour execute() method is called and submits the job;
- TaskActivityBehaviour execute() exits and execution goes into a wait state;
- job service signals Activiti engine when job is complete;
- TaskActivityBehaviour signal() method is called. Method calls leave();
- process continues…

Are either of these the official / preferred method? Should we do it some other way?
Best regards,
Dan

Find more posts tagged with

Comments

jbarrez

Option is what I prefer, as it keeps database transaction not open when not needed. Your second option is actually the same, but with a step that does both in one go. I like it too 😉

The only thing you must be careful of is that, if your external system is REALLY fast, it will try to signal quicker than that Activiti has continued the process. So you do have to build in a query + wait mechanism.

dstone_dalet_co

Thank you for the reply. It sounds like both options are OK but can I just clarify a few points:
1. Did you say you prefer option 1?
2. I thought both options didn't keep the DB transaction open between the start / execute and signal. Is that not the case? I think in a previous thread it was hinted that option 2 didn't keep the DB open (see http://forums.activiti.org/content/java-service-task-passivate-wout-receive-task);
Thanks for warning me about the fast signal issue.
Many thanks, Dan

jbarrez

1 .Yes, my personal preference is 1. But that is mere taste.
2. Correct, which is what I said. Im just pointing out why it's a good idea.

dstone_dalet_co

Thank you for helping and reassuring me that either option is possible.

boekhold

Joram, sorry if I'm asking a stupid question, but what kind of "query" would you need to do to ensure the task is already in the correct state in which it can receive the signal?