Archive

Archive for the ‘InfoPath’ Category

Nintex 2010 Workflow LazyApproval and Inline Functions – fn-Substring explained

August 14, 2013 1 comment

I recently completed an update to a workflow to enable LazyApproval.  Seemed easy enough to do.  There’s just a checkbox in the Flexi-task.  I found that after I enabled the feature and a user approved the workflow task by replying to the email that the workflow was erroring out.  After the approval request was approved or declined, the workflow was updating some fields in the InfoPath form in the form library.  Four promoted fields in an InfoPath form library – three single line of text fields and a date field. Here is the error:

The workflow could not update the item, possibly because one or more columns for the item require a different type of information.

Outcome: Unknown

This was puzzling because if the user approved the task via the Task Form, all fields were updated successfully.  I started to think the issue was with the Date field but discovered it was actually with the Approvers Comments field.  When the user replies via email with a LazyApproval, the approvers comments are the entire email.  In my case, the contents of the email exceeded the limit of the Single Line of Text field.  Since this InfoPath field was promoted as a SharePoint field I wasn’t able update the field type to accommodate this by changing the column data type in the List Settings page.  This ended up breaking the InfoPath form when I tried to publish an update.  InfoPath indicated the field mapping had changed.  Enter the fn-Substring Inline Function.

So having just narrowed down the issue to the number of characters being passed back to the field in the InfoPath Form Library I thought the use of the Inline Function fn-Substring would take care of it.  Well, not quite.  I decided to declare a workflow variable (single line of text) and set it equal to the results of the inline function fn-Substring.  Here’s what that looked like…

fn-Substring({Common:LastApproverComments}, 0, 200)

first variable: Approvers Comments, second variable: 0 – start at the first character, third variable: 200 – include the first 200 characters.  I figured this would be enough.

The result of the initial fn-Substring was just the plain text from the email preceded by the function.  fn-Substring(body of email….  This didn’t seem right.  Why would it work with some plain text in a test workflow but not with my real data.  I missed one crucial piece of information from the documentation on how to use this function.  Let me share it with you.

If text used for a function argument contains function syntax (i.e. a brace or comma character) wrap the argument with {TextStart} and {TextEnd} to indicate a block of text that should not be parsed further.

For example, if a number variable that contains a decimal value is passed to the function, and the decimal separator for your region is a comma, the {TextStart} and {TextEnd} tokens will need to be used.
The stars started to align at this point.  I needed to wrap my first variable {Common:LastApproverComments} between the {TextStart} and {TextEnd} because the contents of the email included commas open and close ().  I assumed the curly braces around Common:LastApproversComments were able to interpret that the entirety of that variable was in fact the first variable – not true.
The completed Inline Function looks like this now.
fn-Substring({TextStart}{Common:LastApproverComments}{TextEnd}, 0, 200)
It’s great that Nintex provide documentation which made troubleshooting this much easier.  It would be great if there was a cheat sheet of all the nuances to Nintex like the tokens {TextStart} and {TextEnd}.  Maybe I’ll start one and post it someday.  Hopefully this helps someone else down the road.

Performance problems with InfoPath Form People Picker resolving names from AD

November 2, 2011 Leave a comment

I encountered an issue where the time to resolve a name from AD in an InfoPath Browser Form People Picker control was taking upwards of 30 seconds, when previously it only took 2-3 seconds.  After further investigation, there appeared to be an issue with a recent change to AD that was causing this performance issue.   AD has approximately 13K user objects in one forest.  And under this current configuration the form would resolve the name in 2-3 seconds.

The problem started to surface last week when the organization began preparing for a merger with an organization of similar size (roughly 13K user objects in their forest).   A two way trust was setup between the two forests in preparation for getting email and calendars working for both organization today.  As you can imagine the communication of these changes and their impact hadn’t been communicated to all potential parties that might be affected by this change.  Subsequently, it was brought to our attention by the user community of the InfoPath forms that they were taking so long to resolve names in the people picker control.  After some searching around to diagnose the issue, we happened upon something I had used in a previous project which is to update the property on SharePoint using stsadm – setsiteuseraccountdirectorypath.  After setting this property we actually saw an improvement in the time from the original 2-3 seconds to not quite 1/2 second.  Who knew the fix would actually improve the previous time.

Below is the script used to make this update.  Of course you only need the stsadm line but if you have more than one site to fix or could see benefit to using this in the future the script below can be saved as a batch file.  You’ll also need to update the ‘-path’ to the OU where you users are located in AD.  And if you need to reset the property just set the ‘-path’ to “” which will return the setting to the default which is configured out of the box.

@echo off
echo Path of site collection with the people picker that needs fixing:
set /P siteURL=

echo Fixing the people picker…

stsadm -o setsiteuseraccountdirectorypath -url %siteURL% -path “ou=NAME OF OU,dc=DOMAIN NAME,dc=com”

echo People picker fixed.

Hopefully this helps someone else out there.  Thankfully it only burned a couple of hours of time this morning which could have led to a more exhaustive exercise with the AD team who was already plenty busy getting email and calendaring working for 26K users vs. 50-100 users who have to wait for a simple little people picker in a handful of InfoPath forms.

UPDATE:  11/18/11

There is another script you can use if you want to add more than one OU. 

stsadm -o setproperty -pn “peoplepicker-serviceaccountdirectorypaths” -pv “ou=OU1,ou=OU2,dc=domainname,dc=Extension” -url http://server:port/sitecollection