1 / 42

KEW Basics: A General-Purpose Electronic Workflow Engine

Learn about the basics of Kuali Enterprise Workflow (KEW), a versatile workflow engine designed to automate business processes. Explore core concepts, workflow offerings, and future technologies.

liggins
Download Presentation

KEW Basics: A General-Purpose Electronic Workflow Engine

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Kuali Enterprise Workflow (KEW) Basics Brian McGough, Manager, Systems Integration, UITS

  2. Project Background • Kicked off at IU 2001 as OneStart Workflow • First production install in 2003 • Joined development forces with Cornell in 2005 and renamed to Kuali Enterprise Workflow • Through 2006 incremental upgrades performed, and the project is now on its 2.2 release

  3. Project Background • Projects using workflow • Kuali • ERA • HR Edocs • Timekeeping • EPIC • Various eDoc lite projects • Core Development Staff • Ryan Kirkendall (Lead Developer, IU) • Eric Westfall (Developer, IU) • Aaron Hamid (Developer, Cornell)

  4. Agenda • Workflow Offerings • Core Concepts • An example workflow • Future technologies

  5. Workflow Offerings • Java API (for the java shops) • Easy to Use • Easy to setup • Client application in control • Requires client application written in java • Web Services API (for other technology shops) • Fairly easy to use • Client application in control • Edoc Lite (for departments without programmers) • Easy to use • XML document definition based • Small amount of technical expertise required

  6. Core Concepts • What is KEW? • KEW is a general-purpose electronic routing infrastructure or "workflow engine” designed to facilitate the automation of mediated business processes

  7. Core Concepts • E-Doc • Individual business transaction • Holds transaction specific information • Title • Business data (xml) • ‘Instance’ of a Document Type; behavior is dictated by its Document Type, sometimes referred to as a ‘Document’ • The ‘thing’ that travels through the Workflow System

  8. Core Concepts • Document Type • Brings Workflow components together into a cohesive unit (routing configuration) • Post Processor • Doc Handler (access point into client application from Action List) • Access Control for certain actions • Defines E-Doc routing paths • Defines E-Doc routing policy • Defines E-Doc Rule configurations • Defines Searchable attributes

  9. Core Concepts • Action List • Each user has an Action List • E-Docs are delivered to the Action List when an E-Doc requires action of a user • Configurable by user • Provides notifications through e-mail • Can view delegated E-Docs • Provides entry point into client application owning the E-Doc • Defined as Doc Handler • Provides link to Route Log • Limited customization through plugable java/xml components

  10. Core Concepts – Action List

  11. Core Concepts • Route Log • An aggregate view of an E-Doc’s relevant routing state • Shows who the E-Doc has been routed to • Shows where in the route chain the E-Doc currently is • Shows the E-Doc’s routing status • Shows the E-Doc’s future recipients • Provides capability to predict the E-Doc’s routing path

  12. Core Concepts – Route Log

  13. Core Concepts – Route Log

  14. Core Concepts • Document Search • Find E-Docs based on various Workflow criteria and optionally document specific criteria • Alternate entry point into client application owning the E-Doc • Provides link to Route Log • Basic and Advanced search • Named Searches allows users to save a search for later use • Provides Entrance into Super User Functionality (Administrative Routing)

  15. Core Concepts – Document Search

  16. Core Concepts – Document Search

  17. Core Concepts • Client Application • Application using Workflow to route E-Docs • Uses Workflow through web services and java components installed in Workflow • Users take actions on Workflow documents in the client application. The client application calls Workflow on behalf of its users

  18. Core Concepts • Workflow and Client Application Interaction

  19. Core Concepts • Rules • Application Routing Data Stored in Workflow • Prevents client applications from writing screens and logic to maintain their routing data • Routing data for multiple applications housed in a single location • Routing for client applications can be managed from a single place • Good for users that have responsibilities in multiple applications • Determine to whom an E-Doc will go based on business data • Will automatically reroute any affected documents when rule changes

  20. Core Concepts • Rule functionality driven by java/xml components that are reusable across client applications • Rule components represent an organizational routing “Tool box” that can be used by any client application in the university to efficiently deliver standard routing behavior • Routing behavior is sharable across applications and therefore more easily standardized • Rule sets created using components not sharable – each client application has rules available only to their document types • Components tell Rule framework how to draw rule data collection fields • Components evaluate each rule against an E-Doc • Components tell client application developers how to attach business data to E-Docs

  21. Core Concepts – Rule Creation • Circled area represents functionality exposed by reusable Workflow Rule java component

  22. Core Concepts - Rules without java • Drive rule/business data matching solely from xml technologies • Only most complex cases will require java programmers

  23. XML Rule Attribute Example • <ruleAttribute> • <name>DepartmentAttribute</name> • <className>edu.iu.uis.eden.routetemplate.xmlrouting.StandardGenericXMLRuleAttribute</className> • <label>Department Routing</label> • <description>Department Routing</description> • <type>RuleXmlAttribute</type> • <routingConfig> • <fieldDef name="department" title="Department" workflowType="RULE"> • <display> • <type>select</type> • <values title="COAS-African American/African Diaspora Studies">AAAD</values> • <values title="COAS-African Studies">AFRI</values> • <values title="COAS-American Studies">AMST</values> • <values title="COAS-Ancient Studies">ANCS</values> • <values title="COAS-Animal Behavior">ABEH</values> • <values title="COAS-Anthropology">ANTH</values> • <values title="COAS-Apparel Merchandising/Interior Design">AMID</values> • </display> • <validation required="false" /> • <fieldEvaluation> • <xpathexpression>normalize-space(substring-before(//department, ' ')) = wf:ruledata('department')</xpathexpression> • </fieldEvaluation> • </fieldDef> • <xmlDocumentContent> • <department>%department%</department> • </xmlDocumentContent> • </routingConfig> • </ruleAttribute>

  24. Core Concepts - EDoc Lite • Workflow renders the UI • Single xml file configures Document Type and UI • UI Configurable across universities and applications using XSLT • Lowers barriers of entry to doing Workflow

  25. EDL XML • <?xml version="1.0" encoding="UTF-8"?> • <data xmlns="ns:workflow" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="ns:workflow resource:WorkflowData"> • <edoclite xmlns="ns:workflow/EDocLite" xsi:schemaLocation="ns:workflow/EDocLite resource:EDocLite"> • <edl name="NewCourseRequest" title="New Course Request"> • <security></security> • <eventNotificationURL>http://localhost:8080/en-dev/snoop.jsp</eventNotificationURL> • <createInstructions>** Fill out the new Course Request.</createInstructions> • <instructions>** Review the Course Request.</instructions> • <fieldDef name="department" title="Department" attributeName="DepartmentAttribute"> • <value></value> • <display> • <type>select</type> • <values title="African American/African Diaspora Studies">AAAD COAS</values> • <values title="African Studies">AFRI COAS</values> • <values title="American Studies">AMST COAS</values> • <values title="Ancient Studies">ANCS COAS</values> • </display> • <validation required="false" /> • </fieldDef> • <fieldDef name="creditType" title="Check Appropriate Boxes"> • <value>undergraduateCredit</value> • <display> • <type>radio</type> • <values title="Undergraduate credit">undergraduateCredit</values> • <values title="Graduate credit">graduateCredit</values> • <values title="Professional credit">professionCredit</values> • </display> • </fieldDef> • <fieldDef name="academicSubjectCode" title="Academic Subject Code"> • <display> • <type>text</type> • </display> • <validation required="true" /> • </fieldDef>

  26. EDL Screen Shot

  27. Core Concepts • Route Modules • Tell Workflow to whom an E-Doc will route • Route based on data maintained by client applications (Workflow has no knowledge of data) • Accomplishes same thing as Rules – Workflow doing less work for you • Post Processors • Client application code contacted throughout the routing process • Simple notification mechanism to allow client applications to do operations based on their E-Docs progression through routing

  28. Core Concepts • Delegation • Allows users to delegate their authority to other users • A user that I delegate to can take action on my behalf • Done on an E-Doc by E-Doc basis and controlled by Rules or Route Modules • This means delegation can be based on business data (i.e. delegate to Sally if E-Doc total dollar amount > $100) • 2 kinds of delegation • Primary – the person who delegates their authority never sees their E-Docs in their Action List. The E-Docs go directly to the delegate’s Action List • Secondary – the delegate only sees the E-Docs if they check for E-Docs delegated to them.

  29. Core Concepts - Delegation

  30. Example Workflow • Show how the pieces fit together using a sample workflow • Document Type routing chains are assembled using “Route Nodes” • A route node is a pointer to a collection of Workflow Rule Components in the Rule system or a Route Module with a name • Policies can be applied at the node level that affect how E-Docs travel though Workflow

  31. Example Workflow Workflow with an E-Doc passing through three route nodes

  32. Example Workflow • Each route node connects reusable routing components with specific Document Types • Policies and behaviors can be configured through route nodes • Each node uses different business data attached to the E-Doc to determine where to send the E-Doc • Lets examine a single node up close and see how it interacts with all the core workflow concepts to form a cohesive route

  33. Example Workflow • Workflow’s interaction with a single node in routing a document

  34. Example Workflow • E-Doc comes into the system • Workflow is a service available to the client application via web services • Workflow is user action driven - a client application must tell Workflow that user X has taken action on E-Doc Y • When E-Doc comes into system Workflow determines which route node to send the document to for further processing • Route Node configuration determines which set of Rules the document will be evaluated against

  35. Example Workflow Rule System Compares document content to rules and creates action requests

  36. Example Workflow - Rules • E-Doc is evaluated against rule set for node. • If document business data matches rule business data the people and workgroups associated with the rules are sent a request • Java/XML components ‘plug’ into the rule system and are ultimately responsible for evaluating the business data contained in the document against the rule data • Route Module could do the same job with data outside the workflow system

  37. Example Workflow Document is sent to appropriate Action Lists with a link back to the client application

  38. Workflow Example - Action List • Action List has a link back to the Client Application • Client Application draws screen and informs Workflow of any E-Doc actions taken by the user • When user takes action on E-Doc the E-Doc is removed from the users Action List

  39. Workflow Example – Post Processor The Document Type’s Post Processor is notified as the E-Doc transitions through routing

  40. Workflow Example – Post Processor • Post processor is Client Application’s ‘hook’ into routing process • Notified during transition from one node to the next • Notified when document routing status changes • Notified when user takes action on document • Can prevent any transition from occurring • Generally, sanity checks are done here and client application data is updated as necessary

  41. Wrap Up • Covered a lot of ground in the last 5 years • Wrapping up some needed functionality in 2.3 • Moving towards industry standards for 3.0 release • BPEL (Business Process Execution Language) • ESB (Enterprise Service Bus) • Moving fast with 3 fte, but could move faster with additional resources devoted to the effort

  42. Wrap up • Check out our website • http://kew.indiana.edu • Contact us • workflow@indiana.edu

More Related