qRules SubmitToSharePointList - Walkthrough for v4.2 - Working With Existing Data & Submitting a Single Mapping - Hilary Stoupa
in

InfoPath Dev

Hilary Stoupa

qRules SubmitToSharePointList - Walkthrough for v4.2 - Working With Existing Data & Submitting a Single Mapping

With qRules 4.2, we've introduced a major improvement to the SubmitToSharePointList command - especially if you have been submitting to multiple lists. The first walkthrough can be found here, and then in this post, we talked about how to save attachments with our list items. Picking up where the second post left off, we are now going to modify our form to submit to one of the individual lists we've mapped. Thus far, we've only submitted to all the lists. Also, because I am frightfully lazy, we are going to start pulling some existing data into our form so we can edit it and update our existing customers.

We'll start with the same template we have been using for the previous two walkthroughs - mine is available here, if you'd like it. Keep in mind that my form & mapping is pointed to sites in my environment, so you'll need to modify that, and it is using the current 4.2 trial version of qRules - which expires 9/15/2012. So, you'll want to re-inject with a new trial if you are following this at a later date.

Data Connections

First, we need to add 2 data connections to our form - one that we'll use for a customer drop down, and the other that we'll use to return all the data for a given customer. The first one, which I'll call the CustomerNumber data connection, is to the Customer list, and returns these columns:

I sorted by Company Name to make the drop down I'll use this data for less annoying.

Return data on load for this connection only:

Now, create another data connection to the Customers list:

Select at least all of the columns that the form is mapped to submit data to. This time, deselect the checkbox to query data on load:

Form Changes

In my form, I've decided to let the user choose an existing customer or just fill in the fields if they want to create a new customer. I've added a drop down that is bound to the /my:myFields/my:Customer/my:ShpId field - you may recall from the earlier walkthough that when mapping, we can indicate a form field that will hold the SharePoint List item ID after a successful submit- we are going to leverage this field to allow our users to open a new form and edit existing customers.

Set the drop down to use the CustomerNumbers data source, with the ID for the value and the Company Name for the display:

Here's my form up to this point, in case I've lost anyone.

After the user selects the Customer, we'll need to query the Customers data source for that customer's data and then populate the main data source nodes with those values - this can be done with ordinary InfoPath rules. While this could be done with rules set on the ShPId field the drop down is bound to, that would make things slightly more complex for us - we'd need to make sure these rules don't run when qRules is populating that field. So, for the purposes of this walkthrough, I'm going to add a button and put these rules on the button. However, you have other options - like:

  • Bind the drop down to another field, and execute the rules from that field - be sure you also set the form field for the ID if you take this approach
  • Have a helper field in a 2ds that set when the form is about to execute the SubmitToSharePointList command, and base conditions off the value of that field to prevent execution of rules when qRules sets the ID field for a new item

For my form - I'm going with a button.

My first rule action sets the Customers query ID field:

To the value of the /my:myFields/my:Customer/my:ShpId field:

Then, I execute the Customers query:

Now, since the user selected the ID of the customer she wants, I could have returned all the customer data and used filtered XPath to get the values I want - and if you are using SharePoint & InfoPath 2007, this would be the approach you would probably take (or use the qRules FilterOwssvr command to get back just the single record you need). Since I only will have one record in my Customers data source, I don't have to use filtered XPath to populate my other form values. That makes me happy.

In the rules above, I am setting main data source Customer group nodes to values from my Customers list.

Preview

Time to check our work - preview the form, and select a customer from the drop down - does all the customer's information get populated correctly?

If not, check and make sure you are returning data to your Customers data source - and here's my form in progress, in case you need to take a look at it.

Submit a Single Mapping

Now that we have added the logic to pull an existing customer into the form, we can add a button to save just the user's Customer changes. The big trick here is making sure that in the mapping we have identified a field to use for the ID:

And making sure we have in our form set that field to the SharePoint List item ID that we wish to update - in my form, I've done this by binding a drop down to the field ( /my:myFields/my:Customer/my:ShpId) and then using a data connection to my target list for the values - so that the user will be picking a valid item ID from the drop down.

Our original submit command was:
SubmitToSharePointList /submit=ShPList

We then added to it for adding attachments in the last walkthrough. I'm not going to be adding attachments here, just editing my existing customer - so I only need to add the mappingName parameter to indicate which mapping I want to submit:
SubmitToSharePointList /submit=ShPList /mappingName=Customers

I'm going to add a region to this customer, since it was missing when I pulled his information into my form:

After clicking my button with the qRules command on it, I can see the region has been added to the customer:

If you would like to verify that only the Customer is submitted, add an Order and use the command that submits only the Customer data - you'll find the Customer is added / updated and the order is not. If you need my final form, here it is.

***********************

There you have it - you can make this more interesting by allowing the user to copy in Orders or Order Details - using CopyTable or Insert - so those could be updated. Of course, you'd probably be submitting the XML to a form library in a real form - so you would open the form to update the order.

But what if someone changed the list item? What if you want your users to be able to edit from the form or the list, and you want to keep them in sync? Stay tuned - next up is a walkthrough on the RefreshSharePointListItems command!

***********************

SubmitToSharePointList Walkthrough
Working with Attachments
RefreshSharePointListItems

Comments

 

qRules SubmitToSharePointList - Walkthrough for v4.2 - Working With Attachments - Hilary Stoupa said:

Pingback from  qRules SubmitToSharePointList - Walkthrough for v4.2 - Working With Attachments - Hilary Stoupa

June 28, 2012 3:59 PM
 

qRules SubmitToSharePointList - Walkthrough for v4.2 - Hilary Stoupa said:

Pingback from  qRules SubmitToSharePointList - Walkthrough for v4.2 - Hilary Stoupa

April 11, 2013 11:44 AM

About Hilary Stoupa

I wandered into development after working as a business process analyst for a global manufacturing company. I create InfoPath solutions for our clients as well as work as a developer on company tools that extend InfoPath. I've also been instrumental in creating the InfoPath Master Class training provided by Qdabra.

Copyright © 2003-2012 Qdabra Software. All rights reserved.
View our Terms of Use.