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 - PowerPoint PPT Presentation

1 / 35
About This Presentation
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

Description:

The University of Arizona eForms: an eSolution to Handling Business Forms Andrew Hollamon Super Coder, Infrastructure Guru, Ubiquitous, Persistent Dude – PowerPoint PPT presentation

Number of Views:451
Avg rating:3.0/5.0

less

Transcript and Presenter's Notes

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


1
The 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
2
The 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
3
The 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!!
4
Who 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.

5
Presentation 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!

6
Anyone 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!!
7
The University of ArizonaKymber HornForm
Developer, Professional Diplomat, Organizer, Why
AskerApplications Systems Analyst, Sr.
Email kymber_at_u.arizona.edu
8
Presentation 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

9
What 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

10
Why 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.

11
Short phases, quick results
  • Our Objective Provide near-term relief to
    departmental financial managers pending long-term
    solutions.
  • Identified five-phases.

12
Short 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.

13
The University of ArizonaAndrew
HollamonSuper Coder, Infrastructure Guru,
Ubiquitous, Persistent DudeApplications
Systems Analyst, Sr.Email Hollamon_at_arizona.edu
14
How 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

15
Project 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

16
Our 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.

17
Requirements
  • 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.

18
Requirements
  • 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).

19
What 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.

20
What 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)
23
Hard 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

24
FDF 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.

25
Second 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

26
Third 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)
29
Whats 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.

30
Issues Challenges
  • Technical/Infrastructure Issues
  • The Economics of eForms
  • Business Issues

31
Infrastructure 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.

32
Infrastructure 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.

33
The 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.

34
The Business Issues
  • Multi-copy Forms
  • Numbered Forms
  • Education/Communication
  • Culture Changes

35
Q A
  • Andrew Hollamon - Hollamon_at_arizona.edu
  • Kymber Horn Email kymber_at_u.arizona.edu
  • Liz Taylor Email lizt_at_arizona.edu
Write a Comment
User Comments (0)
About PowerShow.com