[rules-users] [droolsflow] JPAKnowledgeService - how do you reload a Session with Processes?

Fri Oct 23 12:03:31 EDT 2009

Quoting Bill Tarr <javatestcase at yahoo.com>:

> What is the purpose of persisting the SessionInfo @Entity?  
Note that we are not purely process-oriented but knowledge-oriented, so
this also includes rules and event processing.  If you only use simple
processes without rules, your session state will indeed be empty.  But
all rule-related state (objects in working memory, rules on agenda,
etc.) can also be part of your session state.

> It has lost it's processes, what useful information does it
> have?  Why not just create a new Session and use it to open your
> processes?
If you only use processes without rules, you could do this.

> I do recognize the need to maintain a list of processes associated
> any given domain objects (which for me are Claims.)
Based on your explanation, I still believe you should probably not use
getProcessInstances() to find the process instance you need to signal. 
Main reason is that we want to avoid having all active process instances
in memory (we use lazy loading), and this might become difficult to
manage once you start adding more processes. Alternatively, you could do:

1. Add the necessary data to your Claim object to facilitate looking up
this information later.  For example, use on-entry/on-exit actions to
add an Episode to your claim, where the Episode would contain the
process instance id.  That way you can query the Claim for active Episodes.

2. Retrieve the top-level Claim process instance and search for all
active node instances in there that are SubProcess node instances.  You
can get the process instance id from those as well.

3. Use a custom history log and create queries that could retrieve the
active sub-processes of a parent process based on the logged events.

Kris

> 
> Let me lay out the system and use case, and my proposed solution, and
> you can tell me if I'm barking up the wrong tree.
> 
> MODEL
> 1. I have a *Claim* process
> 2. has 1..n of subflows in a ForEach representing documents
> 3. has 1 supporting subflows each for - Creation, Benefits,
> Subrogation
> 
> WORKFLOW
> 1. Each Claim (and subflows) interacts with several users
> 2. Long periods of time between user interaction (waiting for extenal
> stuff)
> 
> DESIGN IDEA
> 1. Create sessions and processes with JPAKnowledgeService on Claim
> create
> 2. Have Events as blocking points in the flows, persist - await User
> interaction
> 3. Store Session ID in Claim domain object (i.e. Claim#1002 is Drools
> Flow Session#879)
> 4. Events from User, reload session, **route Event to appropriate
> workflow**
> 
> USE CASE
> 1. Receive Event in Document #2 of 2
> 2. All Doc Process are now complete, return to Claim Process
> 3. Claim Process continues, enters Benefits Process
> 
> So, during one Event, Drools has closed a Process, returned to the
> parent Process, then opened a new Process as a subflow.  
> 
> If the reloaded Session knew all the processes associated with my
> Claim, I could handle events coming in easily.
> 
> Look at the session, find the active subflow, pass in the event. 
> Otherwise I must track all subflows.
> 
> Anyway, any help you can provide in helping me understand how to use
> the persistence model better is greatly appreaciated.
> 
> Bill
> 
> 
> 
> ----- Original Message ----
> From: Kris Verlaenen <kris.verlaenen at cs.kuleuven.be>
> To: Rules Users List <rules-users at lists.jboss.org>; Bill Tarr
> <javatestcase at yahoo.com>
> Sent: Thu, October 22, 2009 6:19:30 PM
> Subject: Re: [rules-users] [droolsflow] JPAKnowledgeService - how do
> you reload a Session with Processes?
> 
> The getProcessInstances() method returns all process instances that
> are
> currently loaded into the engine.  When using persistence, we
> deliberately made that method to NOT fetch all active process
> instances
> (as this could be thousands and that would impact performance).  So
> if
> you use persistence, you will always get an empty list as the
> process
> instances are not kept in memory but stored in the database.  But
> don't
> worry, the engine will know when to reload process instances, you
> shouldn't take care of that yourself.
> 
> Could you explain the use case you are trying to support in a little
> more detail?  In general, I think you should be using a history log
> for
> this, where you can query the active instances, the completed ones,
> what
> happened, etc.
> 
> Kris
> 
> Quoting Bill Tarr <javatestcase at yahoo.com>:
> 
> > How do I FULLY reload my session with JPAKnowledgeService? 
> > Specifically, shouldn't my session still know it's processes after
> > reloading?
> > 
> > I'm using JPAKnowledgeService to persist my sessions and
> processes,
> > after running, I have the following DB rows:
> >    
> >    SessionInfo - 1
> >    ProcessInstanceInfo - 3 (1 ClaimFlow, and 2 subflow DocFlows)
> > 
> > I get a session properly with loadStatefulKnowledgeSession: 
> > 
> >    StatefulKnowledgeSession session =
> > JPAKnowledgeService.loadStatefulKnowledgeSession( 1,
> knowledgeBase,
> > null, env );
> > 
> > but this statement returns an empty collection:
> > 
> >    Collection<ProcessInstance> instanceCollection =
> > session.getProcessInstances();
> > 
> > There is no key link between @Entity SessionInfo and
> > ProcessInstanceInfo, so that result makes sense.... but shouldn't
> > restoring the session restore the links to the active process
> within
> > that session?
> > 
> > I can get the processes by id, but I'm not sure grabbing a subflow
> > works in this example, I really want the session:
> > 
> >     ProcessInstance processClm = session.getProcessInstance(1);
> > 
> > Is there actually some other way to retrieve the processes from
> > reloaded session?
> > 
> > As always, thanks for the help!
> > 
> > Bill
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around 
> > http://mail.yahoo.com 
> > 
> > _______________________________________________
> > rules-users mailing list
> > rules-users at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> > 
> 
> 
> 
> 
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
> 
> 
> 
>       
> 
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
> 

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm