AnsweredAssumed Answered

Should this code stay procedural or use process flows?

Question asked by jasonw on Aug 12, 2014
Latest reply on Aug 30, 2014 by jbarrez
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.