Skip to end of metadata
Go to start of metadata

Overview

The RiceApplicationConfigurationService is a service that is published by every KNS client application. It contains various callbacks that the rice standalone server can use to get KNS-related information from a client application. In Rice 1.0.x it defines a few different operations as defined here:

They basically allow for:

  1. The ability to get the base help/inquiry/lookup url for a given business object
  2. The ability to get the KNS AttributeDefinition for a given business object attribute
  3. The ability to get the value of a configuration parameter from a client application's configuration context
  4. The ability to determine if the client application is responsible for a given package or business object
  5. The ability to get "non-database" component names (typically derived from the client application's data dictionary) for use in the system parameter UI screens

Current State of this Service

Performance Issues

There has in the past been some pretty major performances issues rooted in the approach this service takes. One of the biggest problems is that, the way it's implemented, the Rice Standalone Server ends up needing to scan every KNS-enabled application on the service bus to determine if it's responsible for a certain business object when doing things like getting the base urls, getting attribute definitions, etc.

It pulls these lazily (on-demand) and a big problem with this is that there is no guarantee that the application it needs the information from is even online the first time it needs to pull this information (this is of particular problem with the configuration parameter service operation which is used for filling in variable values on doc handler urls).

Analysis

I did some analysis on this class in light of work done up to this point in Rice 2.0 and discovered the following:

  1. In Rice 2.0 the concept of "components" is no longer part of the KNS and is instead part of the Rice core. So the concept of pulling application-specific or "non-database" components from client applications needs to move into the core anyway and out of the KNS (obviously with a provider of such information which sources it from the data dictionary).
  2. I'm not sure that we need methods like getBusinessObjectAttributeDefinition, getBaseLookupUrl, etc. on this service any longer with the changes that were made to how KIM attribute definitions and integration is handled (I believe things like lookup urls should be getting assembled by the type service producing the RemotableAttributeField objects before sending them back to Rice for rendering, eliminating the need for a callback). Right now these callbacks are getting invoked for every business object for lookup and inquiry urls inside of KualiAction.java. I was trying to determine why that's the case. The only other reason I could think that this is taking this heavy-handed approach was for ExternalizableBusinessObjects's (so that inquiries and lookups into ebo's are rendered using the proper urls) but then i realized that the EBO abstraction in the ModuleService allows for specifying inquiry and lookup urls for EBO's so it should be able to be handled here without the need for the callback to RiceApplicationConfigurationService.
  3. The getConfigurationParameter method on the service is convenient for use on doc handler urls (so that applications like kfs can define doc handler urls like ${application.url}/maintenance.do and have that call back into kfs to get it's value for application.url). However, in practice it's problematic because there is no guarantee that KFS will be online when resolution of this value happens and, if it's not, that can really slow down things like document search when it attempts to resolve these values by making callbacks into KFS in this manner and has to wait for responses from the potentially unresponsive KFS server (in cases where it's been taking offline for batch processing which is a typical situation with finance systems as I hear). It seems like things would be simplified if we just allow a system parameter to be defined with the name of "application.url" which can then use the application id/namespace of the system parameter to determine if it's the application id for KFS (or whatever the application in question is based on the application id of the document type being processed). This prevents us from having to deal with special callbacks for dealing with these kinds of situations and doc handler urls can be resolved quickly and easily entirely within the context of the rice standalone server. The doc handler variable resolution already supports using system parameters in such a fashion in order to "fill-in" the values for variables, so there isn't really anything that needs to be done to enable this.

Recommendations

General Approach

The basic recommendation here is that we eliminate the RiceApplicationConfigurationService and related RiceApplicationConfigurationMediationService in Rice 2.0. We can accomplish this by doing the following.

  1. Move the getNonDatabaseComponents portion out of this service and refactor it into a pull model that's part of the core where we can extract and "publish" components names from the KNS/KRAD data dictionary to the rice core component services and those which depend on it (primarily the system parameter services that are now part of the rice core).
  2. We remove the getBaseHelpUrl, getBaseInquiryUrl, getBaseLookupUrl, getBusinessObjectAttributeDefinition, isResponsibleForPackage, and supportsBusinessObjectClass methods from this service because of the reasons mentioned earlier. In summary, this is because in the case of EBO's we can get these values from the EBO framework. In the case of KIM and document search, these are coming through the new RemotableAttributeField framework that is part of the Rice core and integrates with both KRAD and KNS.
  3. We remove the getConfigurationParameter method from this service and replace it with the use of properly configured system parameters to allow for variable replacement in document handler urls.

The above would effectively mean that there would be no RiceApplicationConfigurationService in Rice 2.0.

Client Application Impact

The impact here will be as follows:

  1. A client application which is utilizing docHandlerUrl variable replacement via ApplicationConfigurationService.getConfigurationParameter will need to create a system parameter instead. Using the example of a docHandlerUrl containing ${application.url} on a document type with an application id of "KFS", a system parameter would need to be created as follows:
    • With a namespace code of "KR-WKFLW"
    • With a component code of "All"
    • With an application id of "KFS"
    • With a name of "application.url"
    • With a value that is equal to the appropriate value for the application url
  2. A client application which is using StandardGenericXmlSearchableAttribute using a businessObjectClass in that definition (in order to render a lookup on a doc search field) will need to ensure to set the applicationId of the entry in KREW_RULE_ATTR_T which points to their attribute such that it is the application id of their application. This tells KEW that it needs to execute the xml-based attribute code inside of the client application (where it can successfully resolve lookup url)
  3. Derived components will still be calculated the same way but will be pushed to the rice server from the client application on startup and persisted into a database. Specific can be found below.
  4. KualiAction will no longer always fall back to resolving lookup and inquiry urls remotely if it can't find a business object. Client applications need to be sure that their ModuleServices are returning proper inquiry and lookup url values for their ExternalizableBusinessObjects.

Achitecture of recommended parameter component "push" model

For this information, see the "Loading Application-Specific Components" section in this document: Rice 2.0 - Compatibility Refactoring - ParameterService

  • No labels