Should this code stay procedural or use process flows?

[jasonw]

I am new to BPMS and so this is a question on whether or not Activiti process flow is a better way to re-do my current logic.

We have a system that communicates asynchronously with 'devices' of all kinds (e.g., non-standard thingies).
We currently track each communication request with a device in a "INSTRUCTION" table.
INSTRUCTION table has connection parameters, ,etc. and a status (PENDING, RUNNING, CANCELLED, SUCCESS, FAILED).  So, we can query the table for a current view of the instructions that are pending, running, failed, etc.

Volume:  We do 25,000 instructions per day.

I'd like to look at using Activiti process instances to manage all this code that we currently write/maintain for INSTRUCTION and get rid of it.

Should the code stay procedural or move it to a process flow?

Basic application logic/flow today is:
===========================
1. User (or System/headless job) requests to communicate with a device.   For instance, to display a message on a display device (e.g., overhead traffic sign, kiosk in an airport, TV in a transit bus station, etc.)
2. Instruction object is saved in DB INSTRUCTION table with PENDING status
2. Instruction object is queued in JMS to run asynchronously because you cannot hold up the caller with unreliable device comms.
3. A JMS listener pulls off the queue and executes the Instruction
  a.) Set Status To RUNNING in DB INSTRUCTION table
  b.) Communicates to the device over its preferred native format/protocol (e.g., RFID, snmp, blue tooth, byte streams, etc.)
  c.) Posts reply back to system and we save data to business tables about the reply
4. System updates INSTRUCTION table to SUCCESS or FAIL (e.g., an end state)

I'd want to use Activity Process Engine to eliminate all the INSTRUCTION table code and use process states to query and show where the request is (pending, running, etc.)
I'd want to eliminate all the JMS call/listener logic and have the engine run the task asynchronously.
I'd want the end state of the process instance to update the data gathered from the device, etc.
It would have to handle 25,000+ of these process instances per day.

[jbarrez]

It sounds to me like a fit. The load should be ok on decent hardware.

What's the reason for wanting to migrate? Do you anticipate changes in the logic later on? Or do you feel you're writing your own state machine now?

[jasonw]

Reasons I'm thinking about converting our current approach to a BMP process flow
====================================================
- I'd rather not continue to maintain custom code that is essentially done (and done better) by a product. 

- I'd like to have 'trace-ability' of the process from start to finish.  Currently, our technical solution is essentially fire-and-forget.  Once the instruction has gone asynchronous, we kind of lose what happened to it downstream of it.  We track state changes, but we don't track information about each state change to really understand it.
- I'd like to take advantage of some things offered out-of-the-box by Activiti BPM like 'simulation/replay' where we can re-play a scenario.  The instructions flow would be a sub-process, kicked off from other processes.  For instance, what "incident" triggered the instructions to the devices?  A bad accident?  A delayed flight/bus?, etc.  What devices were contacted, what information was displayed on them, for how long, and how Operators of the system interacted with the devices.

thanks

[martin_grofcik]

Hi,

'simulation/replay'

Please let me know the results. (If you would need any help….)

Regards
Martin

[jbarrez]

<quote>
- I'd like to have 'trace-ability' of the process from start to finish. Currently, our technical solution is essentially fire-and-forget. Once the instruction has gone asynchronous, we kind of lose what happened to it downstream of it. We track state changes, but we don't track information about each state change to really understand it.
</quote>

If you dont have that in the current system, then indeed Activiti will serve that need