Work in Progress
This page is still under construction and information is being added.
0.6 Release Documentation
Table of Contents |
---|
|
Introduction
Return to Top
This section will include what was this release about- infrastructure;
Search, Svc Registries, Rice 2 POC...
Schemas
- Introduction to the OLE Instance Schema
- Introduction to Kuali OLE and the ONIX for Publications Licenses (ONIX-PL) Schema
KFS Upgrade
Rice 2 Server/POC
Recently, Rice 2.0 was released with the features we really need to for our OLE system. The main features that Rice 2.0 has are:
v Kuali Rapid Application Development Module (KRAD). The user interface framework component (UIF) of KRAD is built upon a rich JQuery library, provides more UI flexibility and improved configuration and tooling includes 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, custom constraints. Overall, KRAD will enhance OLE UI capabilities.
v The other important component in Rice 2.0 is Kuali Rule Management System (KRMS). KRMS is a rule engine for defining decision logic, commonly refereed to as business rules. KRMS facilities 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/easy managed business rule system.
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 current version is bundled with KFS, which utilizes Rice 1.x. Since Rice 2.0 formal released on Feb 24th, 2012, it is impossible that KFS can be upgraded onto Rice 2.0 before OLE 0.6 release. And it is not realistic that we abandon KFS and one-year implementation based on that, and rebuild our own financial system for OLE. So for 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 KSB, therefore, the communication between two servers go through SOAP services like the following figure.
As we discussed above, OLE 0.6 still keeps all the financial related functions on OLE/Rice1.x server, such as requisition. On the OLE/Rice2.0 server, two important functions Ingest and Bib 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 was check in and check out from DocStore through web services.
For ingest function on OLE 0.6, the business rules are not hard coded in the codes. Instead, users can define their ingest rules for each vendor in an XML profile, upload to OLE/Rice2, and through KRMS rule management interface, they can actually see those hierarchical rule structure. And 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 were executed on either 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.