allow for setting greedy mode in terms of bpmn execution

[burnettk]

in this scenario, we should continue running engine steps until all engine (automatic) steps are exhausted and the entire process is blocked on human tasks or waiting tasks or similar. this is something that dylan is looking for, and is approximating by avoiding instructions on activities.

relevant PRs:

• https://github.com/sartography/spiff-arena/pull/1161
• https://github.com/sartography/spiff-arena/pull/1173
• https://github.com/sartography/spiff-arena/pull/1191

[dinithihj]

@burnettk Can you please let me know how to test this ticket?

[dinithihj]

@burnettk When you get a chance can you please let me know how to test this ticket?

[burnettk]

@dinithihj sorry for the delay. first, get a token from the developer tools network tab.

make sure this request works:

curl "https://dev.mod.spiff.status.im/api/v1.0/process-groups" -H "Authorization: Bearer [YOUR_TOKEN]

then create an instance:

curl -X POST "https://dev.mod.spiff.status.im/api/v1.0/process-instances/misc:test:madhu-model-1" -H "Authorization: Bearer [YOUR_TOKEN]

the instance request will return an "id".

Run the instance, replacing 35919 with your id:

curl -X POST "https://dev.mod.spiff.status.im/api/v1.0/process-instances/misc:test:madhu-model-1/35919/run?execution_mode=asynchronous" -H "Authorization: Bearer [YOUR_TOKEN]

this will return an instance with status not_started.

then create/run a new instance the same as above except replace execution_mode=asynchronous with execution_mode=synchronous when running. instead of not_started, you should see status user_input_required because it runs as much as possible during the run request, instead of a giving a message to celery to run the instance in the background.

[dinithihj]

@burnettk Thank you for the explanation. I have successfully executed the steps you mentioned. I'll do more testing around this. Just to confirm, this can only be tested on the dev.mod environment, right?

[burnettk]

I think it should actually do a similar thing on other environments, but there may be minor differences.

[dinithihj]

@burnettk I'm testing this on dev.app. Created a model with different elements ex- message events, call activities, sub processes, user tasks, script tasks, etc. Used a script task and exclusive gateway to test different paths of the model. And created another model to trigger and start by message throw event of 1st model.

Model 1: https://dev.app.spiff.status.im/process-models/misc:qa:test-execution-mode Model 2: https://dev.app.spiff.status.im/process-models/misc:qa:test-execution-mode-sub-model

However noticed below while testing.

1. When I create an instance using the command

curl -X POST "https://dev.app.spiff.status.im/api/v1.0/process-instances/misc:qa:test-execution-mode" -H "Authorization: Bearer [TOKEN]

it returned an id and instance status was "not started"

But when I looked at the system a few minutes later, the instance had started and completed on its own if there weren't any human tasks. If there were human tasks, it is keep running upto those human tasks. Is this correct? I thought above create instance command will only create an instance but not start it.

2. If I run the "execution_mode=asynchronous" command right after running the "create instance" command, I get the following error on dev.app.

curl -X POST "https://dev.app.spiff.status.im/api/v1.0/process-instances/misc:qa:test-execution-mode/3284/run?execution_mode=asynchronous" -H "Authorization: Bearer [TOKEN]

(I had to run this command right after the "create instance" command, otherwise it says "Process Instance is currently running or has already run" because of the above issue. )

3. And finally is it possible for you to move these two models to dev.mod, for me to do further testing on dev.mod? I can remember Sasha mentioned that we should never create models on dev.mod and all models need to be created on dev.app and push to dev.mod. I'm not sure how to do this as if I create a PR it'll push models to test.app.

[burnettk]

1 and 2 sound right. I will hopefully remember to force push app-dev to mod-dev.

[dinithihj]

@burnettk Sorry I'm bit confused, What do you mean by 1 sound right?

Regarding the 1 - do you think the "create instance" command should start the process instance? So that means "create instance" command works similar to the run command with execution_mode=synchronous?

In other words, do these below two commands work in the same way?

curl -X POST "https://dev.app.spiff.status.im/api/v1.0/process-instances/misc:qa:test-execution-mode" -H "Authorization: Bearer [TOKEN]

and

curl -X POST "https://dev.app.spiff.status.im/api/v1.0/process-instances/misc:qa:test-execution-mode/3284/run?execution_mode=synchronous" -H "Authorization: Bearer [TOKEN]

[burnettk]

yeah, i think it's ok for created process instances to run. i don't think there is a use case for just creating when you don't want the instance to run. i honestly can't remember why it is two different APIs. it is worth considering making a start API that combines both into one call. it will take some time for the instances to be picked up in the current implementation if run is not called, so the recommended practice would be always calling create and then run.

[dinithihj]

@burnettk Thank you for your explanation I have further tested this on dev.mod with the model https://dev.mod.spiff.status.im/process-models/misc:qa:test-execution-mode

It worked as you explained. When running with execution_mode=synchronous it completes the process as much as possible. And if there are no user/manual tasks within the path it completes the instance. But when you have message intermediate throw/catch events within the path it returns the waiting status.

Please see the below scenario and see whether it's correct.

When you have message intermediate throw/catch events within the path as below

when you create the instance and run it with below command

curl -X POST "https://dev.mod.spiff.status.im/api/v1.0/process-instances/misc:qa:test-execution-mode/36107/run?execution_mode=synchronous" -H [TOKEN]

it returned the waiting status

[burnettk]

waiting sounds right when the instance is waiting for a message, yeah.

[dinithihj]

Tested on dev.mod (version 72/63) using model https://dev.mod.spiff.status.im/process-models/misc:qa:test-execution-mode and https://dev.mod.spiff.status.im/process-models/misc:qa:test-execution-mode-sub-model

When running the create instance command a new instance is created and run

curl -X POST "https://dev.mod.spiff.status.im/api/v1.0/process-instances/misc:qa:test-execution-mode" -H "Authorization: Bearer [TOKEN]

When executing the run command with execution_mode=asynchronous it returns the instance state "not_started"

curl -X POST "https://dev.mod.spiff.status.im/api/v1.0/process-instances/misc:qa:test-execution-mode/37142/run?execution_mode=asynchronous" -H "Authorization: Bearer [TOKEN]

When executing the run command with execution_mode=synchronous it completes the process as much as possible. And if there are no user/manual tasks within the path it completes the instance. (Tested with call activities, sub-processes, script tasks, and manual/user tasks)

curl -X POST "https://dev.mod.spiff.status.im/api/v1.0/process-instances/misc:qa:test-execution-mode/37144/run?execution_mode=synchronous" -H "Authorization: Bearer [TOKEN]

When executing the run command with execution_mode=synchronous and If there are message intermediate throw/catch events within the path it returns the waiting status.

curl -X POST "https://dev.mod.spiff.status.im/api/v1.0/process-instances/misc:qa:test-execution-mode/36107/run?execution_mode=synchronous" -H [TOKEN]

@burnettk above is the summary of testing I have done. Is there anything else I need to test related to this ticket or are we good to move this to resolved?

[burnettk]

That seems sufficient to me, thank you

[dinithihj]

Tested and verified. Closing the ticket.