Saturday, September 24, 2011

Limit number of words in an InfoPath textbox

So you might have figured out you can limit the number of characters in a textbox in InfoPath, but what if you have to limit the number of words someone types? This came up in one project because they were posting the words onto a PowerPoint slide. To do this you must use 'data validation' (InfoPath 2007) or a 'validation' rule (InfoPath 2010) and you will need to select 'the expression...' for your first dropdown in the conditions and type this:

string-length(.) - string-length(translate(., " ","")) > 60 (or the number of words you want)

What this does is pretty straightforward - it counts the number of typed characters in your field (assuming you are placing this rule on the field in which people type - that's the string-length(.) part) and then it subtracts the same number of characters but with all the spaces removed (they were removed by the translate function) and this checks to see if the total is greater than 60...if it is, then your validation rule will tell the user something's wrong because they done typed more than 60 words o_O. This goes on the assumption that every space represents a word...which should be pretty close. Have fun!

SharePoint 2010 Designer Workflow Error

Error: The server could not complete your request. For more specific information, click the details button. When you click the details button, the box is blank.
Our setup: Workflows with a total number of conditions greater than 10-12 would break no matter how complex or how you broke down the steps/conditions when publishing a workflow through Forefront UAG.

Explanation:
There are several causes to this problem that we found as we researched our solution. In many cases, having your SharePoint admin recycle the application pool or adding an 'execution timeout' attribute to workflows on the web.config file helped (esp. for workflows with approval steps). In our case, the problem was that our system has to pass through Microsoft's security server known as Forefront UAG (Unified Access Gateway) when publishing workflows. Your computer talks to SharePoint with requests and receives responses but has to go through the UAG middle man that inspects everything by unboxing it, reviewing it, and packaging back and sending it on its way to the recipient - but it will only tolerate so much information to look through. There was a setting in UAG called 'maximum http body size' I believe that, when doubled, allowed us to publish a slightly larger workflow. So, the administrator went in and altered the settings in UAG to tell it to stop looking at some of these very specific requests for workflow publishing and voila - we can publish workflows now!

For those UAG administrators, I believe you have to modify the trunk, go to the portal tab, and edit the 'do not parse the bodies of these requests' and add your web front ends using the FQDN and add the url pattern for whatever web services are being queried by SharePoint Designer when working with workflows (webs and lists maybe?). It is also noted in the documentation for SharePoint 2010 SP1 that you should also add those servers and the URLs for the lists and webs web services to the 'do not parse the RESPONSE bodies...' option as well.