InfoPath Dev

I had Downloaded Qrules7.2 version from your website. It is going to expire on 15th March2016. I had injected Qrules in to my infopath 2010 template. while inject chosen Browser , infopath 2010 and Sandbox (donot want Admin-deploy). We are looking ot purchase this tool(Qrules 7.2) officially , if my proof of concept (POC) went well. Getting Error: "The form template has been published to the server but it can only be opened in the infopath filler because it contains features that are not compatible with web browsers " Need your urgent and immediate response.

Hi - I replied to your email to support with this information as well - the first thing to verify is that you are a site collection admin and the form is injected with the Sandbox / Browser option selected.

I'm having the same problem with a SP2013/InfoPath 2013 browser form.  I injected it with qRules 7.2, using the site collection admin user account.  This is a 2013, browser, sandboxed and I get the exact same issue.  the qRules injection process turned the form into a filler form.  

 I cannot have this happen - cannot be injected..  I will ask for a refund.

I would send the form, but it is too big to attached. 

 Hey, Laurie - so I think you are saying you are getting the same compatibility error as the original poster when you publish to a form library - is that correct? qRules doesn't change the compatibility on your form (it doesn't turn a browser form into a filler form) but it does add code. Forms with code have different requirements when published to a form library - namely, the sandboxed code service must be enabled, and the user publishing needs to be a site collection admin. You mention that you used the site collection admin account when you injected the form - you need to use it when you publish the form. Let me know if you used that account when publishing, and if you need any help checking that the sandboxed code service is running.

I'm also attaching a form template you can use to verify you can publish a form  with code to a library - it just has a single line of code that sets the only field to "hello" when the form loads. When you go to publish it to a test library, it will pop up a dialog asking if you want to browse to the source code files - you can just click ignore and continue with the publish process. It should give you a better error message if there is some reason that you can't publish a form with code directly to a library on your server.

If it publishes successfully, there may be something else in the form that is an issue - the sandbox in SharePoint is restrictive, and once a form has code, unless it is admin approved, it goes in the sandbox. But these are the first steps I would take to debug the issue.

Of course, if you prefer a refund, contact support AT Qdabra DOT com and someone will assist you.  You can also send your form and I can publish it to one of our test servers to see if the issue is in the form itself.

 I published the form you sent to the library, and I didn't get any popup when I went through the publishing process.  When I opened the form, I did get the hello box.

I would be happy to email you the form, I cannot attach it (it exceeds the limits of attachments allowed - 262KB).    Up until the time I injected the form, it has been publishing as a browser form just fine.

This is the final dialog box after I publish the form.   I have unchecked the Store data returned from queries in offline mode now.  The screen shot is before I made the change.  Do you think this would cause the issue after injection?

 

 

Design Checker:

 

 Hilary,

Would the fact that my form has a call to 'GetUserProfileByName' data connections, and because we are claims, there is a UDCX file, and a secure store app.  Will qRules 7.2 have an 'issue' with this?  Will I need to refactor my form to use qRules for this purpose? I read in the instructions that the form would have to be deployed through central admin to use qRules for GetUserProfileByName.  Really wanting this Sandboxed.

Which we do have that service turned on. 

I was able to remove all of the promoted fields and get the file size down to attach it.

My simple Proof of Concept form for saving attachments, published to our site without an issue.  It doesn't contain a connection to retrieve user information from the UPS.

 

If your test form sandboxed, then we know you have sandboxing service on, and you published as a site collection admin. I'll try this form against one of our servers this morning and see if I can see why it won't sandbox.

 I have qRules forms that use GetUserProfileByName and use UDCX - SharePoint 2013 - and they are browser compatible. Your form published as a browser form to my server (see attached screenshot). I wonder if it might be timing out when publishing to yours - we have probably extended the timeout for the SPUserCodeService on our server.

A few things you may want to try - save a copy of the form, and remove a few views to make it smaller - see if it publishes. You can also run Fiddler while publishing to see if you can get back better error info, or you can try to publish and then check the ULS logs on the server for more details on why the form is failing as browser compatible. I can provide you with more info on using Fiddler, if you need a little help with that. I can also provide you with a PowerShell script that will extend the SPUserCodeService timeout, if that is the issue.

Since you have a test form that sandboxes successfully, you could add the data connection that concerns you to that form, and see if the test form still publishes - that would help rule that out (or in, because as you know, there are an infinite number of possible configuration differences between your server & mine...) 

 I noticed the form I sent you was not injected yet.  Did you inject it with qRules and try to publish it.   Once it injected it is too big to attach to the forum.

If you can send me the info to using Fiddler that will help, and for extending the timeout of SP UserCodeService.  Since I sit in a different location than the actual server - there could be a issued.   It takes me 3 minutes to publish the form up to SharePoint when I do it.... we have a pretty full internet pipeline.

Oh - that explains it - I had assumed it had qRules in it. I'll re-inject and try again. I emailed you on Fiddler earlier, and I'll post the PowerShell script here after I test the form again w/ qRules.

 I'm attaching the script as a text file - it needs to be run from the server in SharePoint Management Shell - it has comments on what it is doing. I've been randomly removing views from your form to see at what point it will publish to the sandbox - I'm trying to see if there is a specific view causing the issue. So far, it seems purely size related - that is, once I remove 3 or 4 views, it will publish as browser enabled.

Obviously, you need all the views in your form - otherwise you wouldn't have created them - but if sandbox is a requirement, you may need to get the size down, even if you extend the timeout. 

I have the same errors with the Timeout. 

So…   what about promoted fields to SharePoint columns? 

Right now, there are over 150 fields getting promoted to SharePoint columns (none are editable).  I’m sure that as well will have an impact - removing then reduced the file size by more than 100KB. 

 

The copy I uploaded to the forum - I removed them for testing purposes.  – If I used additional data connections and qRules to have the forms data published to a SharePoint list, and called back into the form when needed.... will that eliminate promoting not so many columns?

I merged view 02 & 04 since are from the same ‘node’ within the form.   Debug, and email distribution can go.. that makes (3), taking Print View out is 4.   Form's file size is down from 406KB to 337KB - but still will not publish as a sandboxed browser form.  I will try extending the timeout on a test server with this modified version and see what happens.

If this was a centrally deployed form.. would this issue still exist? Don't want to go that route, but might have to given the complexity and size of the form.  There will be at least 3 sites using this template.

 

With a form this large and complex, I'd certainly give admin approving a try. I'm trying it now on our test server & I'll let you know the outcome.

Okay - I was able to admin deploy this form & activate to a site collection on my test server - so if this is a possibility for you, I'd certainly recommend giving it a try.

Just wanted to follow up - were you able to try an admin deploy approach?