Activiti with no forms and modelling machines as users

[vrootid4]

Hi,

Apologies for writing a long mail .
We are in pursuit of building an enterprise application that utilizes the power of activiti. But there's a lot of dilema in our mind.
Here's what is currently available :
1. There are jobs that need to be scheduled. The jobs are executed on multiple web clients (say around 10+ machines). Each job with unique ID is added to just one machine (Say A) which is a starting point of the flow. The execution of each job has a sequence say A->B C-> B IF A AND C BOTH RECEIVED AT B THEN MOVE AHEAD SAY TO MACHINE D. The users are native to the APP and its like machine is responsible to decide the status of a job execution.
2. Our application is utilizing JSP, Struts2, Spring JDBC, MySQL (with app db and activiti db) and now activiti which we need to integrate.

What we want?
So as in (1) above once Machine A pulls the job 1 designated to it from its native DB it then Job 1 once completed at Machine A should continue the path as designed in the process diagram to other machines. BASICALLY we need a state machine / BPM and that is where we think activiti can help. But here's what is different

1. Form to add jobs to machines is already there.
2. Forms to display a job designated to it is also there.

3. How we think activiti can be integrated. Now as far as what we understand there are 2 ways to get this process instance started
a) 1st is a message start event which keeps polling the backend application database (not activiti db) to see whether there is a job to kick-off the process instance. Or this can be a none-start with a Java service task or Java receive task (real confusion here).
With this option most of our tasks will actually be polling the non-activiti db (app native db) to check for certain flags and move the sequence ahead.
b) An entirely different approach. Like a task can be claimed by a user in activiti can we model it in a way where actually a machine claims the whole task?
What approach is advisable?

Any help is appreciated.

Thanks.

[frederikherema1]

If I understand correclty, the "polling" part will be written outside of activiti and will notify activiti, once new "job" should be created/executed.

If you don't know up front how many jobs will be triggered from the "polling", I think it's best to model this with a message-start event. This way, only a process is started when you send a message.

If you would be using an approach with a process with a non-start-event and a receive-task, it would be a different scenario: At some point in time, you decide a new process should be started. You call the startProcessByKey(…) and the process waits in the "receive-task". After a while, your polling-machanism received an event to do something with "job X". You correlate the job-id with the process (e.g. using business-key or variable) and call a signal(processId). This triggers the process to move on.

[vrootid4]

Hi Frederik,

Thanks for your prompt response.
Currently yes we have the polling for the first machine outside activiti (will refer to this as native poller hereon). Basically our poller is nothing but a jsp which keep polling the native db using ajax looking for a certain flag. So the result could bring say 10 jobs from the queue but machine 1 will pick-up 1 job by LIFO. Assuming that I use a message-start event what do I do to know the process can proceed. The "native poller" has marked flag saying that the job on Machine A is now done and pick this up. But this update in not in activiti db. We are very new to activiti and this could probably something very simple. But believe me we are confused.

If you understand our existing system just help us started with a best approach on how we can leverage activiti. To re-iterate currently
1. Native UI add a 10 new jobs in native DB
2. Machine A poller picks up just 1 of the 10 jobs in queue for processing
3. Machine A completes the job and updates Native DB
4. and now how should be the activiti process? If you suggest this is a message start event?

Just help us the process flow for 2 machines A to B if you could. Thanks.

Also one thing we want to be sure is that the whole process cycle - from machine 1 to the last machine must be in sync with the states in activiti at each stage.

[frederikherema1]

Okay, I get the use-case now. What I would suggest (the simplest possible, work from there) is using:

1) A process in activiti, with a non-start event, after the start-event there are different receive-tasks. Each receive-task corresponds to a certain machine that needs to do something, they are connected in the right order you can't to have the job executed (and perhaps have some gateways in between, depending on job state) -> e.g. <receiveTask id="machineAWork" />.

2) Once the native UI create a new Job, call our API (startProcessByKey("key", nativeJob.getUniqueId()), passing in the job's unique ID as a business-key. You now have a process started for the "job".

3) Your native poller on machine A DOES NOT POLL the native db, rather, it uses runtimeService.createExecutionQuery().activityId("machineAWork").list() and takes one of those processes and executes it. The native job can be looked up by using the businessKey provided in the process.

4) After machine A has executed the process, it calls out API: runtimeService.signal(processInstance.getId()) - signaling the process for which the action has been performed.

5) The process is now up to date with the execution-state of the job. Activiti will move on to the next activity in the process, e.g. "machineBWork".

6) Poller on machine B (exactly the same as on machine a) checks for processes waiting in activity "machineBWork"…

If you require user-intervention, the processes can include UserTasks as well. This approach puts the order and actual execution control in the hands of the process, rather than in the hands of your native DB, which is what you need.

[vrootid4]

Lovely! .. Thanks. Let me put our thinking hats. Correlate. In case anything I will get back. Once again thanks for the support.

[vrootid4]

In point (2) when you say we have a process started for the "job" would there be anything like a "wait" consuming memory - like db polling wait tasks? Or it is just a state stored in activiti db?. In our application we can keep say 100 jobs added in advance through the native UI.
As per your suggestions would the process start as soon as the job is added?
The process for a single job looks like
–>Machine A—>Machine B
                                     |
–>Machine C—>Machine D
                                     |
–>Machine E—>Machine F
1. Job 1 starts at A, C and E at once (process variables will be different though)
2. Machine D task will proceed to task F only on completing tasks received from B and C

So coming back I have 100 jobs (ID 1 to 100) added through Native UI 5 days back but I am processing say jobs (ID 15-20) (5 process instances) today. Would suggestion in Point (2) be an overkill? We need something that will somehow start the instance only when the job comes into play.




1. In the cycling of a single job in say 20 machines (each processing 1 job at a time) we would expect max 20 jobs running parallely i.e 20 process instances started parallely. Would it be a memory overkill? or its not a big deal? There is a possibility of each job running different processs design (accept the starting task).

[frederikherema1]

I've totally lost you on what the scope of a process is and what you're doing yourself. Also the term "job" doesn't help when considering activiti also uses jobs

Do you have a process-diagram of the process you're using?

[vrootid4]

The process diagram is attached (rename file to .jpg). Though the diagram refers the term "job" I will refer to in the explanation as "product" and the work to be done at each machine as "task".
- The overall objective to develop a "product" - say we are making a computer
- The making of computer is split into "tasks" to be completed at each machine - say assemble CPU, connect CDR, connect mouse etc.
- In the diagram we have 16 such machines
- Adding "tasks" for a product is a procedure that could be done much in advance from Native UI. Its loading on machines will happen by LIFO.
- Machine A, C, E, G… till O (left column) will get tasks at the same time
- Only when machine A completes it job Machine B will start the work. Likewise C->D, E->F….O->P
- Also for machine D task will load once B and C have completed their tasks. Same dependency goes for F, H etc..till P
- The product will be ready at P

My queries :
1. Would bringing up the process instance when we add tasks in advance be right? Would it be simply consuming some memory?
2. Also is the receiveTask method for each machine be the right way considering 8 machines get tasks at the same time?

We are new to Activiti. Pointers will do. Thanks.

[trademak]

The model like it is right now is not correct. If this model is executed you have a lot of tasks running in parallel and if for example task B is completed the activity for task D is started, but when task C is completed, again a new activity for task D will be started. So you may want to look into the process semantics a bit more.

1. No that shouldn't be an issue
2. See my comment before, it's not modelled correctly now, so really hard to say something about this.

Best regards,

[vrootid4]

Thanks for the update. We are new to activiti but are sure that it could help us with the sequencing of our process.
If you understand the usecase (what is expected) could you suggest atleast some pointer on how the parallel tasks could be modelled/handled? Would receiveTask still hold good?