1. Kuali Rice at Indiana University Important Workflow Concepts Leveraged in Production Environments July 29-30, 2008 Eric Westfall

2. Document Type −Specification for a document that can be created in KEW −Contains identifying information as well as policies and other attributes Super user, blanket approve, exception groups “from” email address for email notifications −Defines the Route Path executed for a document of that type (Process Definition) −Hierarchical - children can inherit certain attributes from their parents −Defined in XML

3. Route Node −Represents a “step” in the routing process of a document type. −Defines the behavior of the document when it reaches that node −Examples: Simple - do some arbitrary work Requests - generate action requests using a Route Module or the Rules engine Split - split the route path into one or more parallel branches Join - join one or more branches back together Sub Process - execute another route path inline Dynamic - generate a dynamic route path

4. Implementing Custom Nodes Custom nodes can be implemented in Java Examples include: −A SplitNode with custom, app-specific logic −A DynamicNode to generate a route path which climbs a hierarchy (KC does this for Unit Hierarchy routing) −A SimpleNode to do some arbitrary work Send an email Call a web service Etc.

5. Documents Documents are created for specific Document Types Submitted to KEW engine for routing Interaction with documents is done through KEW API (or by using KNS) Can receive further actions throughout lifecycle (Approval, Disapproval, etc.) Have an XML payload attached to them which can be used for routing purposes

6. Types of Routing Ad-hoc Routing −Simplest form of routing −Application manually dictates who to route to using API Route Module −Heavyweight component which can be implemented to provide completely custom routing −Most of what can be done in Route Modules can be done using Routing Rules Routing Rules −Rule Attributes −Role Attributes −Rule Templates −Routing Rules

7. Rule System The Rule System is the most commonly used type of routing in KEW The Rule System consists of the following pieces: −Rule Attributes −Rule Templates −Routing Rules GUI for creating Routing Rules Rule Quick Links

8. Rule Attributes A Rule Attribute is a multi-purpose component with the following responsibilities: −Executes logic for Rule evaluation −Defines how Rule data related to the attribute should be collected −Performs validation of Rule data −Generates XML to attach to the payload Can be written in Java or XML+XPath

9. Rule Templates A Rule Template is a collection of Rule Attributes Defines what data should be collected and evaluated on the Rule Example – A template used to create Rules which route to Deans might include Rule Attributes for “Campus” and “School”

10. Routing Rules Routing Rules evaluate data on the document and determine who should receive action requests (approve, ack, fyi) Configured via a GUI (or imported from XML) The RuleTemplate and it’s attributes define what fields will be collected in the Rule GUI During routing, Rule Evaluation Sets are “selected” at each node. Default is to select by Document Type and Rule Template defined on the Route Node Other Rule Selector implementations are available

11. XML-based Routing and Rules XML data on document can be used to make routing decisions. Rule system can leverage this XML for Rule evaluation using Xpath. An example of “Campus Code” XML: − BL Example Xpath configured on Rule Attribute −//campusCode = wf:ruleData(‘campusCode’) −Returns “true” if the campus code on document matches the campus code on the rule, causing rule to fire

12. “Role-based” Routing Sometimes it’s not convenient to use Rules because routing data is already available elsewhere or needs to be resolved dynamically In these cases, use “Role” Attributes A Role Attribute is a component written in Java which can be used to resolve users/groups to route to based on document data KFS Example – Fiscal Officer −Mapping between account and fiscal officer is stored in KFS database −Would be redundant to redefine this mapping in rules

13. Delegation KEW supports ability to delegate Action Requests −Primary Delegation −Secondary Delegation Delegation is currently rule-based Attached to specific responsibilities in Routing Rules

14. Exception Routing If failures or errors occur during routing, the document will go into exception routing Document will retry a configurable number of times before triggering exception routing Users in Document Type’s Exception Workgroup will receive it in their Action List There are other reasons a document might end up in exception routing: −DEFAULT_APPROVE policy is false and no approval requests were generated on the document −No approval requests were generated at a node marked “mandatory” −An approval request was generated after the “final approval” node

15. Searchable Attributes Searchable Attributes can be used to customize Document Search We’ll set up Searchable Attributes for Campus Code so we can search by it Open sample-thin-client-5.xml Ingest sample-thin-client-5.xml Route a document and then search by it’s Campus Code

16. Document Search Security Document Search supports the ability to filter rows from results based on Document Type security constraints Example: true SIS.SR.E.SU.Apprv

17. Super User Actions Super Users are defined by a workgroup associated with Document Type Super Users can access a special screen available from Document Search Can take Actions in place of other users Recorded on Route Log Also a pseudo-super user feature called Blanket Approval

18. Post Processors Receives events as the process is executed −Status Change −Node Transition −Action Taken by User Often used to “commit” the business transaction once all approvals have been gathered −Update database −Execute remote service call Have ability to participate in same JTA transaction as KEW engine

19. Plug-ins A plug-in is a packaged set of code that can be deployed into the standalone server Plug-in layout: −META-INF/workflow.xml −lib −classes When not using an Embedded KEW engine, Post Processors, etc. need to be deployed in a plug-in Additionally, Rule Attributes and other code used by the Rule System should be in a plug- in even if using Embedded KEW

20. Workgroups Workgroup names are globally unique so we encode a namespace into the group name −i.e. SIS.SR.E.SU.Apprv In general, we try to use workgroups on Rules whenever possible Workgroup membership change automatically updates Action Lists

21. Workgroup Types Important for decentralizing routing of groups Allows for different routing based on group type Allows for additional attributes to be attached We are currently just beginning to take advantage of this feature at IU We also have an “ADS” workgroup type which identifies groups from our active directory

22. eDoc Lite eDoc Lite is a simple, form-based system that runs entirely within a Standalone Rice Server, and can be created with no java, just XML. Will learn more about EDL tomorrow