6 Replies Latest reply on Nov 28, 2012 4:32 AM by zdenek.hrib

    Using jBPM as state machine engine - is it a good idea?

    zdenek.hrib

      Hi,

       

      I usualy have a database oriented application, which stores records, where one field of the record (one column in a row in database) stores something called "state" - eg. record is "new", "revised", "waiting for approval" or "cancelled". The state of the record should change automatically according to changes in other fields of the record - eg. if someone changes a description of a "new" record, it should be changed to "revised" but if amount > 100 than it should go to "waiting for approval" instead. I would like to have some library where I could in case of record update do something like this (pseudo-code):

       

      Process process = createProcesFromDefinition("mydefinition.process");

      process.setCurrentState(getStateFromDatabase());

      process.setOldRecord(getRecordFromDatabase());

      process.setNewRecord(getRecordWhichIsToBeSaved());

      State state = process.computeResultingState();

      storeStateToDatabase(state);

       

      I would like to have the process definition (state diagram) in some kind of XML format, and the rules for decision about the resulting transition in MVEL (or something else supported by Drools/JBoss Rules).

       

      Is it possible to use jBPM in this way - just as a state machine engine? Could someone point me in the right direction, which classes should I explore in the jBPM API to do this?

       

      I have seen some examples, but they always start the process from the beginning - but I would like to "fast forward" the process in some other state, provide some data, and let the engine&rules to choose the next state.

       

      Thank you

        • 1. Re: Using jBPM as state machine engine - is it a good idea?
          swiderski.maciej

          I would say you could do this by combining power of jBPM and drools. First of all, I believe that traditional process definition would not fit your needs but ad hoc processes are in my opinion excellent choice here. See some details about ad hoc processes here.

          Just one important comment is that you would not rely on process instance state as it's internal information for the engine and cannot be altered based on business data but rather use process variable that can be easily modified by process activities and rules.

           

          Generally it would work like this:

          - start ad hoc process which will  not make any activity running yet

          - signal given activity or execute rules that will decide what activity should be signaled

          - at any point a decision needs to be taken a business rule task should be executed that will evaluate what needs to be done:

               - set process variable according to current state of the process

               - signal another activity to continue processing

           

          HTH

          • 2. Re: Using jBPM as state machine engine - is it a good idea?
            zdenek.hrib

            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?

            • 3. Re: Using jBPM as state machine engine - is it a good idea?
              swiderski.maciej

              Not sure if I understood concept of "custom persistence module" correctly, if you could elaborate bit more on this would be great.

               

              In general you would need to combine jbpm tables and your data base model so both will have correct persistent store available for its data. Every change of the record would need to signal corresponding process instance to (re)evaluate rules and take appropriate action to move process to another activity/state.

               

              HTH

              • 4. Re: Using jBPM as state machine engine - is it a good idea?
                zdenek.hrib

                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

                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.

                • 5. Re: Using jBPM as state machine engine - is it a good idea?
                  swiderski.maciej

                  In theory I think it would be doable but you need to remember that ProcessInstanceInfo is not the only table used by process runtime, we have WorkItemInfo, SessionInfo, etc. So doing it all would be rather significant change. And even if you do it then I think you won't be able to use process instance state to represent your business state as it is used internally and has some predefined values that must be kept. So you would still need to use process variables to store some data that will be used by the process instance (evaluate rules, etc)

                   

                  What is the issue with having jbpm tables in your data model? Note that they can be in separate schema/db.

                   

                  HTH

                  1 of 1 people found this helpful
                  • 6. Re: Using jBPM as state machine engine - is it a good idea?
                    zdenek.hrib

                    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 ....