[jboss-dev-forums] [Design of JBoss jBPM] - Re: jbpm drools integration meeting

[tom.baeyens@jboss.com]

Hi, i take the liberty to post jeff's response:

"Jeff" wrote : 
  | Thanks for including me on the email thread. I am very interesting in this topic, as I have been working with customer to integrate jBPM and Drools. 
  | 
  | The emails contain various solutions (combined repositories, variable mappings, etc.), but I am not sure in some cases what problems are trying to be solved. So I though I might back up and start at what I think the jBPM / Drools integration requirements are, and see if that helps me understand this email thread.
  | 
  | I think the goal of jBPM / Drools integration should be to provide the application developers with several integration components out-of-the box that are well documented and address many of the common use cases. In many instances however a customer's requirements will be different enough that they will need to create their own integration components. Even in these cases, what we provide out of the box will help them as a starting point.
  | 
  | I think the requirements for jBPM / Drools integration are derived from a few general use cases:
  | 
  | 1) Task Assignment
  | 2) Actions Nodes
  | 3) Decision Nodes
  | 4) Rule Flow
  | 
  | Before discussing the details of each of these, I think there are a couple general observations that should be made. In terms of "how often they change", I believe that users would like to change their rules the most frequently, business processes somewhat frequently, and code (hopefully), not as frequently. Second, they would like business analysts to be able to make the frequent, minor changes to their rules (example below).
  | 
  | 
  | 1) Task Assignment. This involves invoking rules from a "RulesAssignmentHandler" to determine the actorId to set on the assignable (TaskInstance or SwimlaneInstance). In this case the organizational model, some domain objects, and the assignable need to be asserted into the rules engine.
  | 
  | The organizational model does not change too frequently (not more than daily in any case), and is perhaps quite large (thousands of employees) so it would be nice to not have to re-assert into working memory each time an assignment is made. The domain objects are changing from process to process, so they should be re-asserted. The assignable could be a global variable. 
  | 
  | The rules themselves might be quite numerous. For example, if we had an organizational model where users were mapped to roles within an office, and we wanted to assign a Task to someone in a specific role (based on the task definition) and office based on the state the insured lived in and the type of claim, then there might be a separate rule for each office and type of claim.
  | 
  | Rule "Determine Chicago Office"
  | 
  | when 
  | 	Insured ($state : state == "Illinois")
  | 	Claim ($lob : lineOfBusiness == "health") then
  | 	assert(new Office("chicagohealth"));
  | 
  | end
  | 
  | ...
  | 
  | Rule "Determine Actor"
  | 
  | when
  | 	exists Office()
  | 	Office($officeName : officeName)		
  | 	$role : Role()
  | 	Membership( role == $role, office == $officeName, $user : user )
  | 
  | then
  | 	$a.setActorId($user.getName());
  | 
  | 
  | In most cases the same rules would determine task assignment for all tasks within a process definition, so the task assignment rules should be able to be specified for the entire process definition. 
  | 
  | If the assignment rules change, e.g., a new office is opened to support the southern half of Illinois, then it is probable the case that the process definition should change. Otherwise in our example, we might have a claim that was being worked in Chicago office suddenly being assigned to the new office.
  | 
  | This type of usage would be supported by a pre-compiled rule base associated with a process definition. (as Tom describes in 1 in his email).
  | 
  | This scenario would also be well supported through the ability to assert the organizational model into the working memory once, and then use this working memory, asserting new instance of domain objects (and I suppose retracting them as well?). It is not really clear to me how this would work, particularly with multiple threads. Perhaps some kind of partitionable / composite working memory is required.
  | 
  | Although each customer would likely have their own organizational model, an out-of-the-box implementation based on the jBPM Identify component would be very useful for customers to understand how rules based assignment can work.
  | 
  | 
  | 2) Actions / Nodes. This involves invoking rules as at a node in a process, either from an action configured on the node itself or associated with some node event. In this scenario domain objects would be asserted in the working memory, along with the jBPM ContextInstance. The later would be used to communicate the results of the rule execution. I.e., the right hand side would invoke contextInstance.setVariable("resultsOfRuleExecution", "some result").
  | 
  | The ability to describe what domain objects should be asserted by this "RulesActionHandler" on the process definition is required. However this must be extremely flexible, as there are many different possible requirements here: assert all instance of a specific domain object, assert a subset of a specific domain object, assert single instances of many types of domain objects, assert multiple instances of many types of domain objects, etc.
  | 
  | Also, where the domain objects live must be flexible. While it may be convenient to store them off as ContextInstance variable, this involves serializing each object, and, depending on when they are stored in jBPM, the potential for them to become out-of-date. Thus just specifying a set of jBPM constextInstance variable is not enough, there must be a way to describe how to get the domain objects from other repositories (e.g., a hibernate query, a web service, etc.).
  | 
  | As noted above, Customers expect to be able to make minor changes to their rules within the context of an executing business process. So for example a rule compares values from two different domain objects, and if the values differ by more that a specified per cent, then the rule fires and the consequence sets some jBPM ContextInstance variable. In this scenario the user would expect to be able to adjust that deviation percentage, re-deploy the rule file, and when a currently executing process instance gets to the node that fires that rule, it will fire the latest version. So in this case if the rule base was precompiled and stored within jBPM, then there must be a way to modify it while a process instance is executing. I.e., it is okay for the "rule bases to be deployed and managed separately from processes but in the same repository" as long as by separately managed this requirement can be met.
  | 
  | Although each customer would have their own domain model, an out-of-the-box implementation of a RulesActionHandler along with an example would be very useful for customers to understand how rules can be invoked at node.
  | 
  | 
  | 3) Decision Nodes. This involves invoking rules from a RulesDecisionHandler. In this scenario, domain objects would be asserted in the working memory along with a set of transitions, and the token. The LHS of the rules would specify which transition to take, e.g., token.signal("transition"). The token and the transitions could be global variables.
  | 
  | In this scenario we might expect that if the rules for making a process routing decision change, then we might want to re-deploy the process definition.
  | 
  | Although each customer would have their own domain model, an out-of-the-box implementation of a RulesDecisionHandler along with an example would be very useful for customers to understand how rules based decision nodes can work.
  | 
  |   
  | 4) Rule Flow - Using jBPM as to control rule flow. In this scenario this is a single working memory for the process instance, and every node in the process definition asserts, detracts, modifies data to this working memory, causing rules to activate / fire. It is another way to control rule flow at a more macro level (for situations where agenda groups, salience, and just good rule design are not enough).
  | 
  | This requirement would be supported by a "rule flow jpdl" (much like the Seam "page flow" jpdl). Nodes would become blocks of rules (like agenda groups with even more control over when they execute). Process variables would constitute the objects asserted. When the process instance is created, the process variables would be instantiated, others may be created as the process proceeds. 
  | 
  | I am not sure this requirement involves persistent wait states. That is, I believe the execution of the entire process instance happens in a single transition, with no requirement to persist the intermediate state of the rule execution (I may be wrong here, I have not given this scenario much thought). On the other hand, if persistent wait states within the rule flow are required, then what Tom proposes for storing / reconstructing the working memory would be required as well.
  | 
  | I don't understand Tom's comment "By default, jBPM will fire all rules when a process variable is updated." If the update comes from the rules updating the working memory, then they will fire (if their conditions are now satisfied). How else would the process variables change (from some outside source?). Perhaps Tom has a different use case in mind for number 2, although I don't think it fits in the other use cases I described above.
  | 
  | Jeff
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964120#3964120

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964120