http://www.infopathdev.com/
User Profile Service in O365
Hello everyone!
Here's a trick I use in O365 and SharePoint 2013 to get around some rather nasty Web Service query errors in the browser. I'm sure some of you have tried to use this service, and experienced the error.
Many times data connections are set up within your for to query on load. This is not best practice for 2 reasons.
1. Querying data before you need it can create poor form performance
2. In certain cases, such as the user profile service, your query will fail if set to automatically query on open.
So then, how do you get around this behavior if you want to use the service?
ANSWER: Delay the querying of information from the service by unchecking the option to automatically query.
In this instance, It becomes very important to set the query value of the data connection. On the form Load rules in the designer, set the query accountName value to the userName() function, and hen add a rule to query. Publish your form to your site and watch the magic happen!
I have attached the sample for some experimenting. Simply change the user profile service url to your own site and publish.
If using 2013 there's one extra step. You'll need to change the AccountName query value to not include the claims identifier.
Use this formula to set the username without the claims identifier:
substring-after(userName(), "i:0#.w|")
xPaths With Double Forward Slashes Can Prevent Browser Publishing
Here's a trick I use in O365 and SharePoint 2013 to get around some rather nasty Web Service query errors in the browser. I'm sure some of you have tried to use this service, and experienced the error.
Many times data connections are set up within your for to query on load. This is not best practice for 2 reasons.
1. Querying data before you need it can create poor form performance
2. In certain cases, such as the user profile service, your query will fail if set to automatically query on open.
So then, how do you get around this behavior if you want to use the service?
ANSWER: Delay the querying of information from the service by unchecking the option to automatically query.
In this instance, It becomes very important to set the query value of the data connection. On the form Load rules in the designer, set the query accountName value to the userName() function, and hen add a rule to query. Publish your form to your site and watch the magic happen!
I have attached the sample for some experimenting. Simply change the user profile service url to your own site and publish.
If using 2013 there's one extra step. You'll need to change the AccountName query value to not include the claims identifier.
Use this formula to set the username without the claims identifier:
substring-after(userName(), "i:0#.w|")
xPaths With Double Forward Slashes Can Prevent Browser Publishing 
If you use InfoPath long enough, you will eventually run into a browser publishing error message something like this: "The form template has been published to the server but it can only be opened in InfoPath Filler."
Often the message will tell you to examine Design Checker and resolve any errors that appear there, but if there aren't any errors then this message can feel quite frustrating. Your next step in troubleshooting should be examining the SharePoint logs, but that's not possible if you have a cloud-based installation, such as Office 365, and there's no guarantee the logs will contain useful information. Another tool that can help with troubleshooting is Fiddler, a simple desktop application that allows you to examine the web traffic that is sent back & forth between InfoPath and your SharePoint server during the publishing process---but again, no guarantees that that traffic will contain the answer.
If you've tried all these steps and still don't know what's going wrong, then usually (a) there is a configuration issue with your SharePoint server, or (b) InfoPath has failed to catch an error in your form template. A few weeks ago, I discovered one of these types of errors after a long painstaking search. I'm posting this blog to give you a heads up, in case you've got a similar undetected error in your own template.
For some reason, InfoPath will verify xPaths that contain double forward slashes, like the following:
If you then try to browser publish a form containing such an expression, IPFS---InfoPath Forms Service, the server-side web service that converts templates to browser forms---will throw an error and only publish in filler mode without telling you why. What's more, the associated SharePoint logs won’t point to this xPath as a source of the error, leaving you to find this only by trial & error debugging. Isn't that wonderful?
Now, before you throw up your hands and say you don't have the time to manually examine every single rule in your complex form template, there's an easy way to do this: export the source files (File -> Publish -> Export Source Files) then find the file called manifest.xsf and open it in a text editor, such as Notepad. Then simply search for "//my" and, if you have any data connections in your form, also search for "//d" - this will locate only double forward slashes in the xPath expressions in your template.
So, next time you get a browser publish error alert and InfoPath's Design Checker doesn't show any errors, check your xPaths and see if any of them contain double forward slashes.
SPC348: Update on InfoPath and SharePoint Forms
Often the message will tell you to examine Design Checker and resolve any errors that appear there, but if there aren't any errors then this message can feel quite frustrating. Your next step in troubleshooting should be examining the SharePoint logs, but that's not possible if you have a cloud-based installation, such as Office 365, and there's no guarantee the logs will contain useful information. Another tool that can help with troubleshooting is Fiddler, a simple desktop application that allows you to examine the web traffic that is sent back & forth between InfoPath and your SharePoint server during the publishing process---but again, no guarantees that that traffic will contain the answer.
If you've tried all these steps and still don't know what's going wrong, then usually (a) there is a configuration issue with your SharePoint server, or (b) InfoPath has failed to catch an error in your form template. A few weeks ago, I discovered one of these types of errors after a long painstaking search. I'm posting this blog to give you a heads up, in case you've got a similar undetected error in your own template.
For some reason, InfoPath will verify xPaths that contain double forward slashes, like the following:
xdXDocument:GetDOM("Status")/dfs:myFields/dfs:dataFields/d:SharePointListItem_RW//d:ID
In other words, if you have a double slash inside an xPath expression in one of your rules, then InfoPath won't detect it and will treat the xPath as valid.If you then try to browser publish a form containing such an expression, IPFS---InfoPath Forms Service, the server-side web service that converts templates to browser forms---will throw an error and only publish in filler mode without telling you why. What's more, the associated SharePoint logs won’t point to this xPath as a source of the error, leaving you to find this only by trial & error debugging. Isn't that wonderful?
Now, before you throw up your hands and say you don't have the time to manually examine every single rule in your complex form template, there's an easy way to do this: export the source files (File -> Publish -> Export Source Files) then find the file called manifest.xsf and open it in a text editor, such as Notepad. Then simply search for "//my" and, if you have any data connections in your form, also search for "//d" - this will locate only double forward slashes in the xPath expressions in your template.
So, next time you get a browser publish error alert and InfoPath's Design Checker doesn't show any errors, check your xPaths and see if any of them contain double forward slashes.
SPC348: Update on InfoPath and SharePoint Forms
This morning at the SharePoint Conference in Vegas, Microsoft gave a great presentation to a packed room of >1000 attendees.
Here's a link where you can download the slide deck: http//www.infopathdev.com/files/folders/examples/entry96310.aspx
For those with Yammer accounts, here's Microsoft's post: https://www.yammer.com/sharepointconference/uploaded_files/16924826
Quick Summary: Greg, Sonya and Bob gave a very positive talk. They demoed Excel surveys, introduced Forms on SharePoint Lists (FOSL), and talked about the evolving roadmap at Microsoft for form solutions targeting IT professionals. Main focus was no-code solutions. Yay!
My Thoughts: I love the new open and cooperative atmosphere at this year's conference. From Day 1 the theme was cooperation. Bill Clinton gave a keynote where he said we need to celebrate our differences if we are going to survive as a social species (heady stuff). Right after that Julia demoed a new social media app called Oslo and she did the demo on an iPad. Rah rah for the new inclusiveness! This theme was a great backdrop to the InfoPath update talk. InfoPath has always been a sharp knife and some people have cut themselves. The new roadmap pushes four technologies forward to support building better forms that work on a variety of devices and provide contextual data that is not-modal.
Check out our new community site: FormsQuo.com where we will be highlighting various migration paths for you.
Here's a link where you can download the slide deck: http//www.infopathdev.com/files/folders/examples/entry96310.aspx
For those with Yammer accounts, here's Microsoft's post: https://www.yammer.com/sharepointconference/uploaded_files/16924826
Quick Summary: Greg, Sonya and Bob gave a very positive talk. They demoed Excel surveys, introduced Forms on SharePoint Lists (FOSL), and talked about the evolving roadmap at Microsoft for form solutions targeting IT professionals. Main focus was no-code solutions. Yay!
My Thoughts: I love the new open and cooperative atmosphere at this year's conference. From Day 1 the theme was cooperation. Bill Clinton gave a keynote where he said we need to celebrate our differences if we are going to survive as a social species (heady stuff). Right after that Julia demoed a new social media app called Oslo and she did the demo on an iPad. Rah rah for the new inclusiveness! This theme was a great backdrop to the InfoPath update talk. InfoPath has always been a sharp knife and some people have cut themselves. The new roadmap pushes four technologies forward to support building better forms that work on a variety of devices and provide contextual data that is not-modal.
- Excel Surveys - simple surveys that are data-driven and work great from all devices (available in the O365 cloud today)
- Forms on SharePoint Lists - turn your lists into contextual forms (first release in summer of 2014)
- Access Web Apps - rich forms that are backed by relational data (available in the O365 cloud today)
- Word Structured Forms - rich high fidelity forms that print well with structured data that can be integrated with databases (ETA: 2015?)
- InfoPath - currently, this is still the recommended solution for forms from Microsoft
Check out our new community site: FormsQuo.com where we will be highlighting various migration paths for you.
No comments:
Post a Comment