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

2. Document Type • 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 • 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: • <campusCode>BL</campusCode> • 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: <security> <initiator>true</initiator> <routeLogAuthenticated>true</routeLogAuthenticated> <searchableAttribute idType="emplid" name="emplid" /> <workgroup>SIS.SR.E.SU.Apprv</workgroup> </security>

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