Beyond InfoPath
Download as PPTX, PDF•1 like•1,029 views
InfoPath has limitations for advanced forms that require repeating sections, reporting on data, and integrating with external databases. Moving data to a SQL database addresses these issues and enables enterprise-level functionality like centralized data storage, improved reporting, and faster queries. A data-driven web service approach allows InfoPath forms to securely submit and query data from any SQL database without requiring custom code or changes to the database schema. All form templates can leverage a single shared service.
Beyond InfoPath
- 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
- 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