Skip to end of metadata
Go to start of metadata


One of our items for the 0.9.4 release of Rice is to refactor KEW so that it makes proper use of the KNS. This is being done in order to eliminate redundancy and ensure that all of Rice is using a consistent set of services.

There are many different tasks that this will encompase. Some of these tasks can be implemented independent of each other and some are of higher priority then others.

The main JIRA issue for tracking progress on these items is KULRICE-1457

Converting KEW to use the KNS

  1. Refactor KNS and KEW to remove inter-module dependencies
  2. Get rid of duplicate Lookup implementation
  3. Rewrite all exsiting KEW lookups
  4. Rewrite the Rule document so that it uses the KNS document framework
  5. Rewrite the Remove/Replace user document so that it uses the KNS framework
  6. Rewrite Document Search so that it uses the Lookup framework
  7. Get rid of and/or consolidate duplicate Notes/Attachments framework
  8. Get rid of and/or consolidate Application Constants in favor of System Parameters
  9. Migrate to KNS Help framework for field-level help
  10. Refactor/Replace KEW portal
  11. Determine if there is anything which needs to be done with KEW non-document screens (see below)

Other screens that need to be updated. What pieces of the KNS framework can be used for these?

  1. Action List
  2. Route Log
  3. Rule Quicklinks
  4. Other Admin screens
  5. Workflow Quicklinks
  6. Routing Report
  7. Application Constants
  8. XML Ingester
  9. Rule Attribute
  10. Rule Template
  11. Statistics Report
  12. Document Operation
  13. Preferences

KFS Priorities regarding above work

  1. Get rid of duplicate Lookup implementation (and WorkflowLookupableImpl shim)
  2. Rewrite all existing KEW lookups (we care about the ones that are used frequently - not sure there are any that aren't though?)
  3. Rewrite the Rule document so that it uses the KNS document framework (I'm assuming this will involve improving integration from a user and implementing dev perspective)
  4. Rewrite Document Search so that it uses the Lookup framework (I'm assuming this will involve improving integration from a user and implementing dev perspective)

Refactor KNS and KEW to remove inter-module dependencies

The content here was no longer relevant so it has been archived here.


KEW has it's own lookup implementation which pre-dates the implementation in the KNS. This majority of this implementation is contained in the org.kuali.rice.kew.lookupable package.

Lookupable Implementations

There are a series of lookupable implementations inside of the KEW module:

  1. DocumentTypeLookupableImpl
  2. EDocLiteLookupable
  3. RoleLookupableImpl
  4. RuleAttributeLookupableImpl
  5. RuleBaseValuesLookupableImpl
  6. RuleTemplateLookupableImpl
  7. UserLookupableImpl
  8. WorkflowLookupableImpl
  9. WorkGroupLookupableImpl
  10. WorkgroupTypeLookupable

UserLookupableImpl, WorkGroupLookupableImpl and WorkgroupTypeLookupable


These lookups are going to be replaced by corresponding in KIM so they will not need to be converted.



This class is actually in the KNS but it implements the Lookupable interface from KEW. WorkflowLookupableImpl is used as an adapter to be able to use KNS lookupables from KEW. We should be able to get rid of this class once we are using the same KNS framework. However, we can't completely get rid of this without doing some other work first.

Currently, when specifying a lookup, you specify the lookup name. However, we need to also add support for the ability to specify the URL of a lookup. This will allow us to use KFS/KC, etc. lookups from inside of the Rule GUI.

The other option is to leave WorkflowLookupableImpl and convert it so that it just passes directly through to the desired KNS lookup. I would prefer to implement the solution which allows us to get rid of the WorkflowLookupableImpl hack.

DocumentTypeLookupableImpl, RuleAttributeLookupableImpl, RuleTemplateLookupableImpl


We don't have a maintenance screens for any of these but I think (hope) we can still create an inquiry and lookup for Document Type. We will have to set up a data dictionary file for this and create any additional changes to the data model which are required.



There's really no corresponding "business object" representing what needs to be looked up on the eDoc Lite lookup (EDocLiteAssociation is essentially it). As with document type we need to create data dictionary files for this lookup. It wouldn't hurt to create an inquiry as well even though we don't currently have one. One potential issue, is it possible to add a "Create Document" link to a KNS lookup?

RuleBaseValuesLookupableImpl, RoleLookupableImpl


For this particular lookup we should convert it as part of creating the new Rule document. The reason is because it takes advantage of Rule attributes to handle changing what fields are rendered on the search based on the value of the rule template selected. We need to also figure out if it's possible to dynamically update the criteria fields on a rule lookup based on Rule template.

There is also the concept of an OddSearchAttribute which allows for customization of the rule lookup based on attributes attached to the RuleTemplate. We might just be able to keep this concept in place by re-implementing it behind the new Rule lookup implementation (although I would certainly love to rename the attribute!)

Document Search as a Lookup

See notes below.

Features potentially lacking in KNS lookup framework

There may be some features that we take advantage of in KEW which are not supported by the KNS lookups. In these cases we may need to enhancement the lookup framework accordingly. The list below is speculative at this point in time as I haven't confirmed or denied the ability of KNS lookups to handle this:

  1. XML export KULRICE-2241
  2. Custom links in the "Actions" column
  3. Dynamically add criteria to form based on value of other criteria (see Rule lookup)
  4. Dynamically add columns to form based on search values (see Rule lookup)
  5. Various things which may be required to implement document search as a lookup (see Document Search as Lookup section above)

Removal of KEW Lookup Framework


We will want to keep the existing KEW lookup framework around until we complete the conversion of our current lookupables.

In addition, there are various places throughout the code base where we reference the Field, Column and Row objects which are part of the KEW lookup framework. There are corresponding classes in KNS so hopefully it will just be a matter of using these instead.

There are some differences between the KEW and KNS versions of these types but ideally that will get worked out during the conversion of the KEW lookups. If not then that will need to be reconciled as well.

Some places in the code outside of the lookup framework where we reference KEW lookup objects are:

  1. Various document search related classes KULRICE-2245
  2. DTOConverter KULRICE-2244
  3. WorkflowAttribute and it's subclasses KULRICE-2243
  4. RuleBaseValues KULRICE-2246
  5. ExtensionAttribute KULRICE-2247

Implementation Proposal

A good portion of the lookup work can be done in parallel however some of it is dependent upon work being done in KIM. In general, tasks could proceed as follows:

  1. Implement support for missing features in KNS lookups (XML export, etc.)
  2. Convert all existing lookups except identity related ones and rule lookup
  3. Implement Document Search as a lookup (see below)
  4. Implement new Rule document and lookup (see below)
  5. Develop appropriate adapters/features for using any KNS lookup from rules, doc search, etc. (remove the WorkflowLookupaleImpl adapter class)
  6. Wait for KIM work to be completed and for KEW to be retrofitted with KIM
  7. Remove old KEW identity lookups and lookup framework and write conversion documentation

Rewrite the Rule document so that it uses the KNS document framework


This will be one of the biggest pieces of work involved in this process since the current implementation of the Rule GUI is complex. Hopefully, the usage of the KNS will make this much easier to implement.

As part of this, while we are working on the code I think it makes sense to consider the following improvements to the Rule GUI and architecture:

  1. Split the current document into 2 "maintenance" documents:
    1. Rule
    2. Delegation Rule
  2. As part of the above, remove the direct link between a rule and it's list of delegations in the OJB mapping. This causes all kinds of issues when attempting to lock the records. Specifically, when making a change to a delegation, it locks the parent rule at the moment because it has to create a new version of it. This also results in a lock on all other delegations of that rule!
  3. Remove the ability to add more than one rule to a single document. This feature is inconsistent with the behavior of other KNS documents.
  4. Default start and end date to NULL values instead of today's date and a date in 2100. Current implementation is weird.

There are a few potential issues/questions to consider when working on this:

  1. Should this be a maintenance document or a transactional document? My gut tells me this is going to be too complex to implement as a maintenance document but further investigation is warranted.
  2. If we try to implement as a maintenance document, is it possible to get the "custom attribute" behavior required by rules (i.e. the extra fields that show up based on attributes on a rule template)?
  3. Currently we store every version of a rule and link them to the Route Log of the document. Will it be possible for us to provide that behavior with the KNS? Based on my understanding, we might need to change our data model to use a 2 table model rather than a single table with a "current indicator". Of course, we will need to include conversion scripts based on whatever data model changes occur as a result of this.
  4. How can we deal with the 2 screens required by the Rule document in the KNS? For example, there is a screen at the beggining where you enter Document Type and rule template (this is oftentimes bypassed by using the rule quicklinks). Is it possible to have multi-screen documents in the KNS?
  5. There is currently a hacked-in feature which allows for the use of an application constant to specify different rule document types based on rule template/document type being used. This allows for customization of Rule routing processes based on the type of rule. We need to consider how to implement this in the KNS (likely leveraging the work done to support workgroup routing based on workgroup type).

Rewrite Document Search so that it uses the Lookup framework


We should rewrite the Document Search screen so that it is implemented as a lookup. We can still keep the structures for searchable attributes in place but the code may need to be refactored and cleaned up a bit as it is currently quite a mess. Also, document search supports 2 columns on the "detailed" search. We need to determine if this is still a requirement or not. Here is a list of potential issues we might run into when attempting to make Document Search a lookup:

  1. Search history in title bar
  2. Detailed vs. Basic search
  3. Multiple columns on search criteria
  4. Customization of criteria based on Document Type selected
  5. Document search supports query-based parameters to hide criteria
  6. Document search supports query-based parameters for filling in data and auto-submitting search
  7. Support for range-based searching using 2 input fields
  8. Calender widget (not sure if KNS has this or not)
  9. Document search supports execution via an API

Rewrite the Remove/Replace user document so that it uses the KNS framework


Since the workgroup pieces of KEW are being replaced by KIM this once is not necessarily straightforward.

I think that the best way to accomplish the conversion of this document is to leave the current functionality as-is and just have the new implementation use the KIM APIs for querying and updating groups. It will also need to be re-written to use the KNS and will have to be updated to reflect any API changes for rules as a result of the KNS refactoring of that portion of the application.

Get rid of and/or consolidate duplicate Notes/Attachments framework


This is a lower priority item and we may want to wait until 0.9.5 for this. There are a few issues to tackle here:

  1. We have a screen in KEW which can be included as an IFRAME by client applications to add notes functionality.
  2. Notes/attachments are currently used heavily in eDoc Lite.
  3. Note permissions are modeled using a CustomNoteAttribute so we need to consider how we will preserve the functionality provided here.

Get rid of and/or consolidate Application Constants in favor of System Parameters


Ideally we could just wholesale replace our Application Constants with system parameters. There are, however, some potential issues to consider:

  1. Are System Parameters cached? I would assume so. If they are cached is the cache cluster-aware?
  2. In an embedded client, we essentially inherit the values of the application constants from the server. In the KNS model, each client application has it's own copy of system parameters. We need to figure out how best to reconcile this.

Migrate to KNS Help framework for field-level help


I need to do more research into how the KNS help framework works in order to figure out the best way to proceed here. From the KEW Document Search and other screens we link to the KEW help system so we will likely need to reconcile this as part of 0.9.4 if we want to preserve the help functionality.

Refactor/Replace KEW portal

In general, we should create a Rice portal which has the same look and feel as the KFS and KC portals do. Part of this will be to extract what we can of the portal tag libraries/etc. into Rice.

Determine if there is anything which needs to be done with KEW non-document screens

There are many other screens in KEW which will need to be updated to at least use the KNS CSS and tag libraries where appropriate.

Some of these we may be able to leverage other pieces of KNS as well.

Action List


There is the potential that the Action List could be written as a specialized lookup. We need to do some more detailed analysis to determine whether or not this is possible. There are some know issues which would have to be addressed if we were to attempt this:

  • Action List does not contain any sort of search criteria
  • Action List implements customized sorting and paging functionality.
  • Action List provides customization via a CustomActionListAttribute for:
    1. A hidden IFRAME per row for displaying summary info
    2. The ability to take actions directly from the Action List
  • Action List contains a drop-down allowing for specification of delegate action list to view
  • Action List provides customizable columns and row-coloring based on user preferences
  • Action List provides an outbox feature which is essentially another lookup
  • Action List provides filtering mechanisms for tailoring the output of the action list for a particular session



Preferences are linked to directly from the Action List. This is really a maintenance screen for user preferences but it doesn't really look like other maintenance documents (nor does it require routing). To that end, probably the best approach for this screen would be to update the header and CSS.

Route Log


The Route Log is essentially an inquiry on a document but the view is much different than one might see for a standard inquiry.

If the inquiry framework supports this level of customization we will use it. Otherwise, we should update the Route Log jsp to use the KNS CSS and be consistent in the tabbed look and feel.


The Rule Quicklinks is almost like a generated portal providing ease of access into the rule system. There is not really an analogous concept in the KNS from what I can see. As with Route Log it will need to be updated to use the KNS CSS.

Other Screens

There are other screens in KEW which will need to be updated to use the KNS CSS. I would consider these lower priority but I believe it would be advantageous to be able to completely get rid of the KEW copies of the CSS.

Other screens include:

  1. Document Operation KULRICE-2257
  2. XML Ingester KULRICE-2258
  3. Workflow Statistics Report KULRICE-2259
  4. Routing Report KULRICE-2260
  5. Workflow Quicklinks KULRICE-2261
  • No labels