Overview

The default build mode of KFS embeds a full implementation of the Rice server into the KFS application. While this is useful for development and local testing, it is probably not the mode you will want to run in if you plan on deploying multiple Rice-based applications at your institution.

In Standalone Rice mode, the Rice server components are not deployed with KFS and KFS is configured to access certain Rice services by accessing them using both a "server" database connection and as remote web services on the KSB.

To set up a standalone Rice project for development, you are going to need to set up Rice as a standalone project. The Rice project has documentation on how to do that. Since Rice runs via Maven, it will build a war for you that you can place into your Tomcat instance, but you'll still need to configure the Rice environment separately.

In the kfs project's src/main/config directory, you will find a file kfs-rice-skel-config.properties; this file gives a list of the properties you will want to override in KFS when you set up a standalone Rice server. You can override a copy of that file with the properties for your own standalone server, and then when starting your web server, add -Dadditional.kfs.config.locations={path to your kfs rice configuration} to the command line arguments.

Separated Database Setup

You will also want to configure your project so that it uses separate database instances for KFS and Rice. Thankfully, this is easy; see the LiquiRelational section of Database+Coding+Standards

Proper Care and Feeding of Rice

Teams charged with maintaining instances of Rice along with KFS should be aware of some special Rice tips.

Document Operations

The Document Operations screen is simply a convenient interface to carry out CRUD operations on the KEW data model. It should only be used in cases where document routing has become intractable, and then only by experienced personnel who understand the data model underlying Kuali Workflow. Changes to Document Operations do specifically and narrowly what has been done on the screen. For instance, cancelling a document via Document Operations merely sets the status on the KREW_DOC_HDR_T record for the document to "X". It does not clear action requests or action items - that has to be done separately on the Document Operations screen. Also, the post-processor is not run on the document; any logic to be run when the document goes to cancelled will not be called in the least.

These concerns become even more important with the release of KFS 5.3. Starting with that version, KFS tracks KEW document header information in the KFS database, which makes document searches more efficient. However, that mechanism relies on the post-processor. If the post-processor is not run, then KFS's version of the document header could go out of sync with the KEW version of the document header which could lead to multiple problems.

In 99.99% of cases, users who need to push a document through workflow likely want to use superuser operations to act on that document. All superuser approves, disapproves, cancels, etc., call the post-process and clean up the data model appropriately. All of the KEW document header tracked by KFS is also saved correctly. So, if a document needs to be acted on by system administrators, superuser operations - available upon the document itself - are likely the best way to accomplish this work.

The Document Operations screen is useful for reindexing search fields on documents.