Title: The University of Arizona eForms: an eSolution to Handling Business Forms Andrew Hollamon Super Coder, Infrastructure Guru, Ubiquitous, Persistent Dude Kymber Horn Form Developer, Professional Diplomat, Organizer, Why Asker Liz Taylor Original
1The University of ArizonaeForms an eSolution
to Handling Business FormsAndrew HollamonSuper
Coder, Infrastructure Guru, Ubiquitous,
Persistent DudeKymber HornForm Developer,
Professional Diplomat, Organizer, Why AskerLiz
TaylorOriginal Project Manager, Form Developer,
Now the Resource Getter, Direction Setter,
Barrier Jumper, and Integrator
2The University of ArizonaLiz Taylor Original
Project Manager, Original Form DeveloperNow
Resource Getter, Direction Setter, Political
Barrier Jumper, and Integrator Director,
Computing Systems, Financial Services Email
lizt_at_arizona.edu
3The University of ArizonaDown the road about
90 miles and10 degrees cooler!Research I
Institution33,000 Students12,000 Faculty and
StaffThe one with THE basketball team!!
4Who is Financial Services Computing
- Team of 10 Bright Rebels and Innovators
- 1 Director
- 1 Technical Mad Scientist
- 2 analysts/developers (Kymber and Andrew)
- 1 Systems Person
- 1 Staff Development Expert
- 2 Desktop Support gurus
- 2 Students
- Report to Assistant Vice President for Financial
Services - Core Services
- Desktop support and staff development for 180
people - eBusiness development
- Focus on the administrative/financial side of the
University of Arizona.
5Presentation Goals
- Informal (Working Session) Ask Questions,
Interrupt us - Talk about our quick-win, weekly deliverables
plan - Its really simple and relatively cheap not
rocket science - Share what we have really call us, e-mail us
we want to share our experience and/or our
code!
6Anyone in the room who DOES NOT have at least one
of these problems
- Duplicate data entry
- Physical routing of forms
- Physical signatures
- Legacy Systems with batch interfaces
- Too many forms
- Reengineering thats taking too long
- Typewriters!!!
LEAVE NOW YOU SHOULD BE GOLFING!!
7The University of ArizonaKymber HornForm
Developer, Professional Diplomat, Organizer, Why
AskerApplications Systems Analyst, Sr.
Email kymber_at_u.arizona.edu
8Presentation Outline
- What is eForms?
- Why did we do it?
- How did we do it - approach?
- How did we do it technically?
- Whats Next?
- Issues and Challenges we faced
9What is eForms?
- For the Customer
- Seamless web-enabled front-end
- Provides one-stop shopping
- Departmental business managers
- 140 business forms
- Technically
- On-line forms system
- Infrastructure that leverages
- Standard desktop tools
- eMail
- Workflow and mainframe integration
10Why did we do it?
- We have a vision of eBusiness by 2005
- Web Forms
- Self-Service
- Workflow capabilities
- Business rules written to the system processing
software - Electronic Reporting
- Over 140 forms
- Three mainframe legacy systems - MAY never be
replaced (its far enough out we need to do
something now) - In March, 2000 Business Operations Committee
(BOC) identified a priority to transition from
paper forms to electronic equivalents of those
forms.
11Short phases, quick results
- Our Objective Provide near-term relief to
departmental financial managers pending long-term
solutions. - Identified five-phases.
12Short phases, quick results
- Phase I
- Inventory and consolidate forms
- Allow for printing only
- Routing using current business practices
- Phase II
- fillable forms
- Phase III
- XML-based forms
- data-enter-only-once-ever
- manually routed via email.
- Phase IV
- Simple 2-stage workflow
- Phase V
- Integrate or replace w/ full re-engineering
projects.
13The University of ArizonaAndrew
HollamonSuper Coder, Infrastructure Guru,
Ubiquitous, Persistent DudeApplications
Systems Analyst, Sr.Email Hollamon_at_arizona.edu
14How Outline of Technical Aspects
- Project Assumptions Current Situation
- Our current environment, platform, and in-house
skill sets - Requirements Analysis what do we need?
- What we chose First Generation Toolset
- Hard Lessons Learned the limitations of our
original toolset - Second Generation Toolset ActivePDF
15Project Assumptions
- Need to automate business processes
- Need to move to eBusiness services
- Assume the legacy Enterprise Apps are here to
stay - Need to provide relief in some key areas
- Redundant Data Entry
- Math errors (up to 75 of forms have math
errors)! - Physical routing archival of forms
- No information about status of documents
- No formalized authority approval structures
- Huge amount of man-hours to process paper forms
16Our Development Environment
- Our production environment is the result of a
recent migration to new platforms - Windows 2000 w/ COM
- IIS5 Web Servers w/ Active Server Pages
- SQL Server 2000
- Our in-house skill sets
- VB6/COM, Active Server Pages/IIS
- SQL/T-SQL/DTS
- Perl, JavaScript, HTML
- This could be developed on Unix or Windows, using
J2EE, PHP, ColdFusion, ASP, etc.
17Requirements
- MUST be web-based.
- Delegated Administration Administration of
Forms must be done by the Forms Owners, NOT the
IT group. - Low Maintenance Must not require client
deployment. - Platform Agnostic Must support all reasonable
platforms environments. - Usable Output Any data produced must be
portable, interoperable, and agnostic.
18Requirements
- Agile Underlying Infrastructure must be dynamic
and agile enough to evolve over time to a full
eBusiness environment. - Developable Must fit in easily with existing
platforms, environment, and in-house skill-sets. - Consistent Must match existing policy
practices (numbered forms).
19What we chose
- Adobe Acrobat Reader, FDF Toolkit delivered in a
web app. - Adobe Acrobat Reader for client viewer.
- It is ubiquitous, and available for most
platforms. - Form Owners can create their forms in almost any
format. - Almost any document can be easily converted to
PDF format. - Retains exact original formatting layout for
printing. - Adobe FDF Toolkit allows server-side form field
population. - Custom Components for pre-fills numbered forms.
- Database holds form Meta-Data, NOT the forms
themselves.
20What we chose continued
- These options translate into the following
application specs - Active Server Pages on IIS to do the
presentation. - COM COM components do the dirty work in the
mid-tier. - SQL Server stores linking meta-data information
about the forms. - Forms are built prepped in Adobe Acrobat
Exchange, and stored as template files on the web
server. - The result is a plain-vanilla multi-tier web
app, which brokers business forms.
21(No Transcript)
22(No Transcript)
23Hard Lessons Learned
- We quickly discovered the limitations of our
original toolset - Installation Issues
- High support costs on client setup
configuration - FDF/Forms interaction was clumsy and inelegant
- Web Link did not always work predictably
- The Saving Problem
- The Caching Problem
24FDF Issues In Excruciating Detail
- FDF Toolkit Flow, very clumsy
- FDF Toolkit produces FDF data stream
- Important to understand, it does NOT pre-fill the
form server-side, and then dish the filled form
to the client. - It produces an FDF data stream, which includes
the link to the form itself, and all the form
fields data. - Browser sees application/vnd.fdf MIME type, and
hands it to the Acrobat Reader to view. - Acrobat Reader invokes Forms plug-in, which
interprets the FDF data. - Forms plug-in then calls back to the server for
the PDF file. - This is an extra round-trip to the server!!
- Forms plug-in takes over the whole browser
window, and ignores any framesets - Forms plug-in opens in the last active window,
rather than the current window. - Forms plug-in fills in the Form Fields on the
client, and displays the filled form.
25Second Generation Toolset
- Core Issues Not Solved by 1st Generation
- Sensitive Client Installation
- Inelegant interaction with the browser
- Could not save completed forms
- Could not easily refresh forms
- Solution 3rd Party Acrobat Component, ActivePDF
- Only required 3.0 or higher client versions of
Acrobat - Did all its work server-side, in memory
- Dished a plain-vanilla PDF doc that did not
require special processing on the client - Allowed us to bypass Acrobat Readers Save
Problem - Allowed us to bypass Acrobat Readers Caching
Problem - Component paid for itself very quickly by
drastically reducing support costs
26Third Generation (projected)
- Used Web Submit functionality in Acrobat
Reader. - Data submitted from Acrobat Reader comes across
in HTTP PUT format. - Server side components digest persist the data
into well-formed XML for durable storage. - Metadata of documents are stored in a SQL
database. - Data can be passed to any system (legacy systems,
external providers). - This process creates a very modular, extensible,
and agile system.
27(No Transcript)
28(No Transcript)
29Whats Next Snap, Crackle, Pop!
- Interactive, wizard-style interface to eForms.
- Permanent server-side storage of forms.
- Email link to a filled-out form to another
person. - Component to convert XML Doc to mainframe batch
feed document. - Authentication authorization system to manage
storage and access to saved eForms. - Simple 2-stage rigid workflow system.
30Issues Challenges
- Technical/Infrastructure Issues
- The Economics of eForms
- Business Issues
31Infrastructure Issues
- Authentication
- Main eForms site is publicly available.
- Only designated people can modify eForms listings
meta-data. - Authorization
- Different forms are owned by different groups and
may need protected administrative access. - One group will need full access, as they act as
the final owner of the site and its contents,
style, etc. - Solution
- We leveraged a homegrown web based infrastructure
that handles authentication authorization,
using a role-based mechanism. - We were able to plug eForms into this
infrastructure to provide these services. - This will allow us to easily move to later phases
which require routing approval.
32Infrastructure Issues, more
- Messaging
- Need automated communication abilities for
Support, Administration, and Announcements. - As we enter later phases with electronic routing
approval, users will need to be able to easily
send their documents to the correct person based
on their role, without knowing precisely who that
person is at any given time. - Messaging Solutions
- Used listservs to meet the communications needs.
- Leverage the user info in the Authorization
infrastructure to send the forms data to the
correct person.
33The Economics of eForms
- Using 1st generation, low up-front costs, but
high support. - Using 2nd generation toolset, support costs drop
to almost nothing. - Maintenance is delegated to forms owners.
- The marginal cost of expanding to more documents
and a wider audience is limited strictly to
hardware expenses. - Deployment of new forms and changes to forms is
fast cheap. - Always have the most recent version.
34The Business Issues
- Multi-copy Forms
- Numbered Forms
- Education/Communication
- Culture Changes
35Q A
- Andrew Hollamon - Hollamon_at_arizona.edu
- Kymber Horn Email kymber_at_u.arizona.edu
- Liz Taylor Email lizt_at_arizona.edu