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 this architecture.
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.
Code Refactoring
Besides OLE/Rice 2.0 features, the other important piece for OLE 0.6 is the code refactoring. After OLE 0.3 release, OLE development team has better understanding for Rice and KFS. Code refactoring corrects the mistakes made before, and keep OLE system the better maintainability. OLE uses Fisheye as the bug tracking system, documenting all the problems found in the code review process. Jonathan Keller well summarized the common mistakes the developers easily 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... Lists all kinds of problems the developers may have, more detailed see the coding standards for OLE. Code refactoring also brings us other benefit, which is for the future OLE/KFS upgrades on Rice 2.0. It can reduce the problems it may happen during the upgrades.
Services Registries
The Service Registry contains information about all services that have registered from OLE to the services bus. 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 talked with OLE/Rice 1.x, and DocStore.
We have documented our OLE and DocStore services in the OLE service spread sheet, and the DocStore wiki. But we have realized that the documentation is not read friendly. We will continue working on the documentation for OLE 0.8 version. The future wiki for services registry would borrow the idea that Kuali Student did for their services documentation , so that the non-developers can also get benefit from it. More information about services registry in Rice can be found in Rice Wiki.