[rules-users] Finding the approver for an employee (1) Is this a good problem for rules? (2) How you would do it?

Edson Tirelli ed.tirelli at gmail.com
Thu Jan 13 03:53:05 EST 2011


  I will bite... :) follow my thoughts:

(1) Is this a good problem for rules?

  Yes, I would prefer to solve this with rules instead of with an algorithm.
Reasons are because it is well defined problem, it is expressed as a set of
rules by business, it will be easier to implement and maintain long term,
and it is likely that the rules might change over time. The drawbacks are
that the declarative solution will be heavier than the algorithmic solution,
but since it is not a critical path problem and results can even be cached
and only recalculated when data changes, that will probably not be a problem
for your application.

(2) How you would do it?

  There is only one thing that is tricky in this problem for a declarative
solution to deal with, and that is the recursiveness of departments, as you
can have an arbitrary number of departments in the hierarchy, and you need
to define relationships between managers and employees in different levels
of the hierarchy. To solve that the best way I know of is by calculating the
transitive closure, either for departments or for employees/managers. Since
you will have a lot less departments than employees, best is to do it for
departments. The closure can easily be calculated with 2 rules, but could
also be calculated in an external procedure and asserted as data into the
working memory. I am doing it in the rules.

  Other than that, there are several strategies to model the solution on a
forward chaining engine. In my case, I am opting for finding all eligible
approvers first and then eliminating the "false positives" and finally
electing the best (nearest manager) among the remaining approvers. This
could be done in several other ways, including finding conflicts first and
then the actual approvers or taking incremental approaches.

   Also, just to simplify the example, I am using salience as a conflict
resolution, but on a real application I would prefer to use ruleflow-groups.

   Let me know what do you think... :)

   Cheers,
      Edson

-------

   With your example dataset, my result was:

Employee: Mike Approver: Hilary
Employee: John Approver: Hilary
Employee: Kate Approver: Hilary
Employee: Janet Approver: Jessica
Employee: Jessica Approver: Kate
Employee: Jane Approver: Erica
Employee: Erica Approver: Kate

   Domain model (pseudo-code):

Person { name }
Department { name, parent, managers, employees }
Approver { employee, manager, distance }
DepartmentHierarchy { parent, sub, distance }

  Rules (actual code):

============
package org.drools.approver

dialect "mvel"

/*********************************************************
 *  Calculate the transitive closure for the Departments
 *********************************************************/
rule "Create direct department hierarchy"
when
    $d : Department( parent != null )
    not( DepartmentHierarchy( parent == $d.parent, sub == $d ) )
then
    insert( new DepartmentHierarchy( $d, $d, 0 ) );
    insert( new DepartmentHierarchy( $d.parent, $d, 1 ) );
end

rule "Create transitive department hierarchy"
when
    $dh1 : DepartmentHierarchy( )
    $dh2 : DepartmentHierarchy( parent == $dh1.sub )
    not( DepartmentHierarchy( parent == $dh1.parent, sub == $dh2.sub ) )
then
    insert( new DepartmentHierarchy( $dh1.parent, $dh2.sub, $dh1.distance +
$dh2.distance ) );
end

/*********************************************************
 *                  Business Rules
 *********************************************************/
rule "1. Define eligible approvers"
    @doc( "An eligible approver must be a direct or indirect manager of the
Person" )
when
    // there is a person
    $e  : Person( )
    // that is either an employee or a manager in department d1
    $d1 : Department( employees contains $e || managers contains $e )
    // and there is a department d2 in which that employee is not a manager
of
    $d2 : Department( managers not contains $e )
    // and the department d2 is a parent department of the department d1 in
the hierarchy
    $dh : DepartmentHierarchy( parent == $d2, sub == $d1 )
    // and there is a manager on the department d2
    $m : Person( this memberOf $d2.managers )
then
    // this manager is an eligible approver for the employee
    insert( new Approver( $e, $m, $dh.distance ) );
end

rule "2.a. Approver cannot be himself"
    @doc( "An approver cannot be the employee himself" )
when
    $a : Approver( employee == manager )
then
    retract( $a );
end

rule "2.b. Approver cannot be a peer"
    @doc( "An approver cannot be a peer of the employee" )
when
    $a : Approver()
         Department( employees contains $a.employee, employees contains
$a.manager ) or
         Department( managers contains $a.employee, managers contains
$a.manager )
then
    retract( $a );
end

rule "3.a. Approver cannot report to the employee"
    @doc( "An approver cannot report to the employee" )
when
    $a  : Approver()
    $dh : DepartmentHierarchy()
    $d1 : Department( this == $dh.parent, managers contains $a.employee )
    $d2 : Department( this == $dh.sub, managers contains $a.manager ||
employees contains $a.manager )
then
    retract( $a );
end

rule "3.b. An approver cannot be the peer to someone who reports to the
manager"
    @doc( "An approver cannot be the peer to someone who reports to the
manager" )
when
    // An approver
    $a  : Approver()
    // That is a manager of a department
    $d  : Department( managers contains $a.manager )
    // Cannot have a peer
    $p  : Person( this memberOf $d.managers, this != $a.manager )
    // That reports to the employee in another department
    $dh : Department( managers contains $a.employee, employees contains $p
)
then
    retract( $a );
end

rule "Approvers are the nearest managers"
    @doc( "From all eligible approvers, the actual approver is the nearest
manager in the hierarchy" )
    salience -10
when
    $a : Approver()
    exists( Approver( employee == $a.employee, distance < $a.distance ) )
then
    retract( $a );
end


/*******************************************************
 *                Define the dataset
 *******************************************************/
rule "Setup"
    salience 100
then
    hilary  = new Person( "Hilary" );
    john    = new Person( "John" );
    jane    = new Person( "Jane" );
    mike    = new Person( "Mike" );
    kate    = new Person( "Kate" );
    jessica = new Person( "Jessica" );
    janet   = new Person( "Janet" );
    erica   = new Person( "Erica" );
    a       = new Department( "A", null );
    a1      = new Department( "A1", a );
    a12     = new Department( "A12", a1 );
    a2      = new Department( "A2", a );
    a21     = new Department( "A21", a2 );
    a22     = new Department( "A22", a2 );
    a.managers.add( hilary );
    a1.managers.add( john );
    a1.managers.add( jane );
    a12.managers.add( mike );
    a12.employees.add( john );
    a12.employees.add( mike );
    a2.managers.add( kate );
    a21.managers.add( jessica );
    a21.employees.add( janet );
    a22.managers.add( erica );
    a22.employees.add( jane );

    insert( hilary );
    insert( john );
    insert( jane );
    insert( mike );
    insert( kate );
    insert( jessica );
    insert( janet );
    insert( erica );
    insert( a );
    insert( a1 );
    insert( a12 );
    insert( a2 );
    insert( a21 );
    insert( a22 );
end

/*********************************************************
 *             Printing the result
 *********************************************************/
// in a real application, this would probably be a query instead
// that would be invocated on demand by the application
rule "Print all"
    salience -20
when
    $a : Approver()
then
    System.out.println( "Employee: "+$a.employee.name+" Approver: "+$
a.manager.name );
end


-- 
  Edson Tirelli
  JBoss Drools Core Development
  JBoss by Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110113/435b415b/attachment.html 


More information about the rules-users mailing list