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 3.1. Sample KEW embedded deployment

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.kew.web.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.kew.web.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.kew.web.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.kew.web.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 -->
    <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.ThinClientKEWConfigurer">
        <!-- inject the "config" bean into our configurer -->
        <property name="rootConfig" ref="config" />
    </bean>
</beans>  

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

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: