Kuali Rules Management System Kenton Hensley Lead Business Analyst, Kuali Coeus (at Cornell)

1. Kuali Rules Management SystemKenton Hensley Lead Business Analyst, KualiCoeus (at Cornell)

2. What are Business Rules (BR)? • Organization Perspective • guidance, law, regulations and policy that an organization must/expects to implement/enforce • Information System Perspective • provide dynamic control over application behavior and configuration for user • Rules in Rice: • define a specific condition, evaluate the condition, return a decision and execute an enforcing action when the decision is “True”

3. Background • 2008 - KS starts on BR and presents at KD • scope considerations delay input • April 2009 - KC Review of gaps • proposal, prioritization in ARC • KD 2009, Nov – Review of Open Source solutions • decision made to go custom • establish User Requirements and basic scope • Feb 2010, Tucson F2F • scope agreed by KS along with basic design; KS joins dev. effort

4. Goals and Priorities for KRMS • Functional equivalence with Coeus • select workflow maps • call notification engine • execute validations • invoke questionnaires • Rice middleware considerate • Create fit with Rice modules KEW, KNS, etc. • Requirements of other projects • principally KFS, KS

5. Terminology • Looked for industry “standard” terminology • Semantics of Business Rules (OMG) • Drools and other open-source • Informed by Kuali Student’s work • Coeus: Had to give some things a name • Informed by work done on Student • Not yet set in stone

6. Context • Where the rule applies (Business domain is equivalent) • where terms and other objects used are unambiguous and relevant • criteria stored in the Context Descriptor • boundaries primarily defined by Document Type (hierarchical), • all enities used with rules are associated with a context • can have “global contexts) e.g. Workflow (KEW) or KRMS might have a context that other contexts can use • Coeus: • combination of Type, Module, Sub-module create the context

7. Terms & Facts • Def: information relevant in a context and used as operands in propositions (comparison statements) • terms can be arranged in categories • facts are specific instance of Terms, e.g. a Proposal with Proposal ID of 2348910 (the fact) • Coeus: Columns

8. Condition • a condition – a state that exists in the context and evaluated to determine a rules decision (true or false) • constructed of one or more propositions • Coeus: The same

9. Proposition • Proposes/supposes and tests that a condition exists – if it does exist, action is taken (enforcement) • comparison statements made up of an operator and two operands , e.g. X>Y and joined by logical operators • one or more comparison statements joined by a comparison operator • Coeus: • the same

10. Custom Term • custom term – a procedure which can be passed information and returns a value • custom proposition used sometimes to refer to a custom • use for complex evaluations • Coeus: same

11. Actions • A procedure that is executed if the rule condition exists (evaluates to True) • Actions accept information from the context • Actions will be matched to events where they make sense • Coeus: • Type is also the action: Notification, Workflow

12. Events • a defined “happening” in the application that on which other functionality depends • events are “published” and agenda “subscribe” to the events • agenda execution is triggered when the event happens • can have multiple events executing an agenda. • Coeus: • events implicit for each rule type e.g. workflow rules run on submit

13. Agenda • Execution plan for a set of rules • has three operations • run rule • WHEN: branch based on previous rule decision (When TRUE & When False) • FIRST TRUE: run through list of rules until one returns “True” • Coeus: • Meta-Rule

14. UI: Introduction • Using professional interaction designer • Recent decision: KRMS first with KRAD • (Kuali Rapid Application Development) • Significant Design Changes • For Proposition • operands can be any term, custom term, literal or constant • Custom term parameters can accept any term • Agenda logic continues after branching • attempted to simplify look and feel

15. UI: Rules

16. UI: Context View

17. UI: Rule Editor – Condition

18. UI: Agenda

19. Custom UIs – student

20. Miscellaneous • Functional • Execution Logging • a list of evaluations made in the condition • all propositions with facts inserted and the evaluation result • Re-use and Rule Ownership and Versioning • needed to model the way rules are managed • Technical • KRMS will be Exposed on Service Bus • Introduction of KRAD next generation UI for Rice • Custom Editors are possible

21. Scope Impacts – Differences with Coeus • Scope Impacts • Making generic for Rice – Events, Actions • Service Architecture • Integration with KRMS (probably neutral) • Execution Logging/Messaging Framework • Dynamic Term UI based on Term Categories • Re-use • Versioning

22. Status • Functional (April 15) • Specification in third draft • versioning and reuse (timeline uncertain) • need some additional use cases • permissions • actions • Interaction Design (April 15) • Completing second iteration of Mocks • Filling in gaps: Custom Terms, • Context View coming up • Development (Engine POC April 1) • KS working on execution engine • pluggable architecture

23. Implementing KRMS in KC • Define and populate contexts • contexts, terms, custom functions • anything app specific • Implement Org. Logic • traversing tree to find and execute agenda

24. Resources • Rice Rules Page in Confluence • https://wiki.kuali.org/display/KULRICE/Rice+1.1+-+Kuali+Rule+Management+System+%28KRMS%29+Analysis • Rule Semantics (Object Management Group) • http://www.businessrulesgroup.org/sbvr.shtml • Drools BRMS (JBoss) • http://www.jboss.org/drools/ • Rice 2.0 Timeline • https://wiki.kuali.org/x/I0lyEg • Rice Documentation (no KRMS yet) • http://kuali.org/rice/documentation/1.0.3/ • Mocks (change the version number in URL to get the latest) • https://www.kuali.org/mocks/BFN/businessrules06.html