Skip to end of metadata
Go to start of metadata


This document is incomplete


This document does not yet contain full details on all of the service and framework refactoring that was done in the KEW module for Rice 2.0.


Proposed KEW Service Breakdown

Gliffy Zoom Zoom kew-2.0-service-architecture

Client-Server Architecture

Gliffy Zoom Zoom kew-2.0-embedded-client

Service Refactorings

WorkflowDocument, WorkflowInfo, WorkflowDocumentActions, WorkflowUtility, and SimpleWorkflowDocumentActions



More information to come on this, for now see the information below...


Javadoc Link:
WSDL: WorkflowDocumentActionsService.wsdl

The javadoc-ing of the service apis is not yet complete, but there is quite a bit there for the WorkflowDocumentActionsService. The main classes of interest to look at in the javadoc are:

  • WorkflowDocumentActionsService - the main service which implements the various actions that can be performed against a workflow document, this constitutes a lot of the features that were in both the original workflow document actions api as well as the "simple" version of that api.
    • the main feature this service doesn't provide that the original simple service provided is the ability to update and get information back about notes, use NoteService instead.
  • WorkflowDocumentService - defines additional service methods that aren't related to actions
  • WorkflowDocument and WorkflowDocumentFactory - this api replaces the old "stateful" WorkflowDocument api. There aren't any javadocs on this yet, but it mostly just delegates down to the workflow document actions and workflow document services.

Workflow attribute services


Relevant Jiras: KULRICE-5224

RuleValidationAttribute s have historically been used to validate the configuration of a Rule upon save. The RuleValidationAttribute is a simple interface which defines a single validate method. Saving a rule invokes the RuleServiceImpl which in turn obtains the RuleValidationAttribute from the RuleTemplateAttribute class. As with other workflow attributes registered on the document type, they have been loaded via the "object remoting" feature of the KSB which is being removed.

The object remoting lookup has been replaced with a pair of RuleValidationAttribute-specific services which manage resolution and publishing of client RuleValidationAttribute implementation classes. The RuleValidationAttributeResolver is the embedded client-facing service which performs a lookup on the bus of the a RuleValidationAttributeExporterService under the applicable (to the document/attribute) app id. The RuleValidationAttributeExporterService is the framework service which performs the RuleValidationAttribute implementation instantiation on the client (source), and forwards any calls through its facade to the custom implementation. This is done with the help of the ExtensionRepositoryService.

Rice PESC Alignment

Relevant Jiras: KULRICE-5360

KULRICE-5360 Rice PESC Alignment worksheet

Document Search

Relevant Jiras: KULRICE-5056

Document Search has long been a fairly complicated piece of KEW code. It is further complicated by the fact that it has many "pluggable" pieces that weren't all designed well for use in a remote environment. As it stands in Rice 1.0.x, the following pluggable document search components exist:

  1. SearchableAttribute
  2. DocumentSearchResultProcessor
  3. DocumentSearchCriteriaProcessor
  4. DocumentSearchGenerator
  5. SecurityAttribute

The specific functions and roles of each of these will be described in the following sections.


The SearchableAttribute is responsible for the following:

  • Handles generation of XML content for searchable attributes
  • Handles extracting search attribute values for indexing
  • Provides the "rows" to display on document search for the custom search fields
  • provides hooks for validating the data coming from custom search fields

There are a few issues with the current implementation:

  • The getSearchingRows method returns a List of KNS Row objects.
    • These are not easily remotable across a SOAP service interface
  • The validation method returns a list of WorkflowAttributeValidationError, this includes a key, message and a MessageMap
    • need to determine what the requirement is for including a MessageMap, is this really necessary?
    • need to create a properly JAXB-annotated remotable form of the validation error
    • consider moving the validation error up to the core so it can be used across multiple modules
  • There is a mixture of methods that just do backend stuff (like indexing of data) as well as UI stuff (like search rows)
    • consider splitting these up


  • While it may be preferrable architecturally to split up SearchableAttribute, this component is fairly heavily used and implemented in existing systems. So in favor of making a change that will cause more turmoil then necessary, we will keep SearchableAttribute as a single interface.
  • Rename getSearchingRows to getAttributeFields and have it use the new org.kuali.rice.core.api.uif.RemotableAttributeField api
    • Code that processes the return of these will need to take this remotable attribute fields and convert them to the appropriate KNS row/field objects
  • SearchableAttribute itself should no longer implement the Serializable interface as this is unnecessary
  • Need to create a special bean for publishing SearchableAttributes
    • will need a solution like this for all such "plug-point" services
  • Will need to add ability to KREW_RULE_ATTR_T to store a service name instead of a classname
    • Need to modify any reference data in the db to this effect
  • Need to document that implementations of SearchableAttribute should be thread-safe and stateless
    • Ensure that appropriate parameters are being passed in, need more then just DocumentSearchContext?
  • Modify existing subclass implementations to adhere to the above
  • validateUserInputs needs to take a Map<String, String>
  • move WorkflowValidationError up to the core?


    • one challenge here we need to deal with is the fact that it returns a list of KNS Row objects, need to determine how best to remote these
    • we need to do this for WorkflowAttribute as well
    • returns WorkflowAttributeValidationErrors as part of this, may be advantageous to promote this as a concept up to krad/kns or the core
  1. DocumentSearchResultProcessor
    • need to review the need for isProcessFinalResults, probably has to do with not executing remote calls when unnecessary?
    • needs to not throw SQLException
    • DocSearchDTO and DocSearchCriteriaDTO need to be reviewed and converted to immutable model objects as needed
  2. DocumentSearchCriteriaProcessor
    • Review this api and figure out how to make it SOAP remotable
    • what are the search managers used for?
  3. DocumentSearchGenerator
    • need to figure out which is of these operations needs to actually be remotable, some of them use java.sql.ResultSet!
    • may need to split this out into a service that isn't remotable and one that is.
  4. SecurityAttribute
    • this probably needs to pass only the principal id and not the entire person
    • this really should only be executed once per applicatable document type from the document search, right now it executes way too many times since it does so once per row in the document search result(warning)

... TODO

Proposed Refactoring of Document Search plug-points


Document Search Framework Architecture

Gliffy Zoom Zoom doc-search-framework-architecture

Migration and Upgrade Guide



  • No labels