I wanted to note a few things I've run into using qRules in Browser forms, along with some troubleshooting ideas.

• Postback - if your form works in client (preview) but not when opened in the browser, check postback on your controls that are setting commands first. Set postback to "Always" on controls that execute qRules commands.
• Errors - put the error node from the QdabraRules data source onto your form, and admin approve (or sandbox) the form again. See if an error is being returned.
• Data Connections - Permissions can be different. If your data connection works in client, it may not in IPFS. Try converting to UDCX (and be sure to approve the UDCX files). If it is a data connection that qRules is using for something, try executing the data connection outside of the qRules command, see if your form shows and IPFS error with a correlation ID you can use to track down the issue in the logs.
• Bubbling - I've had instances where rules on nodes in secondary data sources will fire when an attribute of the node changes, or where rules on a group fire when a new instance of the group is inserted - these can be hard to track down. Try disabling rules on attributes / child nodes and see if your outcome changes. Then you can start planning a work-around.
• Spaces - I saw an instance where a SubmitToSharePointList command failed in the browser because of an extra space at the end of the name of the mapping data connection. In client, the space was trimmed. In IPFS, it was considered to be part of the data connection name, and we had an error about the data connection not existing.

It can be hard to track some of these things down in IPFS - you can't just set a rule on the Command field to pop up a dialog. What I do is add another field, temporarily, and each time the Command (or Error, or whatever field I want to track) changes, set the trouble-shooting field to its current value concatenated with the new value. This can give me a list of commands that have run (or errors that have occurred) and allows me to track back through the logic to find inconsistencies between browser and client.

You may have gotten the feeling from my latest flurry of cranky and short IPFS related posts that I've been struggling with browser forms a bit lately. You would be correct.

I had a 2010 form with code that I published as sandboxed to my SharePoint 2010 install. I was using the userName() function in a loading rule (to set a field to the user's name, of course). My form threw an error on open - you can find a similar issue outlined here. Apparently the necessary SPClaimProviderManager was not available for sandboxed code.

In our environment, the December 2011 cumulative updates fixed the issue.

I don't know about you, but I sometimes ignore the Design Checker in InfoPath - especially when it is throwing an error over some poor expression box (calculated value) that it thinks is bound to a repeating group (what's that about any way? Aren't these things not bound to anything? Isn't that the point?).

Clicking on one of the errors above in my form popped up this dialog:

The text of the error is:
Control binding is not supported

And the message text is:
Binding a non-repeating control to a repeating field or group is not supported in Web browser forms. To fix this problem, remove the control or replace it with a repeating control, such as repeating section or table. 

And one of my calculated values was selected. The cacluated value was displaying data from a repeating node in a secondary data source, but the XPath had a filter on it - only one value was going to be returned.

The form could be admin approved, and opened and ran in the browser without error.

But then, I added a print view to the form. Clicking the Print Preview button in IPFS would not switch to my print view if there were any design checker errors on the view that used the print view.

Gee. I could add a bunch more fields to my main data source to hold the "display" values for all the fields that I needed to be able to show info from my 2DS in this view. That seemed like a horrid idea.

So, I saved the form as source files and took a look at the view - searching for ExpressionBox took me to one of the culprits. There was an "xd:binding" attribute that had the complete XPath for the expression - it was easy to see that the xsl:value-of node would be providing the actual value. Other expression box controls did not have this attribute, so I removed it and saved the view. When I opened the manifest.xsf in design mode, my design checker errors went away, and Print Preview started working as anticipated.

As always, before you save your form as source files and start poking around in them, make sure you have a backup copy.

InfoPath tries to help out with XPath via the UI, but sometimes to be able to accomplish complex conditions, you may need to write your own XPath. A good knowledge of XPath is also useful for qRules commands.

Here are a few online resources I like for getting comfortable with XPath:

http://zvon.org/xxl/XPathTutorial/Output/examples.html
http://www.whitebeam.org/library/guide/TechNotes/xpathtestbed.rhtm
https://www.w3schools.com/xml/xpath_intro.asp
http://msdn.microsoft.com/en-us/library/ms256086.aspx

Forms injected with qRules or that have custom code can be published as sandboxed in SharePoint 2010, if your SharePoint install has sandbox enabled.

However, we are seeing that forms that have a loading event (either from the injected qRules DLL or in the custom code) appear to run under the service account when they first open. This means that a web service returning Active Directory info (like DBXL) may not return the expected results, if any, if the data connection is set to execute when the form loads.

Setting a rule to execute the data connection when the qRules finishedLoading node is set to true (after qRules finishes initializing) also appears to be running under the service account.

Executing the data connection after the form is completely open appears to run under the actual user account - rules could be set to run on the change of another field if GetMyInfo data is needed.

This also means that a SharePoint web service, like UpdateListItems, will use the same service account. So a sandboxed qRules form that is using the SubmitToSharePointList command will show submitted list items as having been created or modified by the service account.

To work around this, you can continue to admin approve your qRules templates. Admin approved forms make web service calls with the credentials of the logged in user.

If you are using SharePoint and InfoPath 2010, you may already have SharePoint's OData services at your disposal. And while with 2010 we now have query fields for list and library data connections, you can go far beyond basic equivalency in your queries with the OData URI conventions. I've got a video up on Channel 9 you can use to get started leveraging this fantastic tool you may not even be aware you have!

If you are using InfoPath 2010 / SharePoint 2010, you may have already realized you can create REST connections that leverage SharePoint's OData service (ListData.svc). And while there is great documentation on the OData URI protocol conventions, I found an amazing (and gorgeous! H-o-t-!) OData browser today. Check it out here - it is called the Sesame Data Browser, and it will make figuring out those queries so much easier.

Just in case anyone else out there finds themselves smacking into the same ole' brick wall I hit today....

If you have unexpected behavior in a browser template with qRules (by "unexpected", I mean "everything works great in client, but the browser is a trip to crazytown") consider the order of your commands.

My scenario was 3 commands on a single button:

1. Delete command to delete weekend days from a group
2. Delete command to delete certain other days from the same group (holidays)
3. SortTable command to sort the parent group of the group affected by the commands in rule action 1 & 2

Finally, there was a rule action to switch views. All was swell in client - but in the browser, I was surprised to see the Delete command in rule action 2 was failing. Or was it?

I removed all the rule actions and added them back one at a time. The Delete command I was suspicious of was working as anticipated....the rows were deleted. But as soon as I added that SortTable command back in - they weren't!

Now, hopefully some IPFS guru out there will correct me if I am completely in the dark, but I suspect this had to do with postback. My button was set to always postback, but I think the postback from rule action 2 wasn't complete prior to the command in rule action 3 running. That is, even though the command worked, and the nodes were deleted, the XML available to the SortTable command was not the latest and greatest.

My solution was to move the SortTable action into its own rule, and run it first, before the deletes. In my scenario, the field I was sorting on and the order of the parent groups would not be affected by the deletion of the child groups in the other rule actions. Your scenario may be different - but if you have odd browser behavior, look to the order of your commands first.

The problem seemed like it would have an obvious answer. I had an XML that had been digitally signed when the InfoPath template was opened in the browser, but that could not be opened with the same form in the client. The helpful error message said:

Simple, right? It seemed that the browser / client thing was probably a distraction -- something easily explainable. I took the template and quickly disabled all the data connections and all the rules. I figured if no rules were executing, nothing would be getting changed. Turning off the data connections should prevent any default values that used secondary data to get updated. As an aside - should you ever need to do such a thing to troubleshoot, first save your template as source files (the usual disclaimers apply) and then open manifest.xsf in a text editor. For those pesky data connections, use Find and Replace to change initOnLoad="yes" to initOnLoad="no". To disable rules quickly, change isEnabled="yes" to isEnabled="no". Use Replace All at your own risk.

That should do it, right? I had the problem XML saved locally, and set it as my preview data, and went to preview my form. Same error. Now what?

Well, obviously, something must be changing. After removing signatures from the XML (which could only be opened in the browser, mind you), I opened it with the client, and saved off the XML. Using a diffing tool, I compared the two XML. Obviously there were going to be some differences -- the processing-instructions, one was signed, one wasn't... but what most caught my eye were differences in the XML markup itself:

Self closing empty tags from the browser XML.

Looking further at the highlighted differences, I also saw one difference from what appeared to be encoding:

from the browser, and

from the client. One is an apostrophe. I remain uncertain as to what the other is.

These were red herrings, my friends. And while I'd love to build up a great deal of suspense to draw you further into my tale of woe, instead, I am just going to tell you what caused the issue.

Division. My old nemesis long division. Apparently browser and client forms don't agree about the number of decimal places. I'd not looked any further at default values, because I'd disabled the secondary data connections. It never occurred to me that a default value based on values in the main data source XML could possibly be different between XML saved in the browser and XML saved in the client. I was so very very wrong.

Here's the browser value:
4.03571428571429

Here's the client:
4.035714285714286

What makes it all the worse? This difference was highlighted by my diffing tool -- but I was so distracted by all the other highlights (the surrounding differences in the XML tags) that I didn't even notice it.

Wouldn't be a story without a moral. Here's what I learned -- I need to be a lot faster to dump my initial assumptions when I'm having issues figuring out a problem. Every time I thought about default values causing this, I brushed the thought aside, since I'd disabled those data connections.

And watch those default values -- especially in signed sections. The defaults were moved to rules instead, and now the signed XML can be opened in client or browser.

The Usual Disclaimers: If you are going to save your template as source files and do any of the risky and sometimes foolish things I suggest, particularly if you are planning on hitting the "Replace All" button, you really should make sure you've saved a copy first.

I've wanted to blog this for a bit, but it finally reached a tipping point this week when I saw that two posts on the forum and an email in my inbox all needed a hand with the same subject.

You can't work with InfoPath and SharePoint for long before you find that some SharePoint Lists web service methods just don't play fair with InfoPath data connections (yeah, GetListItems, I'm talking to you). But don't let one or two bad apples spoil your barrel, because some of those web service methods work wonderfully with InfoPath. And that is what this post is about, leveraging some of the yummy good methods, and ignoring the bad.

So, you know how when you open a form in client from SharePoint, and someone else has it open, you get a little message letting you know and offering to open a read only copy? But no such love for browser forms.... Imagine, what if your browser form checked itself out with no effort on your user's part at all? And then, when they submitted, it checked itself back in?

This is no early winter pipe dream. You can do this with the above-mentioned IP-friendly web services. Before we dive in, I should mention I'm leveraging some functionality that is only available in SharePoint 2010  (and only seems to work correctly in forms opened in the browser) to find out if the form is already checked out (I underline this so you don't walk all the way through this and then fuss about your version of SharePoint being the wrong one or wonder why it doesn't work in client). I'm sure there are ways to do this in 2007, or in client, so don't let that stop you from giving this a try, but I did want to warn you upfront that your path may be different. Or bumpy.

Check Out Data Connection

In your form, add a receive data connection to the Lists web service for your SharePoint server (http://server/_vti_bin/Lists.asmx  with server replaced with your actual server name). If in doubt,  test your URL in your web browser -- you expect to see a page like this:

Lots of stuff to check out there, but we need to focus. So, back to your form. Receive connection:

SOAP service:

Location of the service:

Select the CheckOutFile operation:

Note the parameters, but don't bother your purty head filling them out:

Ignore the next dialog, and in the final window, de-select the annoying checkbox that ALWAYS wants to get your data on load:

Check In Data Connection

Do everything you did in the section above a second time, with the following exception: select the CheckInFile operation:

You should now have two data connections in your form:

Form Library Data Connection

Create a data connection to the form library the form will submit to. In my case, since I am working with a brand new form, I need to publish my form and create my library. Your form may already be published. This article has more info on how to do this. Be sure you are either using a form field for the form name, or some unchanging piece of data you can get again, as you will need to know the form's name to check it in or out.

After your form is published to a library, create another data connection. This one will also be a receive connection, but this time to a SharePoint List or Library:

Use the URL for the server your form is published to, and select the library the form is published to... Here is the super important bit... select the checkboxes circled in red below:

Make sure you've included the field with info as to who the form is checked out to and indicate you only want data for this form. In this instance, get the data on load -- it will only be a single row.

Make the Magic Happen!

Form Load Rules

Our "Check Out" functionality gets added to the form load rules. Our first rule needs to make sure the form is not already checked out, so it will have a condition that the form is not currently checked out to anyone. Remember, the data connection to the form library is querying on form load, so it will tell us if our form is already checked out:

What you decide to do at this point is up to you -- you may wish to switch to a read only view or you may have a form field for user messages in your form. But regardless of the action for this rule, you need to make sure you've selected to not run any aditional rules if this condition is met:

For your second rule, you'll need to have a condition so that the check out rules only run if the form has been submitted to the library. One way to do this would be to see if the Checked_Out_To field is present:

For your actions, you are going to set the values for the CheckOutFile data connection, then query using that connection. The first parameter is pageUrl:

and it needs to be set to the URL of your form's XML file. You'll probably need to use a concat formula to create the full URL to the XML file:

In the screen shot above, the Title attribute is a field in my form where I am storing the name of the form.

Next, set the value for checkoutToLocal. Here is where MSDN is just invaluable. Let's go see what the options are for that bad boy, shall we?

Given this info, we'll set that field to true:

Having checked MSDN, we know that we can leave the final parameter blank. Our final action for this rule will be to query using a data connection -- the CheckOutFile data connection:

You can add another rule if you like that leverages the CheckOutFileResult and provide your user with information on how to proceed if the result is false for some reason.

Form Submit Rules

You probably already have all kinds of submit stuff happening in your form -- it must at least submit to a SharePoint library, or you would have had no interest in this post and would never have gotten this far. You need your form to be submitting via rules to add this new functionality to check the form in, however. If you haven't already got your form set up that way, modify the submit options. Here's some details -- I'll wait while you fix that.

We need to add to our submit rules -- we have to set the parameters for the CheckInFile data connection, and then we need to execute the query.

First, we set the pageUrl. This should be familiar to you, as we just did this in our form load rules.

Set the comment as you see fit -- it might be nice to set it something like "Auto check out and in from form" so that when someone reviews the history it is clear what was going on.

And, for the CheckinType, back to MSDN:

I'll not pretend I know what the difference is between a "minor" or "major" checkin. I imagine "overwrite" does what it says on the box. At any rate, set that field to 0, 1, or 2

Finally, add an action to run your CheckInFile query. As with checking out, you can check the CheckInFileResult and handle any errors if desired. Publish your form again, make sure your form library is set to always open in the browser, and sit back and relax while your users shower you with accolades.

EDIT: The awesome SharePoint guru, InfoPath MVP & all around good guy Clayton Cobb filled me in on the different checkin types. He says:

those values are referring to minor and major drafts like 1.1, 1.2, 1.3 (minor) and 1.0, 2.0, 3.0 major). First, versioning needs to be turned on, and then it needs to be set to minor or major for these to be in sync.

Thanks, Clayton!

EDIT The Second: Who loves you? Qdabra loves you.... and we now have an XTP with this functionality that will make it even easier for you to implement this functionality in your form!

One of the many fantastic things about InfoPath forms is that we can dictate a data type for a field. If we set a field to be a decimal, for example, the poor user determined to enter an 'a' will always be thwarted.

But if you don't understand what the data for a data type really looks like, it is pretty easy to find yourself in a mess of validation errors. You know better than to set a decimal field to 'a', of course, but what about a date? What should a date look like if you want to set an InfoPath date field? What happens if you try to set a date field to the value of the function now()? Why is the letter "T" even in the title of this post?

All gripping questions that we are now going explore.

First, don't be fooled by form controls. Given the following data structure:

We can add date pickers to our form for any of those data types:

And, I bet if I asked you right now what the data looked like, you'd say "Month, slash, Day, slash, Year". If I asked you to set a rule to set that field's value, you'd use "9/8/2010", for example, and feel very pleased until you saw the data validation errors:

Only the date picker bound to the text field doesn't care about the value. But that control and the field it is bound to are not very discerning. You can type whatever you want in there:

Why is InfoPath being mean to me? If I save the XML from my original image, where I had no validation errors: 

Try to look past the xsi namespace declaration and focus on the values:

Now, let's look at the XML from the sample with the validation errors (this time I'll exclude the namespace declarations):

Especially interesting is the dateTime field. Even when we don't have a time filled out, that datatype requires "T00:00:00".

No matter how we format our control to display, the date and datetime date types will have a specific format. "yyyy-MM-dd" for date, "yyyy-MM-ddTHH:mm:ss" for datetime. And if you set a datetime to the today() function value (which returns a date) or a date to the now() function value (which returns a datetime), you will have validation errors. If you are uncertain why you have an error, you can always save the XML and take a look in a text editor. Select a value using a date picker, and compare to the value you are trying to set the field to.

You can also change your control to show the XML value of the field. Right click the control and open its properties, then click the Format button:

Select the top option:

Preview and select some dates:

Keep this in mind when you are copying data into your form fields from other data sources as well. A SharePoint list may have a field that looks like a date, but is actually a datetime.... and missing the "T" separator between the date and the time! Copy that into a date or datetime field in an InfoPath form and it will behave as if you have surgically removed its birthday.

So remember -- with form controls and data types, you may not be seeing what you are getting at all. If you are troubleshooting a validation error, look at the XML data, make sure the controls you are debugging with are showing you the actual data, and you'll be able to make everything work nicely in no time.

Wouldn't it be nice to be able to use images attached to an InfoPath form in a SQL report? If you are using DBXL to submit your InfoPath data to a SQL database, you are in luck.

InfoPath stores image files in Base64 encoding. Using your document type mapping in DAT, you can shred the value of your picture attachment field to a varchar or nvarchar field in your database. SQL report picture controls can then turn that Base64 back into a picture for display in your report!

For this demo, I'm going to modify the sample Asset Tracking form that ships with InfoPath 2007. I'm going to assume you know how to use InfoPath and modify forms in design mode, that you have DBXL installed and know how to create a document type and a SQL mapping, and that you know how to create a basic SQL report.

First, add a field for pictures to the main data source:

Next, add a control to the form for the pictures:
 

After the form is ready to go, set up your tables for shredding, including a field for submitting your pictures:

Next, in DAT, make sure your form's picture field is mapped to shred to your table:

Create a new report that uses the tables you are shredding your data to. Mine has a simple table bound to my dataset:

Then, in your report, add a picture control for the image data. If you are using SQL 2008, good on you, this is going to be super easy:

But hey, if you are working with SQL 2005 (and lots of us are, don't worry about it), it is still pretty easy -- you just need to use an expression and convert your Base64 string. After adding your image control to your report, modify the properties to use the expression =System.Convert.FromBase64String(your picture field here):

Fill out and submit a few forms to DBXL:

And, after you have data with pictures in your SQL tables, run your new report to see the images:

The best of all worlds -- InfoPath to fill out your forms, DBXL for saving your data to SQL, and SQL reporting to give you aggregated info, including your images!

Adding qRules to your form is simple -- just browse to your form and click Inject and you are done! But what if you want to remove qRules for some reason?

Currently, that is a manual process, but it can be done.

First, use the Logic Inspector to find any rules that are using the Command node from the QdabraRules data connection:

That will help you better understand what will need to change after you remove qRules. Next, you will need to remove one or two data connections, depending on your version of qRules. If you have the trial version, you'll need to remove both the QdabraRules and the QdabraRulesValidation data connections. If you are using a purchased version, you will only need to remove the QdabraRules data connection:

Next, navigate to Tools / Resource Files:

Remove the QdabraRules.xml file:

Finally, we need to remove the .dll that contains the qRules logic. The easiest way to do this is to add code to your form. For example, add a loading event:

Close the Microsoft Visual Studio Tools for Applications window that opens after adding the event, then navigate to Tools / Form Options:

Go to the Programming category, select the Remove Code buttton to remove all code from your form: