Beyond InfoPath

Uploaded on

Selecting a better eForms tool

Selecting a better eForms tool

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Moving Beyond InfoPath SELECTING A BETTER E-FORMS TOOL
  • 2. 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
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. Out-of-box Database Template
  • 7. Out-of-box Templates
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. 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