0.6 Release Documentation

Introduction

The Kuali OLE 0.6 Milestone Release focuses on enhancing the infrastructure that was available in the OLE 0.3 Milestone Release.

• New schemas have been introduced:
  • The OLE Instance schema is loosely based on the MARC Format for Holdings Data (MFHD). OLE Instance documents are used to identify and describe library resources locally owned/licensed by libraries and as such contain unique information that can not be captured in Bibliographic documents that may be used/shared by multiple libraries.
  • ONIX-PL, a standard used to describe and transmit licensing information for electronic resources, will be utilized as the central schema for storing data within Kuali OLE’s licensing module.
• KFS has been upgraded.
• With the onset of Rice 2.0, KRAD and KRMS features have been incorporated into part of OLE.
  • KRAD provides the user interface OLE needs for inquiries and lookups, transactional and maintenance documents.
  • KRMS provides OLE the opportunity to build its own flexible and easily managed business rule system.
• Code refactoring corrects the mistakes made during the 0.3 Milestone Release and keeps the OLE system better maintained.
  The Service Registry contains information about all services that have been registered from OLE to the services bus (KSB), designed to allow developers to quickly develop and deploy services for remote and local consumption.
• KFS PURAP upgrade has been postponed.

Please also see the OLE 0.6 Milestone User Documentation to test run the demo, read through the Drivers Manual, and learn more about the O.6 release.

Schemas

Return to Top

Instance Schema

• Introduction to the OLE Instance Schema 
  • OLE Instance Schema Documentation v 8.1
  • OLE Instance Schema v 8.1 (xsd file)
  • List of Data Elements for v8.1 (updated 4/10/2012)

Licenses Schema

• Introduction to Kuali OLE and the ONIX for Publications Licenses (ONIX-PL) Schema
  • ONIX-PL on the Editeur Website

KFS Upgrade

A full KFS 5.0 code merge and upgrade is expected during the OLE project schedule for OLE 0.8 (spring 2013). OLE did prepare and edit some existing code and services to prepare for eventual upgrades, but partial upgrades during OLE 0.6 were postponed until KFS completes testing and debugging of KFS 5.0.

Return to Top

Rice 2 Server/POC

Return to Top

Recently, Rice 2.0 was released with the features we really need to improve our OLE system. The main features that Rice 2.0 has are:

KRAD

Kuali Rapid Application Development Module (KRAD). The user interface framework component (UIF) of KRAD is built upon a rich JQuery library, provides more UI (user interface) flexibility and improved configuration and tooling including messages and notifications, client side validation, AJAX enabled fields, ... KRAD provides the UI OLE needs for inquiries and lookups, transactional and maintenance documents. For example:

• Perform lookups/inquiries within a lightbox/iframe that pops up over the document
• Open documents or route log from action list or document search in a lightbox
• Add support for some transactional document layouts without using JSPs.
  KRAD makes data dictionary change such as adding lookup constraints and custom constraints. Overall, KRAD will enhance OLE UI capabilities.

For more about KRAD, see Rice KRAD analysis

KRMS

The other important component in Rice 2.0 is Kuali Rule Management System (KRMS). KRMS is a rule engine for defining decision logic, commonly referred to as business rules. KRMS facilitates the creation and maintenance of rules outside of an application for rapid update and flexible implementation that can be shared across applications. KRMS provides OLE the opportunity to build its own flexible and easily managed business rule system.

For more about KRMS, see the KRMS and PeopleFlow Functional Overview

How OLE is affected

Based on the above Rice 2.0 features, obviously, moving OLE to Rice 2.0 framework is what we should go for. However, Kuali OLE's current version is bundled with KFS, which utilizes Rice 1.x. Since Rice 2.0 was formally released on Feb 24^th, 2012, it was impossible for KFS (Kuali Financial System) to upgrade to Rice 2.0 before OLE 0.6 release. It is not realistic to abandon KFS and one-year's worth of implementation based on that and to rebuild our own financial system for OLE. So for the OLE 0.6 release we set up two servers, one for OLE with KFS/Rice1.x to keep our financial functions and one for OLE on Rice2.0 to try the new features and see what kind of benefits it can bring for OLE. Since Rice 1.x can not talk with Rice 2.0 through the KSB (Kuali Service Bus), therefore, the communication between two servers geso through SOAP services like this simple drawing for the architecture. 

As we discussed above, OLE 0.6 still keeps all the finance related functions, such as requisitions, on the OLE/Rice1.x server. On the OLE/Rice2.0 server, two important functions Ingest and Bibliographic Editor were implemented for OLE 0.6 by using KRAD and KRMS. Therefore, on OLE 0.6, Bib Editor will try some of the KRAD features such as client side validation. The actually data is checked in and checked out from the DocStore through web services.

For ingest functions on OLE 0.6, the business rules are not hard coded. Instead, users can define their ingest rules for each vendor in an XML profile, upload to OLE/Rice2, and through the KRMS interface, users can actually see those hierarchical rule structures. Through the ingest staff load interface, they can apply those rules to the data they want to load. Users can easily make changes to the rule profile and the actions they want to apply for those rules. When loading the data, the actual actions are executed on either the DocStore (such as create bib records), or OLE/Rice1.x (such as create PO) by calling the web services and passing the data.

Ingest and Bib Editor will be the good example to show you the benefits we can take from Rice 2.0.

Code Refactoring

Return to Top

Besides OLE/Rice 2.0 features, the other important piece for OLE 0.6 is the code refactoring. After the OLE 0.3 release, the OLE development team has better understanding of Rice and KFS. Code refactoring corrects the mistakes made before, and keeps the OLE system better maintained. OLE uses Fisheye as the bug tracking system, documenting all the problems found in the code review process. Jonathan Keller summarized clearly common mistakes the developers made in the previous codes in this PPT slides. By borrowing the experience from KFS and Rice, we have our coding standards for OLE from naming convention to Data Access Objects, service design and thread safety.
For lists of problems the developers may have in more detail, see:

• the coding standards for OLE (.pdf)
• OLE Standards (.doc)

Code refactoring also brings us other benefits, which will benefit the future OLE/KFS upgrades on Rice 2.0: It can reduce the problems that may occur during the upgrades.

Services Registries

Return to Top

The Service Registry contains information about all services that have been registered from OLE to the services bus (KSB). The Service Registry is available as a SOAP endpoint which allows for registering, removing, and querying on information about these service endpoints. It is important for OLE to make those services accessible remotely due to our OLE 0.6 two servers design since it allows OLE/Rice 2.0 applications to talk with OLE/Rice 1.x and the DocStore.

We have documented our OLE and DocStore services in the OLE service spread sheet, and the DocStore wiki. We realize that the documentation is not reader friendly but we will continue working on and improving the documentation for OLE version 0.8. The future wiki for services registry will borrow some from the Kuali Student services documentation, so that non-developers can also benefit from it.

More information about services registry in Rice can be found in the Rice Wiki.

KFS PURAP Upgrade

(postponed until KFS completes testing and debugging)

Return to Top