cancel
Showing results for 
Search instead for 
Did you mean: 

Batch processing with Activiti

kingsheldor
Champ in-the-making
Champ in-the-making
I'm looking to create a custom software product that can model a fairly complex manufacturing process.  There would be an incoming list of 100 items that all need to go through the same exact process.  We'd like to do this in one batch operation since all items are typically handled at once, however there are different quantity handling requirements for each step.  I could use some advice on how to proceed.

The overall flow is "Step 1" –> "Step 2" –> "Step 3" –> "Step 4", however there are limitations:
1) Step 1 = at most 50 items of the batch [creating 2 sub-batches].
2) Step 2 = all 100 items together.
3) Step 3 = at most 4 items at once [creating 25 sub-batches].
4) Step 4 = 25 items to begin, but can handle all 100 items.

We do have some tracking requirements, most notable:
A) Each entering item needs to be tracked at each step to know where in the station they were placed (i.e. To perform quality measures in my software implementation I need to track which 25 items in the batch were in the upper-left slot at Step 3 and compare the quality to those in the lower-right slot.  I also need to track which 4 items were done in the 12th sub-batch of this hour's run)

I am aware of the multi-instance tasks, and of sub-processes.  I was thinking of making each step a sub-process, with an input gate to know when limitation 4 has been met, and then model the entire process as a generic flow of the 4 sub-processes.  Then, handle each of the quantity requirements in each of the sub-processes individually.  Here are my questions:

1a) Can Activiti cleanly handle this type of batching?  (i.e. can I just throw the list of items at the ProcessInstance, define some sort of sub-batch logic, and let Activiti handle the rest?)

1b) If so, is my line of thought the most efficient solution?

2) If I do the implementation as sub-processes, where is the best place to put the quantity-check logic and orchestration:
   A) In the main process (thus creating multiple sub-processes),
        or
   B) In the individual sub-processes (thus creating 1 sub-processes that executes its internal steps multiple times)?

3) In the future, if we decided to purchase more machinery and implement a second main process (call them Steps 5 through 😎 and then have Step 2 sometimes switch an item over to Step 6 of the other ProcessInstance.  Is this possible with them being separate deployed processes, or do all 8 steps need to be in the same deployed process?

Thanks!
7 REPLIES 7

kingsheldor
Champ in-the-making
Champ in-the-making
I think this goes without saying, but thought I should mention: Because of the tracking/positioning requirements, we want to avoid making each step handle 1 item and have our solution create 100 process instances.

trademak
Star Contributor
Star Contributor
1a Don't see a reason why not.
1b If you use an embedded sub process it's the most efficient way. You can make this embedded sub process multi instance and create sub lists of your items with the right quantities that you defined in your post.
2 For an embedded sub processes the logical place would be a service task before the multi-instance sub process
3 Don't think Activiti mandates them being in the same process definition. It's a design choice not an Activiti requirement.

Best regards,

pmsevestre
Champ in-the-making
Champ in-the-making
One think that I would do is to make a clear distinction between the manufacturing process of an individual item from the batching processes that take a bunch of items and perform a given production step. With this distinction in mind, you'd end with the following processes:

1. A process for each item, with human tasks representing each production step
2. One batching process for each manufacturing step. This processes consists of just
thtwo steps: collect items ready for production (up to the capacity of the cell), perform the production step (multiinstance human task)

Process instances of (1) become process variables for (2) and vice-versa, so you can track wich isnatnces where produced by a batch and the batch runs that participated in the production of a given instance.

I think that approach would also give you extra flexibility, as you can add new item production flows that share common steps ( eg, product 1 has an extra step 5) without any changes on existing processes.

ezg3ta
Champ in-the-making
Champ in-the-making
Hello!

I will borrow this thread, because it perfectly suits my problem. I have to design a bpmn process, which takes care of incoming orders (one process instance = one order), but the orders are processed in batch. The aim is:
1. to know at any moment in which state each order is,
2. to process the orders in batches

Now.. The idea of pmsevstre seems good, except I don't know how to design it - could anyone please make a visual example? I thought I could make it with signals (see picture at the bottom), which would be thrown via the API, but at this time, the "analyse order" or "ship order" step is the same for every order. I would like to do it like pmsevstre suggested - i.e. to implement the "analyse order" as a sub-process in the order process, so that we could have different kind of orders, which demand different kind of analysis.

The association lines (dotted lines) represent the signal throwing and catching between the batch and order process.

And if there would be a way to reuse the "batch process", that would be great Smiley Happy (my example contains 2 separate process definitions for analysis and shipment batch)

BPMN example: https://copy.com/thumbs_public/ET1URFyG1yV2qmuc/activiti.png?size=1024

jbarrez
Star Contributor
Star Contributor
I'm not sure Im following your reasoning here. Why would you want to use signals to continue the batch?
Why not simply set a process variable that indicates the state?

ezg3ta
Champ in-the-making
Champ in-the-making
The reason is, that I don't want the order process to continue until we have enough orders. And until we don't have enough orders, the task list would be full of tasks like "analyse order" - I don't want these tasks to be visible until we have a full batch (for example 20 orders). And even when we have one batch, it would be preferable to get tasks one at a time, or even better, to complete them all in one step (that could be done with a custom GUI, which lets us complete multiple process instances at once).

With that said, it is cruical that the orders have each its own process instance. Also bear in mind, that this is only a simplification of the real process, which is much more complex, but follows this pattern - multiple checkpoints for orders, which are processed in groups (batches), which may not be always the same (meaning that the group of orders, which were processed together in the "analyse" step, may not be the same as the group of orders in the "shipment" step).

Anyway - it would be of great help, if one could simply make an example (preferably a BPMN) of what pmsevestre meant. Smiley Happy

jbarrez
Star Contributor
Star Contributor
Anyone wants that I make examples, i would be doing nothing besides that the whole day if I start doing that 😉

What you need is a global signal. Have a process instance started for each of your orders. Make it go to an intermediate signal event that waits until the global signal is received. That would give you the semantics you described above.