Kuali Project
__________________________________________________________________________________________
Kuali Dependent Tuition Waiver-UITS
Design Document

___________________________________________________________________________________________
Dec 7, 2011

Project Scope

The purpose of this project is to move the current Dependent Tuition Waiver (DTW) application to the new Kuali Rice Workflow engine(KEW).
As part of the work, it may be necessary to identify legacy frameworks and replace them with more current KEW compatible frameworks.
Another objective is to preserve the look and feel of the user interface in order to ensure changes are transparent to the user.
Last but not the least the scope of this project includes meeting the functional requirements specified in the Functional Requirements Document Kuali/DTW UITS (see References below).
References:
_Functional Requirements Document Kuali/DTW UITS - http://confluence.uits.uconn.edu:8080/display/DTW/Functional+Requirements+Document+-+DTW_

Project Dependencies and Assumptions

Dependencies

1. Rice Infrastructure

The DTW thin client application depends on the Kuali Rice infrastructure to handle the workflow (through org.kuali.rice.kew.service.WorkflowDocument).

2. Services

The DTW depends on LDAP webservice to get LDAP info and also depends on the KIM service (Identity Management Service) to get identity info.

3. DTW Plugin

In order for the thin client to work with KEW, a plugin has to be created and deployed.

4. Peoplesoft infrastructure

The application also requires interaction with a peoplesoft server (for data file exchange) and a peoplesoft database view to enable data collection.

Assumptions

1. Original source code is available

Original Source code is available and matches production

1. Rice Infrastructure is available

Kuali Rice infrastructure is available

1. Functional users will be available

Functional users will be available for testing and verification.

Business Objects

Employee

1. Student
2. Person
3. Simple Workflow User
4. Net Id Token
5. Tuition Waiver Document
6. Export Info

Batch Scheduled Jobs

There are two scheduled jobs configured: Request Reminder and Notification retry. These jobs basically send out reminder and notification emails and are scheduled to run after midnight on most days.

Pre-Conditions

There are no preconditions for the notification retry job.
1. Request Reminder needs to be turned on
After the job is kicked of by the cron job it checks to see if the service is enabled before continuing. If the service is not turned on a warning message is logged stating that the DTW reminder job is turned off. No further processing occurs as a result.

Services

The following services on the Kuali Service Bus are being utilized:

1) kimIdentityService

2) kimIdentityManagementService

3) kimGroupService

Configuration

The workflow_clientapp.xml should have the following specified:

<param name="keystore.alias">rice</param>*

<param name="keystore.file">[path-to-rice.keystore]</param>*

<param name="keystore.password">[password]</param>*

*These values should match the corresponding entries in the server's rice-config.xml (This usually resides at /usr/local/rice on most servers).

Additionally, the following end points need to be specified:

<param name=

"workflowdocument.javaservice.endpoint">http://yourlocalip/kr-dev/remoting/WorkflowDocumentActionsService</param>

<param name=

"workflowutility.javaservice.endpoint">http://yourlocalip/kr-dev/remoting/WorkflowUtilityService</param>

<param name=

"identity.javaservice.endpoint">http://yourlocalip/kr-dev/remoting/kimIdentityService</param>

<param name=

"group.javaservice.endpoint">{_}http://yourlocalip/kr-dev/_remoting/kimGroupService</param>

Replace "yourlocalip" with the appropriate URL. You can obtain the exact url by referencing the Service Registry on the Rice Server. To access the registry, login to the appropriate server, then login through the backdoor as "admin". Click on the Administration Tab on the top and then click on "Service Registry" on the right side of the frame.

Build Parameters

T.B.D.[The Build Parameters sub-section provides a listing of the build parameters that must be created for the module to ensure a successful compilation.]
1. <aParameter>
[The parameter is presented here.]
2. <aParameter>
[The parameter is presented here.]

System Parameters

[The System Parameters sub-section provides a listing of the system parameters that must be created for the module to ensure a successful configuration.]
1. <aParameter>
[The parameter is presented here.]
2. <aParameter>
[The parameter is presented here.]

Controllers and Forms

[The Controllers and Forms section provides a detailed review of the web functions that will be represented in the document. This section should include any action and form descriptions required for the project.]

Controllers / Forms

Reports

The reports will sort the UCHC applications from the Storrs based employee applications
1. <aReport>
[The actual report is presented here.]
2. <aReport>
[The actual report is presented here.]

Workflow and Routing

The tuition waiver request will be routed to two nodes: HR1 and HR2.

To enable routing via workflow, the following roles, groups and responsibilities have been created:

DTW-HR1-Group, DTW-HR2-Group, DTW-Admin-Group, DTW-Report-Group: These are user groups. Individual users will be assigned to one or more of these groups. 

HR1 Reviewer, HR2 Reviewer: These are KUALI roles that are assigned to the DTW-HR1-Group and DTW-HR2-Group respectively. 

HR1 Review: This is the name of the responsibilities given to the HR1 Reviewer Role. There are two responsibilities with this name assigned to the HR1 Reviewer role. The difference being that they handle two different document types.

The two document types defined for the workflow are tuitionWaiverDocument for non-health center workflow and HCTuitionWaiverDocument for all health center workflow.

Workflow Actions (optional)

The following are the document workflow states:

1. Pre-Workflow – A document (request) will be in this state when initially created
2. In-Workflow – Once the document has been submitted, its state is changed to this value. Once any user with the appropriate role and at the appropriate node approves the status reflects the approval while still in the In-Workflow state.
3. Post-Workflow – This is the state once the document has gone through all the nodes.
4. Disapproved – This is the state a document is placed in if the request is disapproved for any reason.
5. Canceled – The document's state is changed to canceled if the submitter cancels the request.

Routing Rules and Actions (optional)

Basically the Routing rules are simple for DTW. If an employee is Storrs based, then the routing is as follows: Initiate ->HR 1 -> HR 2
If the employee is from UCHC then the request flow is: Initiate -> HR 1

Roles and Permissions

This section will list the user roles defined and their respective permissions.
1. DTW Admin
This is a role that grants admin privileges to its members (limited to DTW)
2. DTW-HR1-Reviewer
This role represents the first group of approvers who will sign off on a waiver request. If the request orginated from UCHC, then no other roles are involved in the approval process. This Role also has two responsibilities (See Workflow and Routing)

1. DTW-HR2-Reviewer

This role represents the second group of approvers. This role is only relevant to requests that originate from the Storrs campus

1. DTW-Report

This role encapsulates the group of users who can generate reports.

1. Workflow Admin

Data

There are three database tables associated with DTW. No changes are anticipated. For referential convenience these tables are described in detail here.

Additionally the application will use JDBC together with JNDI to access the database tables listed below. Previously the application used Apache OJB. As OJB has been retired by Apache, it is prudent to switch to an access mechanism that is still relevant.

Database Objects

Tuitionwaiver_doc:
doc_hdr_id number(14) not null,
req_type char(1) not null default 'O',
employee_name varchar2(255) not null,
employee_no varchar2(11),
employee_email varchar2(255) not null,
employee_netid varchar2(10) not null,
employee_payid varchar2(10),
employee_dept varchar2(255),
employee_deptno varchar2(10),
employee_phone varchar2(255),
employee_union varchar2(255),
student_name varchar2(255) not null,
student_id varchar2(10) not null,
student_netid varchar2(10) not null,
student_email varchar2(255),
student_semstand varchar2(20),
student_semcode varchar2(12),
student_campus varchar2(32),
student_phone varchar2(12),
student_waiverterm varchar2(12) not null,
percent_eligible varchar2(3) not null,
waiver_amount varchar2(12),
manual_input varchar2(8),
employee_comments varchar2(600),
comments varchar2(600),
hr2_comments varchar2(600),
bursar_comments varchar2(600),
request_date VARCHAR2(12),
export_date VARCHAR2(12),
finalize_date VARCHAR2(12),
doc_statusvarchar2(255) not null,
ver_num number(14) not null,
constraint tuitionwaiver_doc_pk primary key(doc_hdr_id) using index
Tuitionwavier_netid_token:
net_idvarchar2(10) not null,
login_tokenvarchar2(32) not null,
constraint dtw_netid_token_pk primary key(net_id) using index
Tuitionwaiver_options:
option_namevarchar2(255) not null,
option_valuevarchar2(255),
constraint tuitionwaiver_option_pk primary key(option_name) using index
Additionally the following indexes are also created:
TWIDX_NETID on tuitionwaiver_doc(employee_netid)
TWIDX_EMPLNAME on tuitionwaiver_doc(employee_name)
TWIDX_STUDENTID on tuitionwaiver_doc(student_id)
TWIDX_STUDENTNAME on tuitionwaiver_doc(student_name)
TWIDX_WAIVERTERM on tuitionwaiver_doc(student_waiverterm)

Data Conversion

[In this section provide a detailed description of any data that will need to be converted from one format to another. The plan describes the overall approach, assumptions, and processes that will be used in the data conversion. It includes an inventory and cross reference of source and target data elements, schema, metadata and all self-describing files; process for data extraction, transformation and loading for each data source; tools needed to execute the conversion; and strategy for data quality assurance and control].


External Interfaces
[External systems are any systems that are not within the scope of the system under development, regardless whether the other systems are managed by the State or another agency. In this section, describe the electronic interface(s) between this system and each of the other systems and/or subsystem(s), emphasizing the point of view of the system being developed.]

Interface Architecture

[In this section, describe the interface(s) between the system being developed and other systems; for example, batch transfers, queries, etc. Include the interface architecture(s) being implemented, such as wide area networks, gateways, etc. Provide a diagram depicting the communications path(s) between this system and each of the other systems. If appropriate, use subsections to address each interface being implemented.]

Interface Design

[For each system that provides information exchange with the system under development, there is a requirement for rules governing the interface. This section should provide enough detailed information about the interface requirements to correctly format, transmit, and/or receive data across the interface. Include the following information in the detailed design for each interface (as appropriate)]

Additional Information

N.A.

Definitions

[The Definitions sub-section should contain terms that help define the function. They can be defined in any order desired, but generally alphabetical order provides the greatest accessibility.]

Questions/Issues

N.A.