Beyond InfoPath
Upcoming SlideShare
Loading in...5
×
 

Beyond InfoPath

on

  • 835 views

Selecting a better eForms tool

Selecting a better eForms tool

Statistics

Views

Total Views
835
Views on SlideShare
833
Embed Views
2

Actions

Likes
0
Downloads
9
Comments
0

1 Embed 2

https://twitter.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Beyond InfoPath Beyond InfoPath Presentation Transcript

  • Moving Beyond InfoPath SELECTING A BETTER E-FORMS TOOL
  • The Problem  So you have moved beyond the simple InfoPath forms into advanced tasks like:  Have repeating sections within forms with parent, child, even grandchild relationships  Want to report on InfoPath data using tools like SSRS  Want to leverage existing databases/web services for creating rich composite forms
  • What are the options?  Out-of-box approach - create form from SQL database  Customer Code - extend your existing form with custom code  Common Library (Rules) - use one set of rules for all forms  Business Connectivity Services - connect external data systems  Custom Web Service - middle-tier service-oriented architecture View slide
  • Obvious Choice – Submit Data to SQL Server  SharePoint lists/libraries don't scale  Document permissions (ACLs) peter out at 5,000 items  View performance degredation after 10,000 items  SharePoint protocol (DAV) is slow  Limited reporting options   Export to Excel is two dimensional, Performance Point is hard to figure out Relational databases (SQL) enable enterprise scenarios  Central data in one place  Easier to: backup, replicate, repurpose across sites, migrate, integrate with other systems, etc.  Reporting: build dynamic reports with Reporting Services  Performance: filtered queries are faster through SOAP View slide
  • Out-of-box Database Template  Cons   Doesn't work in a browser (because of double hop authentication issue)  Limited data types - must conform to SQL data types   Can't use with existing forms Schema change requires down time Pros  Works out-of-box
  • Out-of-box Database Template
  • Out-of-box Templates
  • Custom Code in the Form  Cons  Developer required and browser support requires admin deploy  Tightly coupled solution cannot be reused for other InfoPath templates  Brittle - breaks easily when database schema changes  Expensive - downtime when form datasource changes  Not Best Practice - SQL command cannot be parameterized  Security risk - however, developer can easily "escape" fields to prevent SQL injection   Pros  Works with existing databases  Does not require deploying a web service
  • Common Library  Code required for advanced operations  Copying, sorting tables  Converting images to links  Integrating with lists  Submitting to a SQL database  Code will be hardcoded to schema of form  Writing code requires a developer  Maintaining separate DLLs is costly
  • What is a common library?  No developer required  Inject library in form template  Use commands via rules  Data-driven commands  Same library for all templates  Less cost to deploy and maintain
  • Business Connectivity Services  Cons   Doesn't support repeating data  Doesn't support certain data types (for ex: bigint)  Stored procedures needed for query performance (to reduce result sets)  CRUD XML is complex   Authentication configuration required Adding fields requires lots of wizard time to reconfigure and doesn't update list editor (i.e. you have to create a new list) Pros  Works with existing databases  Provides list-based editing for data
  • Custom Web Service  Cons   Parameters most likely hardcoded to form template  Web service must be deployed   Developer required Proliferation of Web services complicates migration Pros  No code in form  No code in DB  Fast queries
  • Data-driven Web Service  All InfoPath templates use the same web service  All query shapes use the same web service  SQL to XML mapping defined in dynamic query string  Web methods take XML data to query SQL tables  User impersonation means SQL permissions can be defined to lock down users
  • qDabra Data-driven Web Service (DBXL)  Cons    Web service must be deployed to server More work to configure with existing databases Pros  Single web service supports all form templates  Works with existing forms  No code in form, no code in DB  Fast submits (and queries)  No downtime when schema changes  Less cost to deploy and maintain