1. KUALI ENTERPRISE WORKFLOW OVERVIEW Eric Westfall

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 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  Drop Course

4. KEW – Core Features  Action List (User’s Work List)  Document Searching  Document Audit Trail (Route Log)  Flexible Process Definition (Document Types)  Simulation Engine  Notes and Attachments – All workflow documents get them, even if they don’t want them  Programmatically extensible  Wide array of pluggable components to customize routing and other pieces of the system

5. Document Types  Document Types allow you to specify content that can be initiated using KEW  They are specified using XML markup  They identify this content by a type name  Can also include policies and other attributes  Hierarchical, can inherit attributes from parents  Most importantly, they define the route path for initiated content

6. Process Definition - 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

7. Route Nodes - Split  A split node is one that is capable of splitting the routing path into multiple branches  Branches are executed concurrently

8. Route Nodes - Join  Join nodes complement a split node by allowing the multiple branches of the routing path to converge

9. Route Nodes – Simple Node  Simple nodes are a base type that allows a developer to implement behaviors based on their own particular processing requirements

10. 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

11. 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

12. 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

13. 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

14. Custom Node Implementation  Making an example of the Email Node: public class EmailNode implements SimpleNode { public SimpleResult process(RouteContext context, RouteHelper helper) { if (context.isSimulation()) { // no side-effects! } else { // send off the email } return new SimpleResult(true); }

15. KEW API  Consists of two main services: 1. WorkflowDocumentActions  All operations related to a workflow document 2. WorkflowUtility  Implements various query operations

16. WorkflowDocumentActions  Create  Route  Approve  Save  Blanket Approve  Return to Previous Node  Super User Actions  Attach XML to document  Set document title

17. WorkflowUtility  getRouteHeader  getDocumentType  getAllActionItems  isUserInRouteLog  routingReport (executes the Simulation Engine)  performDocumentSearch  ruleReport  getActiveNodeInstances  getDocumentStatus

18. Rule Routing  Four key components used for Rule Routing  Document Type (specifically the Route Nodes)  Rule Attributes  Rule Templates  Routing Rules

19. Document Type (Route Nodes)  Sample Route Node using ‘Rule Template’ Method … DocumentRuleTemplate  Sample Route Node using ‘Named Rule’ Method … Named TestRule1

20. Rule Attributes  Defines how a Routing Rule evaluates document data to determine whether or not the rule should fire.  Also defines what data is collected on a rule.  An attribute typically corresponds to one piece of data on a document (i.e. dollar amount, department, organization, account, etc.)  Can be written in Java or defined using XML

21. Rule Templates  A composition of Rule Attributes  When a Routing Rule is created, it is created for a specific Rule Template and Document Type.  Defines what data should be collected and stored in the rule (via it’s Rule Attributes)  Also used to identify the set of rules to evaluate at a “Requests” Node  Can also be used to define various other rule properties (defaults, etc.)

22. 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.

23. KIM Responsibility Routing  New to Rice 1.0.x  Leverages Kuali Identity Management module to allow routing to KIM Roles via KIM Responsibility objects  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

24. Document Type Configuration  Node must be defined using xml tag rather than tag used for ‘Rule Routing'  tag identifies to KEW engine that node will use KIM Responsibility Routing  xml tag is used in and elements

25. Qualifier Resolvers  Used to find qualification data for matching to KIM Role Members  Data can be located anywhere including external systems  Defined on Node using fully qualified class name  Single class can be used on multiple document types and multiple nodes

26. Qualifier Resolvers (cont)  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)

27. KIM ‘Responsibility’ Business Object  KIM specific object  Very similar to KIM Permission object  Usually one or more KIM Roles are assigned to a Responsibility  Each Responsibility has a Namespace value (KR- SYS, KFS-AR, KS-LUM) but these are not used by KEW routing  Responsibility has data values associated with it via ‘Detail Value’ elements

28. Responsibility Detail Values  KEW uses specific Responsibility Detail Values to find matching Responsibility objects  Document Type Name  Route Node Name  Responsibility create/edit UI is designed to collect this information  Can be viewed from the Responsibility Lookup

29. Responsibility Detail Values (cont)  documentTypeName – The KEW document type name that the responsibility applies to  routeNodeName – Specific Node Name to use this particular Responsibility for  actionDetailsAtRoleMemberLevel – Tells KEW where to find Action Info (request type, priority, etc)  required – Notifies KEW if this Responsibility is required to generate at least one Action Request

30. KIM Roles  Qualification values returned by node’s Qualifier Resolver class are used to fully qualify Role Members  The Responsibility Detail Value ‘actionDetailsAtRoleMemberLevel’ determines how Role collects Responsibility ‘Action Info’  True: Each Role Member will have it’s own ‘Action Info’ data  False: The ‘Action Info’ data will be set at the Role Level and every Role Member uses it

31. DESIGNING WORKFLOW PROCESSES Eric Westfall

32. Anatomy of a Document Type Definition...............

33. Defining Route Paths P...

34. Designing Workflow Processes  Next, we’re going to take a look at some Document Type definitions in XML.  We will look at some of the Document Type definitions you will work with in the next exercise:  Simple Document Type with Ad-Hoc Routing  Routing Rules using Simple Rule Templates  Parallel Branching using Split Nodes  Using Conditional Split Nodes  Using a PostProcessor

35. Different Types of Nodes P P DepartmentCodeQualifierResolver P FinalApproversTemplate myemail@localhost initiator testemail@localhost ConfirmationEmail.Stylesheet edu.iu.uis.eden.mail.EmailNode