Restart an already finished process instance and job instances

[namnguyen]

Hi,

as far as i know, you can define an activity in a process definition as a job through the configuration of asynchronous. It will be persisted in the ACT_RU_JOBDEF table. At runtime, a job instance of this job definition will be created and persisted in the ACT_RU_JOB table. This job will be accquired by the job acquisition and passed to the queue for execution. This job can only be retried when it fails. Is there anyway you can rerun an already finished process instance and their correspoding finished job instances for a successfully executed case? Or do i have to implement it by myself? Thanks.

Best Regard,

Nam

[thorben....@camunda.com]

Hi Nam,

You would have to create a new process instance yourself and make sure you transport variables etc.  I am not exactly sure what you mean by re-running with finished job instances. For example, the behavior of a timer job is likely to change when you re-run the process.

Anyway, what is the use case you are trying to achieve?

Cheers,
Thorben

[d200...@yahoo.com]

Hi Thorben,

thanks for your prompt reply. My use case is like this: I have a process which consists of for example 3 service tasks (A, B, C). Each service task will call an external service (a software) to produce a result. The result of A will be used as inputfile of service task B. The result of B will be used as inputfile of Service Task C. In my case, eventhough a service task can be successfully executed, it means that it won't cause any failed job but it doesn't mean the result is exactly like my expectation. So sometimes i need to re-run only the service Task B or C not the whole process instance because it will waste time and resources due to the fact that each service task needs a long processing time. All thoughts and suggestions are appreciated. Thanks.

Best Regard,

Nam

[thorben....@camunda.com]

Hi Nam,

There are some considerations:

- If it is an regular case that tasks A or B are not supposed to be executed you might want to model this by exclusive gateways or separate process definitions.
- You can wait for 7.3.0 and the tickets CAM-3453 and CAM-3454 (see links [1] and [2]). These features will allow you to start a process instance at any activity and cancel running activities. However, using this feature regularly to execute process snippets at will defeats the purpose of modelling BPMN in my opinion.

Cheers,
Thorben

[1] https://app.camunda.com/jira/browse/CAM-3453
[2] https://app.camunda.com/jira/browse/CAM-3454

[d200...@yahoo.com]

Hi Thorben,

thanks for your reply and considerations. Modelling the process in BPMN is still very useful and helps us a lot to model our internal workflows, thanks to camunda and your team. But the feature which allows user to start an already finished activity in an already finished process instance will bring many benefits. You can consider this scenario: in Service Task A you call an external application to create a artwork master for print purpose. In Service Task B you call another application to edit this artwork master. And in Service Task C you send this final artwork master to your customer. The process instance will be executed and after an amount of processing time will be considered sucessfully completed with no failed jobs. But when you check the final artwork master (result of Service Task B) you realized it was edited with wrong parameters (color level, opacity, or something wrong with the application at the processing time etc.). So it makes sense just to restart the Service Task B instead of restart the whole process instance which will also restart the Service Task A. Or another use case is: Everythings fine and you send the final artwork master to the customer but after sending, the customer wants to receive the file with different email adress, so you only need restart the Service Task C, not the whole process instance or create a whole new process instance with the same process variables. I think it is a pretty common problem for the users and it is very useful to have that kind of feature. I will appreciate any thoughts and idea to solve this. Thanks

Best Regard

Nam

[thorben....@camunda.com]

Hi Nam,

I see the point with the second example you give. With the first, I personally would model this as a distinct process (or make reviewing the artwork master a part of the process) if this is a common case. Anyway, I don't want to tell you how to model your processes ;)

Would the features described in the two tickets I linked solve your requirement? You could:

- Make a history query to get the process variables of the process instance in question
- start a new process instance at the desired activity with these variables

You cannot tell the engine to stop after that single activity though.

Another idea:
You can use CMMN [1] and BPMN in combination:
Model the automated parts in BPMN and use process tasks [2] in a CMMN model.
For the printing example: You would have one process definition with the entire process and one with only the re-printing activity. CMMN gives users the freedom to start tasks at will and (via repitition rule) any number of times if I am not mistaken.
That's however only a rough idea since we are still unexperienced in the CMMN field and suitable use cases for CMMN, and the engine isn't able to handle repitition rules yet.

Cheers,
Thorben

[1] http://docs.camunda.org/latest/api-references/cmmn10/
[2] http://docs.camunda.org/latest/api-references/cmmn10/#tasks-process-task

[d200...@yahoo.com]

Hi Thorben,

thanks for your suggestion. I think the feature described in the two tickets will solve my requirement. I will also have a look at the combination of CMMN and BPMN. It looks like a promising solution in the future when the process engine supports CMMN.

Best Regard,

Nam

[thorben....@camunda.com]

Hi Nam,

That's good to hear. One clarification: The process engine already does support CMMN, but not 100% of it. Check the docs [1] for coverage.

Cheers,
Thorben

[1] http://docs.camunda.org/latest/api-references/cmmn10/

[d200...@yahoo.com]

Hi Thorben,

thanks for your information.

Best Regard,

Nam