Zdenek Hrib [https://community.jboss.org/people/zdenek.hrib] created the discussion "Re: Using jBPM as state machine engine - is it a good idea?" To view the discussion, visit: https://community.jboss.org/message/778308#778308 -------------------------------------------------------------- Thank you for the quick answer. I was also thinking about some sort of "custom persistence module", because each row/record in my database represents in-fact a running process and the fields of the record are simply the variables of this process instances. Each record update should push the process a step further - mostly using a decision point based on rules evaluating the old and new version of the record (exposed for rules as separate processs variables). I would like to use my record database instead of the original database schema used by jBPM persistence for storing the runtime state of the processes. Do you see this as a feasible solution? -------------------------------------------------------------- Reply to this message by going to Community [https://community.jboss.org/message/778308#778308] Start a new discussion in jBPM at Community [https://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Zdenek Hrib [https://community.jboss.org/people/zdenek.hrib] created the discussion "Re: Using jBPM as state machine engine - is it a good idea?" To view the discussion, visit: https://community.jboss.org/message/778324#778324 -------------------------------------------------------------- Well maybe I got it all wrong so I start with a bit of context ... I understand that the main focus of jBPM is to coordinate a business process covering several B2B interactions with several systems (notifying the external system and also being notified by the external system) and also including some direct human tasks (click the button to approve, etc ...). But I would like to do something different - I would like to use jBPM inside just one system and use it to manage the state transition logic for my records (to make it even more simple it is just a single type of record stored in one table in the database). I would like to use the decision points driven by rules after each record update, but possibly in the future I would like to extend the process definition (state diagram of the record) with some notifications or some other automated tasks in case of some transitions - all of that using the nice tooling of jBPM :-) In this case the state of the process/record is represented by the values of the record fields. One of the fields is called "state" and this is the name of the current state of the record. So this is basically the persistence schema of my process runtime. But the jBPM has its own schema as shown on http://docs.jboss.org/jbpm/v5.3/userguide/ch.core-persistence.html#d0e3334 http://docs.jboss.org/jbpm/v5.3/userguide/ch.core-persistence.html#d0e3334 I do not want the process runtime state to be stored on two separate locations. I would like the jBPM to use my existing process runtime state storage, which is represented by my table in the database. This table should replace the ProcessInstanceInfo table in the jBPM database schema. If I look at the specific fields of the ProcessInstanceInfo table: instanceid - I got primary key in the table already lastmodificationdate - I got that lastModifiedDate in the table already lastreaddate - this should be easy to add processid - all the records are processed by the same process definition so this could be set somewhere else for the whole table processinstancebytearray - instead of this BLOB I would like to use the values the fields (columns) of the record (database table row) startdate - this looks like the date, when the row was inserted/created state - I got this field in the database already optlock - this should be easy to add It looks to me like I would have to implement something like my own variant of JPAKnowledgeService to use my database table with my columns instead of the original jBPM ProcessInstanceInfo table. This is what I ment by *"custom persistence module"* in the earlier post*.* Also I would have to somehow configure the jBPM engine to use this MyOwnKnowledgeService instead of the original jBPM JPAKnowledgeService. -------------------------------------------------------------- Reply to this message by going to Community [https://community.jboss.org/message/778324#778324] Start a new discussion in jBPM at Community [https://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Zdenek Hrib [https://community.jboss.org/people/zdenek.hrib] created the discussion "Re: Using jBPM as state machine engine - is it a good idea?" To view the discussion, visit: https://community.jboss.org/message/778800#778800 -------------------------------------------------------------- my "system" is basically a simple JBoss EAR, exposing basic CRUD operations for one entity through JAX-WS and using JPA to store the entities and Envers for auditing I originally wanted to: 1. store the state of the record only on one place - OK, I guess that the state name could be actually stored in the jBPM tables and not my original tables, but for the other values of the record I would still use my original tables (I will treat the BLOB in the jBPM tables as just a temporary variable storage) 2. trigger the rules evaluation and "next step transition" immediatelly after the entity update - I could call the jBPM engine in the web service bean "update" operation 3. have access to the record data (both old and new version) in the rules so I could decide about the state change -  I can feed the already running process with these variables during the call of jBPM in the web service bean "update" operation 4. the old records to have their running processes immediatelly after upgrading the system to jBPM enabled version - hm, I guess I would have to miss this, but it is not a big deal 5. have the envers data audit to include the state changes - hm, I could try to merge the the data audit trail and the jBPM state audit trail somewhere in the user interface So I guess if I can do something like this in the web service bean operations, then it would be quite simple: CREATE operation: ProcessInstance process = definition.startNewInstance("mydefinition.process", newRecord); //use the values of the created record as starting point including standard process data peristence into jBPM tables newRecord = somehowGetTheUpdatedValuesOfTheNewRecord(); //as it could have been updated inside the process rules newRecord.setProcessId(process.getProcessId()); storeIntoDatabase(newRecord); UPDATE operation: RecordUpdateEvent event = new RecordUpdateEvent(); event.setOldRecord(originalRecord); event.setNewRecord(newRecord); signalEventToTheRunningProcess(originalRecord.getProcessId(), event)/ / do the transition and if there are rules then decide by the record values including standard process data peristence into jBPM tables newRecord = somehowGetTheUpdatedValuesOfTheNewRecord(); //as it could have been updated inside the process rules storeIntoDatabase(newRecord); I would just have to make sure, that the step transitions will be triggered only via the web service bean and not through the UI of jBPM or some other way .... -------------------------------------------------------------- Reply to this message by going to Community [https://community.jboss.org/message/778800#778800] Start a new discussion in jBPM at Community [https://community.jboss.org/choose-container!input.jspa?contentType=1&...]