Presenter(s): Eric Westfall (Indiana University) Scott Gibson (University of Maryland) Travis...

Presenter(s):

•Eric Westfall (Indiana University)

•Scott Gibson (University of Maryland)

•Travis Schneeberger

•Matt Sargent (Indiana University)

Date: 11/14/2011

Time: 1-ish to 5-ish

GETTING STARTED WITH RICE: STAND ALONE SERVER, EDOCLITE, AND APPLICATION DEMONSTRATION & DISCUSSION

PRESENTERS

Eric Westfall (Indiana University)

•Kuali Rice Lead Architect

•Blurb

Scott Gibson (University of Maryland)

•Role

•Blurb

Travis Schneeberger

•Role

•Blurb

Matt Sargent (Indiana University)

•Kuali Rice BAQA

SESSION AGENDA

1.Rice Overview and Architecture2.Rice Stand Alone Server Setup Demo3.eDoc Lite General Overview 4.eDoc Lite Technical Overview5.eDoc Lite Setup Demo6. “Heavy Metal” App Demo7.Open Q/A Forum

SESSION INFORMATION

•This is not a session where you need to follow along and do the setups as we do, just a demo•Please ask questions at anytime. Grade school rules, raise your hand.

•We’ll take a couple of breaks, but feel free to come and go as you need to

•Have fun and enjoy

Kuali Rice Overview and Architechture

RICE OVERVIEW AND ARCHITECTURE

1.What is Kuali Rice?

2.Goals of Kuali Rice

3.Current Rice Modules

4.Deployment and Integration Options

WHAT IS KUALI RICE?

• Kuali Rice is really 2 Things:

• Middleware Services

• Application Development Framework

• Various modules are integrated into a cohesive software stack

• Provides a common “platform” for Enterprise application development and integration

VISION

• Support the needs of the Kuali Application Projects

• Kuali Financial System (KFS)

• Kuali Coeus (KC)

• Kuali Student (KS)

• Kuali Open Library Environment (OLE)

• Kuali People Management for the Enterprise (KPME)

• Provide enterprise class middleware suite of integrated products that can be used by non-Kuali projects as well.

• Local projects at an institution or organization

GOALS

• Create a common and consistent architecture for Kuali• Leverage existing open source solutions when possible• Build a large community of interest with strong

sustainability by encouraging adoption and contribution• Design, construct, and deliver all components in a

service-oriented fashion• Promote the design and implementation of modular

components• Provide a reference implementation based on industry

standards• Ensure open source license compliance is maintained

KUALI RICE COMPONENTS

• Version 1.0.x

• KSB - Kuali Service Bus

• KIM - Kuali Identity Management

• KEW - Kuali Enterprise Workflow

• KEN - Kuali Enterprise Notification

• KNS - Kuali Nervous System

• Version 2.0 – (Beta available now!)

• KRMS – Kuali Rule Management System

• KRAD – Kuali Rapid Application Development

KUALI SERVICE BUS

• Simple service bus

• Service Registry

• Service Connectors and Exporters

• Reliable Messaging

• Topics and Queues

• Failover and Load Balancing

• Service Security

KSB ARCHITECTURE

SERVICE REGISTRY

KUALI IDENTITY MANAGEMENT

• Shared Identity and Access Management (IAM) services

• Can be used by Kuali and non-Kuali projects

• Rich and customizable permission-based authorization system

• Services available as SOAP endpoints with reference implementations

• Loose coupling between services

• Provides a platform for IAM service integration and customization

• Graphical user interface screens for maintenance

KIM – SUPPORTED CONCEPTS

• Entities

• Principals

• Groups

• Roles

• Permissions

• Responsibilities

KUALI ENTERPRISE WORKFLOW• Content-based routing and approval engine

• Documents created from process definitions (Document Types) and submitted to the workflow engine for routing

• Routing decisions made based on the document’s content

• Traditionally used for business transactions in the form of electronic documents that require approval from multiple parties. For example:

• Transfer of Funds

• Hire/Terminate Employee

• Timesheet

• Create Course

• Add/Drop a Class

• Action requests generated by engine: approve, acknowledgement, fyi

• Composed of a set of service APIs, frameworks, and GUIs

KEW CORE FEATURES

• Action List

• Document Search

• Includes custom document attribute indexing for search

• Route Log

• Document Types and Flexible process definitions

• Rules Engine

• Email Notification

• Notes and attachments

• Pluggable frameworks for customization of routing and other portions of system

• eDocLite - framework for creating simple documents quickly

KUALI ENTERPRISE NOTIFICATION

• Responsible for processing and dispatching notifications

• Works with the action list to provide a single place for all university related communications

• Workflow items come from KEW

• Non-workflow items from KEN

• Non-workflow example items

• Overdue library book

• A concert on campus

• Graduation checklists for seniors

KUALI NERVIOUS SYSTEM

• Kuali Rice application development framework

• Reusable code, shared services, integration layer, and a development strategy

• Common look and feel

• Business process-centric model with workflow as a core concept

• Built-in integration with KEW

• Built-in integration with Kuali Identity Management for authorization

KNS CORE CONCEPTS

1. Business Objects – represents the data model for the application

2. Lookups – allows for performing searches against business object data

3. Inquiries – displays detailed information about business objects

4. Documents – data entry (create and edit, can interact with workflow)

5. Data Dictionary – defines metadata about business objects, lookup, inquiries, and documents

KUALI RAPID APPLICATION DEVELOPMENT (RICE 2.0)

• An effort to “modernize” the Kuali development platform

• Intended to be the eventual replacement for the Kuali Nervous System (KNS)

• Why KRAD? What’s wrong with the KNS?

• Struts 1.x based, KRAD is Spring MVC-based

• Very little built-in rich user interface support

• User experience is targeted to administrative users

• Only has built-in support for a small set of screen types

• Note however, most of the core architectural concepts and frameworks from KNS are still relevant in KRAD

KRAD – LAUNDRY LIST

KUALI RULE MANAGEMENT SYSTEM (RICE 2.0)

• Implements a Business Rule Management System (BRMS) for Kuali

• BRMS - a system used to define, deploy, execute, monitor and maintain business rules

• Business Rules – decision logic that is used by operational systems within an organization or enterprise

• Consists of a rule repository and a rules execution engine

• Designed and built to address requirements in both Kuali Coeus and Kuali Student

KUALI RICE MODULES

3. Current Rice Modules

Current

Upcoming

DEPLOYMENT AND INTEGRATION

• Kuali Rice provides different options for how it can be deployed and integrated with other applications

• Attempts to be flexible in the available configuration options

• Rice Deployment Options• Bundled – Kuali Rice is “bundled” into

your application• Standalone – a Kuali Rice standalone

server is deployed

DEPLOYMENT AND INTEGRATION

• Standalone Server Client Integration Methods

• Embedded Workflow Engine Services

• Embedded Identity Services

• KEW Java Thin Client

• Web Services

• Can configure hybrids of above using available “run modes” for Rice modules

• The underlying engine for this flexibility is the Kuali Service Bus

• Facilitated by Rice’s service-oriented and modular design

MODULAR DESIGN

• Kuali Rice is composed of a set of high-level modules

• Each module composed of a set of service interfaces and API components

• Each module also has a reference implementation of those services

• Each module publishes services on the service bus that should be available externally

ARCHITECTURE

Service APIs KEW KEN KIM

Reference Implementation Kuali RiceDatabase

Kuali Service Bus ServiceRegistry

Application KNSApplication

Code

WHAT DOES THIS MEAN FOR INTEGRATION?

• Applications that are integrating with Kuali Rice can:

• Call some services remotely

• Embed some components

• Implement a hybrid approach

• At the end of the day, services are located and invoked, they may be deployed locally or remotely and caller does not need to know

• Powered by: the Resource Loader Stack

RESOURCE LOADER STACK

BUNDLING KUALI RICE

• All Kuali Rice modules and services are embedded into the client application, including the Web Application

• Does not require the deployment of a standalone Rice server

• Ideal for development or “quickstart” applications

• This is not desirable for Enterprise deployments of Kuali Rice

BUNDLING KUALI RICE

STANDALONE RICE SERVER

• Central Kuali Rice instance that can be integrated with multiple clients

• Facilitates a single KEW Action List, Document Search, etc.

• Shared KSB Service Registry

• Supports multiple integration options for clients:

• Java Thin Client

• Embedded Workflow Engine

• Embedded Identity Services

• Web Services

EMBEDDING KUALI ENTERPRISE WORKFLOW

• It’s possible to embed the KEW workflow engine into a client application

• In these cases the engine processing happens in the client application

• Interaction with the Rice Standalone Server is handled via KSB and the database

REASONS TO EMBED KEW

• Transactional - integration of transactions between client application and embedded KEW (via JTA)

• Fast - Embedded client talks directly to database

• Scalability – distribute workflow engine processing load

• No need for application plug-ins on the server

EMBEDDED KEW

JAVA THIN CLIENT (KEW)

• Allows you to use the workflow services from a java application

• All services are invoked remotely

• Does not require the service bus to function

• Good for “KEW-only” integration

SOAP WEB SERVICE CLIENTS

• Rice exposes a number of SOAP services

• Can use provided WSDLs to build clients for them on virtually any platform

• KIM Services:

• Identity, Role, Group, Permission, and Responsibility services

• KEW Services:

• WorkflowDocumentActionsService

• SimpleDocumentActionsService

• WorkflowUtilityService

BRINGING IT ALL TOGETHER

• Leveraging the KSB and the previous examples, it’s possible to utilize multiple strategies for Kuali Rice integration and deployment

• Examples:• Some clients running as Thin Clients• Some clients leveraging code deployed in plug-ins

on the standalone server• Multiple servers deployed in a cluster for scalability• Some clients integrating directly with SOAP

endpoints• Some clients running in Embedded Mode

THE WHOLE PICTURE

Rice Standalone Server Setup

Demo

RICE STANDALONE SERVER SETUP DEMO

•The Standalone Rice Server download is available in .war form on the Rice website

•Provides services from the following Rice components:

•KEW

•KEN

•KSB

•KIM•Coming in 2.0 KRAD

•Coming in 2.0 KRMS

eDoc Lite General Overview

EDOC LITE GENERAL OVERVIEW

Why?•Sometimes you need simple 1-2 page electronic documents, with simple routing.•Sometimes you need a simple stop gap process while an application is being developed.•These are situations where eDoc Lite comes in.•eDoc Lite is a simple, form-based system that runs entirely within workflow, and can be created with no java, just XML.


Key Concepts

•Rapid Implementation

•Easily re-configured

•Easily manageable

•No application to redeploy

•Entirely web-based from design/development and user perspectives

•Support for notes and attachments


Key Concepts (continued)•No java code required; only XML

•Using XML against a schema for form fields layout•Using your own custom XSLT for presentation

•Simple Validation Rules•Regular Expression•Validate Against List•Custom Validators•Required/Not-Required•JavaScript Validation


What are some abilities for eDoc Lite?

•Replace simple paper-based processes

•Hide fields based on routing rules

•Restrict read/write of particular fields

•Perform field level validation

•Leverage KIM principals, workgroups, and roles for routing


What are some limitations for eDoc Lite?

•Being simple, you don’t get all the bells and whistles you may with a large scale application

•Can’t pull data from external sources

•Perform mathematical functions on input fields


Examples of Use•Academic Position Request for Affirmative Action•University Graduate School Course Remonstrance Request•Health Center Appointment Request•Internal Funding Request•Security Token Requests•More at...

https://wiki.kuali.org/x/FoH7Dg

https://wiki.kuali.org/x/FoH7Dg

eDoc Lite Technical Overview

EDOC LITE TECHNICAL OVERVIEW

•Every eDoc Lite consists of 4 pieces:

•Field Definitions – defines what fields the EDL has, what type, validations, etc. Similar to a Data Dictionary definition in KNS

•Style sheet – an XSLT style sheet that renders the EDL for the user

•Document Type – defines the workflow process for the EDL

•EDL Association – associates each of the 3 pieces above to form an eDoc Lite

EDOC LITE TECHNICAL OVERVIEW

1.Architecture

eDoc Lite Demo

EDOC LITE DEMO

•For this exercise we will look at a very feature-rich real world eDoc Lite form•University Office of Affirmative Action Recruitment•As positions are being reviewed for posting, interviewing, and hiring, the OAA needs to approve each step to ensure that best efforts are being taken to comply with all Affirmative Action statutes•All Academic positions at IU’s Bloomington Campus are approved through this process

EDOC LITE DEMO

OAA Routing Process

1.School / Responsibility Center

2.Office of Affirmative Action Workgroup

3.Office of Affirmative Action Director

4.Office of the Vice Provost for Faculty and Academic Affairs

5.Upon final approval (step 4), the initiator and School/RC are sent acks of processing

EDOC LITE DEMO

•First we need to setup EDL, ingest the following from the rice project:

•edlstyle.xml

•widgets.xml

•edlstyle.xml is the default style for eDoc Lite documents •widgets.xml is an XSLT library that is used for rending input tags for the various fields on a document

EDOC LITE DEMO

The following files in the sample-edoclite folder need to be ingested in this order:

1.OAA-Workgroup.xml

2.OAA-Attributes.xml

3.OAA-RuleTemplates.xml

4.OAA-DocumentType.xml

5.OAA-ChildDoctypes.xml

6.OAA-Rules.xml

7.OAA-VacancyNoticeEDL.xml

8.OAA-WaiverRequestEDL.xml

9.OAA-InterviewRequestEDL.xml

10.OAA-OfferRequestEDL.xml

11.OAA-SearchStatusEDL.xml

EDOC LITE DEMO

•Now, let’s create a new Vacancy Notice eDoc Lite document and route it

•Note:

•Validation that is being performed as the document is being filled out.

•Attachments and notes are available

•As the request moves through the routing, certain fields are editable and others are not

EDOC LITE DEMO

•Open OAA-VacancyNotice.xml

•Examine <edl> section

•Examine <style> section

•Examine <association> section

EDOC LITE DEMO

•Since EDL uses KEW for its routing. You can implement Post Processors to write your EDL data to a database.•There is one already available which can be used out of the box to write to:

•EN_EDL_DMP_T•EN_EDL_FIELD_DMP_T

•This data can then be reported to a DSS environment or extracted via some other process

Heavy Metal App Demo

“HEAVY METAL” VS EDOCLITE

• eDocLite is a tool for building simple form-based applications backed by workflow

• “Heavy Metal” is a playful term for a standalone client application that integrates with Kuali Rice and it’s services

• We are going to go through the process of creating one such application

OPTIONS FOR CREATING A RICE CLIENT APPLICATION

• Use the jars in the binary distribution, configure and create application manually

• Use Rice jars in Kuali Maven repository

• Use the createproject.groovy script provided by Rice

• This is the quick and easy way!

createproject.groovy

• A script written in Groovy that generates a Kuali Rice client application

• So what exactly does it do?

• Generates a Maven-based project skeleton for a Kuali Rice client application

• Generates a Rice configuration file in a standard location

• Can optionally include a sample application

THE GENERATED PROJECT

• Is a standard Eclipse project (including .classpath and .project files)

• Can be easily imported into your workspace

• Is configured as a “bundled” client application

• This means no Rice Standalone server is required in order to use the application

• Includes support for KNS, KEW and KIM usage

• Contains standard Spring Framework XML configuration for Kuali Rice client applications

• Includes a script to launch an embedded Jetty engine in which to run the generated application

THE DATABASE

• As mentioned, createproject.groovy generates a Bundled Rice application

• This means it needs a full “server” database

• Luckily for us, we demonstrated how to do this when we looked at how to use the Impex tool!

• Now, we will demonstrate the process of generating a Kuali Rice client application using createproject.groovy

Cue the Demo…

Client Application and Project

Layout

THE GENERATED PROJECT

• Now that you’ve seen how to generate a project, let’s look at the different pieces in depth.

• The pieces we will examine include:

• General project layout

• pom.xml file

• Eclipse classpath configuration

• Launch script

• Rice XML Configuration Files

• The included sample application classes

• Spring Configuration Files

• OJB Mapping Files

PROJECT LAYOUT

• Project root

• pom.xml

• Launch script

• src/main/java

• Location for your java classes

• src/main/resources

• Location for non-java files that need to be available as resources on the classpath

• Spring configuration files

• OJB configuration files

pom.xml

• Used by Maven

• “pom” stands for Project Object Model

• This defines the following:

• Name of your project

• Project version number

• Dependencies

ECLIPSE CLASSPATH CONFIGURATION

• Generated during project creation

• This .classpath file was generated using the mvn command:

• mvn eclipse:eclipse

• If you ever need to add a library to your project, add dependency to pom.xml and execute “mvn eclipse:eclipse”

LAUNCH SCRIPT

• “Launch Web App.launch”

• An Eclipse “launch” scripts which starts up a Jetty server on port 8080

• This Jetty server loads your generated client application

RICE XML CONFIGURATION FILES

• There is one important one in the generated project:

• src/main/resources/META-INF/myapp-config.xml

• Contains any fairly stable or unchanging config properties

• Uses the “config.location” element to import the file from your user home directory

• This was generated automatically during project creation:

• ~/kuali/main/dev/myapp-config.xml

RICE XML CONFIGURATION FILES

• General syntax of the xml files is like this:

• <param name=“…”>…</param>

• Can also reference other parameters

• <param name=“…”>${other.param}/blah</param>

• Import other files using:

• <param name=“config.location”>…</param>

SAMPLE APPLICATION CLASSES

• Class files under src/main/java

• All are included in the edu.sampleu.travel package

• Consists of sample application implementation using the KNS and KEW

• Resources under src/main/resources

• Primarily Data Dictionary files here

• Located in edu.sampleu.travel.datadictionary package

SPRING CONFIGURATION FILES

• This is where the most important pieces lie

• There are 5 main Spring configuration files

1. SpringBeans.xml

2. myapp-RiceDataSourceSpringBeans.xml

3. myapp-RiceJTASpringBeans.xml

4. myapp-RiceSpringBeans.xml

5. myapp-SampleAppModuleBeans.xml

OJB MAPPING FILES

• src/main/resources

• OJB-repository-sampleapp.xml

• This file maps the various objects in the sample application to their corresponding database tables

• class-descriptor, field-descriptor, collection-descriptor, etc.

CRAVING MORE INFORMATION?

Visit http://kuali.org/rice

Test Drive http://demo.rice.kuali.org

Download http://kuali.org/download-form

Get Involved http://kuali.org/join

Contact Us [email protected]

Presenter(s): Eric Westfall (Indiana University) Scott Gibson (University of Maryland) Travis...

Documents

Transcript of Presenter(s): Eric Westfall (Indiana University) Scott Gibson (University of Maryland) Travis...