Viewpoint : MOSS

InfoPath Browser Enabled Forms and Crossing Web Applications

Jeremy Williams — Fri, 13 Aug 2010 17:09:15 GMT

Scenario:

A browser-enabled InfoPath form was to be built that allowed users to fill out a form, email it to themselves, attach a document to be uploaded to SharePoint, and then sent to an individual that understands SharePoint. Sure, the easy answer here is to make the user upload the file directly and just classify it there. The problem is that many users are unwilling to be trained on SharePoint, so this was elected as a compromise to fully utilizing SharePoint. There’s some other border-cases that this form solves, but this is neither here nor there.

Challenge:

The form has a number of drop-downs in it, some are SharePoint ‘choice’ fields, and two are SharePoint ‘lookup’ fields. The choice fields all function just fine since I’m using a nice little XML file to specify those dropdowns (they rarely change and it’s much quicker to load than querying all of the lists). The lookup lists do need to be refreshed on each form load, since those are subject to additions. However, InfoPath Browser forms have a nasty habit of ordering SharePoint-list-data source values by ID rather than Title. [To add further insult to injury, the full-blown InfoPath client orders by Title..] Users wouldn’t go for that on lists that contain upwards of 500 choices, so I had to find a way to order by Title…

After reading some great articles on using owssvr.dll to get a XML output for a particular list, I figured I had the problem licked. This method would allow me to return live data (on form-load), required no code-behind, and seemed straight-forward. So I followed the instructions (http://blogs.msdn.com/b/infopath/archive/2007/01/15/populating-form-data-from-sharepoint-list-views.aspx), and then pressed enter to get a plain-white IE window (no XML as promised). After verifying that this wasn’t some obscure browser setting, I looked at the lists I was referencing and they were (both) custom lists that also had lookup columns contained within. I then suspected that the lookup column (especially one that allowed multi-select) wasn’t supported by the owssvr.dll method. Luckily for me, we are running a nifty little master-list data synchronization on this environment. The custom code basically reads a list (considered the ‘master’) on Web Application A, Site Collection A, and then writes any add/update/delete actions to copy-lists stored other Site Collections under Web Application B. Anyways, the ‘synchronized’ lists don’t contain the lookup columns, just the ‘ID’ and ‘Title’ values. Effectively, this allowed me to test owssvr.dll reading a ‘simple’ list…

After running a quick test, I discovered that owssvr.dll worked famously with the sync-lists! So, I rebuilt my form data connections, redeployed the form, and then BAM! Yet another error about SharePoint not being able to access data sources [Error ID 6932](and all of my dropdowns of lookup lists were blank). After some poking around, I surmised that InfoPath form services (even with cross-domain enabled) doesn’t like crossing SharePoint web applications, even though the user account I was using had permissions to both web applications.

Fix…Workaround:

So, to get the form to play nice, I simply deployed my form and associated data sources in a site under Web Application B. By doing this, my owssvr.dll XML files could reference the appropriate sync-lists correctly and in the same web application. After I did this, the form worked as advertised and I simply changed all of the applicable links to point to the new form location.

I realize that this is a fairly unique scenario, but I think there are a couple of important takeaways. First of all, for users that are running into the blank-white IE screen when using owssvr.dll, hopefully this post helps you in your test cases by trying the method after removing lookup columns. And Second, for those who might be considering/trying to get InfoPath Browser Forms to cross web applications, realize that you may have to somehow provide a simplified version of your list-data.

At the end of the day, the form worked as advertised, and the correct columns were returned (and ordered).

Customizing People Search Results in MOSS 2007 – Part 3 of 3 – Search Results Customization

Jeremy Williams — Mon, 14 Jun 2010 17:51:28 GMT

This is the third and final post of a three part series, if you missed it, here’s Part 1 and Part 2. This post will go into the details of consuming the managed properties we configured last time around, and then displaying them in our search results.

As a review, here’s where we are:

User Profile Properties Changes
SharePoint Search Changes
Search Results Page Customization

Add Managed Properties to List of Columns to Query

The first step to displaying your newly added managed properties in the search results is make sure they’re being returned as part of your result-set! To do this, navigate to the people search result page on your Search site. A quick and easy way to do this is to run a search (using the ‘People’ scope) for your own name. Once you’re on the search page, go ahead and edit the page. Once you have the page in edit mode, click on the context menu for ‘People Search Core Results’ and select ‘Modify Shared Web Part’. On the pane that appears to the right, go ahead and expand the ‘Results Query Options’ Group, then click the text box under the ‘Selected Columns’ heading; and finally, click on the button with the ellipsis (…). This will pop up a text editor. To prevent yourself from going a little crazy, I highly recommend editing this text in something else, like Notepad/Wordpad/your favorite IDE/etc. You will want to add a line (below) for each of your newly added custom managed properties.

<Column Name="YourManagedPropertyNameHere”/>

In the screenshot below, you can see that I’m adding my ‘StreetAddress’ managed property:

Once you’ve added all of your properties, go ahead and paste your XML back into SharePoint pop-up text box and click ‘Ok’ on the web part property pane to save your changes. Now, your custom property is available to and for our final step…

Reference columns in custom XSLT

Now that the people search core results web part is properly returning your managed columns, you’ll want to customize it’s XSLT (style sheet) to include the newly added column(s). Same as last time, I highly recommend you edit this XSLT in your favorite IDE, as it’s really painful to work with code in SharePoint’s popup text-editor. Anyways, to access the XSLT, go ahead and click ‘Modify Shared Web Part’ on the People Search Core results web part, and click the ‘XSL Editor…’ button.

The XSLT sheet that ships with SharePoint is about 360 lines long, and there’s a couple of places you’ll need to add your column(s). For the example, I’m simply going to stick in the ‘StreetAddress’ field after a user’s title, department, phone, and office. Certainly, you can do much cooler things here with the XSLT, but I’ll save that for another day. The first place you’ll need to add your column is around line 137. In my example below, I have established my XSLT variable for StreetAddress as ‘street’ (mainly to illustrate the naming differences).

Important Note: in the ‘select’ value, be sure to use ONLY lowercase text; if you do capitalize names here, you run a very high risk of the proper field not being returned.

The next place to add the property is around line 337, as shown below:

And finally, I’ve added an XSL if-block with street around line 355:

Doing this will yield the following results:

Before:

After:

Final Thoughts

Clearly, the trickiest part of this process is the XSLT customization, which is why I’ve chosen to show you how to simply add a property to the XSLT. You can do all kinds of cool things with XSLT, such as return the users in a grid pattern with key information beneath their picture, or return people with a contact-card styling, the list is as long as your imagination.

Thanks for sticking through all three posts with me; I hope this helps clear up any confusion on the whole process.

Errata

Random Error

Sometimes, SharePoint will throw a false error at you after clicking ‘Ok’ to web part changes. The error looks something like this:

If you do come across this, simply check in your page and then click in the URL bar and press enter (don’t just refresh the page). If you still get the error after that, you’ve most likely made a coding error in your XSLT.

Field Not Displaying

If your field isn’t returning, and you’re fairly confident that you’ve written valid XSLT and added/configured/mapped all your properties correctly, you might need to refresh your user profiles. To do this, initiate a full import on your people profiles in SharePoint. Once the full import has completed, start an incremental search crawl to pick up these changes. Once complete, go ahead and run your people search again and your field should now appear:

Example of Missing Field (notice the hanging ‘-' after ‘Downtown’; this is where Street Address should be:

Example of the Missing Field existing as expected:

Customizing People Search Results in MOSS 2007 – Part 2 of 3 – Search Configuration

Jeremy Williams — Wed, 09 Jun 2010 17:36:00 GMT

This is the second post of a three part series, if you missed it, here’s Part 1. This post will go into the details of taking the User Profile Properties we created the last time around, and making sure that they’re available to us in Search.

As a review, here’s where we are:

Run an incremental crawl

If you haven’t already, be sure to run a full import on your user profiles (This should be done after you’ve added all your custom profile properties from step one) Assuming that a full import has run, the next step is to run a crawl on whatever content source is crawling people. 9 times out of 10, this would be the ‘Local Office SharePoint Server Sites’ content source. This can be done by going to your Search Administration page, clicking on ‘Content Sources’ then selecting ‘Start Incremental Crawl’ from the ‘Local Office SharePoint Server Sites’ context menu.

After the crawl has completed, it should have picked up all of your newly defined user profile properties as a crawled property. Next, we’ll want to use those newly crawled properties in the creation of our managed properties. The managed property will (ultimately) be used to return information about a user in the search results.

Add mapped profile properties as managed properties

To create a new Managed Property, navigate to your SSP management page. From there, click on Search Administration, and then click on ‘Metadata properties’. Once at the Metadata Property Mappings window, click on the ‘New Managed Property’ link, which will take you to a screen similar to the one shown below:

This is where you will be defining the name (to be used in search) of all your people profiles. Personally, I like to use the same name as that returned by the crawled property. This is due to the fact that I handled the naming of the property when I created it. It simply makes life easier to remember only one property name that to track the property through all phases (AD, Profile Property, Crawled Property, Managed Property, XSLT variable). In the screenshot above, I have created a managed property for Street Address. Assuming you’re following my advice above, you will use the same profile property name for naming the managed property. In my example, this yields a Property name of: “StreetAddress”. Filling in a description is strictly optional, I have elected not to do so in my example. Be sure to leave the ‘Text’ radio button checked, as this will act as a filter on crawled property search we’re about to run. [Obviously, if you’re adding a crawled property that is an integer value, be sure to change this radio to reflect as such] Next, you will need to click ‘Add Mapping’ to select the crawled property(-ies) referenced by this managed property. In my example, I know that I named by Profile Property ‘StreetAddress’, so I’ll search for ‘Street’ in the dialog:

This is an easy one, as only 1 result was returned. Generally speaking, if you get more than 1 result, be sure to select the result prefixed with ‘People’. Click Ok and you’ll return to the ‘New Managed Property’ Screen. The remaining options shouldn’t impact us, so you can leave them alone. Go ahead and click Ok. Voila, you’ve created a Managed Property for StreetAddress, bringing you one step closer to your customized People Search experience. Repeat as necessary for all of the properties you’ve added to User Profiles.

Run an incremental crawl

When you’re finished adding all of your new Managed Properties, you’ll need to run an incremental crawl. Disclaimer: Most (if not all) Microsoft documentation claims that you have to run a full crawl at this point. I’ve only had to do that once for people profiles and their associated metadata properties; typically, the incremental crawl works for me. The purpose of this crawl is to ‘pick up’ all of your newly update managed properties. Once you start this crawl, go ahead and get yourself a cup of coffee and marvel at your SharePoint prowess!

That wraps it up for the second step of the process. I hope to have the third and final post up soon, so stay tuned!

Customizing People Search Results in MOSS 2007 – Part 1 of 3 – User Profile Properties Change

Jeremy Williams — Tue, 25 May 2010 14:03:00 GMT

One of the niceties (at least for us implementer-folk) of SharePoint’s search is that both the content and display of the result page can be changed with a few tweaks to some the profile sync process, managed properties, search query result web part properties, and the result XSLT. Okay, so I’ll admit, it isn’t the most straightforward process, but it’s still pretty cool that this can all be accomplished without any custom code! If you have liberal definitions of “out of the box SharePoint functionality” like I do, then you’re in luck. Everything we’ll be going through here can be considered Out of Box!

Alright, so this post-series will be fairly detailed, therefore it will be broken up (for both author and reader sanity) into three parts:

User Profile Properties Changes
SharePoint Search Changes
Search Results Page Customization

For those of you that have done any searching on the subject, you will find a decent amount of custom people search XSLT result sets out there. However, what you’ll struggle to find is an end-to-end instruction set to fully implement a customized people search experience. I know it’s a lofty goal, but I hope this series of posts can help you get from zero to your custom people search experience. At the very least, it should get you pretty close!

So here’s the process that we’ll be going through:

If you are only going to use the 21 or so default mapped properties, feel free to skip ahead to the second post. Again, this first part is only required if you have non-standard user properties that you would like to display in People Results. My favorite example of a non-standard attribute is the ‘Mobile Phone’ value. In most AD implementations, a standard user account will not be able to ‘read’ this attribute into SharePoint’s user profiles. In order to properly access these properties, work with your AD administrator to secure a Profile Import Account with the correct level of access. Basically, the account will need the ability to read each of the fields that you’re working to import. I’m not going to dive into the details of setting up the correct permissions in this series, perhaps in the future I’ll tackle that subject. In the meantime, if (and only if) you’re in a test environment, the easy solution is to use a Domain Administrator account; please do not do this in your production environment.

To change this account, navigate to the Shared Services Provider (SSP) that you’ll be working on (you may have a direct link and/or it’s accessible from Central Administration). Once on the SSP homepage, click the ‘User Profiles and Properties’ link. From the next page, you will want to click on the ‘Configure Profile Import’ link. From the following page, select the ‘Specify Account’ radio button in the ‘Default Access Account’ heading and enter in the credentials for your elevated account.

The next step in the process is to add whatever additional fields you need to the ‘User Profiles and Properties’ area. To do this, navigate to SSP homepage, and click on the ‘User Profile Properties’ link. Near the bottom of this window, you will see a heading called ‘User Profile Properties’; click on the ‘Add profile property’ link. This will bring you to the form shown below. If you’re looking to display the ‘mobile’ attribute (or whatever value you’re adding here) to all employees, feel free to mirror the settings in the screenshot below. If not, tweak the settings to your liking.

The hardest part of this form is the dropdown near the end where you actually select what Active Directory field you will be mapping to. These field names are not necessarily intuitively named. For example, city is called ‘l’. To get an idea of what field you’re looking for, go ahead and and fire up ADSI Edit and connect to your favorite domain controller. From here, you’ll want to navigate to an OU that contains a User Account with the property that you’re looking for. Once you find the user account, go ahead and right click on it, and select properties. This will bring you an exhaustive list of that object’s AD attributes. Go ahead and find the property you’re looking for and then select that property in SharePoint’s Add User Profile Form. Be sure to note the AD-names of all properties that you add as you’ll need this list later.

After clicking OK and repeating this process for all of the non-standard fields you want to import you should be ready to move on to the next post, which I’ll finish up in the next couple of days.

Um, why is my SharePoint workflow clearing out date fields?

Kathryn Ciaralli — Mon, 12 Apr 2010 13:24:00 GMT

A few months ago I was writing configuring a very simple workflow using Nintex Workflow 2007. The workflow ran on a document library, did some work when a document was uploaded, then updated the metadata on the document. While testing what was supposed to be a "very simple workflow" I discovered that when I updated the metadata (a non-date field) on the document via workflow, any date fields on the document would be cleared out. My initial reaction was that something was awry with my worfklow...and I went down the path of troubleshooting. After many hours, I was finally led to this little gem by my BFF Google, which describes my issue perfectly:

You manipulate custom properties for documents in a document library. When you use code to read or to write the SPListItem.Properties property bag, data loss for date fields occurs. The data loss occurs only when you call the SPListItem.Update()/SystemUpdate after the property bag read operation or write operation.

Ah-ha! This sounds pretty darn accurate.

The problem - SharePoint SP2.
The solution - Hot Fix (KB 968850): http://support.microsoft.com/?kbid=968850

...see, the workflow remained "very simple" after all. ;)

Your welcome!

Get This: Title Icon in Web Part

Kathryn Ciaralli — Mon, 22 Feb 2010 19:55:00 GMT

On many occasions I have needed to use an image icon within the title of a given web part; this dresses up the web part and adds visual appeal. Historically, I have addressed this either using styles (with an image background) or a content editor web part (and setting the chrome to none on the web part in question) to get the desired effect. This has always been somewhat painful and I was surprised that Microsoft hadn't addressed this. Well, they had - I just didn't know it. :)

On a project last summer I stumbled upon the Title Icon in web parts...I had never noticed it before!! For those of you that had, to some degree, ignored the Advanced settings of a web part - this is where you will find the Title Icon (and yes - this is super duper easy).

Navigate to the page where the web part is located
Modify Shared Web Part
1. Expand the "Advanced" section
2. In the "Title Icon Image" URL field - enter the URL of the icon to be displayed
3. ...and voila - the image is resized on the fly and sits nicely in line with the web part title:

Get This: Search Stemming in MOSS 2007

Kathryn Ciaralli — Mon, 22 Feb 2010 19:39:00 GMT

How many times have you searched for something in SharePoint that you KNOW is out there and has been crawled, but it doesn't come up in your search results? Then it hits you like a bolt of lightning...you searched for the singular version of a term but the term that's out there is the plural version. Why didn't it come up in your search results? Do you really need a best bet for that? Nope. You just need to enable Search Stemming, which btw is native to MOSS 2007. Here's how:

Navigate to the search results page
Edit the page
Modify the "Search Core Results" web part
1. Expand the "Results Query Options" section
2. Check "Enable Search Term Stemming"

Yep - that's all there is to it. Now - why isn't this enabled by default? Apparently this is not supported in all languages, thus it's disabled by default. Now if you can just remember to do this with every implementation you would be all set. :)