Modelling question: Multiple contributors to activity

[michaelfranz]

Activiti newbie question (apologies if this is the wrong forum):

An activity (a "Job") involves collecting data pertaining to the quality of physical artefacts. The quality of said artefacts is determined by human inspection.

When a Job is defined by a "Job Manager", the artefact type, total quantity of artefacts to be inspected, and location(s) [artefacts may be spread over various geographical locations] of the artefacts are specified.

One or more "Inspectors" is/are tasked with conducting the inspection. Each one of the Inspectors independently performs inspections, recording as they proceed the number of artefacts inspected, the number or defects, additional observations (notes) etc. Inspections may take place in shifts, with new Inspectors coming on board at any time, others ending their contribution to the inspection when their shift ends.

Inspection data are gathered in real-time, with a Job Manager regularly receiving updates re the total number of artefacts inspected, number of defects etc. In effect, each Inspector contributes to a collective result - that being the overall result of the Job.

Finally, a Job can be aborted pretty much at any time.

For simplicity I have omitted several aspects of the process, but my newbie questions are as follows:

How best to model the Inspectors' respective contributions to the overall result? I've heard of multi instance tasks, subprocesses, but don't have the experience to know which (if any) is the best approach. Any advice welcome!

How best to model the fact that a Job can be aborted at any time. At the moment I've used an exclusive gateway after virtually every user task, one branch of which is to a user task for stating the reason for "early" termination. It seems reasonable enough to me but I'd be interested in opinions.

[frederikherema1]

If you have the same task that should be repeated X times (potentially, but not required;, by different users) you can use the multi-instance approach (see user guide). If its more than a single "activity" that needs to be repeated, you can bundle all the work in a sub-process and repeat that.

If you want to have the abortion of a job be based on the outcome of the user-task, you can indeed use a exl-gateway after a user-task. When the job should be aborted, you can thow an Error-event, for example. In case you're "job-process" is wrapped in a sub-process, you can add a catching-error-boundary-event to the sub-process. When one user sends a request to "cancel" the job, the whole sub-process is terminated and the process moves on to the activity you have modeled after the "boundary event" (potentially process-end or a special user-task).

[michaelfranz]

Terrific info. Many thanks.

A couple of points re your first suggestion:

It's not so much a "repeated task". It's more like one or more users contribute participate on a single task.

However, having done a little bit of reading around this in the past hours (see section "Multiple Resource Patterns" at http://www.workflowpatterns.com/patterns/resource/), I now have the feeling that this should be modelled differently to what I first envisaged and I suspect this is probably what you're getting at: The main process deals with the "Job". This is assigned to a Job Manager and stays that way until completion. It's execution results in the instantiation of 1..n "Inspections" with one inspection per Inspector. I guess this could be a subprocess [comments welcome]. Once each or the Inspection subprocesses are completed - or aborted - the main process can complete.

Finally, I presume all this can be expressed using the Activiti Designer. I must confess I'm finding the tool a bit clunky (on Mac at least), but that might be down to inexperience.

Apols for the undoubted misuse of the terminology… new territory.

[jbarrez]

If the tool feel clunky somehow, please create Jira issues accordingly so we can fix them. That too, is contributing to open source!