Kuali Rice 2.4.2 KEW Guide

Workflow is a very general term and means different things in different contexts. For example, it may mean the sequence of approvals needed for a Leave Request or it may refer to a complex scientific procedure.

In our context of enterprise applications within a higher education institution, we're usually talking about business process management when we discuss workflow. Usually, this revolves around business rules, authorizations, and routing for approval.

A simple example is a leave request system. It needs some workflow to get the necessary people (supervisor, etc.) to approve it. This is one example of the routing and approval side of a workflow.

You may also have business rules in workflow that dictate that some people get automatic approval for leave requests. This is a business rule detail that workflow executes by automatically routing these types of requests past the approval steps.

The Kuali Enterprise Workflow (KEW) product revolves around routing and approval of documents. It is a stand-alone workflow engine upon which you can integrate other enterprise applications to do routing and approvals.

In addition, KEW contains an eDocLite system. This is a mechanism to create simple data-entry forms directly in KEW. You can also create routing rules around eDocLite forms. eDocLite forms are the rough equivalent of the basic, one- or two-page forms that are commonly used to process business and get signature approvals.

The benefit of eDocLite in KEW is that it does not require a separate application. You can use eDocLite in KEW simply by setting up the forms that your institution or department needs.

Overall, KEW is based on documents. In KEW, each document has a collection of transactions or things to be done. Each transaction is approved or denied individually in KEW.

For example, John Doe may use a Leave Request document in KEW to ask for a week off in June. The KEW Leave Request document contains enough information for his supervisor to make a decision about John's leave. (The document may use data keys to retrieve external information, such as John's past Leave Requests and available hours.) Once John submits his Leave Request, KEW routes it to John's supervisor for approval. Depending on how John's department has configured KEW for routing Leave Requests, after John's supervisor approves or denies his request, KEW may route it to more people for further action to be taken.

Once John's Leave Request document is processed, it triggers a PostProcessor, which can perform any desired additional processing. This is most commonly used to "finalize" the business transaction once all approvers have signed off on it. In this particular example, it might call another service that would update records in the Leave Request application's database, indicating that the individual has successfully scheduled leave during that time period.

In addition, the KEW PostProcessor contains hooks for all the stages that a document goes through. For example, an external application may use a KEW workflow for routing and approval of documents, and that application may take action at each change in state of a routed document.

The primary benefit of KEW workflow is the correct routing for approval of documents. It enforces your business-specific rules about who needs to approve what documents, in which scenarios.

Simple Workflow Example

Leave Request: Each person has one other person (possibly more) who needs to approve his or her leave requests. In this context, KEW is the system that manages both the approval structure and the leave requests themselves (the actual approvals).

More Complex Workflow Example

Purchasing Desktop Computers: You may need several business rules in KEW for this, such as a rule to enforce:

In this example, KEW requires an approval if:

The workflow also requires an approval by the signer (or delegate) for each spending account that you use for the purchase.

In KEW, Approval Types are set up such as account approver, supervisor, or organizational/department hierarchy approver. An Approval Type contains the applicable routing and approval rules. Once you create an approval type, those routing and approval rules are available for other workflow clients and scenarios. This creates a tipping point situation, in which the more applications and business processes you set up through workflow, the easier it gets to do new ones.

In addition, KEW can help you with distributed management of approval structures. Each group at your institution (each college, unit, division, etc.) can create their own approval and workflow structure for their group, and you can centrally manage the workflow above those groups. This allows groups to manage their own internal controls and structures, while still being subject to higher-level institutional controls.

KEW is not a general-purpose application builder. For complex applications, you need to develop applications separately and then integrate them with KEW. For simple forms or documents that need approval, you can use eDocLite, but this only works in simple cases, analogous to a one- or two-page paper form that requires signatures. It is important to note, however, that Kuali Rice does include a framework called the Kuali Nervous System (KNS) that can be used to facilitate the development of more complex applications and includes built-in integration with KEW.

KEW is not a general-purpose business rules engine. For example, it does not know that a continuation account must be specified when an account is closed. Those types of rules are the responsibility of the application itself to manage. However, this is not a clear-cut line, as KEW does manage business rules that directly affect routing and approval.

KEW is not an Organization Hierarchy manager. For example, it will not automatically manage your organizational hierarchies and internal structures. However, integration with these hierarchies and structures can be accomplished using KEW, and leveraging such hierarchies for routing and approval is a very common need for many applications.

Nearly anything, in theory. In the current version of KEW, any application can access KEW if it can:

(The recommended cross-platform integration method is over web services.)

Yes, absolutely!

KEW is an incredibly powerful platform for routing and approval for enterprise (i.e., large) applications. However, it also includes eDocLite, which makes it easy to develop simple business-process forms and run them through KEW. In this situation, in its most simple form, you can do all of your work within KEW, and most of that work is in developing your form configurations. If needed, the eDocLite process can also hook into a post-processor to take an action once a document's approvals are complete.

Kuali Enterprise Workflow provides a common routing and approval engine that facilitates the automation of electronic processes across the enterprise. The workflow product was built by and for higher education, so it is particularly well suited to route mediated transactions across departmental boundaries. Workflow facilitates distribution of processes out into the organizations to eliminate paper processes and shadow feeder systems. In addition to facilitating routing and approval, workflow can also automate process to process related flows. Each process instance is assigned a unique identifier that is global across the organization. Workflow keeps a permanent record of all processes and their participants.

Figure 3.8. Action List Preferences: Document Route Status Colors Section

For example, if you set these colors for these routing status levels:

Your Action List Preferences page looks like this:

Figure 3.9. Action List Preferences: Document Route Status Colors Example

Click the Save button at the bottom of the page to make these changes in your Action List.

Action Lists your color changes by Status:

Figure 3.10. Action List Preferences: Document Route Status Colors Action List Example

Figure 3.11. Action List Preferences: Email Notifications Preferences

The fields used to maintain email preferences are located in a new "Email Notification Preferences" section at the bottom of the Workflow Preferences screen. The "Email Notification Preferences" section accommodates two new options and allows selection of how and when to receive reminder emails on items sent to the Action List.

In this section, one can select whether or not to receive emails as the Primary Delegate, as the Secondary Delegate, and also set the Default Email Notification preference (None, Daily, Weekly, or Immediate). If you are NOT a Primary or Secondary Delegate, you can leave those fields as unchecked.

You can choose to get email reminders on one of these Default Email Notification schedules:

The first new option allows overriding of the 'Default Email Notification' preference and setting of different frequencies to receive notifications based on the document type of the action request (Timesheet, EPTO, Hire Employee eDoc, Create Additional Pay eDoc, Requisition, etc.).

The parameters set for the default email notification and document-type notification work together to determine when a given action item is included in the immediate, daily, or weekly email reminders.

If one sets a 'Default Email Notification' without any 'Document Type Notifications,' then emails are sent (or not sent), based on the default selection.

The second new option allows one to turn notifications on or off based on the request type (Complete, Approve, Acknowledge, or FYI) when "Immediate" is set as the 'Default Email Notification.'

Figure 3.12. Action List Preferences: Document Type Notifications

However, adding a 'Document Type Notification' that is different from the 'Default Email Notification,' forces the document-type notification to take precedence. This allows users to customize by document- type for email reminders. For example:

In addition, when the 'Default Email Notification' is set to "Immediate" one can use the Send Email Notifications For option to decide whether or not to receive notifications by request-type.

All four of the request-types are already "checked" by default in your Workflow Preferences screen.

Figure 3.13. Action List Preferences: Action Requested Email Notification

When an action request is received, and the preference is set to receive an immediate reminder, the system checks to ensure that the request-type checkbox is turned-on (checked) before an email is sent.

This allows these checkboxes to be used as a switch to 'turn-on or turn-off' the "immediate" email reminders for a given request type. For example:

Remember, all of these preferences and settings are on your Action List Preferences page.

As described above, you can use the Action List Preferences page to tell KEW to automatically update (refresh) the information on your Action List on a regular schedule, such as every 15 minutes. You can also click the Refresh button near the top of your Action List page to update the page at any time.

If you have a large Action List, the Filter function can help you by displaying only action requests of certain types. To use the Filter function, click the Filter button in the top right corner of your Action List page:

This displays the Action List Filter page:

Figure 3.14. Action List Filter Page

When you have used a filter on your Action List, you can see a Clear Filter button at the top of your page:

Figure 3.17. Action List: Clear Filter Button

Click this button to display all of your action requests again.

Remember, you can click the Filter button at the top of your Action List page to return to the Filter page and change or Reset your filters.

Action Requests are one of the core functions of the Kuali Enterprise Workflow (KEW) system. An Action Request is a call from KEW to a person or group to take action on a document. Action Requests are created when the system or a person routes (sends) a document to another user and ask that user to do something with the document. You might ask someone to approve an expense, for example, or to acknowledge that he or she received a copy of an expense report.

Once an Action Request has been created in KEW, the associated document is sent to the appropriate users' action lists. A user can open his or her Action List and from there, view information about the document, open the document, and/or take the requested action. If a user takes an action, for example, approves or disapproves a document, that is called an Action Taken.

The path that the document takes from its starting point to final approval is called its route. Each point along that path where a person needs to do something with the document (approve, acknowledge, etc.) is called a node on the route.

Each action request has one row on your Action List. There are five types of Action Requests:

There are other actions that you can take in addition to Action Requests. We will look at those in the Action Taken section below.

Every action request has a recipient. The recipient is the individual or group of individuals whose action is requested on the document. There are three types of recipients:

Roles are groups of users or KIM Groups associated with a document.

The first user in a Group to take action on a request satisfies (completes) that request. Role requests can be set up to work the same way as Group requests or to require that everyone in that Role approves the document before the request is satisfied.

In certain situations, you can use roles for action requests and you can delegate action requests. You can think of these as trees or as a parent action request that has children action requests.

Roles are groups of Principals or Groups that KEW creates based on rules your institution sets up. Since KEW can only create an action request for a single person or group but a role may have several people or groups in it, KEW creates an action request for the role (a parent request), and that action request creates child action requests that go to each person or group in that role.

The parent role request can have any number of children requests that are each either a user request or a group request.

Combining Role Requests and Delegation

You can combine a role request with a delegate. In fact, in the previous example, the action request that is sent to Joe as a fiscal officer is really a role request. The action request tree for that scenario is:

Figure 3.18. Delegation Tree Example

This tree is three levels deep and shows a role delegating to a user. You can also have a role delegate to another role.

Actions are how a user interacts with KEW. Actions can be performed in response to an Action Request (such as an Approve action) or they can be user-initiated (such as the routing of a document). Most, but not all, actions create Action Takens. The Action Taken is recorded on the Route Log and associated with a satisfied action request, where appropriate.

The KEW Action library contains these Actions, explained below:

Superuser Quick Action's Tab

With the release of Rice 2.1 a new option is available for applications to enable. Superuser's can now access documents directly from the standard document search and quickly perform approval, acknowledgment, FYI, or disapproval actions from this new tab on the document. This streamlined version of the still available superuser form of document search will allow for common actions to be taken in a more user friendly fashion. Pending actions are displayed in a list that the super user can check off and take the actions necessary all at once (see example below). Before actions can be taken, a annotation must be provided.

By default, the new tab will not appear on a document.

<kul:superUserActions />

This needs to be included in the JSP of a document for the superuser tab to be shown. The logic for whether it should actually display anything is contained inside of this. Developers may also look at KualiMaintenanceDocument.jsp in the Rice code for an example.

Figure 3.20. New Superuser Tab Example

You can go to the eDocLite Lookup by:

Figure 4.2. eDocLite Lookup

On the eDocLite lookup page, users can search for an eDocLite document based on several criteria:

You can use the above criteria to limit your search results. A search will produce a list of one or more results that look similar to the following:

Figure 4.3. eDocLite Lookup: Search Results

Clicking Create Document on any line takes you to the eDocLite document screen where new documents can be created. The line item you choose will result in that document being used as a template for the new one you are creating. More information on this follows in the section called Create New eDocLite Document.

Clicking any underlined Id will take you to the eDocLite Inquiry screen for that document.

Standard in KEW there is one eDocLite for electronic routing, and new eDocLites can be added based on business requirements. Some of the functions that eDocLites are used for in business include:

The Document Header contains the following fields:

This portion of the document is where the user identifies the routing and complete business function.

This area is used to add annotation and choose action to be taken on this eDocLite document. Annotation is the comments associated with the routing process. You can add them to different nodes of the routing process and take actions on an eDocLite by adding annotations. The annotation appears in the route log of eDocLite as comments. Notes are the comments associated with this specific eDocLite form and appear with the form and not in the route log.

The following is one example of an eDocLite form:

eDocLites are highly customizable. New eDocLites can be designed for new business and functional requirements. The document header and routing annotation and notes parts will be same or similar, the form will be different.

eDocLites can be designed to include following functions:

The Routing Rule Delegation screen you see when creating a new Rule has eight tabs:

The Delegation Details, Delegate Rule, Persons, and Groups tabs are discussed in the sections that follow. The remaining four tabs are commonly used throughout Rice and are described in the Common Features and Functions section of the User Guide.

The Delegation Details tab is where you associate a Parent Rule with a Delegate Rule. It is also where you assign the Reviewer role.

The Delegation Details screen is displayed differently, depending on whether you are creating a new Rule or editing/copying a Rule. The version you see when creating a new Rule looks similar to this:

Figure 6.8. Routing Rule Delegation: Details Section

The information displayed is a copy of the information for the Parent Rule. Descriptions of these fields are below. Change this information as needed, then click the submit button to create this new Rule.

The version you see when editing or copying a Rule looks similar to this:

Figure 6.9. Routing Rules Delegation: Edit/Copy View

When you first see this version, the information in both columns is the same. You can modify the information in the fields in the right column, but not the left column. After changing the information appropriately in the right column, click the submit button to save your changes to this Rule.

The fields are the same in both versions of the screen:

The Delegate Rule tab is displayed differently, depending on whether you are creating a new Rule or editing/copying a Rule. The version you see when creating a new Rule looks similar to this:

Figure 6.10. Routing Rules Delegation: Delegate Rule Tab

Enter the appropriate information for your new Delegate Rule in these fields. There are descriptions of each of these fields below.

The version you see when editing or copying a Rule looks similar to this:

Figure 6.11. Routing Rule Delegation: Delegate Rule Tab, Edit/Copy View

When you first see this version, the information in both columns is the same. You can modify the information in the fields in the right column, but not the left column. After changing the information in the right column appropriately.

The fields are the same in both versions of the screen:

Rice displays the Persons tab differently, depending on whether you are creating a new Rule or editing/copying a Rule. This tab lets you add people to the Rule and set the type of Action each person needs to take under this Rule. The version of the Persons screen that you see when creating a new Delegate Rule looks similar to this:

Figure 6.12. Routing Rules Delegation: Persons Tab

Enter the appropriate information for the Persons section of your new Delegate Rule in these fields. There are descriptions of each of these fields below.

The version you see when editing or copying a Rule looks similar to this:

Figure 6.13. Routing Rules Delegation: Persons tab, Copy/Edit View

Use the top portion of this tab to add a new Person to this Rule and set the Action that Person needs to take and its Priority. Use the lower portion of this tab to change existing values for this Rule.

The Groups tab differently, depending on whether you are creating a new Rule or editing/copying a Rule. The version you see when creating a new Rule looks similar to this:

Figure 6.14. Routing Rules Delegation: Groups Tab

Enter the appropriate information for the Groups section of your new Delegate Rule in these fields. These fields are described below.

The version you see when editing or copying a Rule looks similar to this:

Figure 6.15. Routing Rules Delegation: Groups Tab, Edit/Copy View

Use the top portion of this tab to add a new Group. Use the lower portion to change existing information for a Group.

In the default implementation of Rice you can find the link to the Routing Report on the "Main" tab of the portal inside the "Workflow" pane. If for some reason the link is not visible on the "Main" tab you can still directly navigate to the Routing Report. To access the tool directly, replace the last part of the Rice Portal URL (portal.jsp) with kew/RoutingReport.do (for example, http://my.kuali.host/kuali/portal.jsp would become http://my.kuali.host/kuali/kew/RoutingReport.do). The following page is displayed:

Figure 6.22. Routing Report: Template Selection

The first thing to do is select the rule template to use for the test from the drop-down list. When you select a template the page will update to show the routing data that you need to enter to run the test:

Figure 6.23. Routing Report: Template Selection, Detail

The data entry fields for the routing data use the standard controls described in the Standard Buttons on Lookup Screens document. Here is the example with the routing data:

Figure 6.24. Routing Report: Routing Data Entry

The specific information you need to enter is specific to the rule template you selected. Once you have entered the information, click the button to display the report:

Figure 6.25. Routing Report: Route Log View

The upper section of the report (labeled "ID: 0") contains the basic document information fields as if this was an actual document; several fields are blank since there is no actual document.

The lower section of the report (labeled "Pending Action Requests") contains the routing that the document would be given. Clicking the button on any action displays more detail of the action:

Figure 6.26. Routing Report: Route Log View, Pending Action Requests

The Rule Maintenance Document Type Document screen you see when creating a new rule is composed of seven tabs:

The screen you see when you are editing an existing Rule includes an additional tab called Roles.

The Rule, Persons, Groups and Roles tabs are unique and are discussed in the sections that follow. The remaining four tabs are commonly used throughout Rice and are described in the Common Features and Functions section of the User Guide.

The Rule tab is presented differently depending on whether you are creating a new Rule, or editing/copying a Rule. The version you see when creating a new Rule looks similar to this:

Figure 6.28. Rule Maintenance Document Type Document: Rule Tab

The version you see when editing or copying looks similar to this:

Figure 6.29. Rule Maintenance Document Type Document: Rule Tab, Edit/Copy View

The Persons tab is presented differently depending on whether you are creating a new Rule, or editing/copying a Rule. The version you see when creating a new Rule looks similar to this:

Figure 6.30. Rule Maintenance Document Type Document: Person Tab

The version you see when editing or copying looks similar to this:

Figure 6.31. Rule Maintenance Document Type Document: Person Tab, Edit/Copy View

The Groups tab is presented differently depending on whether you are creating a new Rule, or editing/copying a Rule. The version you see when creating a new Rule looks similar to this:

Figure 6.32. Rule Maintenance Document Type Document: Groups Tab

The version you see when editing or copying looks similar to this:

Figure 6.33. Rule Maintenance Document Type Document: Groups Tab, Edit/Copy View

The top portion of this tab is used to add a new Group while the lower portion is used to change existing values.

Figure 7.2. Document Actions

Several functional buttons are added under the Document Action section:

Figure 7.6. Action Items

It is important to note that the ActionItem is a de-normalized representation of an Action Request on the document that is used to render the Action List in an efficient matter. Therefore, it contains some copies of data from both the document and the request itself.

Figure 7.7. Route Node Instances

The Route Node Instances are modeled as a Directed Acyclic Graph starting at the node instance pointed to by the Initial Route Node Instances field in the Document section. Therefore, if you delete a route node instance, it will follow all links through its set of Next Route Node Instances and delete those as well.

Figure 7.8. Branch States

All documents are required to have at least one branch that is named PRIMARY. Therefore, it is advisable to not rename the PRIMARY branch.

Figure 7.9. Annotation

Here you can enter an annotation explaining the changes being made. This will be logged on the Route Log so that it can be preserved as part of the audit trail for the document.

Once the changes have been made on the document operation screen, hit the Save button and the changes will be executed on the server. Remember that in order for a change to take place the appropriate radio button must be selected on the data that requires modification.

Examples of each are outlined below

Begin to build a Kuali Enterprise Workflow the same as you build any other Java-enabled web application. You build it with all the business logic for the application and, for example, communication to the workflow engine using web services.

As an example, the Travel Request Client Web Application uses Struts, Spring, and OJB.

For the rest of this section, this guide refers to the Java application communicating with the Kuali Enterprise Workflow as the Client Application. The Client Application needs a service that will interact with the workflow system. This service will perform actions such as locating a document in the workflow system and routing the document.

Below are examples from the Travel Request Sample Client. The methods in the TravelDocumentService class find a TravelDocument in the workflow system, save and route a TravelDocument, and validate a TravelDocument.

findByDocHeaderId() - Finds a Document in the workflow engine:

public TravelDocument findByDocHeaderId(Long docHeaderId, String principalId) {
    if (docHeaderId == null) {
        throw new IllegalArgumentException("invalid (null) docHeaderId");
    }
    TravelDocument result = travelDocumentDao.findByDocHeaderId(docHeaderId);
    if (result != null) {
        // convert DocAccountJoins into FinancialAccounts
        ArrayList accounts = new ArrayList();
        for (Iterator joins = result.getDocAccountJoins().iterator(); joins.hasNext();) {
            DocumentAccountJoin join = (DocumentAccountJoin) joins.next();

            FinancialAccount account = financialAccountService.findByAccountNumber(join.getAccountNumber());

            accounts.add(account);
        }
        result.setFinancialAccounts(accounts);
        try {
            WorkflowDocument document = new WorkflowDocument( principalId, result.getDocHeaderId());
        } catch (WorkflowException e) {
            LOG.error("caught WorkflowException: ", e);
            throw new RuntimeException(e);
        }
    }
    return result;
}                

The TravelDocumentServiceImpl class populates the attribute values on the workflow document (Employee, Account) that will be used for future routing. It does this by calling its getEmployeeAttribute() and getAccountAttribute() methods and adding the results to the workflow document by calling the addAttributeDefinition() method.

private WorkflowAttributeDefinitionVO getEmployeeAttribute(TravelDocument travelDocument) {
    WorkflowAttributeDefinitionDTO attrDef = new WorkflowAttributeDefinitionDTO("edu.sampleu.travel.workflow.EmployeeAttribute");
    String principalName = travelDocument.getTravelerUsername();
    attrDef.addConstructorParameter(principalName);
    return attrDef;
}



private List getAccountAttributes(TravelDocument travelDocument) {
    List accounts = travelDocument.getFinancialAccounts();
    List accountAttributes = new ArrayList();
    for (Iterator accountIterator = accounts.iterator(); accountIterator.hasNext();) {
        WorkflowAttributeDefinitionDTO attrDef = new WorkflowAttributeDefinitionDTO("edu.sampleu.travel.workflow.AccountAttribute");
        FinancialAccount account = (FinancialAccount)accountIterator.next();
        attrDef.addConstructorParameter(account.getAccountNumber());
        accountAttributes.add(attrDef);
    }
    return accountAttributes;
}

In the Travel Request Sample Client, the WorkflowDocHandlerAction struts action class calls the workflow lifecycle methods (approve, acknowledge, etc.) on the workflow document.

WorkflowDocHandlerAction - Take approve action. (Each workflow action - acknowledge, complete, etc. - is like this):

public ActionForward approve(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception {
    LOG.info("entering approve() method ...");
    DocHandlerForm docHandlerForm = (DocHandlerForm) form;
    WorkflowDocument document = docHandlerForm.getWorkflowDocument()
 document.approve(docHandlerForm.getAnnotation());
    saveDocumentActionMessage("general.routing.approved", request);
    LOG.info("forwarding to actionTaken from approve()");
    return mapping.findForward("actionTaken");

}

Set up the WorkflowDocument in the initializeBaseFormState() method of the DispatchActionBase from which the Struts action classes inherit. Obtain the workflow document with this line of code:

String principalId = getUserSession(request).getPrincipalId();
WorkflowDocument document = new WorkflowDocument(principalId, docId);

Package the Client Application (client web application) for deployment the way you normally package web applications. The Travel Request Sample Web Application does this with an Ant build script. The dist step of the build.xml script builds the SampleWorkflowClient.war file.

Deploy the plugin to your workflow installation. Copy the plugin directory structure to your application plugins directory. Please see the Workflow Plugin Guide for more information.

Deploy the Client Web Application to your Application server the way you normally deploy web applications.

To effectively use any of the KEW integration modes besides bundled, a Standalone Rice Server will need to be deployed.

Here is a diagram illustrating what a sample embedded deployment might look look.

Figure 9.1. Embedded Deployment Diagram example

Bundled mode is the same as embedded mode except that the client application embeds the entire Kuali Rice system within it (including the web application). The embedding of the web application portion is accomplished by utilizing Struts Modules.

Configuration is the same as embedded mode, with the exception of loading the web application portions in the web.xml:

<filter>
    <filter-name>UserLoginFilter</filter-name>
    <filter-class>org.kuali.rice.krad.web.filter.UserLoginFilter</filter-class>

</filter>


<filter-mapping>
    <filter-name>UserLoginFilter</filter-name>
    <servlet-name>action</servlet-name>
</filter-mapping>



<servlet>
    <servlet-name>action</servlet-name>
    <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
    .. other struts configuration if applicable
    <init-param>
        <param-name>config/en</param-name>
        <param-value>/en/WEB-INF/struts-config.xml</param-value>
    </init-param>
    <load-on-startup>0</load-on-startup>
</servlet>


<servlet>
    <servlet-name>remoting</servlet-name>
    <servlet-class>org.kuali.rice.ksb.messaging.servlet.KSBDispatcherServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>



<servlet>
    <servlet-name>export</servlet-name>
    <servlet-class>org.kuali.rice.kew.export.web.ExportServlet</servlet-class>
</servlet>


<servlet>
    <servlet-name>attachment</servlet-name>
    <servlet-class>org.kuali.rice.kew.notes.web.AttachmentServlet</servlet-class>
</servlet>



<servlet>
    <servlet-name>edoclite</servlet-name>
    <servlet-class>org.kuali.rice.kew.edl.EDLServlet</servlet-class>
</servlet>



<servlet-mapping>
    <servlet-name>remoting</servlet-name>
    <url-pattern>/remoting/*</url-pattern>
</servlet-mapping>


<servlet-mapping>
    <servlet-name>action</servlet-name>
    <url-pattern>*.do</url-pattern>
</servlet-mapping>

<servlet-mapping>


    <servlet-name>export</servlet-name>
    <url-pattern>/export/*</url-pattern>
</servlet-mapping>


<servlet-mapping>
  
    <servlet-name>attachment</servlet-name>
    <url-pattern>/en/attachment/*</url-pattern>
</servlet-mapping>


<servlet-mapping>
    <servlet-name>edoclite</servlet-name>
    <url-pattern>/en/EDocLite</url-pattern>
</servlet-mapping>

org.kuali.rice.krad.web.filter.UserLoginFilter – This filter is used to assist the KEW bundled web application in determining who the authenticated user is. Specifically, the login filter invokes the KIM identity management service to determine the identity of the authenticated user.

Typically, a previously executed filter will challenge the user on entry to a Rice web page for their authentication credentials using CAS or some other form of single sign on (SSO) authentication system.

For development and testing purposes, Rice provides a simple filter implementation that will present a simple sign on screen. This screen displays only a single login entry field and submit button. The user can enter their username (no password) and press the submit button, and the system authenticates the user for entry into the system.

This can be configured as follows in the web.xml:

<filter>
    <filter-name>LoginFilter</filter-name>
    <filter-class>org.kuali.rice.krad.web.filter.UserLoginFilter</filter-class>

</filter>



<filter-mapping>
    <filter-name>LoginFilter</filter-name>
    <servlet-name>action</servlet-name>
</filter-mapping>

and in the rice-config.xml:

<param name="filter.login.class">org.kuali.rice.krad.web.filter.DummyLoginFilter</param>
<param name="filtermapping.login.1">/*</param>

org.apache.struts.action.ActionServlet - The Struts servlet which loads the KEW Struts module. The module name should be 'en'. Struts only allows a single Action Servlet so if you are using Struts in your application, all of your Struts modules will need to be configured using the init-param elements in this servlet definition.

org.kuali.rice.ksb.messaging.servlet.KSBDispatcherServlet - A servlet which dispatches http requests for the Kuali Service Bus (see KSB documentation for more details). The servlet mapping here should correspond to the serviceServletUrl configuration parameter for the KSBConfigurer.

org.kuali.rice.kew.export.web.ExportServlet - serves exports of lookup results as XML files

org.kuali.rice.kew.notes.web.AttachmentServlet - serves attachments that have been attached to documents using the KEW Notes and Attachments framework

org.kuali.rice.kew.edl.EDLServlet - The servlet used to interact with eDocLite documents. See eDocLite documentation for more information.

Here is the Spring configuration for a thin client in ThinClientSpring.xml:

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">

<beans>
    <!-- point Rice to the file containing your configuration params -->
    <!-- which should include a parameter setting kew.mode to "THIN" -->
    <bean id="config" class="org.kuali.rice.core.config.spring.ConfigFactoryBean">
        <property name="configLocations">
            <list>
                <value>classpath: yourThinClientApp-config.xml</value>
            </list>
        </property>
    </bean>
    <!-- Pull your configuration params out as Properties -->
    <bean id="configProperties" 
class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
        <property name="targetObject" ref="config" />
        <property name="targetMethod" value="getProperties" />
    </bean>
    <!-- expose configuration params to Spring -->
    <bean class=
"org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
        <property name="properties" ref="configProperties" />
    </bean>
    <!-- The RiceConfigurer that sets up thin client mode -->
    <bean id="rice" class="org.kuali.rice.kew.config.KEWConfigurer">
        <!-- inject the "config" bean into our configurer -->
        <property name="rootConfig" ref="config" />
    </bean>
</beans>  

For more details on configuring Rice for a thin client, please see the Intro to Rice Guide in the Implementation Details section, the Thin Client Implementation sub-section.

Since KEW and KIM use the KSB to expose their services, the endpoint URLs are the same as those exported by the KSB.

An example configuration for these might be:

<param name=
"workflowdocument.javaservice.endpoint">http://yourlocalip/kr-dev/remoting/WorkflowDocumentActionsService</param>
<param name=
"workflowutility.javaservice.endpoint">http://yourlocalip/kr-dev/remoting/WorkflowUtilityService</param>
<param name=
"identity.javaservice.endpoint">http://yourlocalip/kr-dev/remoting/kimIdentityService</param>
<param name=
"group.javaservice.endpoint">http://yourlocalip/kr-dev/remoting/kimGroupService</param>

Here is a diagram showing what a thin client deployment might look like.

Figure 9.3. Thin client deployment diagram

If embedded.server parameter is enabled (set to true), then two additional features will be loaded when KEW is started:

The XML Loader will poll a directory for XML files to ingest into the system (as configured by the data.xml.* properties).

The Email Reminders will handle sending Daily and Weekly batch emails for users that have their preferences set accordingly.

KEW requires and uses the database platform implementation in order to function. These may be implemented differently for each support database management system.

The current functional implementations of this platform are:

When running a Standalone Rice Server, you may want to implement your own filters for authentication purposes. The system comes with a special filter that will read filter definitions and mappings from the configuration system.

The Bootstrap Filter is a generic filter that is applied to all web requests, which then delegates to any filters and are setup through the default configuration. This mechanism allows registration of institution-specific filters without the necessity of modifying the web application configuration file (/WEB-INF/web.xml) within the standalone webapp.

Filter syntax is as follows:

<param name="filter.filter name.class">class name of filter</param>

filter name is an arbitrary name for your filter:

<param name="filter.myfilter.class">edu.institution.organization.MyFilter</param>

Any number of configuration parameters may be defined for a given filter as follows:

<param name="filter.filter name.filter param name">filter param value</param>

For example:

<param name="filter.myfilter.color">red</param>

<param name="filter.myfilter.shape">square</param>

For custom filters to be invoked, they must first be mapped to requests. That is done via the filter mapping parameter:

<param name="filtermapping.filter name.optional order index">path matching expression</param>

filter name is the name of your previously defined filter, optional order index is an optional integer used to specify the position of the filter in the invocation order, and path matching expression is a Servlet-specification-compatible url pattern.

<param name="filtermapping.myfilter.1">/special/path/</param>

If an order index is not specified, it is assumed to be 0. Filters with equivalent order are ordered arbitrarily with relation to each other (not in order of filter or mapping definition). A full example follows:

<param name="filter.myfilter.class">edu.institution.organization.MyFilter</param>

<param name="filter.myfilter.color">red</param>

<param name="filter.myfilter.shape">square</param>
<param name="filter.securityfilter.class">edu.institution.organization.SecurityFilter</param>

<param name="filter.securityfilter.secretKey">abracadabra</param>

<param name="filter.compressionfilter.class">edu.institution.organization.CompressionFilter</param>
<param name="filter.compressionfilter.compressLevel">5</param>
<param name="filtermapping.securityfilter.1">/secure/</param>

<param name="filtermapping.myfilter.2">/special/path/</param>

<param name="filtermapping.compressionfilter.3">/*</param>

The CustomEmailAttribute interface provides two methods for adding custom content to both the subject and the body.

public String getCustomEmailSubject();

public String getCustomEmailBody();

Note that each of these values is appended to the end of either the subject or the body of the email. The rest of the email still uses the standard email content.

Also, when implementing one of these components, the document is made available to you as a RouteHeaderDTO and the action request related to the notification is made available as an ActionRequestDTO.

Once you have implemented the CustomEmailAttribute, you need to make it available to the KEW engine (either deployed in a plugin or available on the classpath when running embedded KEW).

<data xmlns="ns:workflow" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="ns:workflow resource:WorkflowData">
    <ruleAttributes xmlns="ns:workflow/RuleAttribute" xsi:schemaLocation="ns:workflow/RuleAttribute resource:RuleAttribute">
        <ruleAttribute>
            <name>MyCustomEmailAttribute</name>
            <className>my.package.MyCustomEmailAttribute</className>
            <label>MyCustomEmailAttribute</label>
            <description>My Custom Email Attribute</description>
            <type>EmailAttribute</type>
        </ruleAttribute>
    </ruleAttributes>
</data>

<data xmlns="ns:workflow" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="ns:workflow resource:WorkflowData">
    <documentTypes xmlns="ns:workflow/DocumentType" xsi:schemaLocation="ns:workflow/DocumentType resource:DocumentType">
        <documentType>
            <name>MyDocType</name>
            <label>My Document Type</label>
            <postProcessorName>...</postProcessorName>
            <attributes>
                <attribute>
                    <name>MyCustomEmailAttribute</name>
                </attribute>
            </attributes>
            <routePaths>
                ...
            </routePaths>
            <routeNodes>
                ...
            </routeNodes>
        </documentType>
    </documentTypes>
</data>

Because the operation of parts of KEW is dependent on a set of Document Types and Attributes being available within the system, there is some bootstrap XML that you will want to import. The easiest way to do this is to import the files in the following locations using the XML Ingester:

These files include the following:

Application constants you may want to change:

In the core document types and rules config, you will need to change:

KEW has several components that you can use to configure routing. Typically a single application will write a set of these components for reuse across multiple Document Types. These components are wired together using an XML configuration file that you need to import into KEW. See Importing XML Files to KEW for more information.

This document looks at defining the routing components available in KEW and how to use these components to make a cohesive routing setup.

These components are contained in a Document Type that is defined in XML. A Document Type is the prototype for eDocs. Below is the Document Type configuration that explains how KEW uses the eDoc rule:

<?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">
    <documentTypes XMLns="ns:workflow/DocumentType" xsi:schemaLocation="ns:workflow/DocumentType resource:DocumentType">
        <documentType>
            <name>YOURSERVICE-DOCS.RuleDocument</name>
            <parent>YOURSERVICE-DOCS</parent>
            <description>Add/Modify Workflow rules</description>
            <label>Add/Modify Workflow rules</label>
            <postProcessorName>your.package.routetemplate.RulePostProcessor</postProcessorName>
            <authorizer>your.package.CustomDocumentTypeAuthorizer</authorizer>
            <superUserGroupName>WorkflowAdmin</superUserGroupName>
            <blanketApproveGroupName>IU-WORKFLOW-RULE-BLANKET-APPROVERS</blanketApproveGroupName>
            <defaultExceptionGroupName>YOUR_EXCEPTION_TEAM</defaultExceptionGroupName>
            <docHandler>https://yourlocalIP/en-prd/Rule.do?methodToCall=docHandler</docHandler>
            <notificationFromAddress>...@yourEmailServerIP.edu</notificationFromAddress>
            <active>true</active>
            <routingVersion>1</routingVersion>
            <routePaths>
                <routePath>
                    <start name="Adhoc Routing" nextNode="Rule routing Route Level" />
                    <requests name="Rule routing Route Level" />
                </routePath>
            </routePaths>
            <routeNodes>
                <start name="Adhoc Routing">
                    <activationType>S</activationType>
                    <mandatoryRoute>false</mandatoryRoute>
                    <finalApproval>false</finalApproval>
                </start>
                <requests name="Rule routing Route Level">
                    <activationType>S</activationType>
                    <ruleTemplate>RuleRoutingTemplate</ruleTemplate>
                    <mandatoryRoute>true</mandatoryRoute>
                    <finalApproval>false</finalApproval>
                </requests>
            </routeNodes>
        </documentType>
    </documentTypes>
</data>

Configuration Steps

Let's go through the configuration step-by-step and explain what all the pieces mean:

DocumentTypeName Definition

<name>YOURSERVICE-DOCS.RuleDocument</name>
<parent>YOURSERVICE-DOCS</parent>
<description>Add/Modify Workflow rules</description>
<label>Add/Modify Workflow rules</label>

The section above defines the Document Type's name, its parent, description, and label. The name is used by the client application's API to communicate with KEW. Here is a sample of code from the client application's API communicating with KEW:

WorkflowDocument document = new WorkflowDocument(new NetworkIdVO("username"), "DocumentTypeName");
document.routeDocument("user inputted annotation");

The above code will route a document in KEW.

• The string DocumentTypeName exists in KEW and you define it using the <name> element.

• The parent element gives the Document Type a parent Document Type. Use this for inheritance of routing configuration and policies.

• Description is defined as shown. The document's Description is displayed on the Document Type report.

• Label is typically the forward-facing name for the Document Type. The label is displayed to the user when an eDoc is in their Action List and they use it when they search for an eDoc using DocSearch.

PostProcessor Class

<postProcessorName>your.package.routetemplate.RulePostProcessor</postProcessorName>

The element above determines which class to use for the PostProcessor for this particular Document Type. This component receives event notifications as eDocs travel through routing.

DocumentTypeAuthorizer Class

<authorizer>your.package.CustomDocumentTypeAuthorizer</authorizer>

The element above determines which class to use for the DocumentType Authorizer for this particular Document Type. This component performs authorization checks as the eDoc travels through routing.

Managed Workgroups

<superUserWorkgroupName>WorkflowAdmin</superUserWorkgroupName>
<blanketApproveWorkgroupName>WorkgroupBlanketApprovers</blanketApproveWorkgroupName>

<defaultExceptionWorkgroupName>WorkflowAdmin</defaultExceptionWorkgroupName>

This section sets KEW managed workgroups in several roles in the Document Type.

• SuperUserWorkgroupName defines the workgroup that determines whether a person is allowed to take Super User Actions on a document through the Super User interface.

• The content of element blanketApproveWorkgroupName determines which people have access to blanket approve a document.

• defaultExceptionWorkgroup determines to which workgroup to send an eDoc of this type if it goes into exception routing. This is an optional element. You can also define Exception Workgroups with a route node.

docHandler

<docHandler>https://yourlocalIP/en-prd/Rule.do?methodToCall=docHandler</docHandler>

The docHandler tells KEW where to forward users when they click an eDoc link. See Document Search for more information.

notificationFromAddress

<notificationFromAddress>...@yourEmailServerIP</notificationFromAddress>

When KEW sends an email notification to a user regarding a document of this type, the From address on the message is the address specified here. This is helpful because users will often reply to the messages they receive from KEW, and this allows their responses to go to an appropriate address for the Document Type. This is an optional element. If it is not defined here, KEW uses the default From address. See the Installation Guide for more detail.

active

<active>true</active>

Use active to define the activeness of a Document Type. KEW does not allow anyone to create eDocs of an inactive Document Type.

routePaths

<routePaths>
    <routePath>
        <start name="Adhoc Routing" nextNode="Rule routing Route Level" />
        <requests name="Rule routing Route Level" />
    </routePath>
</routePaths>

The above defines the path an eDoc will travel as it progresses through its life. Start and Requests are some of the standard node types used. There is only one stop each eDoc must make as it travels through workflow. The eDoc starts at the step Adhoc Routing and then progresses to the request node named Rule routing Route Level.

Additionally, an automatic progression of the application document status may be configured to occur on route node transition with the addition of the nextAppDocStatus attribute in the elements of a routePath:

<routePaths>
    <routePath>
        <start name="Initiated" nextNode="DestinationApproval" nextAppDocStatus="Approval in Progress"/>
        <requests name="DestinationApproval" nextNode="TravelerApproval" nextAppDocStatus="Submitted"/>
        <requests name="TravelerApproval" nextNode="SupervisorApproval" />
        <requests name="SupervisorApproval" nextNode="AccountApproval" />
        <requests name="AccountApproval" />
    </routePath>
</routePaths>
                

This section only defines the path the eDocs will travel, and optionally the application document status transitions. The nodes themselves are defined below.

Node Definition XML

<routeNodes>
    <start name="Adhoc Routing">
        <activationType>S</activationType>
        <mandatoryRoute>false</mandatoryRoute>
        <finalApproval>false</finalApproval>
    </start>
    <requests name="Rule routing Route Level">
        <activationType>S</activationType>
        <ruleTemplate>RuleRoutingTemplate</ruleTemplate>
        <mandatoryRoute>true</mandatoryRoute>
        <finalApproval>false</finalApproval>
    </requests>
</routeNodes>

This is the node definition XML. This determines certain behaviors each node can have.

Activation Type determines if Approve requests are activated all at once or one at a time. Any given requests node can generate multiple rules that can then generate multiple requests. The ActivationType value specifies if all action requests generated for all fired rules are activated immediately (P = parallel activation), or if the set of action requests generated by each rule are activated one after the other, according to rule order (S = sequential activation). However, to activate requests starting with those with the smallest priority and to active all those requests in parallel the activation type of (R = priority-parallel activation). Once all requests are approved, then the next priority will be activated. This is essentially a hybrid of the traditional sequential and parallel activation types. Activation type is only relevant when multiple rules are generated.

Figure 9.5. Parallel and Sequential Activation Types

Figure 9.6. Parallel-Priority Activation Type

The mandatoryRoute key determines if it's mandatory to generate approval requests. If a route node is mandatory and it doesn't generate an approve request, the document is put in exception routing.

The finalapproval key determines if this node should be the last node that has an approve request. If approvals are generated after this step, the document is thrown into exception routing.

Finally, there is a request node named Rule routing Route Level with a key called ruleTemplate. This is our hook into the rule system for KEW:

<ruleTemplate>RuleRoutingTemplate</ruleTemplate>

And this is our hook into a route module:

<routeModule>package.your.ARouteModule</routeModule>

KEW contacts the route module when the document enters that route node and the route module returns Action Requests for KEW to deliver.

Rule Attributes

If the application integrating with KEW is using Rules to contain the routing data and RuleAttributes for document evaluation, then the routing configuration requires more XML. Below is an XML snippet that defines RuleAttribute; this is written in Java.

<?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">
    <ruleAttributes XMLns="ns:workflow/RuleAttribute" xsi:schemaLocation="ns:workflow/RuleAttribute resource:RuleAttribute">
        <ruleAttribute>
            <name>RuleRoutingAttribute</name>
            <className>org.kuali.rice.kew.rule.RuleRoutingAttribute</className>
            <label>RuleRoutingAttribute</label>
            <description>RuleRoutingAttribute</description>
            <type>RuleAttribute</type>
        </ruleAttribute>
    </ruleAttributes>
</data>

The above defines a RuleAttribute called RuleRoutingAttribute. RuleRoutingAttribute maps to the Java class org.kuali.rice.kew.rule.RuleRoutingAttribute. The type of this attribute is a RuleAttribute; essentially this means the RuleAttribute's behavior is determined in a Java class. There are also RuleAttributes made entirely from XML, but programming attributes is outside the scope of this Guide.

Rule Templates

Finally, we need to tie the RuleAttribute to the Document Type. This is done using the RuleTemplate and it is defined using XML. The RuleTemplate schema below provides further explanation:

<?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">
    <ruleTemplates XMLns="ns:workflow/RuleTemplate" xsi:schemaLocation="ns:workflow/RuleTemplate resource:RuleTemplate">
        <ruleTemplate>
            <name>RuleRoutingTemplate</name>
            <description>RuleRoutingTemplate</description>
            <attributes>
                <attribute>
                    <name>RuleRoutingAttribute</name>
                    <required>true</required>
                </attribute>
            </attributes>
        </ruleTemplate>
    </ruleTemplates>
</data>

Note

Notice that the name of this RuleTemplate, RuleRoutingTemplate, matches the name given in the ruleTemplate element in the Document Type route node declaration. Also, notice that the RuleAttribute made above is referenced in the RuleTemplate above in the attributes section.

<attributes>
    <attribute>
        <name>RuleRoutingAttribute</name>
        <required>true</required>
    </attribute>
</attributes>

The RuleTemplate is the join between RuleAttributes and Document Types. In this way, we can reuse the same attribute declaration (and therefore Java logic) across Document Types.

Once the XML, condensed into a single file, is uploaded into KEW, eDocs of this type can be created and routed from a client application.

All the content in the code examples above is aggregated into a single file below with a single surrounding data tag:

<?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">
    <ruleAttributes xmlns="ns:workflow/RuleAttribute" xsi:schemaLocation="ns:workflow/RuleAttribute resource:RuleAttribute">
        <ruleAttribute>
            <name>RuleRoutingAttribute</name>
            <className>org.kuali.rice.kew.rule.RuleRoutingAttribute</className>
            <label>foo</label>
            <description>foo</description>
            <type>RuleAttribute</type>
        </ruleAttribute>
    </ruleAttributes>
    <ruleTemplates xmlns="ns:workflow/RuleTemplate" xsi:schemaLocation="ns:workflow/RuleTemplate resource:RuleTemplate">
        <ruleTemplate>
            <name>RuleRoutingTemplate</name>
            <description>RuleRoutingTemplate</description>
            <attributes>
                <attribute>
                    <name>RuleRoutingAttribute</name>
                    <required>true</required>
                </attribute>
            </attributes>
        </ruleTemplate>
    </ruleTemplates>
    <documentTypes xmlns="ns:workflow/DocumentType" xsi:schemaLocation="ns:workflow/DocumentType resource:DocumentType">
        <documentType>
            <name>EDENSERVICE-DOCS.RuleDocument</name>
            <parent>EDENSERVICE-DOCS</parent>
            <description>Add/Modify Workflow rules</description>
            <label>Add/Modify Workflow rules</label>
            <postProcessorName>org.kuali.rice.kew.postprocessor.RulePostProcessor</postProcessorName>
            <superUserGroupName namespace=KR-WKFLW">WorkflowAdmin</superUserGroupName>
            <blanketApproveGroupName namespace=KR-WKFLW">WorkflowAdmin</blanketApproveGroupName>
            <defaultExceptionGroupName></defaultExceptionGroupName>
            <docHandler>https://yourlocalIP/en-prd/Rule.do?methodToCall=docHandler</docHandler>
            <active>true</active>
            <routingVersion>1</routingVersion>
            <routePaths>
                <routePath>
                    <start name="Adhoc Routing" nextNode="Rule routing Route Level" />
                    <requests name="Rule routing Route Level" />
                </routePath>
            </routePaths>
            <routeNodes>
                <start name="Adhoc Routing">
                    <activationType>S</activationType>
                    <mandatoryRoute>false</mandatoryRoute>
                </start>
                <requests name="Workflow Document Routing">
                    <activationType>S</activationType>
                    <ruleTemplate>RuleRoutingTemplate</ruleTemplate>
                    <mandatoryRoute>true</mandatoryRoute>
                </requests>
            </routeNodes>
        </documentType>
    </documentTypes>
</data>

<NetworkIdRoleAttribute>
    <myNetworkId>dev1</myNetworkId>
    <myNetworkId>dev2</myNetworkId>
    <myNetworkId>dev3</myNetworkId>
    ...
</NetworkIdRoleAttribute>

In addition to routing workflow based on users and workgroups using routing rules, you can also route workflow based on KIM responsibilities. This allows you to utilize group membership and role assignments to manage who is permitted to perform approvals.

<requests name="Rule routing Route Level">
    <activationType>S</activationType>
    <ruleTemplate>RuleRoutingTemplate</ruleTemplate>
    <mandatoryRoute>true</mandatoryRoute>
    <finalApproval>false</finalApproval>
</requests>

<role name="Purchasing">
    <qualifierResolverClass>
org.kuali.rice.kns.workflow.attribute.DataDictionaryQualifierResolver
</qualifierResolverClass>
    <activationType>P</activationType>
</role>           

To upload XML, go to Ingester UI and select the XML file that you want to import:

Figure 10.1. Ingester

After upload, notice the red arrow and the statement, Ingested xml doc: <name of file>:

Figure 10.2. Ingestion Complete

The main Message Queue screen:

Figure 10.3. Message Queue Screen

Examining this sample screen, we see there are 20 entries in the message queue, one on each row. The columns display information about each entry:

Once a message entry has been successfully processed, it is deleted from the queue.

Sometimes it is necessary to manually edit a route queue entry that is halted inside of the queue. This situation might happen when:

In all cases, the status of the entry is ROUTING, but there is no longer a worker thread processing the entry. Currently, KEW doesn't implement any auto-detection of failure cases. To put one of these entries in a state where it can be picked up by the route manager again, simply click the Edit link and set the entry's status back to QUEUED. Here's a screen shot of the Route Queue Entry - Edit screen:

Figure 10.4. Route Queue Entry Edit Screen

Use the Queue Status dropdown list to change the status of the entry. You may also want to set the Retry Count to zero to allow you to diagnose the problem before the document goes into exception routing.