...
- Introduction to the OLE Instance Schema
- Introduction to Kuali OLE and the ONIX for Publications Licenses (ONIX-PL) Schema
...
Recently, Rice 2.0 was released with the features we really need to for 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.
...
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.
...
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 formal was formally released on Feb 24th, 2012, it is was impossible that KFS can be upgraded onto for KFS (Kuali Financial System) to upgrade to Rice 2.0 before OLE 0.6 release. And it It is not realistic that we 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 go geso through SOAP services like this simple drawing for the architecture.
As we discussed above, OLE 0.6 still keeps all the financial finance related functions, such as requisitions, on the OLE/Rice1.x server, such as requisition. On the OLE/Rice2.0 server, two important functions Ingest and Bib 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 was check is checked in and check checked out from the DocStore through web services.
For ingest function functions 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 the KRMS rule management interface, they users can actually see those hierarchical rule structurestructures. And through 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 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.
...
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 for of Rice and KFS. Code refactoring corrects the mistakes made before, and keep keeps the OLE system the better maintainabilitymaintained. OLE uses uses Fisheye as as the bug tracking system, documenting all the problems found in the code review process. Jonathan Keller well summarized the clearly 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
For lists of problems the developers may have , more detailed see in more detail, see:
Code refactoring also brings us other benefitbenefits, which is for will benefit the future OLE/KFS upgrades on Rice 2.0. : It can reduce the problems it that may happen occur during the upgrades.
Services Registries
...
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 talked 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. But we have realized We realize that the documentation is not read reader friendly . We but we will continue working on and improving the documentation for OLE version 0.8 version. The future wiki for services registry would will borrow some from the idea that Kuali Student did for their services documentation , so that the non-developers can also get benefit from it. More
More information about services registry in Rice can be found in in the Rice Wiki.