Technical Consultants Group 061208

Owned by Joyce Johnstone
Last updated: Dec 16, 2008 by Craig GilmoreVersion comment
7 min read

MIV Technical Consultants Group - June 12, 2008

Attendees: Debbie Lauriano (IET) Curtis Bray (IET), Joyce Johnstone (IET), Scott Kirkland (CA&ES), Stephen Paulsen (IET), Benny Poon (SOM), Everett Wilson (OCP), Ken Taylor (CA&ES)

Absent: Ray Tai (Vet Med), Hemang Patel (CBS), Jonathan Keller (AFS)

V2 project schedule

  • On Track: Project is currently on schedule to meet the June 30, 2008 delivery date.
  • QA testing: Winding down and the bug fix count is stable so that we can complete by June 26.
  • Load testing: Using Borland's SilkPerformer. We have a server at the Data Center and agents at the NOC and Data Center. We had to bypass distauth and allow access from authorized IP address. The agent just accepts who you say you are. That way we can simulate lots of users. We're also QA regression testing at the same time. It's interesting to see how it slows downs. And testing has been able to confirm performance improvements or identify areas that need to be tuned.
  • Google Analytics: Adding to the MIV pages to gather historical user data. June 30 we can start tracking. Our load tests can be adjusted to the real load based on what pages are being used. Google Analytics is easy to set up. It just takes 5 lines of Javascript. UCD Communications uses it on the campus Web site so they can determine where users go when they leave the campus site. Middleware would also like to set this up for MyUCDavis. For MIV we're just tracking usage within MIV.

What's next?

  • Spring Framework: Implementing for the CV and Biosketch upgrade. Wanted to get more consistent development processes in place. Requires less work. Pre-defined frameworks keep staff aligned with similar skills. People can share knowledge. Also want to use for CAS and other Middleware projects. White Pages is already using Spring. Are you using the data persistence or framework layer? Using front to back. The middle layer has dependency injection and data access with Spring JDBC. We could use Hibernate but for now we'll still be writing sql statements. Spring MVC layer might have to be put on the shelf and then go go back to JSP/servlets. We'll do a proof of concept. The pages are already created and designed in an MVC manner but not in an MVC framework. When V3 (Workflow and Role Mgmt) is done and things are more consistent then we can switch to Hibernate and swap out that one layer. We will not be converting the V2 upgrade to Spring. As we move forward will implement in the framework.
  • Spring Training: We're sending MIV developers to four weeks of training on Spring advance features. Is there anyway to share your knowledge or experiences? Yes, you're invited to attend the Spring training and we could probably hold more trainings. Would be useful to have more developers involved to share what we're learning. We could contact TIF or TSP to see who's interested. Can we start a a Java-sig? They get started and then fall apart. Need a mailing list for Java. There are no programming mailing lists. There have been but again they fall apart.
    Framework cross fertilization between IET staff and projects. Scott has been working with Hibernate but not Spring. Has Struts and Windsor. Also looking into MVC. Keep him mind for training.

Recommendations to the Provost for next versions of MIV

The MIV Roadmap Timeline and recommendations for next features were made to the Provost by the Steering Committee represented by Connie Melendy and Dave Shelby. The Provost has accepted these recommendations. The next step is to make a funding proposal to ORMP.

  • V2.1 - CV and NIH Biosketch
    Updates to create a generically formatted CV and a NIH grant agency-formatted documents that can be edited or formatted using MS Word or other software.

  • V2.2 - Data Imports
    Create an import tool to select citations from EndNote, a bibliographic organizational program for searching bibliographic databases. EndNote can retrieve publication citations and save them in a file that MIV uses to populate publication fields. This key component was added to Plan C to allow for user buy-in with the ease of use to add publications without the need for manual data entry.

  • V2.3 - Document Uploads
    Create a centralized PDF upload process for all letters and the DESII Report. These are documents that do not have be part of the data repository.

  • V2.4 - Engineering Codes
    Add fields to the publication data entry forms for the symbols and notations specific to the College of Engineering.

  • V3.0 - Workflow and Role Mgmt
    Update the workflow processes and roles that move a packet through the various stages (department, dean's office, AP, CAP). New processes and roles will not be added. The roles and workflow will be the same as in MIV currently but the code will be simplified. With these changes the roles and processes can be extended later.

  • Ongoing maintenance
    Fix bugs and make ongoing improvements, such as a process for appeals or more roles in role management.

Review CV and NIH Biosketch functional and technical design

Functional design and prototypes:

V2.1 CV Functional Requirement
V2.1 CV Prototype
V2.1 NIH Biosketch Functional Requirement
V2.1 NIH Biosketch Prototype

Technical design: https://confluence.ucdavis.edu/confluence/x/woWb

  • Upgrade will make these simple and consistent. Give some options about alignment and bolding but nothing very fancy. The technical design treats these two features as the same thing. CV is a biosketch but just a personal biosketch. The main design is based on the biosketch and the CV is just one of those.
  • Technical design allows users to create new, modify existing, and select what they want included based on the broad categories and then choose the specific records to include. Users will be able to create and duplicate the outline.
  • Will create editable formats: PDF, RTF, WML ODF, OXML. Will probably just offer RTF and PDF initially. RTF has everything we need for an editable format. We can pull the document into an editor and save as something else.
  • NIH has particular rules so there are limits on what/how many records can go into particular biosketch. Biosketchs have optional, required, and prohibited records based on biosketch type. Whereas the CV has no particulars.
  • If we add a NSF biosketch, we'll add new table definitions and biosketch specific fields. If we have biosketch specific records they'll get pulled in based on the type or keep generic as key value pairs.
  • Page size and margins are predefined. We're providing for different possibilities but users won't be able to choose. We're making provisions for things not on the interface.
  • Heading format options apply to all headings. May be able to offer minor formatting options such as highlighting one word only in a heading (not sure if this works).
  • Min/max settings will be defined in the limits table. This defines what's available on that page. Users can create a new biosketch with one set of pages that it gets the text strings based on Biosketch type.
  • A wizard tool allows you to create or stop at a step. Pages are either created in the Wizard mode or stand alone mode. Why does the wizard allow you to save rather than just go to 'Next'? Should say 'Proceed' or 'Next' and just save when you're not going to the next step. Because you could fill out choices and stop and then just create from the menu later and output the documents.
  • These features are not going to be a document repository. The documents will expire. We'll have a cron job that runs nightly to delete ones that are a certain age. We discussed expiration of files vs. and responding at the time you want to create a new version of the document. But making sure user understands this is difficult.
  • Discussed using Spring webflow but that seemed too heavy for what we need. We're just going to produce PDF and RTF. Performance will be fine so we will output both. If we output more formats then we'll have test. Also if we produce all five formats, then we need to explain what each one is. If the biosketch is too complex for RTF then have to do another format. Would be helpful to place an icon next to link. Similar to how DaFIS does because users are used to RTF on DaFIS. Put the icon next to link, don't make icon the link.
  • What does Banner do for reporting? Only has limited reports. SIS-DS serves ORMP mostly. Reporting/transcripts is a data access issue. OUR wants to control the transcripts.

Kuali Days (held in May 2008)

  • Kuali has lots of interesting modules. The most relevent to MIV is the KEW (Kuali Enterprise Workflow) engine for V3 (Workflow and Role Mgmt). Kuali role management is really just a specification right now. There's nothing there yet. The idea is people will take the interface definition and plug into the back-end. We'd be plugging our existing system into that.
  • By the time we work on V3, Kuali will have KIM (Kuali Identity Management). There maybe some lining up with KIM and KEW. Testing KIM reference implementation now. You could take KIM off the schedule without reference implementation for now.
  • Where does AFS team and Middleware overlap? DaFIS is committed to Kuali Financials and is a contributer to workflow. Are contributions needed because campuses are too complex? Probably, you work with basic components and 90% can write their own pluggins. Kuali Finaincials pulled out the infrastructure pieces and those infrastructure pieces became Kuali Rice.
  • Other Kuali efforts include Kuali Research and Administration (uses workflow 1.0 release). And, Kuali student project which is 5 years out but you can pick up modules and use what you want

Discuss guiding principles for evaluating locally developed systems for enterprise use

  • Ran out of time.

Topics for next meeting

  1. Discuss guiding principles for evaluating locally developed systems for enterprise use (continued discussion)