[jboss-user] [jBPM] New message: "Re: Where to implement database work?"

[Viorel Andronic]

User development,

A new message was posted in the thread "Where to implement database work?":

http://community.jboss.org/message/532306#532306

Author  : Viorel Andronic
Profile : http://community.jboss.org/people/klawandronic

Message:
--------------------------------------------------------------
OK! Let me put it a little different.
 
JBPM allows the programmer to run custom code in certain places of a process, as described in the user guide, under the user code paragraph:
 
> 
> 
> 
> - custom
> - event-listener
> - assignment-handler in task
> - handler in decision
> - condition in transition
> 
 
I want this code to perform work on my database, preferably in a transaction.
 
I followed some guidelines and ended up having a very decoupled but 'not very useful?' architecture:
 
- JBPM deployed as a service with JTA configured XA on it's Oracle jbpm database
- business logic code inside a JBoss EJB container working XA on it's Oracle mydb database
- the EJB layer is starting and signaling JBPM processes sucessfuly right out of the box. GREAT!!!
 
But now I reached a point where I believe that the custom JBPM user code should actually use data found in mydb database(and/or other business logic code) to be able to perform REAL MAGIC. Otherwise I will have to hard-code business logic stuff in the JBPM custom code and JBPM execution information in the EJB layer; it is obvious that this scenario is to be avoided.
 
One way to avoid JBPM custom code to interact with the database is to store all info in the process instance variables when starting it. This could be enough if my custom code doesn't need to do database updates - and, normaly, it shouldn't. But take the following scenarion:
 
- I have a state machine and I start it from the EJB layer
- then, the recommended way to react on state change(according to common sense and also the user guide) is by using an event listener. GREAT!
- now the EJB layer needs to signal the process instance to continue to the next state, but my EJB doesn't know what state(the execution id) the process is in now(because I don't want to hard-code the states of the process in the EJB layer) since no one notified it(because my listener is not in the EJB container's scope, thus it cannot signal any EJB), nor find any useful information in the databse(since the listener doesn't have access to mydb) - as I think of it, one way to fix this is to use the listener to store the current execution id inside a process variable(but what if the EJB layer needs to react to the state change imediately or what if there are multiple concurrent executions in the process?)
 
I know that I may be looking at things in a wrong way, but I wasn't able to find any best practices related to this 'limitation'.
 
I saw that there is a way to call an EJB layer method from JBPM by using the <java> tag and looking up the bean in JNDI, but I'm not sure this applies to all cases. How can I 'trick' a state machine to notify the EJB layer whenever the state the process is in changes?
 
Regards,
Viorel

--------------------------------------------------------------

To reply to this message visit the message page: http://community.jboss.org/message/532306#532306