InfoPath Dev

Can someone at Qdabra give be a quick overview of the tools you guys offer. Mainly, Database Accelerator and qRules. I couldn't find a comparison on the product pages. I saw and tested Database Accelerator already and like the ease of what it does but have not gone too deep into it. However, I understand you guys have qRules which does the same thing? My scenario: We have forms and lots of them that we will be converting to Infopath with Sharepoint integration. All of these will have a non-standard workflow that will require Visual studio. They will also have custom codes as well as call many other webservices to pull data. Ultimately, once all data are pulled and forms are approved by multiple managers, supervisors, revisions and entities and it will be saved both to sharepoint list and =>>> shredded to sql server for data analysis. Can someone tell me how I can use your tool or set of tools can help us do this. Whether I need DBXL or qRules (both) or whatever else you guys have. thanks.

Qrules embedds code in your template/form(.xsd)  It eases some of the custom code development.  I find I can accomplish most of what I want without add my own code.  Basically a function library.  An enhancement for the form development.

DBXL process the resulting documents/data (.xml) generated by your template/form into SQL Server tables.

Thanks Marzipan!

Hi Mike,

• qRules is a common code library that we first created in 2008. We release updates every quarter. 
• Many forms need a little bit of extra functionality which requires code.
• One problem with extending InfoPath is that it requires a developer.
• Another problem is that developer will give you a solution which is specific to one form;
• qRules solves both problems because it's a generic common library. You use it in all your forms. No developer, no maintenance nightmare.
• DBXL is a Web service that we created in 2004. It is in it's 8th year. We release two updates per year.
• InfoPath browser forms need a Web service to submit to a SQL database. In addition, using fields to filter SQL database queries cannot be done unless you write code. 
• Same issues as above when writing code to extend a form - you need a developer and they will develop a specific solution that cannot be reused.
• In addition, there are many gaps in SharePoint (permissions, migration of forms, form-to-form connectivity, offline synchronization for form libraries, etc.) that we have filled.
• DBXL solves these problems and fills many gaps in SharePoint. Indeed, it can be used without SharePoint to store forms in a database enabling many advanced form-to-form scenarios.

I would be very happy to present a short 20 minute demonstration for you. We have a weekly webinar on qRules (Thursday, 8am Pacific). We are starting a weekly DBXL webinar soon.

Thank you for your interest.

Patrick, thanks for the response.

I had been reading some of the instructions manual on setup of the tools and have two questions.

1. What is my limitation as far as setting up the tool in an integrated mode versus side by side. I believe in the Sharepoint integration instructions, the integration into sharepoint is one of them if you want to set them up side by side. Also, IPFS is not possible with side by side UNLESS you have SP2010? I know that it matters as far as the form with codes or not. If you can fill me in so I can sound intelligent trying to explain it to another..:-)

2. As far as the database it's shredding to...the DocId(Int) is required in the main table. A user filling the form actually create a unique number (UniqNum - String) for the form in which we use as the form identifier. Does anyone have any suggestions as far as ensuring form uniqueness in DBXL as well as sql server taking the DocId into account.

In my testing of DBXL, if I had the same form filled open after the user submit. I noticed that DBXL create a new document with a different DocID, however the unique number (UniqNum) the user entered is the same. I want to ensure that it does not allow a user to submit or shred to a different DocId if this unique number (UniqNum) is the same. I am assuming when it creates a new DocId for the same open form is a matter of configuration, but how can I take into account with the (UniqNum).

I am just trying to create a prototype to show that this tools works in our environment so I can wow them to buy the tool....thanks

System setup: We are starting from scratch with all new form conversion. Infopath 2010, SP2010 Our forms call other webservice and will contain Workflows and more than likely contain codes.

Thanks for the great questions.

1. Integrated vs. Side-by-side
• Integrated is easier to configure and supports dynamic permissioning for browser-based forms using data views. You can set up a data view that shows only the forms a user has permission to see. This is done by having the data view call one of the DBXL Web services. Top open the forms in the browser does require a separate form configuration to open in place and pull the XML from the Web service.
• Side-by-side is meant for those who cannot install the Web service on the SharePoint box. Basically, the forms get submitted to both SharePoint and DBXL. To keep things in synch, we've created an XML Template Part (XTP) that you can easily add to your form to enable logic around submit. To get IPFS to submit to a Web service on a different machine requires UDC files and those have to be configured to submit using a system account (like Network Service) because IPFS doesn't forward credentials. I think you might be able to set up SSO or Kerberos to do this but I'd have to check with my support team. Using a default system account will work, but obviously won't give you dynamic control over permisions.
• Of course, you could create a Workflow to submit to DBXL too. Key thing is to configure DBXL to map back to SharePoint so that the XML forms have DocIDs in them (necessary for updating previously saved rows in the DB). Data views get around this by using links and passing input parameters to InfoPath, in effect telling it which item to open.
2. Form Uniqueness
• Kaoru actually published a nice blog on this recently: http://www.infopathdev.com/blogs/kaoruo/archive/2011/08/26/use-qrules-to-create-unique-form-names.aspx

When submitting a new form, you'll want to either a) close the form on submit, or b) use qRules with SubmitToDBXL. The latter will inject the DocID in your form allowing multiple saves for new forms.

That's great. Please let us help you with the WOW. Just send email to Support (at) Qdabra (dot) com if we can help you do anything to enable your killer demo.

System setup: sounds good. Lots of people doing the same thing. :)