Perform a search within the Client scopes to bring up the Client Results page. Click on Site Actions and Edit Page. Edit the Search Core Results web part by clicking the Modify Shared Web Part from the Edit (dropdown) menu:

On the left hand side pane, under the Results Query Options, click inside the Selected Columns to make the blue ellipsis button appear. Click on the blue ellipsis button:

At the bottom of the text, before the </Columns> tag, add a column entry for each managed property that was created for the BDC content source:

Click OK.

Next click on the XSL Editor under the Data View Properties:

The XSL entry will appear in the text dialog.  It may be easier to copy and paste the code out into a different code editor and then paste back into the dialog for the remaining XSLT steps.

XSLT: Overriding the results URL

The tasks outlined in this section are for the scenario where we want to show a custom URL in the results versus the one returned from the normal search results. While this may not apply to everyone, the steps show how to add a new variable based on a custom search column and use it within the overall XSLT.

Locate the “This template is called for each result” section of the code.

Add a new variable name entry for the ClientURL under the two predefined variable entries (all variables should be in lowercase regardless of how the managed property was defined):

Next, find and change all “$url” entries to “$clienturl”.

Find the “xsl:value-of select=”url”" entry within the hithighlightedproperties condition code (when statement). Change the “url” to “title”.

Locate the span class for srch-URL (span class=”srch-URL”). Within this section, locate the when condition for the hit highlighted properties as shown:

Replace the “hithighlightedproperties/HHUrl” with “clienturl”

Several lines down, replace the “url” in  “xsl:value-of select=”url”" with clienturl (xsl:value-of select=”clienturl”)

Click Save, Click OK on the web part tool pane and publish the page. The client search results should now show the custom client URL that is being returned from the BDC.

XSLT: Creating the Additional Reference Links within the Results

If you perform a Google search and you hit a website’s core address (such as Microsoft.com), there are additional reference links that appear within the search results:

You can add these to the MOSS Search results as well. The reference links can be displayed using standard HTML. This HTML should be placed after the “p class=”srch-Metadata” section (therefore after the p end-tag) :

The “ENTER THE HTML HERE” message will not appear - this was entered for demonstration purposes.

The following is sample code within a <div> block for rendering the additional link references. The appropriate URLs should be retrieved from the BDC and entered appropriately (the columns used here are generalurl, contacturl, documenturl, and referenceurl):

Blank rows or cells are placed for spacing purposes. Additional URL properties will require additional variable entries as entered above (e.g. xsl:variable name=”generalurl” select=”generalurl”)

Here is a sample output:

Conclusion

We’ve done many things with the MOSS Search capabilities but obviously there are many more features and functionality. If you would like to see other search topics covered please send them along to mann@rdacorp.com.

This article was posted on:

Customizing Search Series - Finally Customizing the Search Results

Bjorn, first tell me a bit about yourself? Who are you and why should people listen to what you say?

My name is Bjørn, and I’m a SharePointholic. I’ve been in IT since I can remember, but started my professional career in 1993. Since then I have worked on both the admin and developer side of the fence.

I set up my first SharePoint installation for my own company in 2001 and have since installed countless SharePoints, ranging from small fire-and-forget team sites to completely customized massive portals.

However, I didn’t really get into the SharePoint developer thing until WSS3 came out. I started writing webparts and stuff for WSS2 but never liked the development experience.

As to why people should listen, I have no idea. Perhaps because I am passionate about what I do and in addition passionate about writing about what I do. That passion means I put a lot of time and energy into continualy improving and learning.

People seem to appreciate what I write based on feedback and blog readership, and if they can learn something from it, thats even better.

What will the topic of the book?

The book will be focused on understanding the architecture of SharePoint from a user experience perspective. It will be a book for architects, developers, and designers who want to truly understand the architecture of SharePoint and how they can apply that to create great user experiences.

Will this be another CSS/master pages book then?

Ah, no, by all means, no. I make a clear distinction between experience and interface here. The user interface is just a small part of the experience. Other factors such as functionality of pages, content types, working with email on lists, and modifying the authoring experience are all part of the user experience. At the time of this writing I have written about one third of the content for the book and I have written less than two full paragraphs relating to design, css and master pages.

I make no attempt to teach people css or html, and there is no need to know any of that stuff to learn everything that is in the book.

Who will be the primary audience?

Everyone! Buy one for each of your friends, and two for yourself!

Jokes aside, the book is primarily for SharePoint developers who are familiar with the basics but want to learn more and go deeper into SharePoint architecture. You should know your master page theory, but you don’t need to know the CAML required to create a list from scratch. You will after you have read the book, though.

The secondary audience will be architects, developers, and designers who seek to better understand the options for enhancing the user experience and thus be a better resource for others who may not know all the nitti-gritty details of what is possible.

Ok, so tell me a bit more about the actual contents.

The book will be divided into three sections or parts. The first part will focus on getting the bare minimum of SharePoint knowledge down, such as basic feature design and CAML/XML basics. The second part is a deep dive into the core of SharePoint, going from the site itself down to inner workings of custom fields. Then, in the third section, we put all that knowledge into creating a new solution from bottom up.

I am also trying to focus on unique knowledge and stay away from what has already been written in other books. Of course, there will always be overlaps, but much of what I write I have yet to find described anywhere else.

Can you give some examples of unique content?

Sure! For example I have yet to find any books that explains the steps, or actually step singular, required to email enable a custom list. Anyone can click the ‘Email enable this list’ for a document library or several other list template types, but that does not work for custom list, or a number of other lists. In the book I explain how email enabling works down to reading the reflected source code of SharePoint, and then explain how to email enable custom lists using only a single line of code.

I also take the time to test every attribute and feature of definitions to verify the official documentation. Sadly there are many examples where the documentation is either lacking or even plain wrong. I make a note in the text every time I find something like this and document the findings by showing reflected source code as well examples.

How does the article series “Customizing the user experience” fit into all this?

The article series actually came first, I only started thinking about the book after I saw that I would never be able to fit everything I wanted into an online series.

The online series stands on its own, and you can learn plenty from just reading that and never read the book. If you do get the book, however, you fill find tons of more information on each topic. I have had to prioritize and cut content from the online series in order to remain sanely short.

If you compare the first part, which is the longest article I have written online, the book chapter for the same topic is about three times as long. The “Lists and list templates” part is almost ten times as long in the book because I can go deeper and cover more ground.

Why would this book be any different than other books on SharePoint?

I focus highly on also creating a great reading experience by trying to tell a story while explaining the technical details. When I start a new chapter I first create the story, which often has absolutely nothing to do with the contents of the chapter itself. For instance, chapter 7, which details lists, list forms, and views, the story revolves around a journey through a forest searching for a hidden monster that lives in a cave.

A monster?

Hehe, yeah, I’ve spoken to many a SharePoint developer who are trying to create views from scratch. It is quite often painful and many have ‘fallen’ to the beast, running out of the room while cursing SharePoint and the day Bill Gates was born.

Sounds more like a fairy tale than a SharePoint book

Perhaps, but there is very little direct story telling here. I use humor and other literary tools to hopefully make the reading a bit more enjoyable. I write the story first to set the mood and pace for different sections of the chapter. I realize that people will buy Tolkien books if they want to read stories, so 99% of the content is still pure technical skill building. The story is just as much a tool for me in writing a chapter as it will be for the reader. If it’s not fun for me to write it sure as heck won’t be any fun to read.

The message in chapter 7 is: “Don’t go into the cave unless you are prepared, and the weapons you choose are the knowledge you gain. ”

I was also thinking of having the chapter on fields and columns take the reader into the role of a private investigator in a murder mystery, complete with femme fatales and gunfights, trying to find out what killed the text field type. I figured a lot of the readers like RPGs so they might appreciate being part of the book rather than just observing. I still have to get that past my editor, though, he might not see the fun that I do.

Why do you write so much?

Heh, I love to write, but more importantly I want to participate in the community, be part of the experience in a manner of speaking. There’s a certain mentality in Norway called Jante that frowns upon anyone who stands out. I hate that mentality and hopefully by contributing to the community and showing what can be done if one participates I can inspire others to be more active as well. In the long run this means more people on the scene and by random chance alone at least some of them will be good and teach me something new

So you are not making any money off this?

Not directly, no. I do get royalties from the book, but not nearly the same as I would have made had I put the same amount of work into customer projects. However, demonstrating skill and being visible is a great way of getting attention, and I have noticed a rise in requests for my time.

Why did you choose to write for SharePoint Magazine?

It was just a stroke of luck I guess. I had an idea for my first article on runtime modification of components and had begun writing for my own blow when I happened to stumble across the then unlaunched SharePoint Magazine web site. I shot off an email to you and you accepted. It’s a lot easier to reach a wider audience when writing for a magazine than just in my own blog.

Now that the magazine has been up for a few months I see that the value to the community is much higher than I expected. The quality of the articles, the topics available, and the update frequency is spot on. I am really happy to be part of a great team of authors here.

Thank you Bjorn for taking the time to answer these questions. Do you have any final thoughts?

Yes, absolutely. If you are planning on participating in the community, do so. Take the first step, get a blog up, start writing. The SharePoint knowledge pool is growing worldwide but demand is growing even faster. Share your knowledge so everyone can benefit.

Oh, and I love my wife very much. I promised her I’d say that

If you want more information about the articles, the book or Bjorn, here’s how you will get that:
Bjorn’s articles on SharePoint Magazine
“Building the SharePoint User Experience”, book blog
Furuknap’s SharePoint Corner, Bjorn’s blog

This article was posted on:

SharePoint Magazine talks to Bjørn Furuknap about his upcoming book "Building the SharePoint User Experience"

How you measure the success of any SharePoint project is open to much debate. Your typical tangible metrics around how a particular project has performed in terms of Time, Money and Quality, are still the main areas are what most organisations focus on upon to gauge their ultimate success. This is irrespective of whether or not the true ‘measures of success’’ from a SharePoint deployment aren’t actually felt by the business until longer after the project team has been moved on to other things.

But with the introduction and importantly adoption of SharePoint into many organisations growing exponentially over since the release of MOSS 2007 last year, it brings with it a number of challenges to say the least. The delivery of Microsoft’s premier collaborative platform, SharePoint, will put under pressure one or more of these metrics during the project life cycle, as any novice or experienced SharePoint, traditional infrastructure or software project managers whom take on the management and delivery of these projects, will tell you.

Having spent the last 7 or so years leading successful bid teams to win and then go on to manage the deployments of SharePoint into large and small businesses, spread across several industry sectors, (and in some cases to help organisations ‘recover’ failed projects), this article looks at the reasons why SharePoint projects can and do go awry. And in an effort to educate readers through the sharing of knowledge and experience here in this article, it will highlight some areas for you to be aware of and plan for accordingly so that you increase your chances of a successful SharePoint project.

Why are SharePoint projects difficult to deliver?

There are many reasons why SharePoint related projects run into difficulty and like any other IT project, they fall under the following headlines well documented by others:

• Poor Scope Definition
• No inherent Project Culture within the business
• Poor Stakeholder Management
• Poor Project Governance
• Poor Project Management skills
• Weak Planning (for the project and beyond once it has been deployed)
• Lack of proper change and risk identification and management.

However, there are other reasons that organisations need to be aware of.

Reasons Specific to SharePoint Projects

Here are some of the main additional reasons why SharePoint projects fail to live up to expectations and in particular areas your organisation needs to be aware of and plan for accordingly to increase the likelihood of success of your SharePoint deployments:

Underestimating the Scope of the Project Deliverables

In particular for the medium to large organisations, they often fail to plan and budget properly for the enormity of the Project deliverables that feature in SharePoint deployments.

These are often in areas such as:

• Strategic and Operational impact business practices
• SharePoint Governance
• Project Team Resources and skills
• Planning and Design (in particular around those that demand re-branding of SharePoint interface)
• Infrastructure (to support both internal and collaborative working externally)
• Application Delivery, Build and Test (In particular for deployment with bespoke elements)
• Migration of content or documents from file shares, existing intranet(s) and other line of business applications, (databases, etc)
• Release & Change Management
• Launch Activity and User Adoption going forward
• IT Helpdesk and User support following Go-Live.

Business ‘Quick Wins’ to demonstrate value

More often than not, SharePoint is first introduced as a replacement Intranet. Fine, it will do that very well. But often businesses forgot to include in their planning, enhancements to the intranet that could give it the ‘wow’ factor when the business first starts to use it.

Such ‘Quick Wins’ can be relatively minor in effort, but tremendously valuable when try to gain momentum and secure support from the wider business that the adoption of SharePoint within the business is more than just an intranet replacement solution. They are more aligned to a different way of working for the business which should be one of the strategic objectives is much more than this and are key to business adoption.

Such ‘quick wins’ should be identified earlier on and planned into a release program following the launch of the initial project to ensure the deployment of SharePoint is a success not just at the beginning, but continues to be so as it is further utilised and deployed within the business.

Short term planning, long term pain

Forget to include long term planning and management of your SharePoint project at your peril!

Businesses often forget to include the long term planning within the initial phase at the beginning, especially around the underlying architecture to support potential changes in the future. Thus potentially needing to re-invest in significant infrastructure costs later on when for example you wish to introduce an extranet facility or include another business units’ content following a business buyout.

It is critical you consider those changes planned for the future now within the SharePoint underlying architecture & infrastructure. This will I guarantee save you money and pain later on!

Lack of SharePoint experience in your Project team

Do you use a one of your team members whom has never worked with SharePoint before? Or hire a SharePoint Developer or SharePoint Consultant on your project team, or perhaps both…?What about SharePoint Architect, Business Analysts, Web Designer or even an experienced SharePoint Project Manager?

For many larger projects ALL of these resources are needed and getting this wrong in terms of the mix of roles and experience of resources is one of the major reasons why projects will fail, as project planning around resourcing is badly managed and underestimated by the team at the beginning.

The product feature set is vast and all too often project teams are poorly equipped in terms of the relevant team members experience of the product core features, including the underlying infrastructure to support the larger implementations. It is critical you understand the challenges here and ensure you get the right resources on board and consider carefully whether or not to use a single developer/consultant resource hoping they will cover it all. The chances are they won’t, will struggle to meet deadlines, cause project overruns  and in the end it will cost you a lot more to make it right or worse you abandon a sound valuable strategic platform because of a poor initial experiences.

Lack of SharePoint Project Management Delivery experience

Often overlooked, but good solid experience of managing SharePoint related projects is worth its wait in gold. Often, IT departments and outside consultancy’s will assume its like every other Microsoft infrastructure related project, which it is not! Nor is it like any other traditional software related project either.

It is more like something in between, which is why it proves challenging for IT management and existing Project Managers in either camp to get their heads around the issues and challenges. This is both at the beginning in terms of planning, in the middle in terms of day to day management and towards the end when you are ready to go live and you have underestimated all the activities that need to happen to make it visible and importantly adopted by your users both from launch day and beyond.

Wrong Infrastructure and Poor Architecture

An area often overlooked, but be warned a little forethought here can save you a lot of money/effort. As the SharePoint product spans across both intranet, extranets and now public facing web sites, the right infrastructure supporting SharePoint users is crucial for successful delivery and operation.

The end to end design of a SharePoint technical architecture  will often need to touch on other technologies such as networks, firewalls, Proxy Servers, ISA servers, anti-virus software and database clustering to name but a few. In addition, capacity planning for your hardware is also important as quite often you will need to potentially plan for every 1MB of user storage, over 3mb (yes 3!) of storage space for your whole environment!!

Together with a relatively complicated, and costly licensing model from Microsoft, do your homework on this area before your commit your budgets and commence your project.

Customisation or Configuration?

I will describe ‘customisation’ is essentially an activity whereby a SharePoint developer deploys bespoke handwritten code within a SharePoint environment, whereas ‘configuration’ is the manipulation of existing “out of the box – (OOB)” features to meet your needs.

More often than not, many organisations will opt for the former as they don’t know the latter well enough and assume they have no choice, but this should be counselled against doing so without proper consideration of the impact and risks.

MOSS/WSS are very pervasive technologies and being able to support the environments both from launch to decommissioning/migration is key.  The MOSS/WSS feature set is huge, hence understanding what you can do out of the box with the product is difficult, if not impossible for one individual resource to know. But that doesn’t mean you should turn to custom development, more you need seek and if need be to bring in the right skills and experience of those that do understand how to get the most out of the platforms array of features, before you commit to development resourcing on the project.

Custom development definitely has its place however, but do not underestimate the effort it takes for even your best developers to come up to speed with the inner workings of SharePoint. Particular areas for your Training/R & D efforts are that of SharePoint branding, workflows and how you deploy your solutions, as the three main areas which crop up as being the more challenging than you perhaps expected or planned for.

Hence, having the experience to know when to use custom development is important because remember, you pay for your custom changes several times, not just the few days of developer time for a minor enhancement that doesn’t seem to be there out of the box. Namely you pay for the:

1. Initial bespoke code

2. Testing when service packs or ‘hot fixes’ come along that may break your bespoke code (could be several times in the life of the platform)

3. Finally, when you migrate to next version of SharePoint or new product, and the migration tools don’t like your bespoke work as its not supported.

So, do you really customise SharePoint or configure…? Will the customisation you are about to embark upon be really worth it to your business needs? Really think this through before you open up your SharePoint deployment with Visual Studio or SharePoint Designer. Quite often its easier and hence cheaper to modify the business process or to leave out the functionality altogether. On this latter point I have witnessed all too often a bespoke ‘function’ not available out of the box, be custom built at great expense, only for it to be rarely if at all used by the end user.

Poor Planning for User Adoption

There is little point in designing and deploying the ‘best’, most detailed SharePoint solution if from launch date, very few users can access it, those that can can’t seem to find information or use it very well and those that can’t access it that eventually do, don’t go on to then use it and nor reap the benefits of collaborative working.

Planning for ‘Launch and User Adoption’ and the results of this are key to the ‘perceived’ success of the project more so than just the usual time/quality/money metrics. It revolves around planning, stakeholder management and user awareness, be that in form of training or briefing them of the new ways in which to enhance and improve how they work and make their jobs easier.

Businesses should have a longer engagement plan of objectives, deliverables,budgets and milestones for enhancements to the solution following the initial launch. Such long term planning is often missed.

Conclusion

This article has highlighted many issues organisations deploying or are about to will come across and indeed, many organisations will face difficulties in some or all of the above, as a consequence of lack of experience, poor decision making or expectation management with the business sponsors.

So what do organisations do to avoid many of the issues raised in this article. Quite simple, if you can start small (don’t run before you can walk so to speak) do so and get to know the vast array of features and functions available out of the box with the platform. Do not let loose your developers on a project until you have fully explored the rich feature set provided out of the box and established that the end result is really worth it to the business when all costs (short and long term) associated with custom development are weighed up.

If you’re planning a large deployment however, plan, plan and plan some more, review your approach carefully and seek the knowledge and wisdom of others whom have done it before, know the pitfalls and have learnt the lessons before you commit your resources.

Finally, it’s worth considering getting specialist advice from the outset from those that have been there before and can help your organisation through this period of change and allow your users to reap the full benefits of using Microsoft’s SharePoint collaborative platform whilst allowing your to get on with doing what you do best. If you do go external for such resources, then ensure appropriate levels of knowledge transfer take place to your staff during ALL phases of the project and not just at the handover!

Andrew Walmsley

Director – WorkShares Limited © 2008

This article was posted on:

Successful SharePoint Projects, Myth or Reality?

When I started this series of articles, I knew it would be quite a few parts and ambitious in its way. But after reading some of the other great articles on SharePoint Magazine, such as Bjørn Furuknap’s first article on customising the user experience, I’m now feeling like I picked the easiest topic of all!

Seriously, Bjørn, part 1 of your series is the closest experience I can imagine to any man giving birth! I bet you feel relieved getting that one out of your system!

So, do I feel guilty that my subject matter is easier? Am I suffering nerdiness envy?

Hell, no! I’ll stick to my fantasy world of user acceptance testing with Homer Simpson any day!

Previously…

Given that there are big time gaps in getting these articles out, I’d just like to reiterate that this series is pitched at a very wide audience, so hard-core nerds will probably find it waffly and frustrating. But then again, most regular people find hard core nerds waffly and frustrating .

I have been writing this series from the point of view of a frustrated implementation developer/engineer who has to deal with a clueless business development manager and a difficult customer. This, of course, is completely unfamiliar territory for all implementation developer/engineers because none of you reading this would have ever experienced such a situation, right? … hehe

Part one of this series introduced some background and provided the requirements for the leave application/approval process for the Springfield nuclear power plant. Those requirements were:

Parts two to four were really the “slick presales demo” parts of this series where the world is promised to the client and, hence, expectations were completely off the planet. Thus, we started out nice and easy in part two and three, where we introduced InfoPath 2007 and went through the exercise of importing the existing Springfield MSWord based form. We then added some data entry controls and tidied up the formatting. In part four, we published this form to SharePoint itself.

All in all, the first four articles covered some pretty straightforward stuff. Now, however, the salesman has moved on and our intrepid engineer is starting to get into the pointy end of things. In part five we delved into the scary world of web services and InfoPath data connections so satisfy the requirement of automatic identification of the requestor. That was a bit of a jump, wasn’t it?

This time around, let’s take care of the “reduce data entry” requirement, and leverage some of InfoPath’s useful features to make our form smarter. For those who found article 5 a bit heavy, this one is actually quite a bit easier (but it’s just a brief lull before we get to coding!). At the end of part 5 I said I’d deal with how to automagically handle the employee number - but I have decided to take care of that a little later.

Preventing a rift in the space-time continuum

Yeah, I know I was using the Simpsons theme for this series, but today I am dropping in a dash of Heroes.

First up, we need to add some logic to the form so that it doesn’t submit crap (that’s the technical term for “invalid”) information. For example, we want to make sure that you cannot return to work on a date *before* you leave - unless you’re Hiro Nakamura, of course.

Generally, for the rest of us who cannot bend time, you do actually come back to work at some point *after* you leave, so let’s make the necessary changes to ensure that our form does not destroy the world in some space-time vortex.

Today we are interested in the three date/time fields as shown below.

If you recall in part three where we created the form controls, we gave them the meaningful names of CommenceDate, CompletionDate, ReturnDate.

For reference, at any time, you can review your field names easily by clicking the “Data Source” link in the InfoPath design pane as shown below.

So, we have these three date fields and the rules are:

• The completion date cannot be *before* the commencement date.
• The return to work date cannot be *before* the completion date.

When you think about what we are doing here, we are validating data to make sure that it matches our business rules. Fortunately for us, InfoPath has some nice capabilities here to assist. Even better, they called it “Data Validation”. So, let’s take a closer look…

• Select the “Completion Date” control, right click and choose “Data Validation”

You are presented with a fairly unexciting text box asking you to add a condition that determines whether the value entered is valid. Clicking the “Add…” button displays the dialog box to add a condition. It is quite common to have multiple conditions that need to be satisfied in order for the data entered to be considered valid.

In our case, we wish to ensure that the CompletionDate field cannot contain a value that is less than the CommenceDate field. Create this condition by specifying “less than” from the middle drop down box, and then picking the “CommenceDate” field for the third dropdown box.

Clicking OK and we have our completed validation condition!

One final OK and we are back at our form and ready to test this. Rather than publish the form to SharePoint now, we can make use of InfoPath’s “Preview” button on the toolbar and test it out. Below I have an example preview where Homer has been identified as per the previous post. Additionally, I have used the date picker to specify the commencement date (October 25 2008) of leave.

What do you now see on the Completion Date field? What’s with that red asterix? Maybe I should hover my mouse over it and take a look, eh?

Aww… How sweet! A tooltip that matches the description I gave for this data validation condition. Well, what do you know? I spelt data instead of date (don’t worry I’ll fix it up later).

So, let’s try and defy time, then. I will enter October 24th as my return date. Doesn’t seem vary happy does it?

But if I change the date to the 25th of October (therefore validating the rule we set up), InfoPath happily accepts the value.

That it? That was easy!

Yeah, it was very easy so what are you complaining about? Easy is good and there should be more of it!

We now need to do the same thing for the “Return to Work” form field. Essentially, we perform the very same steps and thankfully for the both of us, I am not going to smother you with screenshots. This is where you try it yourself and instead I will simply list the steps and one screenshot.

1. Right click the ReturnDate field and choose Data Validation
2. Add a new validation condition where the ReturnDate is less than the CompletionDate
3. Add a tooltip text “Return date cannot be before the completion date”
4. Click OK twice and test using the preview button

The published experience

Now that we have successfully tested the validation rules for the date fields, let’s publish the form to SharePoint and see what it all looks like. I followed the exact publishing steps that I outlined in part 4, so please refer to that article if you need a recap.

I navigated to the forms library as described in part 4 and created a new form.

I then deliberately entered bad data into the form and sure enough, the data validation rules picked up on the issue. Excellent - Waylon Smithers is very pleased!

Reviewing our progress…

So, since we are about to see off part 6, our Project Manager wants to get a status update on how the Springfield leave form project is progressing. So, after 6 articles, what have we achieved? To remind you, the requirements were:

Identification of Homer is now sorted, and we have taken steps both in the areas of reducing data entry and validating the dates (excluding days absent). So, we are tracking nicely and haven’t fallen behind schedule just yet .

Before we continue with addressing all of these requirements, we will have to take a bit of a detour as I explain below.

Too good to be true?

Here’s a little experiment for you to try. On the above form, published in its current form with deliberately invalid dates (highlighted in red), you will see a toolbar that has a “Save”, “Save As”, “Close” and “Print View” on it. I clicked the Save As button and was dutifully prompted for a filename. I called the form “Homer’s Test Form” as shown below and clicked Save

I then closed the form and checked out the form library on the http://radioactivenet site. What the…! It saved it! What’s the point of data validation if you can just save the form anyway?

The answer to that question, my friends, is there is a difference between saving a form and submitting a form. But you will have to wait for part 7 of this series for that riveting discussion!

Thanks for reading

Paul Culmsee

www.cleverworkarounds.com

www.sevensigma.com.au

This article was posted on:

A tribute to the humble leave form - part 6

ADF Overview

Since we understand the BDC to be a middle man between the user interface and some back-end system, we need some way of mapping how the back end system is structured.  This mapping can then be consumed from the various interfaces such as Web Parts and searching that we covered in the last article.  Since BDC is designed to pull data from virtually any relational database or SOAP-based Web Service, you’d correctly guess that the ADF must be flexible and generic in nature.  As mentioned already, the ADF is an XML file with a specific schema and its concept can be likened to a logical database diagram.  By logical, I mean that it does not have any vendor-specific features such as data types.  Keep in mind that it must also be flexible enough to connect to Web Services as well, so it can’t be too database-centric as well.

XML makes good sense for the definition as it is a declarative way to define the back-end in a generic way.  By being declarative, and not done programmatically through code, it helps ensure that we have a loosely-coupled design.  This is very important as front-ends and back-ends are likely to change, and we want to make sure the maintenance effort spent on this middle layer is minimized.  As we’ll see later, having it XML based also makes it easier to automatically generate this definition.

In Figure 1 below, you can see a conceptual overview of how the ADF is used.  The browser makes a regular request where BDC data is needed (e.g. a BDC Web Part, Search, etc.).  The MOSS web front end receives the request, and as part of its processing, hands the BDC request off to the Object Model. The Object Model (also known as the API or Application Programming Interface) gets the definition for this ADF from its catalog.  With the details on the ADF known, the Object Model requests the data from the database or Web Service.  The response is returned and then formatted as appropriate for delivery back to the browser.

Figure 1: Data flow overview with BDC

To best understand the ADF, it helps to have an understanding of some of the terminology used.  This will relate directly to structures found in the XML definition.  Those with a database background (and also those developers with knowledge of ADO.NET) should pick these concepts up right away.

Line of Business.  Line of business (or LOB) is just a term that refers to a back-end system.  As you’ll see shortly, a single ADF is comprised of one or more LOB instances.

Entity.  An entity works like a table.  The entity term is also used when designing a logical database diagram, and the concept is the same.

Method.  A method is how we request data (or query) from an entity.  For a database, it is usually a SQL select statement or stored procedure.  For a Web Service, it would be a Web Method.  Each entity supports multiple methods.

Parameter.  Parameters are the inputs and outputs to a method.  Each parameter has a name and a .NET data type (e.g. System.Int32 or System.String).

Filter Descriptor.  Filter descriptors provide an easy way for users to filter records (rows) found in an entity.  It is mostly commonly used with the Business Data List Web Part.  For example, you might want to allow users to quickly find a company by its name.

Association.  Associations are how relationships are represented.  For example, an Employee entity might have an association with a VacationRequest entity.  For a database, these are normally used on child tables that have a foreign key.

Action. Actions are used with entities and allow you to link to external applications or custom SharePoint pages for additional processing.  These are commonly used in write-back situations, and we will look closer at these in the final article in this series.

The ADF Schema

Now that you have a pretty good idea of what the ADF does and some of the vocabulary, let’s go ahead and examine the XML Schema for an ADF.  (Note: this is not intended to be a detailed discussion; for a deeper look, please consult the MOSS SDK (Software Development Kit) here: http://msdn.microsoft.com/en-us/library/ms563661.aspx.)  One of the screen shots from this SDK is very helpful in understanding the high-level hierarchy of the ADF.  You can see it here:

Figure 2: ADF Schema Overview

LobSystem is the root element in the ADF file.  It contains attributes to the required namespaces, specifies whether it is a Web Service or Database, and sets the Name of the ADF.

LobSystemInstance is where you define your connection in the ADF.  Even though the XML schema looks like it supports multiple connections, you can only have a single connection defined in your ADF.  Through Property child elements, you define the connection string to this data source.  Those with ADO.NET experience will quickly recognize this example below as a Windows-integrated login to a SQL Server.

Figure 3: LobSystemInstance

The details of authentication is a complex subject, and we’ll just cover the basics here.  When connecting, you have four options when it comes to authentication.

1) PassThrough.  PassThrough can be used to authenticate the user in one of two ways, using Windows credentials or database credentials. With Windows (shown in Figure 3 above), the client’s Windows credentials are forwarded to the back end system.  This can be used for both databases and Web Services.  The problem with this, however, is that unless you’re using Kerberos (or your Web Service/database server is on the same physical machine as your SharePoint web front end), this will fail.  This is due to Windows NT Lan Manager’s (NTLM) inablility to delegate.  With database credentials, you use a database-specific username and password to log in.  This can only be used against a database server, not a Web Service.

2) RevertToSelf. This means the credentials of the Application pool is used to authenticate the user.  This will solve the the delegation problem from above, but all users will effectively use the same login on the back end.

3) WindowsCredentials/RDBCredentials.  These are used in conjunction with Single Sign On (SSO).  In this model, the user’s credentials (either a Windows login or a database-specific login) for the external system are pulled from the SSO database.

4) Credentials.  This is only used if you are connecting to a Web Service and cannot use Windows authentication.

For more details on authentication, I recommend you start your reading here:  http://msdn.microsoft.com/en-us/library/ms566523.aspx.

Within LobSystemInstance, each entity for this connection is defined.  The entity itself is not very interesting as it just defines a friendly name by which users will reference it.  Within each entity, you define an identifier and methods.  An identifier is the primary key, or the column(s) from the entity that can be used to uniquely identify each row.  These are very important as they are used in a number of ways.  Often, these are ID columns, such as CustomerID as shown here.

Figure 4: Identifier

Also part of each entity are the methods.  These are really the heart of the ADF as it defines the actual data that will be pulled.  It is where you specify a select statement (e.g. select * from table), a stored procedure, or a Web Method if it’s a Web Service.  Since there may be multiple ways to query data from an entity, you can have multiple methods.  Here is a simple example with returning a few columns from a table named Customers.

Figure 5: Method

Within a method, you may want to define one or more ways in which this method can be filtered by users.  This is used within the BDC Web Parts.  For example, for the list of customers above, imagine your company has hundreds of them.  How will your users easily find the one they are looking for?  Start by asking yourself what are the common ways they might want to lookup a customer—perhaps by Name, by Region, or by a Contact Name.  If this makes sense then you understand FilterDescriptors.  Here is a simple look at two FilterDescriptor entries that have been made.  The Name attribute you see here defines the friendly name that users will work with, so make sure this name makes sense to them.

Figure 6: FilterDescriptor

Now that you understand filtering, let’s go back to methods for a bit.  In the ADF, there are different types of methods, and the three primary types we work with are Finder, SpecificFinder and IdEnumerator.  Finder methods are used when you want to return one or more rows from an entity.  For example, find all customers who are in the North America region.  SpecificFinder is used to find a single row and is used in conjunction with the Identifier mentioned above. For example, find me the one Customer that has CustomerID = 42.  IdEnumerator is used to return the identifier value for each row.  In code terms, this would look something like Select CustomerID from Customers.  The BDC uses this when crawling for Enterprise Search integration.  You will find each method type defined within a MethodInstance.

Let’s move on to Parameters.  Parameters allow you to describe the exact input and output for methods.  Input parameters (Direction = “In”) are used with Filter Descriptors.  There are different types of output parameters, but the most common are Return parameters (Direction = “Return”).  These are used to describe each column that is returned from a method.  For each parameter, you define the friendly name and its .NET-matching data type.  In Figure 7 below, we see the two parameters that are defined for our two FilterDescriptors above.  These are input parameters as shown here:

Figure 7: Parameter

Last but not least, let’s cover Associations.  We use Associations to define the actual relationships that exist in the external system.  BDC can directly work with one-to-one and one-to-many types of relationships.  When you define an Assocation, you define the SourceEntity (i.e., the parent or primary) and the DestinationEntity (i.e., the child or foreign).  You also must point to a method in the child entity that returns all the child rows based on a single parent row.  This method will usually “join” these two tables together.  In SQL terms, it would be something like

Select * from Orders
join Customers on Orders.CustomerID = Customers.CustomerID
where Orders.CustomerID = 42

Here is an example on how an Association is defined in the ADF:

Figure 8: Association

Creating ADFs

In the small snippets above, you can probably see that the XML syntax won’t likely roll off your fingertips.  It takes time and practice to get good at writing them.  These can be created in any text or XML editor, including Visual Studio.  If you will be using Visual Studio, I recommend you import the BDCMetaData.xsd schema file so at least you get IntelliSense.  You can follow the guidance on how to set this up from SharePoint MVP Andrew Connell here.

Fortunately, there are tools out there that can reverse engineer the database (or Web Service) and generate most if not all of the ADF file for you. Even if you only have to write one ADF, these tools may be worth it.  The three main ones available to you are

• BDC Definition Editor
• MOSS BDC Design Studio
• BDCMetaMan

BDC Definition Editor is free and comes from Microsoft.  You can install it after you install the MOSS SDK.  Sadly, with this tool, you get what you pay for.  It doesn’t generate Finder methods, crashes quite a lot, and requires you to install SQL Server 2005 Express (even if you have a full SQL Server instance installed).  It’s certainly better than nothing but not recommended for regular use.

MOSS BDC Design Studio is a commercial product from Simego.  The latest version 2.0 has a nice wizard interface when setting up each entity.  It can be used to generate ADFs on common databases like SQL Server and Oracle as well as Web Services. It is reasonably priced at $200 for a single license.

BDCMetaMan from Lightning Tools is the top-of-the-line and de-facto standard for generating ADFs.  It is well written and fully featured.  It is also the most expensive at $1200 per license but well worth it if you use it enough.

Loading the ADF into MOSS

Once your ADF file has been generated, it needs to be loaded into your SharePoint environment.  This is done through your Shared Services Provider (SSP).  To get there from Central Administration, click on your SSP name in the Quick Launch menu on the left, then click Import application definition in the Business Data Catalog section.  Loading it is as simple as browsing to the file and clicking the Import button.  When you upload the ADF, it will validate the XML file. It will then create entries in your SSP Database for each LobSystemInstance and Entity.

Once the ADF is loaded, you might want to take a look at its structure.  Just click on View applications from the main SSP screen, and then navigate down through your named ADF and into each entity.  With the exception of custom actions, everything else is read only, so you can’t really make any changes.

Setting Permissions

When you’re done poking around, you’ll probably want to set permissions on your new definition.  Permissions apply to these levels in the ADF hierarchy: LobSystem (the whole ADF), Entity, Method and MethodInstance.  This means you can secure at a high level such as each ADF, or very granularly such as each Method within an Entity.  Unfortunately, the administration GUI only lets you set permissions down to the Entity level, so this is the lowest level that most people work with. You can also set permissions at a higher level (even the whole BDC) and copy these down to lower levels.  When setting permissions, you have four permissions to choose from.  Each is introduced here:

• Edit.  This permission allows you to delete or add new ADFs into BDC.  You would grant this to those who would be uploading new ADFs into your SSP.
• Execute.  This allows you to execute Method Instances.  If you apply this permission at the entity level, it applies to all methods and method instances for this entity.
• Select in Clients.  This defines whether you can see the entity when configuring BDC Web Parts or adding a BDC column to a list.
• Set Permissions.  This allows you to change permissions for other users at the various levels as described in this section.

That said, the common approach is to give users both the Execute and Select in Clients permission for all entities that they will be working with.  As standard with SharePoint, you can assign permissions to Users or Groups.

With that, we bring this Part Two article to a close.  By now, you should have a solid understanding of how BDC works and how to create, load and secure your ADF entities.  In the next session, we’ll focus more on creating ADFs for Web Service systems.  From there, we’ll then move over to the UI and how to leverage the value that these ADF entries give you.

This article was posted on:

Everything You Need to Know about BDC: Part 2 of 8

There are a couple of reasons. Firstly I never thought of it and secondly no one asked me - at least not until fairly recently. As you probably know I was one of the MVPs who combined to write a book for Wrox (Real World SharePoint 2007) but that came about because another MVP had put the idea of such a book to Wrox and he’d then asked for volunteers to write a chapter each on something they felt happy about writing about. So I wrote the introduction!
After that I was asked a couple of times to comment on book submissions by other people so it finally got into my head that you didn’t actually have to wait to be asked but that you could think of a title and a set of chapters and then suggest such a book to a publisher. I didn’t of course.
Then I was asked a couple of times, but once it was a very general “please let us know if you have an idea for a book” and the other time it was an offer to be a co-author of a book about an aspect of SharePoint I didn’t know much about, so that didn’t seem in the end to be a particularly good idea either.
But then I was offered the Teach Yourself book and that not only was a ready-made subject area but one (WSS 3.0) I thought I knew enough about to be able to write a whole book about.

So you just started writing?

No actually my first reaction was to say that we were a bit late in the production cycle of the SharePoint v3 products so shouldn’t we put it off until v4 … but I was told (probably correctly as you may have noticed that books are now being written timed to come out up to six months after mine) that there still was a market for a good book.
So I decided that if the book is going to come out later than quite a lot of others, it had better include lots of things which weren’t available to those earlier writers. So it’s based on Service Pack 1 code; has an appendix on installing WSS 3.0 in Windows Server 2008 (moved later with the other appendices to the book’s web site); and includes things like Search Server 2008; the “Fantastic 40″ templates and various web parts and so on that weren’t available at the release of WSS 3.0.
Anyway I’m getting ahead of myself. Even if I had been invited to write the book, the first task I had was still to provide chapter titles so that they could have some hope that the book would both match the aims of the series and also be written. As the title is “in 24 Hours” that meant writing the titles of 24 chapters. I would imagine that about half of those have survived in the final book because it’s only when you are writing that you notice that you need more (usually you need more) space than one ca. 20 page chapter gives you so you need two or even three (and less often you notice that you don’t really have enough to talk about of any value to fill a full chapter so you maybe combine two into one).
After that set of chapter titles was approved, contracts were exchanged where I would hand over 6 chapters by date X; the next 6 by date Y etc. These were tough deadlines but I made them!

Tell us something about writing the book and what is in it.

Many SharePoint books are written by two or more people and I suspect that means that they are writing chapters at the same time and need to be aware of what the other person has written.
Because I was the sole author I was able to write the book entirely in the order it appears in the printed version. So it starts with an introduction chapter (completely different to the Wrox chapter I’d written a year earlier); goes on to install the product and then spends roughly a third of the book using that installation to go into basic usage and administration before closing that section of the book with a real-life example of how you would put together the bits and pieces the reader has learned so far.
I spent a lot of time thinking about which real-life solution I should pick and in the end decided that most people have at one time or another watched a TV show about a major crime investigation, so I’d use that. It means I don’t have to explain the background yet it gives the opportunity to use all kinds of lists and libraries and also have different sites and different access rights.
I’m quite happy with the result. It gives, I hope, a clear picture of the sort of things you need to think about when creating SharePoint sites for any kind of a customer or private requirement.
The next set of chapters is about the interaction of Office and WSS 3.0. There I’ve made a point of not assuming - as the Microsoft books often seem to do - that people will be using Office 2007 but also show the interaction with the equivalent Office 2003 products.
The only exception to that is Access 2007 (and not Access 2003) because I’d earlier noticed that although Microsoft expects people to use that for reports of SharePoint lists, nobody seems to have written about it much. So I have one chapter where I show how Access 2007 (and OneNote 2007 - something which also doesn’t seem to be covered elsewhere) work with WSS 3.0 but I also have a second chapter where I show how to create reports from both single WSS 3.0 lists (using a wizard) and from multi WSS 3.0 lists (NOT using a wizard!).
I have a couple of chapters on Search Server 2008 both installing and then using it on top of WSS 3.0. That includes how you can amend the standard WSS 3.0 search box so that it becomes a Search Server 2008 Advanced search box.
Then I have a couple of chapters on workflow. The first looks at the different kinds of workflows you can have in connection with the SharePoint v3 products before going on to specifically create a standard WSS 3.0 workflow and the second then looks in detail at a SharePoint Designer 2007 workflow.
I then have a couple of more SPD 2007 related chapters - one about creating DataView web parts and the next as part of a chapter on how the end-user and site (rather than system) administrator can make safety copies of his data. This includes backup/Restore information but before that mentions simpler methods such as “Save List as Template”.
Finally there are some chapters on using ready-made templates ; on using language packs and on using third-party web parts (both free and commercial).

It seems to cover a lot of ground. Is there anything you don’t write about?

There’s nothing in the book about developing own code. For that I recommend one of the many developer books out there.
This is a book about using what Microsoft provide - either in the product itself or in combination with other “free products” (Search Server 2008 Express; application templates; language packs, web parts) or with SharePoint Designer 2007 or Office 2003/2007.
The other thing you may have noticed above is that the SPD 2007 chapters don’t include a chapter on amending the look and feel of your site. I couldn’t do justification to that in a single chapter and there are any specialist books on SPD 2007 that people should read if they are planning to change the look of their site(s) so radically that they need advice on how to do it. Instead I concentrate if you like on the technical areas of SPD 2007 usage.

Your book is less than 500 pages long, how did you fit this breadth of content in it?

A: It all comes down to writing style and assumptions made about your readers. I assumed that my readers would prefer to be given introductions into the whole range of options for a WSS 3.0 installation rather than being spoon-fed a massive amount of detail on a limited range of subjects.
So, for instance, when I work through Lists and Libraries, I use in my examples only the few different field types I mostly use rather than going into details about every single field type. This means that the book retains its relevance to real life and keeps moving forward (and I hope retains the interest of its readers rather than boring them with too much detail - they can investigate the other field types by themselves later).
Another thing I try to do is to not over-complicate the examples so I don’t need to spend time explaining the aim of the example. This doesn’t mean that the examples aren’t representative of real-life needs but it does mean that for instance the Access reports I create are built using a couple of easily-understandable lists.

Is there anything you are particularly proud of in the book?

I’m actually proud of a part of a chapter that has been moved to the web site because it was regarded as being a bit beyond the scope of the book.
When you write about SPD 2007 Data View Web parts, it’s very easy to just show the sunny side and quickly knock off a web part where for instance a field is in red if sales are too low. So, while I have that show-off stuff too, when I wrote the chapter on Data View web parts I started off with a list of requirements that I thought a typical boss would demand.
As I started working through those requirements, everything went smoothly until I found that, using the user interface, it was impossible to solve one of them. Instead it would be necessary to write code.
Now what I could have done would have been to go back in the chapter and simply remove that requirement. Yet - and this is what I am proud of - despite a rapidly-approaching time-limit, I spent the next couple of days learning more than I wanted to about XSLT and XPath and finally with the help of a fellow SharePoint MVP found the exact code I needed to solve that requirement too.
So now people reading the book will first see a seemingly reasonable list of requirements; see how to solve most of them quickly and easily and yet will be aware that not everything that looks easy to solve is and that if they get a request from their boss they should build in an extra couple of days just in case.
The printed chapter in the final version satisfies most of the requirements (and ends with that warning!). The final requirement from the list of requirements is then covered in a page on the book’s web site that carries on where the written chapter leaves off.

Finally, Mike, the book title says “SharePoint 2007: Using Windows SharePoint Services 3.0″. Throughout this interview you’ve been talking about WSS 3.0. Should people using or planning to use MOSS 2007 not bother reading your book?

It IS a book about WSS 3.0 but at the same time I’ve always thought that anyone who will be using MOSS is well advised to learn about the basics by running WSS 3.0. I’ve thought that for many years so it’s nothing new that I’ve just put in to sell more copies of the book - I really do think that is the best approach. MOSS itself includes so much functionality it must be terribly difficult to learn SharePoint on a MOSS system - far better to start on WSS 3.0 and then work your way up.
So, yes, people new to the SharePoint products can certainly gain benefit from the book even if they later are involved with MOSS-based sites. As you know, virtually everything you can do in a WSS 3.0 system can be done in a MOSS system in just the same way, so there’s very little knowledge gained from reading the book that will be lost on moving to MOSS - mainly just the installation details in fact.
The other thing is that almost all the new (and possibly unique) content in the second half of the book both applies to MOSS and also might well be new to existing MOSS users. To take one example I’ve not mentioned before, the built-in Blog system is the same in both WSS 3.0 and MOSS 2007 and isn’t particularly good. So I’ve described in the book how to install and use the “Extended Blog Edition” which is part of the free Community SharePoint Kit.

This article was posted on:

SharePoint Magazine talks to Mike Walsh about his new book

We have three goals for this series:  1) Give you a strong understanding of what BDC is and how it works; 2) Ensure you recognize the value it brings organizations; 3) Provide you with the technical know-how to set it up and use its many features.

BDC Overview

As you already know, Microsoft Office SharePoint Server (MOSS) provides tremendous value as an intranet solution. One of the ways it excels is that it provides a single access point for the data assets in your organization. In many cases, these assets are stored in a Word doc, a PDF, an Excel workbook, etc.  In other words, it’s just a file. We call these sources unstructured data due to their flexibility in storing almost endless forms of information. It’s this flexibility that has made MS Office such a popular software suite. Users can work in a rich client application and then simply save the file, presumably into a document library.

This is where the power of MOSS as a document management system comes in. When coupled with an enterprise search engine, it’s even greater. Despite the unstructured nature of these files, users can go into their portal and by either a few navigation clicks or a quick search, they can find the answers they need. Having this centralized location for answers yields not only productive employees, but happy ones. It may seem that users have the best of both worlds: the flexibility of storing data the way they want, and the ability to publish it knowing that other users can find it.

But hang on, it’s not quite this easy. Sometimes, structure is necessary. Structure imposes rules and order. Do we really want to store all our customer orders in a single Excel sheet? Structure helps ensure we have valid, manageable, and most importantly, trusted data. For these structured data needs, IT professionals have relied on the tried and true relational database, and many vendors such as Oracle, IBM and Microsoft have made a bundle selling their flavor of SQL.

With these relational database management systems, information is locked in server-side databases. You usually work with the data through a separate application, perhaps a rich client or a web-based interface. These structured databases are the lifeblood for critical systems such as accounting, CRM (Customer Relationship Management), ERP (Enterprise Resource Planning), and a myriad of other line-of-business needs.

In fact, these solutions have become so popular and easy to build, they have sprung up all over the organization into what I like to call database sprawl. Typically, each of these systems is another data island, disconnected from the others. In many cases, information is duplicated across these systems, causing chaos where order was expected. From the user’s standpoint, they can be perceived as very inflexible and frustrating: Where is the data I need?  How do I log into that system?  Once I’m logged in, how do I access it?  By the time each question is answered, precious time is lost.  Or worse, we give up and make decisions based on no data at all.

This yields an interesting dichotomy in the way we store data. On one end, we have the unstructured nature of MS Office; on the other, we have the structure provided by the relational database. Interestingly, both can result in chaos. What you’ll be pleased to know is that MOSS can also bring some order to the database sprawl as well, and it does so in a very similar way.

With Business Data Catalog, part of MOSS Enterprise, we again get directed us back to the SharePoint interface to get access to our data. With BDC, this structured data can be exposed through Web Parts; it can be indexed and searched; it can be merged with data found in lists. With BDC connections to your back-end systems, we can find and consume both structured and unstructured data assets that exist in our organization. And we do this from one location, one interface.

Architectural Overview

A holistic view of what BDC can do and how it works is best depicted in Figure 1.

Figure 1: BDC Architecture

What you see along the top are the primary ways BDC can expose data from your back-end systems. Here is an overview of each of these from left to right:

1) BDC data can be surfaced using the many out-of-the-box Web Parts. This is the most common way and very easy for the users to search, filter and sort for information. You simply add one of the BDC Web Parts to any page, point it to one of the sources in the catalog and users are ready to go. All data is pulled in real-time using this approach.

2) SharePoint Lists allows you to merge data that lives in SharePoint along with data from a back-end system. For example, perhaps you have customer names stored within a list. From your CRM system, you would also like to see contact information for each customer. By adding a BDC field to your list, you can copy the corresponding data from your back-end system and store it within the list. Typically this matchup is done one-to-one. To ensure the copied data doesn’t get stale, users can refresh it on demand.

3) Search allows you to set up a content source and point it to an application in the BDC. SharePoint then goes through through BDC to crawl your structured data source and store the keywords in its index. Your search queries can now go across both structured and unstructured sources giving you a unified set of results.

4) User Profile Importer allows you to supplement attributes found in the User Profile store from external databases. This is important for many organizations as their Active Directory or LDAP directories are rarely populated with all user details. For example, how many IT administrators will actually fill in the birthday or skills attribute? Data like this is usually found in HR systems anyway.  Using BDC, these values can be pulled and matched up with the user, providing a complete set of accurate values.

5) With custom applications, you can avoid having to write another data layer for your new application. Instead of directly connecting to the system using ADO.NET or a Web Service, you can consume the data using the BDC Object Model. This gives you a more flexible, declarative style of talking to your back end.

With each of these approaches, you may have noticed that the concept is predominantly read-only in nature. This is similar to decision support systems.  That is, we usually use BDC to consume the data from these back end systems, but rarely write back to it. In the final article in this series, you’ll see how you can write to your back end system.

A Quick Look at BDC in Action

Let’s see how this works.  In this first example, we demonstrate the Business Data List Web Part (#1 from above).  This makes the finding and displaying of rows from a table very easy.  As you see here, we are finding all rows from the Customers table (perhaps from a CRM database) that contain the word “market” in the name.

Figure 2: Business Data List Web Part

In the second example, we see how users can search for both documents and BDC sources (#3 from above).  A search for Great Lakes has been issued, and we see both document and BDC Search Results listed together.  We’ll go into far more detail on these features and others as we get into other articles.

Figure 3: BDC Search Results

How Does BDC Work

Now that you have a better idea of what it can do, you’re probably wondering how does it work? As you can see, the BDC is a middle man between your interface and the back end. To provide this universal interface, it uses a database-like XML syntax that is called an Application Definition File or ADF. This ADF defines the connection, the entities (for a database, these are usually tables, views or stored procedures), how to filter, what associations (relationships) exist and what user-friendly names should be used. These names can even be localized in different languages. This ADF is intended to be a generic interface describing the dictionary of information available. Once these ADF files are stored within the catalog, the first four options above are available without having to write any code. Of course, security is an important consideration when we talk about exposing sensitive data, so we’ll see how the BDC addresses this concern in the next article.

For the actual back end, as you can see in Figure 1 above, this can be any ADO.NET accessible database with an OLEDB or ODBC driver.  This covers most every database from MS Access and SQL Server to Oracle and IBM DB2. The back-end can also be a specially-written SOAP-based Web service.  The BDC is configured within a Shared Services Provider (SSP) which allows you to take advantage of BDC technology within any Web Applications within your SharePoint Farm.

Series Outline

With that, that nearly brings us to a close for this first article. But before we let you go, here is an outline on how we are structuring this series.  To get the full value, you should go through these in order, but we’ll try to keep them discrete so that you can jump around and focus on the ones that are most important to you. Note: these may slightly change as we go through each of these.

Part 1
In this first part, as you have now read, the focus is be on the concepts, the value it can bring organizations, the architecture, and an overview of each article in the series.

Part 2
This article will introduce the Application Definition File. By the end, you’ll understand the role it plays, how it works, and have a high-level grasp of its schema.  We’ll also introduce tools that allow you to generate these XML files.  Securing ADFs will also be covered in this article.

Part 3
This article will cover how the Web Services can be used instead of a direct connection to a database.  It will look at the kind of Web methods you’ll need to write if you want to expose your systems to BDC this way.

Part 4
This will be a two-part article.  In first half, we’ll look at the out of the box Web Parts that BDC provides.  These is the most common way that this structured data is presented to users, so we’ll give it a solid overview.  The second half will cover how you can cache BDC data into SharePoint lists.  This will allow you to marry SharePoint data and BDC together into one consolidated view.

Part 5
This article will cover everything you need to know to to configure Enterprise Search to crawl BDC data.  We’ll cover content sources, scopes, and how to configure MOSS for both full and incremental crawls of your structured data.

Part 6
As mentioned above, BDC can supplement properties contained within User Profiles. This allows you to pull critical data elements from external ERP or HR systems and map them to out-of-the-box or custom User Profile properties.  This article will cover everything you need to know to get this working for you.

Part 7
This article will apply mostly to the developers out there and will cover the BDC Object Model.  You’ll see how custom Web Parts, application pages or other custom-built SharePoint applications can consume BDC database without your having to write another data layer.

Part 8
In the final article, we will cover Custom Actions how these can be used to safely write changes to the back-end database or Web Service.  While not used often, this may prove to be a practical way for users to maintain some of the data in these external systems.

This article was posted on:

Everything You Need to Know about BDC: Part 1 of 8

Custom Search Page Creation

The out-of-the-box Search Center actually contains both a Search Page and a Search Results page for All Sites and People. Therefore, to be consistent, we should also create a Search Page and Search Results Page for our new Clients scope.

First we will create the Search Page. Go to the Search Center site and select Create Page from the Site Actions menu:

On the Create Page screen enter Clients for the Title of the page and the URL name. Select the Search Page layout and then click on Create:

The new page will appear in Design mode. Edit the Search Box web part and enter “ClientResults.aspx” in the Target search results page URL setting (under Miscellaneous):

Click OK and Publish the page.

Creating the Search Results Page

The creation of the search results page is the same process. Go to the Search Center site and select Create Page from the Site Actions menu:

On the Create Page screen enter Client Results as the Title of the page and ClientResults for URL name. Select the Search Results Page layout and then click on Create:

The new page will appear in Design mode. Edit the Search Box web part and enter “ClientResults.aspx” in the Target search results page URL setting (under Miscellaneous):

Click OK and Publish the page.

Creating New Tabs

Go back to the main Search Center again and Edit the Page. Click on Add Tab near the top:

This will bring up a screen to add a new tab (for Search Pages). Enter Clients for the tab name and Clients.aspx as the page (remember this is for the search pages, the results are next):

Click Ok and publish the page.

Perform a search under the All Sites scope such that the results page appears. Edit this page and click on the Add New Tab towards the left of the screen:

This will bring up a screen to add a new tab again but this time it will be for the Search Results Pages. Enter Clients for the tab name and ClientResults.aspx as the page:

So now the Search Center should be loaded up with a Client Search Page, Client Search Results Page, and the appropriate tabs.

Updating the Client Scope

Now that we have the client results page created, we need to go back and update the scope such that any search within the client scope uses the proper results page. Therefore, back in Central Administration under the Search Settings, click on the View Scopes within the Scopes section:

On the next screen, select the Clients scope to bring up the scope properties and then click on the Change Scope Settings link:

This will bring up the Edit Scope screen. Simply change the Target Results Page setting to the “Specify a different page for searching this scope” and enter “ClientResults.aspx” within the Target results page box:

Click OK. The scope will need to be updated but that happens automatically.

What’s Next?

We are coming down the home-stretch. Everything is now set-up for the customization of the search results. The final article will go into details in how we can use the managed properties and the results XSL to generate customized search results within our clients scope.

This article was posted on:

Customizing Search Series - Creating the Custom Results Page

With Silverlight you can really light up your SharePoint user interfaces. It can be used in different SharePoint domains like web parts, application pages, navigation, content management, custom fields, editor parts, etc.

In this tutorial I’m going to explain how you can host a Silverlight 2 beta 2 application from within a SharePoint Web Part. The Web Part will pass the URL of the SharePoint site together with the name of the list for which the Silverlight application will show the data. The retrieval of the data will be done by the Silverlight application using the HttpWebRequest technique for calling the SharePoint web services. As the SharePoint web services return a chunk of XML the XML will be handled by using LINQ for XML. The data will be bound to the Silverlight controls.

When the Web Part loads the complete list of AdventureWorks products will be loaded. In the Topic box you can enter a part of a product number and click the Search button. Based on that search string a restricted list of products will be returned. You can select  a product from the list to view its details.