Qdabra qRules

Re: Injecting qRules causes errors when trying to publish a browser enabled form to SharePoint

preimer — Thu, 19 Jul 2012 16:14:17 GMT

I have had a chance to try out the script that was posted by Jim and it remedied the problem. As you mentioned, we are considering going with an admin-approved deployment given the nature of the script but for the moment, the script will allow us to continue working. Thank-you both Hilary and Jim.

Re: Injecting qRules causes errors when trying to publish a browser enabled form to SharePoint

Hilary Stoupa — Thu, 19 Jul 2012 00:01:40 GMT

I asked Jim to chime in, because I thought we had seen this before - as you saw with testing, the issue is with resources for the Sandbox being exceeded when the form is published, whether with qRules or with code.

You may want to try admin approving the form. If that isn't possible in your environment, Jim has also posted a script that will increase these resources - but you'd need an admin to take care of that as well (at which point, perhaps admin approving the form will be a viable option).

Re: Injecting qRules causes errors when trying to publish a browser enabled form to SharePoint

preimer — Wed, 18 Jul 2012 23:30:32 GMT

I apologize for not being clear previously. The answer "yes" applies to both of the previous questions that you asked. (Do you have other forms with qRules published as Sandboxed browser forms? If you take a new, blank form and inject with qRules does it Sandbox?) I just tried your suggestion of taking a form that has a problem with qRules, removed qRules from the form, added an empty code-based "form loading event" and tried to deploy. It appears that the deployment failed in exactly the same way as with qRules injected.

Re: Injecting qRules causes errors when trying to publish a browser enabled form to SharePoint

Jim Cantwell — Wed, 18 Jul 2012 23:16:23 GMT

There is often a combination of limits that prevent publishing forms in the sandbox. While only 10% of the publishing time may be related to the code, the time required to process the views contained in the xsn contribute to the overall overhead. So forms with more views may see this problem with a minimal amount of code. The only way to work around this is to reduce the number of views, or increase the sandbox limits.

Below is one script to increase the values, the second to restore back to default levels after publishing. The “SharePoint 2010 User Code Host”service needs to be restarted after running the script. The script only needs to be run once, but the "SharePoint 2010 User Code Host" service must be restarted on all servers in the farm where the service is running.

This numbers are probably overkill, but we went over what we expected it to need to successfully publish

# THESE LIMITS SHOULD ALLOW TO PUBLISH YOUR FORM

$spCodeService = [Microsoft.SharePoint.Administration.SPUserCodeService]::Local

$cpu = $spCodeService.ResourceMeasures["CPUExecutionTime"]

# NOTE THE VALUE BEFORE THE UPDATE TO RESET LATER

$cpu.AbsoluteLimit

$cpu.AbsoluteLimit = 600

$cpu.Update()

$cycles = $spCodeService.ResourceMeasures["ProcessCPUCycles"]

# NOTE THE VALUE BEFORE THE UPDATE TO RESET LATER

$cycles.AbsoluteLimit

$cycles.AbsoluteLimit = 2000000000000

$cycles.Update()

# NOTE THE VALUE BEFORE THE UPDATE TO RESET LATER

$spCodeService.WorkerProcessExecutionTimeout

$spCodeService.WorkerProcessExecutionTimeout = 600

$spCodeService.Update()

# "SharePoint 2010 User Code Host" must be restarted in the services applet

After publishing, run this script

# RESET LIMITS TO DESIRED DEFAULTS

$spCodeService = [Microsoft.SharePoint.Administration.SPUserCodeService]::Local

$cpu = $spCodeService.ResourceMeasures["CPUExecutionTime"]

# RESET CPUExecutionTime to normal running level (60 is SharePoint default)

$cpu.AbsoluteLimit = 60

$cpu.Update()

$cycles = $spCodeService.ResourceMeasures["ProcessCPUCycles"]

# RESET ProcessCPUCycles to normal running level (100000000000 is SharePoint default)

$cycles.AbsoluteLimit = 100000000000

$cycles.Update()

# RESET WorkerProcessExecutionTimeout to normal running level (30 is SharePoint default)

$spCodeService.WorkerProcessExecutionTimeout = 30

$spCodeService.Update()

# "SharePoint 2010 User Code Host" must be restarted in the services applet

Re: Injecting qRules causes errors when trying to publish a browser enabled form to SharePoint

Hilary Stoupa — Wed, 18 Jul 2012 22:57:19 GMT

So, was the "yes" answer to both of my questions? You can sandbox other forms with code or qRules, but you can't sandbox large forms with qRules / code.

I think it would be good to take a copy of a form that won't sandbox with qRules in it and add custom code - see if it will sandbox then. Just go to the Developer tab and add a loading event and see what happens.

Re: Injecting qRules causes errors when trying to publish a browser enabled form to SharePoint

preimer — Wed, 18 Jul 2012 22:43:41 GMT

Yes. From looking at the logs, it does appear that once qRules is injected, the form is considered to be a Sandbox form. I just tried it with a new blank form and injected qRules. We are starting to notice the problem with some of our other forms now. There seems to be some correlation between the size of the form and the frequency of deployment failures. As our forms get larger in size and more complex we start to see the issue. The file size where the problem starts to occur intermittently is around 170-180Kb. When the size of the file is around that size, the deployments fail every once in a while. As they get larger, they fail more often, until eventually the deployment fails every time. Paul

Re: Injecting qRules causes errors when trying to publish a browser enabled form to SharePoint

Hilary Stoupa — Wed, 18 Jul 2012 22:14:11 GMT

Hi -

So you know, if the form does not have code in it when you publish it, it won't be going into the Sandbox. No need, since there is no code.

Do you have other forms with qRules published as Sandboxed browser forms? If you take a new, blank form and inject with qRules does it Sandbox?

Injecting qRules causes errors when trying to publish a browser enabled form to SharePoint

preimer — Wed, 18 Jul 2012 21:58:33 GMT

We are running into an interesting issue when trying to deploy an InfoPath 2010 browser enabled form to a SharePoint 2010 form library. When we perform a Sandbox deployment of the form without qRules inject, the deployment goes as expected. Once qRules is injected and the form is redeployed, the deployment fails and produces an error message with a message indicating that "there was a problem with the deployment and the form can only be opened using InfoPath Filler". At this point the form is not making use of any qRules functionality. It has only been injected. Other similar browser enabled forms with qRules injected do not produce this behaviour. When we looked in the SharePoint ULS logs we found the following error(s): - - The worker process executing this request was killed because it exceeded the resource ProcessCPUCycles. - userCodeWrapperType.FullName = "Microsoft.Office.InfoPath.Server.Host.FormServerUserCodeWrapper", userAssemblyGroup = ".UserCodeAssemblyGroupId = ", GroupId = "6ED9B8C4235B46E09EAE91625BD5AFAF-YAjVK7TlRPUvYr43ZSYCuyjT5WdU8uGR+k4u9DPg+jg="", .RootDirectoryPath = "C:\ProgramData\Microsoft\SharePoint\UCCache\8CF32E47E5D68C7\6ED9B8C4235B46E09EAE91625BD5AFAF%2DYAjVK7TlRPUvYr43ZSYCuyjT5WdU8uGR%2Bk4u9DPg%2Bjg%3D-2"", siteCollectionId = a3af6549-3f23-46d1-80f4-4d50d773ad18, executionContext = "Microsoft.Office.InfoPath.Server.DocumentLifetime.RemoteConversionContext We have upped the settings for the SharePoint 2010 Sandboxed Code Host process, but this has had no effect. Any ideas on what we can do to resolve this issue? Does the size and/or complexity of the form in question with qRules injected have an impact on Sandboxed form deployment? Thanks, Paul