1. M ODELING B USINESS P ROCESSES IN K UALI E NTERPRISE W ORKFLOW Eric Westfall – Indiana University Claus Niesen – Iowa State University

2. ANATOMY OF A WORKFLOW ENGINE What is a Workflow Engine? Orchestrates business process workflow It accomplishes this via: routing content through a variety of routing nodes What must it be capable of doing? Modeling both simple and complex processes Interacting with multiple entities (both humans and services) Running asynchronously Transactional operation

3. KEW OVERVIEW Composed of a set of services APIs, frameworks, and User Interfaces Routes documents based on type, where the associated Document Type definition declares a route path for the document. Based on this route path, various behaviors will be performed based on the document content. Often, this behavior consists of interacting with one or more parties in the form of approval requests. For example: Transfer of Funds Timesheet Add/Drop Course Travel Authorization

4. KEW – CORE FEATURES Action List Document Search Route Log (Audit Trail) Notes and Attachments Simulation Engine Customizable and programmatically extensible

5. DOCUMENT TYPES Document Types allow you to specify content that can be initiated using KEW They are specified using XML markup

6. DOCUMENT TYPE DEFINITION...............

7. DOCUMENT TYPE Name – unique name that identifies this document type Parent – document type from which it inherits attributes SampleDocumentType RiceDocument

8. DOCUMENT TYPE Description – the primary responsibilities of this document type Label – UI name of the document type The Sample Document Type Sample document type to demonstrate KEW

9. DOCUMENT TYPE – POST PROCESSOR Responsible for completing business transaction Notified on node transition, status change, or action taken Specific to a particular set of Document Types org.kuali.rice.krad.workflow.postprocessor.KualiPostProcessor

10. DOCUMENT TYPE - SECURITY Customize who can view the document type Document Search Route Log Doc Handler Redirection SampleGroup

11. DOCUMENT TYPE - POLICIES Enforce policies on the document type DEFAULT_APPROVE true

12. DOCUMENT TYPE – SEARCH ATTRIBUTES Customization of document search Add document data as searchable fields Specify search fields of interface* Specify result columns to be shown* *can be conditional

13. DOCUMENT TYPE – ROUTE PATH Specifies the flow between the route nodes

14. ROUTE NODES Some of the primary types of Routing Nodes include: Split Nodes Join Nodes Simple Nodes Request Nodes Dynamic Nodes Sub Process Nodes You can also implement custom Nodes

15. ROUTE NODES - SPLIT A split node is one that is capable of splitting the routing path into multiple branches Branches are executed concurrently

16. ROUTE NODES - JOIN Join nodes complement a split node by allowing the multiple branches of the routing path to converge

17. ROUTE NODES – SIMPLE NODE Simple nodes are a base type that allows a developer to implement behaviors based on their own particular processing requirements

18. SIMPLE NODE EXAMPLES EmailNode: Allows sending of email messages LogNode: Sends messages to Rice’s logging stream SetVarNode: Allows setting of document variables RequestsNode: Generates action requests

19. ROUTE NODES - REQUEST NODES Generates ActionRequests that are fed into the action list(s) of a user, workgroup, or role Requires user action to proceed Include: approve, disapprove, acknowledge, etc… Have an associated Activation Type: S (Sequential): An ActionRequest is sent and must be acted upon before sending the next ActionRequest P (Parallel): Multiple ActionRequests are sent at once Requests can be generated by a custom Route Module or by the Rules engine

20. ROUTE NODES – DYNAMIC NODES Dynamic nodes are a more advanced form of developer-implemented node They allow for the dynamic modeling of a route path This is done by instantiating a set of node instances that will then be fed to the routing engine

21. DYNAMIC NODE EXAMPLE: Hierarchy Routing

22. ROUTE NODES – SUB-PROCESS Sub Process Nodes are named route paths that can be included in a document type’s primary route path. They allow the workflow author to create a route path that can be reused

23. CUSTOM NODE IMPLEMENTATION public class EmailNode implements SimpleNode { public SimpleResult process(RouteContext context, RouteHelper helper) throws Exception { if (context.isSimulation()) { // no side-effects! } else { // send off the email } return new SimpleResult(true); }

24. KEW APIS WorkflowDocumentActionsService – operations related to actions on workflow documents WorkflowUtilityService – miscellaneous operations In Rice 2.0, WorkflowUtilityService was split into the following: WorkflowDocumentService – document-related operations DocumentTypeService – Document Type-related operations ActionListService – retrieve action lists RuleService – interact with KEW rules engine NoteService – notes and attachments on documents

25. Workflow Document Actions Create Route Approve Save Blanket Approve Return to Previous Node Super User Actions Attach XML to document Set document title Execute Simulation

26. Using the API (Rice 2.0) WorkflowDocument document = WorkflowDocumentFactory.createDocument(“ewestfal”, “MyDocType”); document.setApplicationContent(“ my doc content ”); document.routeDocument(“My custom annotation”); String documentId = document.getDocumentId(); // after some routing happens... WorkflowDocument document = WorkflowDocumentFactory.loadDocument(“somebody”, documentId); if (document.isApprovalRequested()) { document.approve(“I approve this!”); }

27. RULE ROUTING Four key components used for Rule Routing Document Type (specifically the Route Nodes) Rule Attributes Rule Templates Routing Rules Not to be confused with the capabilities provided by KRMS (new module of Rice in version 2.0, we will discuss this later)

28. USING RULES Sample Route Node using ‘Rule Template’ Method … DocumentRuleTemplate Sample Route Node using ‘Named Rule’ Method … Named TestRule1

29. ROUTING RULES Evaluated against a document to determine who should receive action requests at a particular node. Created against a Rule Template. Rule matching behavior is handled by the Rule Attributes when the rule is executed. Defines the principals (users), groups and/or roles who should receive action requests should the rule fire. Examples: If dollar amount is greater than $10,000 then send an Approval request to Joe. If department is “HR” request an Acknowledgment from the HR.Acknowledgers workgroup.

30. KIM RESPONSIBILITY ROUTING Leverages Kuali Identity Management module to allow routing to KIM Roles via “responsibilities” which have been defined on those roles Allows for both KIM Permissions and workflow routing to use same KIM Roles Can be used with ‘Rule Routing’ on a single document type but not single node

31. RESPONSIBILITIES IN KIM Defines a responsibility to take action as part of a workflow process Based on: Document Type Route Node at which the responsibility should be applied Specifies: The action which should be generated when the responsibility is triggered (approve, ack, fyi, etc.) Request priority Force Action flag Responsibilities are assigned to roles, all members of the role inherit them

32. QUALIFIER RESOLVERS Used to find qualification data for matching to KIM Role Members Data can be located anywhere including external systems Can be custom coded java class implementing QualifierResolver interface Some provided options included in Rice NullQualifierResolver (Match All Role Members) XPathQualifierResolver (User provided XPath Expression) DataDictionaryQualifierResolver (KNS Specific)

33. PEOPLE FLOWS New to KEW in Rice 2.0 Principals, groups, or roles who need to take action in a prescribed order Supports delegation Processed as a combination of parallel and sequential processing Acts as a mini People-based workflow Integrated with the KRMS rules engine

34. PEOPLE FLOWS

36. EXAMPLE BUSINESS PROCESSES Using the tools available in KEW, many different types of workflow processes can be built Examples: HR Transactions (Hire, Terminate, etc.) Timesheet Review and Approval Purchasing Drop/Add Class

37. EXAMPLE - HUMAN RESOURCE TRANSACTIONS

38. EXAMPLE – TIMESHEET REVIEW AND APPROVAL

39. EXAMPLE - PURCHASING

40. SIS – DROP/ADD – THE RICE WAY EXAMPLE – DROP / ADD CLASS

41. QUESTIONS? Learn more at http://rice.kuali.orghttp://rice.kuali.org Join the rice.collab@kuali.org mailing listrice.collab@kuali.org