InfoPath Dev

Hello there,

I am building out some forms at my current company and they have a licensed copy of Qrules 7.1. They have an O365 (SharePoint online) tenant with E2 licenses.

 One of the business requirements has been easily satisfied using Qrules with browser-enabled form library forms and repeating sections. Everything works fine, however the load time of the form(s) is between 20-45 seconds even if all form load events and data connections are turned off.

As a further test I created a basic form library and created a simple InfoPath form that renders instantly in the browser, until I inject it with Qrules. Is there anything that can be done about the load time of an injected form?

I realize that postbacks will always be slow but the users are not going to enjoy waiting nearly a minute for a form to load, then another delay on any postbacks(if enabled).

Any suggestions?

 - James 

 Hi - I'd love to see if I can repro this (the load time issue) on our Office 365 site. Can you either attach your test form under Options or email it to Support AT Qdabra DOT com and reference this thread?

Thanks! 

Hilary,

I will attach 2 simple test forms I created, one is pre-injection. Injection obviously increases the size of the form as expected, but the performance hit (while browser rendering) seems unusually high.

The performance its exhibiting is tolerable but once it has any substance it will only get worse (unless it has no injection, then I can put all kinds of data and rules before it slows down). One thing I noticed is that even switching between views takes much longer than expected. On the pre-injected form I can switch back and forth probably 8-10 times before the injected form changes once.

I love the functionality/ease of use Qrules provides but as it stands the various forms I built for the business are almost unusable in the browser, while lightning quick in the client. I appreciate any suggestions you can provide.

- James

 Thanks for the samples - I'll take a look later today and get back to you. All forms with code (or qRules - either way, they end up in the Sandbox) are slower to load in the browser than forms without code - the Sandbox is the culprit here. But it sounds as if you are experiencing much worse Sandbox related slow down than I've been seeing in browser forms on prem on in Office 365. So - I'll publish up to one of my O365 sites and see what the times look like. :)

Hilary Stoupa:

 Thanks for the samples - I'll take a look later today and get back to you. All forms with code (or qRules - either way, they end up in the Sandbox) are slower to load in the browser than forms without code - the Sandbox is the culprit here. But it sounds as if you are experiencing much worse Sandbox related slow down than I've been seeing in browser forms on prem on in Office 365. So - I'll publish up to one of my O365 sites and see what the times look like. :)

 Thanks Hilary. I appreciate it.

- James 

 Okay - I am (unfortunately) not seeing the same thing in my Office 365 site. I had to kill the data connections in your form samples because I don't have a the same list (of course) - but my loading time for no qRules was about 2.36 seconds, and with qRules it was 2.58 seconds. View switching was also comparable - with no rules my view switches varied from about 1.3 to about 1.95 seconds and with qRules, I was seeing about 1.3 to about 2.0 seconds. I did have some switches that were very fast in both forms, and also had moments in both forms where things seemed to take longer. Would you like a sample form with a line of code (so it goes in the sandbox) to see if you have the same results with it?

 Hmm, yes I would like that sample. View switching no qRules was about the same as yours and with qRules would take 9-15 seconds. Perhaps I will have to contact Microsoft and inquire with them also. I appreciate the assistance!

P.S. Have you had any experience with the "Server Resource Quota" for SharePoint online site collections?

Thanks again for everything,

James 

Try publishing this. It has a single line of code, thus will go into the sandbox. When you go to publish, it will pop up a dialog asking if you want to browse to the code file. There should be an “ignore” button that will allow you to proceed w/ the publication. You can add views, etc - just don't change the name of the field that is in the data source, as it is being set by code when the form loads. I've not made any changes to Server Resource Quota before, no. 

EDITED - Sorry, I seem to have saved this form as filler - you should be able to change to browser and publish tho 

 Thanks Hilary,

I published this with views and such, confirmed it went into the sandbox, and tested. Almost no perceptible difference between this and a form without any code behind. I also retested the qRules injected form I sent yesterday and it also seemed noticeably more responsive (about 2-3 second view switching). It would seem performance is dramatically different based on several factors. It is making me wonder about browser-based form library forms with O365 SP Online.

I asked about the Server Resource Quota because the total resources are based on the user licenses, and we currently only have 20 licenses active.

Thanks again for all your help,

- James 

 Our company isn't very big, so I'd guess we are probably in the 20 licenses or less range - so, the site I tested on is likely similar to yours.... It gets really hard to debug issues on Office 365, especially if you are used to being able to check server logs....