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 Project Manager, Form Developer, Now – the Resource Getter, Direction Setter, Barrier Jumper, and Integrator

The University of Arizona Liz Taylor Original Project Manager, Original Form Developer Now – Resource Getter, Direction Setter, Political Barrier Jumper, and Integrator Director, Computing Systems, Financial Services

The University of Arizona Down the road about 90 miles and 10 degrees cooler! Research I Institution 33,000 Students 12,000 Faculty and Staff The one with THE basketball team!!

eForms: an eSolution to Handling Business Forms 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.

eForms: an eSolution to Handling Business Forms 5 Informal (Working Session)– Ask Questions, Interrupt us Talk about our quick-win, weekly deliverables plan It’s really simple and relatively cheap – not rocket science Share what we have – really – call us, us – we want to share our experience and/or our code! Presentation Goals

eForms: an eSolution to Handling Business Forms 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 that’s taking too long – Typewriters!!! LEAVE NOW – YOU SHOULD BE GOLFING!!

The University of Arizona Kymber Horn Form Developer, Professional Diplomat, Organizer, Why Asker Applications Systems Analyst, Sr.

eForms: an eSolution to Handling Business Forms 8 Presentation Outline What is eForms? Why did we do it? How did we do it - approach? How did we do it – technically? What’s Next? Issues and Challenges we faced

eForms: an eSolution to Handling Business Forms 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 Workflow and mainframe integration

eForms: an eSolution to Handling Business Forms 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 (it’s 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.

eForms: an eSolution to Handling Business Forms 11 Short phases, quick results Our Objective: Provide near-term relief to departmental financial managers pending long- term solutions. Identified five-phases.

eForms: an eSolution to Handling Business Forms 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 . Phase IV – – Simple 2-stage workflow Phase V – – Integrate or replace w/ full re-engineering projects.

The University of Arizona Andrew Hollamon Super Coder, Infrastructure Guru, Ubiquitous, Persistent Dude Applications Systems Analyst, Sr.

eForms: an eSolution to Handling Business Forms 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

eForms: an eSolution to Handling Business Forms 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

eForms: an eSolution to Handling Business 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.

eForms: an eSolution to Handling Business Forms 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.

eForms: an eSolution to Handling Business Forms 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).

eForms: an eSolution to Handling Business 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.

eForms: an eSolution to Handling Business Forms 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.

eForms: an eSolution to Handling Business Forms 21

eForms: an eSolution to Handling Business Forms 22

eForms: an eSolution to Handling Business Forms 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’

eForms: an eSolution to Handling Business Forms 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.

eForms: an eSolution to Handling Business Forms 25 Second Generation Toolset Core Issues Not Solved by 1 st Generation – Sensitive Client Installation – Inelegant interaction with the browser – Could not save completed forms – Could not easily refresh forms Solution: 3 rd 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 Reader’s Save Problem – Allowed us to bypass Acrobat Reader’s Caching Problem – Component paid for itself very quickly by drastically reducing support costs

eForms: an eSolution to Handling Business Forms 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.

eForms: an eSolution to Handling Business Forms 27

eForms: an eSolution to Handling Business Forms 28

eForms: an eSolution to Handling Business Forms 29 What’s Next: Snap, Crackle, Pop! Interactive, wizard-style interface to eForms. Permanent server-side storage of forms. 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.

eForms: an eSolution to Handling Business Forms 30 Issues & Challenges Technical/Infrastructure Issues The Economics of eForms Business Issues

eForms: an eSolution to Handling Business Forms 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.

eForms: an eSolution to Handling Business Forms 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.

eForms: an eSolution to Handling Business Forms 33 The Economics of eForms Using 1 st generation, low up-front costs, but high support. Using 2 nd 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.

eForms: an eSolution to Handling Business Forms 34 The Business Issues Multi-copy Forms Numbered Forms Education/Communication Culture Changes

eForms: an eSolution to Handling Business Forms 35 Q & A Andrew Hollamon - Kymber Horn – Liz Taylor –